Re: [spring] A review of draft-ietf-spring-srv6-srh-compression-08

[Adrian Farrel <[e-mail]>]

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:[e-mail]> 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?