Hi Adrian, Best wishes to you too.
Many thanks again for your most valuable feedback and suggestions on this document. Cheers, Francois On Dec 30, 2023 at 17:24:26, Adrian Farrel <adr...@olddog.co.uk> wrote: > Hi Francois and best wishes for the New Year. > > Tl;dr This is good work. Thank you for the effort. > > Individual responses in line. > > Adrian > > Thank you for this follow-up. > > > Indeed, we were still working on some of your comments when revision -09 > > was pushed. Those remaining comments should now be addressed in revision > > -10 ( > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/10/ > ). > > > Please see our reply to each comment below. > > > Thanks, > > Francois (on behalf of the C-SID co-authors) > > > >>> 0. Please get into the habit of running idnits before posting a new > > >>> revision. > > >>> > > >>> == Missing Reference: 'RFC8200' is mentioned on line 996, but not > > >>> defined > > >> > > >> RFC 8200 is only mentioned in a quoted text from RFC 8754. We fixed > > >> the quote format in revision -09, so that idnits should no longer > complain > > >> about this. > > > > > > Hmmm. Idnits continues to object. > > > I don’t have a strong opinion, but inserting an Informative Reference > would clean it up. > > > We added a reference to RFC 8200 in revision -10 for another purpose, so > that nit > > should be gone for good this time. > > > Perfect > > >>> 13. Section 2 has: > > >>> > > >>> | A compressed Segment List encoding may also contain > > >>> | any number of uncompressed SID sequences. > > >>> > > >>> Yeah, and zero is any number. But I think you say this more > > >>> gracefully. > > >> > > >> This zero case was not intended to be covered by "any number" but > > >> by the use of the modal "may": "A compressed Segment List encoding > > >> **may** also contain \[...\]." That said, please let us know if you have > > >> any suggestion to improve this phrasing. > > > > > > Well, not sure. If you meant to exclude zero, then perhaps > > > | A compressed Segment List encoding contains one or more > > > | uncompressed SID sequences. > > > If you meant to allow zero, then > > > | A compressed Segment List encoding contains zero, one, or more > > > | uncompressed SID sequences. > > > We rephrased this in revision -10 per your suggestion. > > > | * Compressed segment list encoding: A segment list encoding that > | reduces the packet header length thanks to one or more C-SID > | sequences. A compressed segment list encoding also contains zero, > | one, or more uncompressed SID sequences. > > Nice > > >>> 16. Section 3 > > >>> > > >>> | When a sequence of consecutive SIDs in a Segment List shares a > common > > >>> | Locator-Block, a compressed Segment-List encoding can optimize the > > >>> | packet header length by avoiding the repetition of the Locator-Block > > >>> | and trailing bits with each individual SID. > > >>> > > >>> I think you are saying two separate things in this paragraph, but the > > >>> text is not very clear: > > >>> - a compressed Segment-List encoding can be used > > >>> - the act of compressing the Segment-List might reduce the packet > > >>> header length > > >> > > >> We rephrased this sentence in revision -09. > > >> > > >> | The compressed segment list encoding decreases the packet header > > >> | length by avoiding the repetition of the same Locator-Block and > > >> | reducing the use of padding bits. > > > > > > This is much better. > > > I think you are asserting that the compressed list always reduces the > > > packet header length, but (of course) there is an edge condition where > > > it makes no difference (compress one SID into a C-SID). > > > You're right. We adjusted the wording in revision -10 to state the intend > > rather the result. > > > | The compressed segment list encoding seeks to decrease the packet > | header length by avoiding the repetition of the same Locator-Block > | and reducing the use of padding bits. > > Good > > >>> 26. Section 4.1 > > >>> > > >>> | An SR segment endpoint node instantiating a SID with the NEXT-C-SID > > >>> | flavor MUST accept any argument value for that SID. > > >>> > > >>> It is clear that the endpoint knows the flavor of the SIDs it has > > >>> initiated, but it is not clear how the flavor of the SID is known > > >>> by anyone else in order that they can compress it or use an > > >>> argument value. > > >> > > >> The SID flavor is advertised in the control plane as part of the > "behavior" > > >> identifier (see RFC 9252, RFC 9352, https://www.iana.org/assignments/ > > >> segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors). > > > > > > If you believe this is clear then, that’s fine. Otherwise, just add a > few words. > > > We added some text at the beginning of section 6 in revision -10 to clarify > > this aspect. > > > | An SR source node may learn from a control plane protocol (see > | Section 8) or local configuration the SIDs that it can use in a > | segment list, along with their respective SR segment endpoint > | behavior, flavors, structure, and any other relevant attribute (e.g., > | the set of L3 adjacencies associated with an End.X SID). > > Looks good. > > >>> 40. Note that, per #39, there is a gnarly error condition. If a not > > >>> REPLACE-C-SID LNF finds its way into a C-SID sequence and it is not > > >>> at the end of the sequence, that is OK because the rest of the > > >>> sequence will be skipped, except... > > >>> > > >>> If the not-REPLACE-C-SID is in one C-SID container and there follows > > >>> another (continuation) C-SID container, then stuff will go badly > > >>> wrong! The packet will either be misrouted or dropped at the next > > >>> node. Dropping is not so bad, misrouting is embarrassing and to be > > >>> avoided. In both cases, network diagnostics are needed. > > >>> > > >>> In general, it may be argued that this is an encoding error. Whoever, > > >>> built the SID list made a mess. But there is the case where the node > > >>> that initiated the SID has made a mistake, and there may be a transit > > >>> case where a SID is moving between flavors. > > >> > > >> The problem that you describe can happen with any SRv6 SID. If the > > >> SR source node places an incorrect SID in the segment list, or if the > > >> SR segment endpoint node advertises something different than > > >> what it installed, then issues can happen. Classic network diagnostic > > >> tools like ping or traceroute can be used to troubleshoot such issues. > > > > > > I don’t want to make a big thing of this, and you are, of course, right > that > > > any SID list could be messed up with “interesting” results. > > > However, I think this document introduces another way to mix things up > > > because the SID list could be built correctly, but compressed > incorrectly. > > > I appreciate that ping and traceroute are good diagnostic tools, and they > > > can help isolate the point in the compressed SID list where the error is > > > found. > > > > > > Maybe it is not necessary to say any more, although I always like to call > > > out potential problems because they help people identify what they > > > should worry about in an implementation and deployment. > > > The compression is really a part of building the SRv6 packet. The source > > node is responsible for finding our the right SIDs to use, compressing > them, > > and generating the appropriate packet header. It may outsource the first > > operation (e.g., when the segment list is obtained via config, PCEP, or > BGP), > > but remains in charge of the last two and may mess them up. > > > Yes, that's the point I was trying to drive at. The SID list is built by > one component and it gets it right (or wrong in the way we are familiar > with). Another component is responsible for SID compression and could mess > that up in its own way. > > From an externally visible perspective, there is no difference whether the > > bug resides in the compression logic or in the header generation. The same > > erroneous packet can be produced with the same results in the network. > > > Right. If we treat everything as a black box, wrong is just wrong. > Again, this is not a biggie, but I just think that this document adds more > complexity (it's good complexity!) and so more opportunity for errors. > > >> 62. I had to read Section 8 a few times. > > >> > > >> The End.XPS is a new SID behavior defined in this document. While you > > >> then go on to define how it may be given a C-SID flavor, the End.XPS > > >> SID is not anything to do with compression: it is a new concept and I > > >> don't see why you have "hidden" it in this document. Indeed, it > > >> doesn't seem to be mentioned in the Implementation Status section or > > >> in the IANA section, so perhaps it is "ambitious" to include it in > > >> this document. > > >> > > >> While you say that the "End.XPS behavior described in this section is > > >> OPTIONAL" I think that is a bit confusing. It implies that the > > >> described processing is optional. I think you could use "The use of > > >> the End.XPS SID behavior is OPTIONAL." But you do go on to write... > > >> > > >> | This section defines an optional solution and SID behavior allowing > > >> | for the use of different Locator-Blocks between routing domains. > > >> > > >> So how do you handle the scenario described if you don't use this > > >> optional solution and an End.XPS SID behavior? > > > > > > You don’t seem to have answered this one (now Section 7). > > > Yes. We did not forget your question, but were still working on the text > > update for this section. > > > We reworked this section 7 in revision -10, making it more clear why the > > solution is useful and how it works. > > > If this solution is not available, the source node may need to use a > different > > C-SID sequence for each of the traversed domains, ending the previous > > sequence before the domain boundary and starting a new one for the next > > domain (this is also mentionned in the new text). > > > Section 7 in -10 is much better. Thanks. > > >>> 66. Section 9 > > >>> > > >>> | The SR segment endpoint node MUST set the SID argument bits to 0 > when > > >>> | advertising a locally instantiated SID of this document in the > > >>> | routing protocol (e.g., IS-IS [RFC9352], OSPF > > >>> | [I-D.ietf-lsr-ospfv3-srv6-extensions], or BGP-LS > > >>> | [I-D.ietf-idr-bgpls-srv6-ext]). > > >>> > > >>> b. What happens if a node receives an advertisement of a SID with one > > >>> of these flavors but does not support the advertised flavor? That > > >>> may be answered with a simple "handled as described in..." > > >> > > >> If a node does not support the SIDs of this document, then it won't > follow > > >> whatever this document says. It is not clear how adding text here could > help. > > > > > > It’s true, you can’t say anything normative about how an implementation > > > that does not support this specification must behave. > > > But you can add information for the reader to explain how this is > backward > > > compatible by noting (with reference) the expected behavior or a node > that > > > receives an advertisement of a SID with SID type that is unknown or > > > unsupported. > > > We added text following your suggestion at the end of section 8 in > revision -10 > > of the document. > > > | When a node that does not support this specification receives an > | advertisement of a SID of this document, it handles it as described > | in the corresponding control plane specification (e.g., Sections 7.2, > | 8.1, and 8.2 of [RFC9352], Sections 8, 9.1, and 9.2 of > | [I-D.ietf-lsr-ospfv3-srv6-extensions], and Section 3.1 of [RFC9252]). > > Nice > > >>> c. What happens if a node receives an advertisement of a SID with one > > >>> of these flavors but the argument bits are non-zero? The answer is > > >>> is not to be found in other documents because those documents don't > > >>> describe those flavors (but you might have "MUST treat the received > > >>> advertisement as malformed/unsupported and process it as described > > >>> in Section x.y of RFC abcd." > > >> > > >> This is described in section 6. For example, > > >> > > >> | A SID with the NEXT-C-SID flavor is compressible if its structure is > > >> | known to the SR source node and its Argument value is 0. > > >> > > >> In this case the source node would not compress the SID. > > > > > > Ah, interesting. So this would be a valid advertisement and a valid SID > that > > > can be used as a normal SID. It just can’t be compressed using the > > > mechanisms defined in this document. > > > This is correct. > > > OK. Clear. > > >>> 67. Section 9 > > >>> > > >>> | Signaling the SRv6 SID Structure is REQUIRED for all the SIDs > > >>> | introduced in this document. > > >>> > > >>> b. What does a receiver do if it gets an advertisement of one of a > > >>> SID with one of these SID flavors but without an indication of the > > >>> SRv6 SID Structure? Again, possibly, "MUST treat the received > > >>> advertisement as malformed/unsupported and process it as described > > >>> in Section x.y of RFC abcd." > > >> > > >> This is described in section 6 (see response to comment 66.c. above). > > > > > > And a similar response. You are saying that this is a valid > advertisement > > > of a SID that can be used as normal, but can’t be compressed using the > > > mechanisms defined in this document. > > > It wouldn't be a valid advertisement in the sense that the node advertising > > the SID did not follow the "REQUIRED", but the SID remains usable by the > > source node. > > > Let's not quibble about the meaning of "valid advertisement" or we will > get in a mess 😊 > The advertisement indicates a SID that can be used, so we're good. > > >>> 70. Section 9 > > >>> > > >>> For a segment list computed by a controller and signaled to an SR > > >>> source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy] > > >>> or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides > > >>> the ordered segment list comprising the uncompressed SIDs to the SR > > >>> source node. The SR source node may then compress the segment list > > >>> as described in Section 7. > > >>> > > >>> I asked a question in #53 about whether the compression could be done > > >>> by a controller. You seem to be saying that it cannot, but I don't see > > >>> why that is the case. Compression is non-trivial processing, and there > > >>> could be implementation benefits from placing it in a controller. > > >>> > > >>> However, it is possible that your thinking is that the source node > > >>> would like to hold an uncompressed SID list for diagnostic purposes. > > >>> > > >>> In any case, how does a source node process if it receives a SID list > > >>> that has already been compresses? In some cases, how would it even > > >>> know! > > >>> > > >>> Actually, there is an implicit architectural requirement here that > > >>> sets the control as determining the path as a SID list, but the source > > >>> node as responsible for listening to the SID advertisements to know > > >>> what flavors (and SID structures) have been advertised in order to > > >>> process the compression. Why do you force this separation? Why can't > > >>> the controller listen to all the advertisements? > > >> > > >> When a controller computes the segment list, it listens to all > > >> advertisements. It needs to know the meaning of each of the segments > > >> that it places in the segment list. > > > > > > I agree with this statement. > > > > > >> We rephrased this paragraph in revision -09 to clarify that the > controller > > >> passes the behavior/structure information to the source node along with > > >> each SID. > > >> > > >>| For a segment list computed by a controller and signaled to an SR > > >>| source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy] > > >>| or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides > > >>| the ordered segment list comprising the uncompressed SIDs, with their > > >>| respective behavior and structure, to the SR source node. The SR > > >>| source node may then compress the segment list as described in > > >>| Section 6. > > > > > > OK, this is clear, and reading the cited drafts indicates that the “SID > list” > > > they facilitate the controller providing is a list of SIDs and not the > SID list > > > that is placed in the SRH (without compression). > > > > > > I still think it is sad that there is no facility for the controller to > perform > > > compression (since it has the time and the CPU), but, well, I won’t force > > > the point. > > > We do not want to prevent a controller from performing compression in > > the future, but would like to limit the scope of this document to the case > > where the source node performs this operation. > > > >> 74. I wonder what the plans are for the draft referenced from Section 11 > > >> I-D.clad-spring-srv6-srh-compression-illus appears to have expired > > >> some long time ago and has only had nit changes since it was first > > >> posted in October 2021. Is the content even consistent with this draft > > >> which has constantly evolved over the last two years? > > >> > > >> Clearly, that draft is not normative and only supplies illustrations, > > >> but if it is deemed helpful to have illustrations, something needs to > > >> change. Alternatively, perhaps Section 11 should be cut. > > > > > > You didn’t answer this and I don’t see any change in the document. > > > Also, I see no progress on the referenced draft. > > > I think it is time to cut this section – this document stands on its own. > > > We removed this section and reference in revision -10. > > > Ack > > >>> 75. I think Section 12 could really use some more details. > > >>> For example: > > >>> - Do you expect deployments to restrict a single SR-domain to use at > > >>> most one flavor of C-SID? > > >>> - If not, it would be useful to have a section in the document > > >>> making a clear description of the processing when both flavors > > >>> are present. I think it "just works" but a little more text > > >>> describing how/why this is the case would help. And compare with > > >>> Section 4 where there is a recommendation to limit to a single > > >>> flavor in a single domain - certainly, the "ease of operation" > > >>> mentioned in that section deserves to be called out here. > > >>> - Do you make a distinction between SR-domain and AS/routing domain > > >>> as described in Section 8? > > >> > > >> We reworked the text in section 3 and 8 to clearly differentiate the SR > > >> domain (RFC 8402) and the routing domain. > > >> > > >> In section 4, > > >> > > >>| The SIDs of both flavors can co-exist in the same SR domain, on the > > >>| same SR segment endpoint node, and even in the same segment list. > > >>| However, it is RECOMMENDED, for ease of operation, that a single > > >>| compressed encoding flavor be used in a given routing domain. In a > > >>| multi-domain deployment, different flavors MAY be used in different > > >>| routing domains of the SR domain. > > >> > > >> In section 8 (section 7 in revision -09), > > >> > > >>| Some SRv6 traffic may need to cross multiple routing domains, such as > > >>| different Autonomous Systems (ASes) or different routing areas within > > >>| an SR domain. Different routing domains may use different addressing > > >>| schema and Locator-Blocks. > > > > > > These are good changes. But Section (now) 11 remains looking very thin. > > > If you are reluctant to add substance to the section maybe we should cut > it. > > > We merged this section into the security considerations in revision -10. > > > A good solution. > > >>> 76. You might add a note to the top of Section 13 to remind the RFC > > >>> Editor to clean up the many references from this section when it is > > >>> deleted. > > >> > > >> This sentence is an XML2RFC boilerplate (`<section > removeInRFC="true">`). > > >> Can it be edited? > > >> > > > You can write whatever you like in addition to the auto-generated text. > > > My suggestion is to add something like. > > > > > > RFC-Editor: Please clean up the references cited by this section before > publication. > > > We added this text in revision -10. > > > Fine. > > >> 77. I found Section 14 to be very sparse and so a little unbelievable. > > >> Surely Section 8 introduces some Security concerns? Should you > > >> have an Informative reference to draft-li-spring-srv6-security- > > >> consideration or some similar ongoing work to address the continued > > >> concerns about SR security. > > > > > > I don’t see an answer or any changes on this point. In order to get > through > > > today’s IESG, I think you are going to have to say more than is written > here. > > > > > > It is not a weakness to call out security vulnerabilities/concerns > because > > > it helps people know exactly what precautions to take when deploying. > > > Similar to #62 above, we were still working on the text update for this > section. > > > We reworked this section in revision -10. > > > This is better. Thanks. We'll see what the IESG does with it. > > >> 78. Is Section 15 (IANA) missing registration for End.XPS with and > > >> without flavors? > > > > > > I don’t see an answer or any changes on this point. Surely if the section > > > defining End.XPS is to remain in this document, there must also be > > > corresponding IANA work. > > > Fixed in revision -10. We will request the codepoint allocation from IANA > > and update the table as soon as we get that. > > > This looks right. > I was momentarily concerned that there is no request of vanilla End.PS and > End.XPS SIDs, but that is aligned with Sections 7.1 and 7.2. > > > 81. Hoping that Appendix A will be resolved > > > > > > Are these issues, in fact, resolved and just listed here for information? > > > If so, then I think it is time to remove the section or add a note that > the > > > issues have been resolved. If not, then we need a plan to resolve them! > > > This text indeed seems outdated. We will work with the chairs to figure > > out what to do with it. > > > The issues related to this draft are tracked on GitHub. > > > OK. I would certainly recommend having all existing issue in git hub > resolved and this section removed before passing the draft to the AD. > > >>> 82. I wonder whether you need some clarification in the document to > > >>> describe if you can have multiple C-SID flavors of the same SID > > >>> advertised and, if so, how a path selection node might decide which > > >>> flavor (including the non-CSID flavor) to use at any hop as it > > >>> builds the path. > > >> > > >> It seems generally better for a source node to select a C-SID flavor SID > > >> over an equivalent non-C-SID flavor SID, given that the former enables > > >> compression. > > > > > > That’s a good thing to say. Want to add it to the document? It’s either > plain > > > text, or a recommendation. And it is a very few words. > > > > > >> However, a choice between one C-SID flavor or the other is unlikely to > > >> present itself given the recommendation to avoid mixing C-SID flavors > > >> within a routing domain (section 4). > > > > > > Weeeeell, it is “only” a recommendation. And, indeed, the document > > > goes to some lengths (possibly to address the issue of “is this one or > > > two solutions presented in a single document?”) to show that you can > > > mix compression flavours in the same SID list. That means that > > > advertising both flavours of C-SID is both possible and acceptable. So > > > you can’t gloss over answering what happens when both flavours are > > > present: how do you choose? > > > We added some guidance on this aspect in section 6.2 in revision -10, > > although the general mechanism to come up with an uncompressed > > segment list remains out of scope. > > > | It is out of the scope of this document to describe the mechanism > | through which an uncompressed segment 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 segment list. For example, by selecting a C-SID > | flavor SID over an equivalent non-C-SID flavor SID or by consistently > | selecting SIDs of the same C-SID flavor within each routing domain. > > That helps. Thanks. > > > 83. It would be really good to include a section on future compatibility. > > > > > > a. What consideration should be given to future SID endpoint behaviors > > > in terms of making them compressible using the flavors here? > > > We added this new section in revision -10. > > > | 11. Applicability to other SR Segment Endpoint Behaviors > | > | Future documents may extend the applicability of the NEXT-C-SID and > | REPLACE-C-SID flavors to other SR segment endpoint behaviors. > | > | For an SR segment endpoint behavior that can be used before the last > | position of a segment list, a C-SID flavor is defined by reproducing > | the same logic as described in Section 4.1 and Section 4.2 of this > | document to determine the next segment in the segment list. > > Nice > > > b. Are there any comments the document should include about inventing > > > future C-SID flavors > > > No comment. :) > > > Well, section 11 says it all now, so good. > > > === END > > > > > > > On Nov 16, 2023 at 19:55:38, Adrian Farrel <mailto:adr...@olddog.co.uk> > wrote: > Hi again Francois, > > Thanks for your patience while I got back from Prague. > > I have looked through the diffs and respond in line below. > > This is good work, and captures very nearly everything. I snipped out > every point of agreement. > > Best, > Adrian > > > 0. Please get into the habit of running idnits before posting a new > > > revision. > > > > > > == Missing Reference: 'RFC8200' is mentioned on line 996, but not > > > defined > > > RFC 8200 is only mentioned in a quoted text from RFC 8754. We fixed > > the quote format in revision -09, so that idnits should no longer complain > > about this. > > > Hmmm. Idnits continues to object. > I don’t have a strong opinion, but inserting an Informative Reference > would clean it up. > > > 13. Section 2 has: > > > > > > | A compressed Segment List encoding may also contain > > > | any number of uncompressed SID sequences. > > > > > > Yeah, and zero is any number. But I think you say this more > > > gracefully. > > > This zero case was not intended to be covered by "any number" but > > by the use of the modal "may": "A compressed Segment List encoding > > **may** also contain \[...\]." That said, please let us know if you have > > any suggestion to improve this phrasing. > > > Well, not sure. If you meant to exclude zero, then perhaps > | A compressed Segment List encoding contains one or more > | uncompressed SID sequences. > If you meant to allow zero, then > | A compressed Segment List encoding contains zero, one, or more > | uncompressed SID sequences. > > > 16. Section 3 > > > > > > | When a sequence of consecutive SIDs in a Segment List shares a common > > > | Locator-Block, a compressed Segment-List encoding can optimize the > > > | packet header length by avoiding the repetition of the Locator-Block > > > | and trailing bits with each individual SID. > > > > > > I think you are saying two separate things in this paragraph, but the > > > text is not very clear: > > > - a compressed Segment-List encoding can be used > > > - the act of compressing the Segment-List might reduce the packet > > > header length > > > We rephrased this sentence in revision -09. > > > | The compressed segment list encoding decreases the packet header > > | length by avoiding the repetition of the same Locator-Block and > > | reducing the use of padding bits. > > > This is much better. > I think you are asserting that the compressed list always reduces the > packet header length, but (of course) there is an edge condition where it > makes no difference (compress one SID into a C-SID). > > > 26. Section 4.1 > > > > > > | An SR segment endpoint node instantiating a SID with the NEXT-C-SID > > > | flavor MUST accept any argument value for that SID. > > > > > > It is clear that the endpoint knows the flavor of the SIDs it has > > > initiated, but it is not clear how the flavor of the SID is known > > > by anyone else in order that they can compress it or use an > > > argument value. > > > The SID flavor is advertised in the control plane as part of the "behavior" > > identifier (see RFC 9252, RFC 9352, > https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors > ). > > > If you believe this is clear then, that’s fine. Otherwise, just add a few > words. > > > 40. Note that, per #39, there is a gnarly error condition. If a not > > > REPLACE-C-SID LNF finds its way into a C-SID sequence and it is not > > > at the end of the sequence, that is OK because the rest of the > > > sequence will be skipped, except... > > > > > > If the not-REPLACE-C-SID is in one C-SID container and there follows > > > another (continuation) C-SID container, then stuff will go badly > > > wrong! The packet will either be misrouted or dropped at the next > > > node. Dropping is not so bad, misrouting is embarrassing and to be > > > avoided. In both cases, network diagnostics are needed. > > > > > > In general, it may be argued that this is an encoding error. Whoever, > > > built the SID list made a mess. But there is the case where the node > > > that initiated the SID has made a mistake, and there may be a transit > > > case where a SID is moving between flavors. > > > The problem that you describe can happen with any SRv6 SID. If the > > SR source node places an incorrect SID in the segment list, or if the > > SR segment endpoint node advertises something different than > > what it installed, then issues can happen. Classic network diagnostic > > tools like ping or traceroute can be used to troubleshoot such issues. > > > I don’t want to make a big thing of this, and you are, of course, right > that any SID list could be messed up with “interesting” results. > However, I think this document introduces another way to mix things up > because the SID list could be built correctly, but compressed incorrectly. > I appreciate that ping and traceroute are good diagnostic tools, and they > can help isolate the point in the compressed SID list where the error is > found. > > Maybe it is not necessary to say any more, although I always like to call > out potential problems because they help people identify what they should > worry about in an implementation and deployment. > > 62. I had to read Section 8 a few times. > > > The End.XPS is a new SID behavior defined in this document. While you > > then go on to define how it may be given a C-SID flavor, the End.XPS > > SID is not anything to do with compression: it is a new concept and I > > don't see why you have "hidden" it in this document. Indeed, it > > doesn't seem to be mentioned in the Implementation Status section or > > in the IANA section, so perhaps it is "ambitious" to include it in > > this document. > > > While you say that the "End.XPS behavior described in this section is > > OPTIONAL" I think that is a bit confusing. It implies that the > > described processing is optional. I think you could use "The use of > > the End.XPS SID behavior is OPTIONAL." But you do go on to write... > > > | This section defines an optional solution and SID behavior allowing > > | for the use of different Locator-Blocks between routing domains. > > > So how do you handle the scenario described if you don't use this > > optional solution and an End.XPS SID behavior? > > > You don’t seem to have answered this one (now Section 7). > > > 66. Section 9 > > > > > > | The SR segment endpoint node MUST set the SID argument bits to 0 when > > > | advertising a locally instantiated SID of this document in the > > > | routing protocol (e.g., IS-IS [RFC9352], OSPF > > > | [I-D.ietf-lsr-ospfv3-srv6-extensions], or BGP-LS > > > | [I-D.ietf-idr-bgpls-srv6-ext]). > > > > b. What happens if a node receives an advertisement of a SID with one > > > of these flavors but does not support the advertised flavor? That > > > may be answered with a simple "handled as described in..." > > > If a node does not support the SIDs of this document, then it won't follow > > whatever this document says. It is not clear how adding text here could > help. > > > It’s true, you can’t say anything normative about how an implementation > that does not support this specification must behave. > But you can add information for the reader to explain how this is backward > compatible by noting (with reference) the expected behavior or a node that > receives an advertisement of a SID with SID type that is unknown or > unsupported. > > > c. What happens if a node receives an advertisement of a SID with one > > > of these flavors but the argument bits are non-zero? The answer is > > > is not to be found in other documents because those documents don't > > > describe those flavors (but you might have "MUST treat the received > > > advertisement as malformed/unsupported and process it as described > > > in Section x.y of RFC abcd." > > > This is described in section 6. For example, > > > | A SID with the NEXT-C-SID flavor is compressible if its structure is > > | known to the SR source node and its Argument value is 0. > > > In this case the source node would not compress the SID. > > > Ah, interesting. So this would be a valid advertisement and a valid SID > that can be used as a normal SID. It just can’t be compressed using the > mechanisms defined in this document. > > > 67. Section 9 > > > > > > | Signaling the SRv6 SID Structure is REQUIRED for all the SIDs > > > | introduced in this document. > > > > > > b. What does a receiver do if it gets an advertisement of one of a > > > SID with one of these SID flavors but without an indication of the > > > SRv6 SID Structure? Again, possibly, "MUST treat the received > > > advertisement as malformed/unsupported and process it as described > > > in Section x.y of RFC abcd." > > > This is described in section 6 (see response to comment 66.c. above). > > > And a similar response. You are saying that this is a valid advertisement > of a SID that can be used as normal, but can’t be compressed using the > mechanisms defined in this document. > > > 70. Section 9 > > > > > > For a segment list computed by a controller and signaled to an SR > > > source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy] > > > or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides > > > the ordered segment list comprising the uncompressed SIDs to the SR > > > source node. The SR source node may then compress the segment list > > > as described in Section 7. > > > > > > I asked a question in #53 about whether the compression could be done > > > by a controller. You seem to be saying that it cannot, but I don't see > > > why that is the case. Compression is non-trivial processing, and there > > > could be implementation benefits from placing it in a controller. > > > > > > However, it is possible that your thinking is that the source node > > > would like to hold an uncompressed SID list for diagnostic purposes. > > > > > > In any case, how does a source node process if it receives a SID list > > > that has already been compresses? In some cases, how would it even > > > know! > > > > > > Actually, there is an implicit architectural requirement here that > > > sets the control as determining the path as a SID list, but the source > > > node as responsible for listening to the SID advertisements to know > > > what flavors (and SID structures) have been advertised in order to > > > process the compression. Why do you force this separation? Why can't > > > the controller listen to all the advertisements? > > > When a controller computes the segment list, it listens to all > > advertisements. It needs to know the meaning of each of the segments > > that it places in the segment list. > > > I agree with this statement. > > We rephrased this paragraph in revision -09 to clarify that the controller > > passes the behavior/structure information to the source node along with > > each SID. > > > | For a segment list computed by a controller and signaled to an SR > > | source node (e.g., via BGP [I-D.ietf-idr-segment-routing-te-policy] > > | or PCEP [I-D.ietf-pce-segment-routing-ipv6]), the controller provides > > | the ordered segment list comprising the uncompressed SIDs, with their > > | respective behavior and structure, to the SR source node. The SR > > | source node may then compress the segment list as described in > > | Section 6. > > > OK, this is clear, and reading the cited drafts indicates that the “SID > list” they facilitate the controller providing is a list of SIDs and not > the SID list that is placed in the SRH (without compression). > > I still think it is sad that there is no facility for the controller to > perform compression (since it has the time and the CPU), but, well, I won’t > force the point. > > 74. I wonder what the plans are for the draft referenced from Section 11 > > I-D.clad-spring-srv6-srh-compression-illus appears to have expired > > some long time ago and has only had nit changes since it was first > > posted in October 2021. Is the content even consistent with this draft > > which has constantly evolved over the last two years? > > > Clearly, that draft is not normative and only supplies illustrations, > > but if it is deemed helpful to have illustrations, something needs to > > change. Alternatively, perhaps Section 11 should be cut. > > > You didn’t answer this and I don’t see any change in the document. > Also, I see no progress on the referenced draft. > I think it is time to cut this section – this document stands on its own. > > > 75. I think Section 12 could really use some more details. > > > For example: > > > - Do you expect deployments to restrict a single SR-domain to use at > > > most one flavor of C-SID? > > > - If not, it would be useful to have a section in the document > > > making a clear description of the processing when both flavors > > > are present. I think it "just works" but a little more text > > > describing how/why this is the case would help. And compare with > > > Section 4 where there is a recommendation to limit to a single > > > flavor in a single domain - certainly, the "ease of operation" > > > mentioned in that section deserves to be called out here. > > > - Do you make a distinction between SR-domain and AS/routing domain > > > as described in Section 8? > > > We reworked the text in section 3 and 8 to clearly differentiate the SR > > domain (RFC 8402) and the routing domain. > > > In section 4, > > > | The SIDs of both flavors can co-exist in the same SR domain, on the > > | same SR segment endpoint node, and even in the same segment list. > > | However, it is RECOMMENDED, for ease of operation, that a single > > | compressed encoding flavor be used in a given routing domain. In a > > | multi-domain deployment, different flavors MAY be used in different > > | routing domains of the SR domain. > > > In section 8 (section 7 in revision -09), > > > | Some SRv6 traffic may need to cross multiple routing domains, such as > > | different Autonomous Systems (ASes) or different routing areas within > > | an SR domain. Different routing domains may use different addressing > > | schema and Locator-Blocks. > > > These are good changes. But Section (now) 11 remains looking very thin. > If you are reluctant to add substance to the section maybe we should cut > it. > > > 76. You might add a note to the top of Section 13 to remind the RFC > > > Editor to clean up the many references from this section when it is > > > deleted. > > > This sentence is an XML2RFC boilerplate (`<section removeInRFC="true">`). > > Can it be edited? > > > You can write whatever you like in addition to the auto-generated text. > My suggestion is to add something like. > > RFC-Editor: Please clean up the references cited by this section before > publication. > > 77. I found Section 14 to be very sparse and so a little unbelievable. > > Surely Section 8 introduces some Security concerns? Should you > > have an Informative reference to draft-li-spring-srv6-security- > > consideration or some similar ongoing work to address the continued > > concerns about SR security. > > > I don’t see an answer or any changes on this point. In order to get > through today’s IESG, I think you are going to have to say more than is > written here. > > It is not a weakness to call out security vulnerabilities/concerns because > it helps people know exactly what precautions to take when deploying. > > 78. Is Section 15 (IANA) missing registration for End.XPS with and > > without flavors? > > > I don’t see an answer or any changes on this point. Surely if the section > defining End.XPS is to remain in this document, there must also been > corresponding IANA work. > > 81. Hoping that Appendix A will be resolved > > > Are these issues, in fact, resolved and just listed here for information? > If so, then I think it is time to remove the section or add a note that the > issues have been resolved. If not, then we need a plan to resolve them! > > > 82. I wonder whether you need some clarification in the document to > > > describe if you can have multiple C-SID flavors of the same SID > > > advertised and, if so, how a path selection node might decide which > > > flavor (including the non-CSID flavor) to use at any hop as it > > > builds the path. > > > It seems generally better for a source node to select a C-SID flavor SID > > over an equivalent non-C-SID flavor SID, given that the former enables > > compression. > > > That’s a good thing to say. Want to add it to the document? It’s either > plain text, or a recommendation. And it is a very few words. > > However, a choice between one C-SID flavor or the other is unlikely to > > present itself given the recommendation to avoid mixing C-SID flavors > > within a routing domain (section 4). > > > Weeeeell, it is “only” a recommendation. And, indeed, the document goes to > some lengths (possibly to address the issue of “is this one or two > solutions presented in a single document?”) to show that you can mix > compression flavours in the same SID list. That means that advertising both > flavours of C-SID is both possible and acceptable. So you can’t gloss over > answering what happens when both flavours are present: how do you choose? > > 83. It would be really good to include a section on future compatibility. > > > a. What consideration should be given to future SID endpoint behaviors > > in terms of making them compressible using the flavors here? > > > b. Are there any comments the document should include about inventing > > future C-SID flavors > > > Nothing for this? > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
