Just to close the loop on this... Thanks Francois for handling my comments!
Based on our offlist conversation, the following change was also agreed upon... OLD: > “As examples, it could be learnt via configuration or using a signaling > protocol." > NEW: > "As examples, it could be learnt via configuration or signaled by a > controller.” Thanks! Dhruv On Wed, Feb 14, 2024 at 2:23 PM Francois Clad <fclad.i...@gmail.com> wrote: > Hi Dhruv, > > Thank you for your support and suggestions. > > We have integrated those changes as part of revision -12 of the document. > Please find the detailed replies inline. > > Thanks, > Francois > > > ## Suggestions > > > > - A general reader might be tempted to know why two flavors exist? > Perhaps a few sentences in section 4 could be added. > > - An operator might be looking for guidance on when to use which flavor > and with which C-SID lengths. Perhaps these are things better suited in > proposed srv6ops, or is it possible to add some high level operational > guidance here? > > We added a paragraph towards the beginning of section 4 to explain this. > > | SRv6 is intended for use in networks of diverse sizes, requiring > | different SID numbering spaces. The two flavors introduced in this > | document come with their recommended C-SID lengths as specified in > | Section 4.1 and Section 4.2. Larger C-SID lengths may be more > | suitable for networks requiring ample SID numbering space, while > | smaller C-SID lengths are more suitable for compression efficiency. > | Thus, the two compression flavors allow the compressed segment list > | encoding to adapt to this diversity of requirements by supporting > | multiple compression levels. An operator can choose the flavor > | suitable for their use case, deployment design, and network scale. > > > - Section 11, is there any guidance to these future documents that is > worth adding? > > None. > > > ## Minor > > > > - Consider adding one sentence to introduce SRv6 in the abstract. > > We added this sentence to the abstract. > > | Segment Routing over IPv6 (SRv6) is the instantiation of Segment > | Routing (SR) on the IPv6 dataplane. > > > - Consider adding text that the term LOC is used for SID locator in RFC > 8986 alongside other terms. > > The abbreviation LOC is defined and used in RFC 8986 but not in this > document. > > > - Section 5, RESERVED is not a BCP14 keyword, perhaps reword to use > another BCP14 keyword if you need a normative framing! > > Changed to lowercase "reserved". > > > - Section 7, in Locator-Block B2/m, better to explicitly say what m is. > > We clarified the meaning of B2 and m as follows. > > | Each instance of an End.PS SID is associated with a target Locator- > | Block B2/m, where B2 is an IPv6 address prefix and m is the > | associated prefix length. > > > - Section 7.1, "it could be learnt via configuration or using a > signaling protocol", which signaling protocol are you thinking of? > > As mentioned in the previous sentence, this is outside the scope of the > document. > > > - Table 1, there are some TBA in the list, which seems incorrect as they > have assigned values in the registry already, please use the values instead > of TBA! Also consider adding all columns as per the registry that includes > Hex, change control as well. > > These TBA values were allocated recently. We have now added the allocated > values to the table. > > > ## Nits > > > > - Expand SRv6 in Title > > Fixed. > > > - Expand for following abbreviation > > - PSP > > - USP > > - USD > > Fixed. > > > - I find this style "The SPRING working group has observed that..." odd > and not suitable for standard track RFC. > > We rephrased the paragraph to remove this phrase. > > | Some SRv6 applications such as strict path traffic engineering may > | require long segment lists. Compressing the encoding of these long > | segment lists in the packet header can significantly reduce the > | header size. > > > - Section 7 title "Inter Routing Domains Compression" is unclear! > Perhaps "Compression in Multiple Routing Domains" or "Inter-Domain > Compression"? > > Changed to "Inter-Domain Compression". > > > On Feb 4, 2024 at 11:21:22, Dhruv Dhody <dhruv.i...@gmail.com> wrote: > >> Hi Joel, WG, >> >> I support this I-D and would like to see it published. I have a few >> suggestions that the authors and WG could consider. FWIW I did not review >> the pseudocode for correctness :) >> >> ## Suggestions >> >> - A general reader might be tempted to know why two flavors exist? >> Perhaps a few sentences in section 4 could be added. >> - An operator might be looking for guidance on when to use which flavor >> and with which C-SID lengths. Perhaps these are things better suited in >> proposed srv6ops, or is it possible to add some high level operational >> guidance here? >> - Section 11, is there any guidance to these future documents that is >> worth adding? >> >> ## Minor >> >> - Consider adding one sentence to introduce SRv6 in the abstract. >> - Consider adding text that the term LOC is used for SID locator in RFC >> 8986 alongside other terms. >> - Section 5, RESERVED is not a BCP14 keyword, perhaps reword to use >> another BCP14 keyword if you need a normative framing! >> - Section 7, in Locator-Block B2/m, better to explicitly say what m is. >> - Section 7.1, "it could be learnt via configuration or using a signaling >> protocol", which signaling protocol are you thinking of? >> - Table 1, there are some TBA in the list, which seems incorrect as they >> have assigned values in the registry already, please use the values instead >> of TBA! Also consider adding all columns as per the registry that includes >> Hex, change control as well. >> >> ## Nits >> >> - Expand SRv6 in Title >> - Expand for following abbreviation >> - PSP >> - USP >> - USD >> - I find this style "The SPRING working group has observed that..." odd >> and not suitable for standard track RFC. >> - Section 7 title "Inter Routing Domains Compression" is unclear! Perhaps >> "Compression in Multiple Routing Domains" or "Inter-Domain Compression"? >> >> Thanks! >> Dhruv >> >> On Mon, Jan 22, 2024 at 7:58 PM Joel Halpern <j...@joelhalpern.com> wrote: >> >>> (One of the other chairs pointed out that this had not gone to the >>> list. So forwarding the announcement.) >>> >>> This tarts the WG last call on the above document. >>> >>> Thank you, >>> >>> Joel >>> >>> >>> -------- Forwarded Message -------- >>> Subject: IETF WG state changed for >>> draft-ietf-spring-srv6-srh-compression >>> Resent-Date: Sun, 21 Jan 2024 11:25:02 -0800 (PST) >>> Resent-From: alias-boun...@ietf.org >>> Resent-To: bruno.decra...@orange.com, aretana.i...@gmail.com, >>> j...@joelhalpern.com, pengshup...@huawei.com >>> Date: Sun, 21 Jan 2024 11:25:02 -0800 >>> From: IETF Secretariat <ietf-secretariat-re...@ietf.org> >>> <ietf-secretariat-re...@ietf.org> >>> To: draft-ietf-spring-srv6-srh-compress...@ietf.org, >>> spring-cha...@ietf.org >>> >>> >>> The IETF WG state of draft-ietf-spring-srv6-srh-compression has been >>> changed >>> to "In WG Last Call" from "WG Document" by Joel Halpern: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ >>> >>> Comment: >>> This starts the WG last call for this document. Please comment with >>> support >>> or opposition, and explanation of your perspective. Silence is not >>> consent, >>> and just "support" or "oppose" is not helpful. This call will run through >>> the end of Feb 4, 2024. Yours, Joel Halpern - responsible Spring co-chair >>> >>> PS: I would appreciate a document shepherd from the WG for the bnext >>> step. Email me if you are willing. >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
