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
