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
