Hi John, Thanks again for your feedback.
We just pushed revision -23 with some more changes to address the remaining points of your review. These changes are listed inline below. https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/23/ Thanks, Francois On 6 Feb 2025 at 10:26:54, Francois Clad <fclad.i...@gmail.com> wrote: > Dear John, > > Many thanks for reviewing this document. > > I just pushed a -21 that should address your DISCUSS point (see inline > below). > > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/21/ > > We are also working on your remaining comments and hope to address them > later today. > > Thanks, > Francois > > On 5 Feb 2025 at 21:07:34, John Scudder via Datatracker <nore...@ietf.org> > wrote: > >> John Scudder has entered the following ballot position for >> draft-ietf-spring-srv6-srh-compression-20: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> ## DISCUSS >> >> I have a minor and easy-to-fix point I'm flagging as a DISCUSS to make >> sure >> it's not missed. >> >> ### Section 6.4, what's "NL"? >> >> ``` >> When receiving a SID advertisement for a REPLACE-CSID flavor SID with >> LNL=16, FL=0, AL=128-LBL-NL-FL, and the value of the Argument is all >> 0, the SR source node marks both the SID and its locator as using >> 16-bit compression. All other SIDs allocated from this locator with >> LNL=16, FL=16, AL=128-LBL-NL-FL, and the value of the Argument is all >> 0 are also marked as using 16-bit compression. When receiving a SID >> advertisement for a REPLACE-CSID flavor SID with LNFL=32, AL=128-LBL- >> NL-FL, and the value of the Argument is all 0, the SR source node >> marks both the SID and its locator as using 32-bit compression. >> ``` >> >> "NL" isn't defined anywhere in the document. I assume you meant "LNL". >> Please >> fix, or define "NL" if that isn't what you meant. >> >> Also (and this isn't DISCUSS-level, just noting here since it's in the >> same >> paragraph), is there some logic behind why you express the same thing two >> different ways within the same paragraph? Assuming you meant LNL, then is >> there >> some merit to writing AL=128-LBL-NL-FL instead of AL=128-LBL-LNFL? >> > > Thanks for catching this! We corrected the text in revision -21 to > "AL=128-LBL-LNFL”. > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> ## COMMENT >> >> ### Section 4.1, cite for "reduced SRH" >> >> The first time you mention "reduced SRH", please provide the appropriate >> citation, I believe it's RFC 8754 Section 4.1.1. >> > Indeed, we have now added this reference in revision -23. >> ### Section 4.1, inconsistent ordering makes me sad >> >> I find it odd that although "the elements in the SRH Segment List appear >> in >> reversed order of their processing" the elements in a NEXT-CSID container >> appear in forward order of processing, especially given that with >> REPLACE-CSID >> they appear in reversed order. >> >> Given that it's presumably too late to change this choice now, I don't >> really >> care what the reason was. However, I do think that given the asymmetry of >> the >> design, it would be a service to the reader to add a note to Section 4.1 >> pointing it out, along the lines of, "Note that although the elements in >> the >> SRH Segment List appear in reversed order of their processing, as >> specified in >> Section 4.1 of [RFC8754], the elements within a given CSID container >> appear in >> forward order." >> > We added a paragraph in Section 4.1 based on your suggestion. | Note that the CSIDs within a given CSID container appear in forward | order to leverage the longest-prefix match IP forwarding, while the | entries in the SRH Segment List appear in reversed order of their | processing, as specified in Section 4.1 of [RFC8754]. >> ### Section 6.2, opaque paragraph >> >> I found this paragraph to be unnecessarily opaque: >> >> ``` >> It is out of the scope of this document to describe the mechanism >> through which an uncompressed SID list is derived. As a general >> guidance for implementation or future specification, such a mechanism >> should aim to select the combination of SIDs that would result in the >> shortest compressed SID list. For example, by selecting a CSID >> flavor SID over an equivalent non-CSID flavor SID or by consistently >> selecting SIDs of the same CSID flavor within each routing domain. >> ``` >> >> As far as I can tell, what you mean is, "Some SID lists will be more >> compressible than others. We aren't going to tell you how to produce SID >> lists, >> but you should try to make them compressible, for example [...]". >> >> I'm not proposing that as actual replacement text since it's more >> informal than >> the rest of your document, but hopefully it gets the point across. >> > This document does not tell how to produce SID lists because compressibility is only one factor out of many in this equation. The SID list may need to minimize a metric, exclude some links, be disjoint from another one, etc. Instead, the document gives hints that a SID list calculation method should consider to make the SID list more compressible. We tried to clarify this point in revision -23. | It is out of the scope of this document to describe the mechanism | through which an uncompressed SID list is derived, since such | mechanism may include a wide range of considerations independent of | compression (e.g., minimizing a specific metric, excluding certain | links, or providing a loop-free fast-reroute path). As a general | guidance for implementation or future specification, such a mechanism | should aim to select the combination of SIDs that would result in the | shortest compressed SID list. For example, by selecting a CSID | flavor SID over an equivalent non-CSID flavor SID or by consistently | selecting SIDs of the same CSID flavor within each routing domain. >> ### Section 6.3, opaque rule >> >> When I consider these two rules: >> >> ``` >> 2. When the last Segment List entry (index 0) in the SRH is a NEXT- >> CSID container representing more than one segment, the PSP >> operation is performed at the segment preceding the first segment >> of this NEXT-CSID container in the segment list. If the PSP >> behavior should be performed at the penultimate segment along the >> path instead, the SR source node MUST NOT compress the ultimate >> SID of the SID list into a NEXT-CSID container. >> >> 3. If a Destination Options header would follow an SRH with a last >> Segment List entry being a NEXT-CSID container representing more >> than one segment, the SR source node MUST ensure that the PSP >> operation is not performed before the penultimate SR segment >> endpoint node along the path. >> ``` >> >> If I read them correctly, it would be possible to rewrite rule 3 in a more >> straightforward manner, e.g., >> >> 3. If a Destination Options header would follow an SRH with a last >> Segment List entry being a NEXT-CSID container representing more >> than one segment, the SR source node MUST NOT compress the ultimate >> SID of the SID list into a NEXT-CSID container. >> >> Is there any other way to obey the MUST in rule 3, other than by obeying >> the >> MUST NOT of rule 2? The rewrite exposes a bit of a logical contradiction >> between the "if" clause and the "then" clause, but at least it's clearer. >> I'd >> welcome a better fix, though. (Or a correction if I've misunderstood.) >> > There are (at least) two ways to meet this requirement. Either the last segment is not compressed or the "the segment preceding the first segment of this NEXT-CSID container in the segment list" does not have the PSP flavor. Given this, it may be best to state the requirement rather than mandate a specific solution, or solutions, that could preclude other ones from being used in the future. We clarified this PSP flavor condition in rule 2 as follows. | 2. When the last Segment List entry (index 0) in the SRH is a NEXT- | CSID container representing more than one segment and the segment | S preceding the first segment of this NEXT-CSID container in the | segment list has the PSP flavor, then the PSP operation is | performed at the SR segment endpoint node of S. If the PSP | behavior should instead be performed at the penultimate segment | along the path, then the SR source node MUST NOT compress the | ultimate SID of the SID list into a NEXT-CSID container. >> >> >>
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
