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

[Francois Clad <[e-mail]>]

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