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 <[email protected]> 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. > > ### 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." > > ### 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. > > ### 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.) > > > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
