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

[Adrian Farrel <[e-mail]>]

Francois,

 

Thank you for the highly positive response to my review. I know it can be harsh to receive large late-stage reviews, so it is particularly refreshing that you take this position.

 

It’s going to take me a short while to go through your responses, but Joel is chasing me, so I am likely to get to it soon [1]

 

Best,

Adrian

 

[1] https://datatracker.ietf.org/doc/draft-farrel-soon/ 

 

From: Francois Clad <[e-mail]> 
Sent: 11 November 2023 15:58
To: [e-mail]
Cc: SPRING WG List <[e-mail]>
Subject: Re: [spring] A review of draft-ietf-spring-srv6-srh-compression-08

 

Dear Adrian,

 

Thanks a lot for this outstanding review!

 

It definitely took us a while to go through your review, but your comments, questions, and suggestions helped us tremendously to improve this document.

 

We believe that the changes we made as part of revision -09 (https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/9/) should address most of your feedback.

 

Please also see inline below our response to each of your comments.

 

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.

 

> 1. Please expand "SRH" in the document name.

 

We changed the document name to "Compressed SRv6 Segment List Encoding" in revision -09.

 

> 2. Please expand "SR" in the Abstract.

 

Fixed in revision -09.

 

> 3. The Abstract and Introduction say "a compressed SRv6 Segment-List

>   encoding", but it seems that this document describes two such

>   encodings. Perhaps, "...which enable compression of the Segment List

>   in the Segment Routing Header (SRH)."

 

We updated the text in revision -09 as per your suggestion.

 

| This document specifies new flavors for the Segment Routing (SR)

| segment endpoint behaviors defined in RFC 8986, which enable the

| compression of an SRv6 segment list. Such compression significantly

| reduces the size of the SRv6 encapsulation needed to steer packets

| over long segment lists.

 

> 4. It would be nice if the Abstract gave a clue as to why the Segment

>   List needs to be compressed. For example, "to enable more entries in

>   the Segment List without causing excessive growth in the size of the

>   packet header."

 

We updated the text in revision -09 as per your suggestion (see response to 3. above).

 

> 5. Please decide whether "Segment List" or "Segment-List" or "segment

>   list" and fix it in the whole document.

 

We modified the text in revision -09 to consistently use the term "segment list". The only remaining occurrences of "Segment List" are those referring to the Segment List field of the SRH.

 

> 6. In the Introduction. s/segment identifier/Segment Identifier/

 

Fixed in revision -09.

 

> 7. Decide between "Segment Routing Header" and "Segment Routing header"

>   and fix the whole document.

 

Fixed in revision -09.

 

> 8. The motivation for this draft is indicated in the Introduction with

>   a reference to draft-srcompdt-spring-compression-requirement. A

>   few things:

>   a. This draft was replaced by draft-ietf-spring-compression-

>      requirement two years ago.

>   b. draft-ietf-spring-compression-requirement has expired and perhaps

>      the WG intends it to fade away now that this draft is close to

>      completion.

>   c. If you don't want to set out more details of the motivation in

>      this document (which would be fine) then I think the reference to

>      this draft needs to be normative - without reading it, I cannot

>      know why this work exists and whether I need to implement it. But,

>      considering #b, you might find it easier to add a few lines to

>      summarise the motivation and drop the reference.

 

We removed the reference to draft-srcompdt-spring-compression-requirement in revision -09 and replaced it with a short reminder of the rationale for compressing the segment list.

 

| The SPRING working group has observed that some use cases, such as

| strict path TE, may require long segment lists and that steering

| packets over such long segment lists using the SRv6 dataplane

| requires a large SRH.

 

> 9. Section 2 has...

> 

> |  This document leverages the terms defined in [RFC8402], [RFC8754],

> |  and [RFC8986].  The reader is assumed to be familiar with this

> |  terminology.

> |

> |  This document introduces the following new terms:

> |

> |  *  Locator-Block: The SRv6 SID block (IPv6 prefix allocated for SRv6

> |     SIDs by the operator) of an SRv6 SID Locator, as defined in

> |     Section 3.1 of [RFC8986].

> |

> |  *  Locator-Node: The identifier of the parent node instantiating a

> |     SID in an SRv6 SID Locator, as defined in Section 3.1 of

> |     [RFC8986].

> 

>   Well, this document doesn't introduce those terms as they are defined

>   in RFC 8986. And anyway, the initial paragraph assumes the reader is

>   familiar with Locator-Block and Locator-Node.

 

RFC 8986 defines the concepts, but not the terms. We clarified this in revision -09.

 

| *  Locator-Block: The most significant bits of a SID locator that

|    represent the SRv6 SID block. The Locator-Block is referred to as

|    "B" in Section 3.1 of [RFC8986].

| *  Locator-Node: The least significant bits of a SID locator that

|    identify the SR segment endpoint node instantiating the SID. The

|    Locator-Node is referred to as "N" in Section 3.1 of [RFC8986].

 

> 

> 10. It is unfortunate that you chose "Compressed-SID" and not

>    "Compressible-SID", or if you actually meant "Compressed-SID" then

>    the definition in Section 2 should say not that the SID supports

>    compressed encoding, but is a compressed encoding. But it can't be

>    used as a term both for a SID that could be compressed and (as in

>    the definition of C-SID container) an SID that is compressed.

 

We clarified the definition of a Compressed-SID in revision -09.

 

| *  Compressed-SID (C-SID): A compressed encoding of a SID. The C-SID

|    includes the Locator-Node and Function bits of the SID being

|    compressed.

 

> 11. Section 2 has:

> 

> |  *  C-SID sequence: A group of one or more consecutive segment list

> |     entries carrying the common Locator-Block and a series of C-SID

> |     containers.

> 

>   But surely, according to the definition of C-SID container, a group

>   of one segment list would be a single C-SID container, not a series.

 

We corrected the definition of a C-SID sequence in revision -09.

 

| *  C-SID sequence: A group of one or more consecutive segment list

|    entries carrying the common Locator-Block and at least one C-SID

|    container.

 

> 

> 12. Please choose "Compressed Segment List encoding" or "compressed

>   Segment List encoding" and fix the document accordingly.

 

Fixed in revision -09 to "compressed segment list encoding".

 

> 

> 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.

 

> 14. Section 3

> 

> |  In an SRv6 domain, the SIDs are allocated from a particular IPv6

> |  prefix: the Locator-Block.

> 

>   This appears to say that all SIDs in an SRv6 domain come from the

>   same Locator-Block. That isn't true according to the definition of SR

>   domain in 8402. So maybe you should write,

> 

> |  In an SRv6 domain, each SID is allocated from a particular IPv6

> |  prefix: the Locator-Block.

 

Thanks for the suggestion. We preferred to remove this sentence in revision -09 since it was unnecessary and, as you pointed out, confusing.

 

> 15. Section 3

> 

> |  When the combined length of the SRv6 SID Locator, Function, and

> |  Argument is smaller than 128 bits, the trailing bits are set to zero.

> 

>   Please say the trailing bits of what.

 

We rephrased this sentence in revision -09.

 

| In addition, when the combined length of the SRv6 SID Locator,

| Function, and Argument is smaller than 128 bits, the least

| significant bits of the SID are padded with zeros.

 

> 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.

 

> 17. Section 3

> 

> |  The compressed Segment List encoding is fully compliant with the

> |  specifications in [RFC8402], [RFC8754], and [RFC8986].

> 

>   Well, 8754 unwisely includes a copy of the definition of the SRH from

>   RFC 8200 saying...

> 

> |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> |   |                                                               |

> |   |            Segment List[0] (128-bit IPv6 address)             |

> |   |                                                               |

> |   |                                                               |

> |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 

>   ...and...

> 

> |  Segment List[0..n]:  128-bit IPv6 addresses representing the nth

> |     segment in the Segment List.  The Segment List is encoded starting

> |     from the last segment of the SR Policy.  That is, the first

> |     element of the Segment List (Segment List[0]) contains the last

> |     segment of the SR Policy, the second element contains the

> |     penultimate segment of the SR Policy, and so on.

> 

>   Of course, the 128 bit SRH SID list entry has long since stopped

>   being an IPv6 address, per se. And this draft places C-SID containers

>   into the SRH such that a "Segment List entry" of 128 bits may now be

>   all or just part of a C-SID container.

> 

>   What is more, you make changes to the SRH processing defined in RFC

>   8986.

> 

>   This just means that "fully compliant" is a stretch.

> 

>   Perhaps you simply don't need this sentence? Or perhaps you mean to

>   say that it doesn't change the processing of uncompressed SID

>   sequences.

 

We rephrased and clarified this sentence in revision -09.

 

| The compressed segment list encoding is fully compatible with and

| builds upon the mechanisms specified in [RFC8754] and [RFC8986].

 

> 18. Section 3

> 

> |  It is expected that compressed encoding flavors be available on

> |  devices with limited packet manipulation capabilities, such as legacy

> |  ASICs.

> 

>   An interesting statement. Who expects this? What would happen if it

>   wasn't true? Why bother saying it?

 

We removed this sentence in revision -09. It is indeed not needed.

 

> 19. Section 3

> 

> |  The compressed Segment List encoding supports any Locator-Block

> |  allocation.  While other options are supported and may provide higher

> |  efficiency, each routing domain can be allocated a /48 prefix from a

> |  global IPv6 block (see Section 6.2).

> 

>   a. There are two compressed encodings defined in this document, so

>      "The compressed Segment List encoding..." seems wrong.

 

The term "compressed encoding" refers to the compressed segment list being pushed onto the packet, and that combines the use of both flavors (see section 6).

 

>   b. What is the second sentence actually saying?

 

We clarified this sentence in revision -09.

 

| For example, each routing domain within the SR domain can be

| allocated a /48 Locator-Block from a global IPv6 block available to

| the operator, or from a prefix allocated to SRv6 SIDs as discussed

| in Section 5 of [I-D.ietf-6man-sids].

 

> 20. Section 4

> 

> |  This section defines several options to achieve compressed Segment

> |  List encoding in the form of two new flavors

> 

>   Several options? Or two options?

 

Two options. We rephrased this sentence in revision -09.

 

| This section defines two SR segment endpoint flavors, NEXT-C-SID and

| REPLACE-C-SID, for the End, End.X, End.T, End.B6.Encaps,

| End.B6.Encaps.Red, and End.BM behaviors of [RFC8986].

 

> 21. Section 4

> 

> |  two new flavors for the End, End.X,

> |  End.T, End.B6.Encaps, End.B6.Encaps.Red, and End.BM behaviors of

> |  [RFC8986]

> 

>   Unclear from this why NEXT-C-SID does not support End.DX and End.DT

>   while REPLACE-C-SID does.

 

We clarified in revision -09 that these SIDs are not defined because they are not useful.

 

| A counterpart NEXT-C-SID flavor is not defined for these SIDs

| because they can be included within a C-SID sequence that uses the

| NEXT-C-SID flavor without any modification of the procedure defined

| in [RFC8986].

 

> 22. Section 4

> 

> |  These flavors could also be combined with behaviors

> |  defined in other documents.

> 

>   I mean, yes, but, what?

 

We clarified this sentence in revision -09.

 

| Future documents may extend the applicability of the NEXT-C-SID and

| REPLACE-C-SID flavors to other SR segment endpoint behaviors.

 

> 23. Section 4

> 

> |  The compressed encoding can be achieved by leveraging any of these SR

> |  segment endpoint flavors.  The NEXT-C-SID flavor and the REPLACE-

> |  C-SID flavor expose the same high-level behavior in their use of the

> |  SID argument to determine the next segment to be processed, but they

> |  have different low-level characteristics that can make one more or

> |  less efficient than the other for a particular SRv6 deployment.

> 

>   a. This is the first mention of NEXT-C-SID and REPLACE-C-SID and

>      there is no way to understand this paragraph without reading the

>      rest of the document. I think you need some introductory text to

>      talk about the fact that the document:

>      - has two flavors

>      - the names of the two flavors

>      - some high-level distinguishing factors of the flavors

>      Then it would make sense to include this paragraph.

 

We added such an introductory text in revision -09.

 

| The NEXT-C-SID flavor and the REPLACE-C-SID flavor both leverage the

| SID Argument to determine the next segment to be processed, but

| employ different segment list compression schemes. With the NEXT-

| C-SID flavor, each C-SID container is a fully formed SRv6 SID with

| the common Locator-Block for all the C-SIDs in the C-SID container, a

| Locator-Node and Function that are those of the first C-SID, and an

| Argument carrying the subsequent C-SIDs. With the REPLACE-C-SID

| flavor, only the first element in a C-SID sequence is a fully formed

| SRv6 SID. It has the common Locator-Block for all the C-SIDs in the

| C-SID sequence, and a Locator-Node and Function that are those of the

| first C-SID. The remaining elements in the C-SID sequence are C-SID

| containers carrying the subsequent C-SIDs without the Locator-Block.

 

>   b. The second half of the paragraph appears to say that one or other

>      flavor may be a better choice depending on the nature of the SRv6

>      deployment. But I don't find any help in deciding which one I

>      should deploy in my network. Is that text that is missing (perhaps

>      from Section 12), or is it discussed in another document (in which

>      case, please give a reference). Of course, if implementations only

>      support one flavor, then my deployment choice is highly limited,

>      and if some of my implementations support only one flavor while

>      others support only the other flavor, then my deployment choice is

>      confused!

 

We removed the last sentence of this paragraph in revision -09.

 

> 24. Section 4

> 

> |  It is RECOMMENDED, for ease of operation, that a single compressed

> |  encoding flavor be used in a given SRv6 domain.  However, in a multi-

> |  domain deployment, different flavors can be used in different

> |  domains.

> 

>   a. s/can/MAY/

 

Fixed in revision -09.

 

>   b. What is an "SRv6 domain" in this context? Is it the same as an "SR

>      domain" from RFC 8402? If so, given the ambiguity of the

>      definition in 8402 (an SR domain contains all of the nodes

>      participating in the source-based routing model and most commonly

>      includes all of the protocol instances in a network, but can be

>      split into multiple SR domains) it would be really helpful to add

>      some clarity to this paragraph.

> 

>      In fact, your second sentence says the same as the first sentence!

> 

>      Of course, if you mean a different type of domain, then please

>      clarify.

 

We rephrased and clarified this paragraph in revision -09.

 

| 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.

 

>   c. "Ease of operation" hides quite a lot! Perhaps you would add a

>      note to say that both flavors can coexist within the same SR

>      domain.

 

We clarified this in revision -09 (see quoted paragraph in response to 24.b. above).

 

> 25. Section 4

> 

> |  *  Variable LBL is the Locator-Block length of the SID.

> |

> |  *  Variable LNFL is the sum of the Locator-Node and the Function

> |     lengths of the SID.  It is also referred to as C-SID length.

> |

> |  *  Variable AL is the Argument length of the SID.

> 

>   It would be helpful to set these variables in the context of RFC

>   8986. I think that 8986 calls LBL as L, LNFL as L+F, and AL as A.

 

RFC 8986 uses these variables for both the length of the component and its value, and redefines them in Sections 4.13, 4.14, 4.15. To avoid any confusion, we chose to define a different set of variables in this document.

 

> 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).

 

> 27. The Figure 1 caption is odd?

> 

> |  +------------------------------------------------------------------+

> |  |     Locator-Block      |Loc-Node|            Argument            |

> |  |                        |Function|                                |

> |  +------------------------------------------------------------------+

> |   <-------- LBL ---------> < LNFL > <------------- AL ------------->

> |

> |     Figure 1: Example of a NEXT-C-SID flavored SID structure using a

> |     48-bit Locator-Block, 16-bit combined Locator-Node and Function,

> |                           and 64-bit Argument

> 

>  I don't see anything in the figure that is:

>  - an example

>  - a indication that the LBL, LNFL, and AL are 48, 16, and 48

 

We clarified the figure caption in revision -09.

 

| Figure 1: Structure of a NEXT-C-SID flavor SID (scaled for a 48-bit

| Locator-Block, 16-bit combined Locator-Node and Function, and 64-bit

| Argument)

 

> 28. Section 4.1

> 

> |  A C-SID sequence using NEXT-C-SID comprises one or more C-SID

> |  containers, each carrying the common Locator-Block followed by a

> |  series of C-SIDs.

> 

>   I think that causes confusion. By saying "the common" you imply that

>   each container carries the same LB. Perhaps you could s/the common/a/

 

We clarified this text in revision -09.

 

| A C-SID sequence using the NEXT-C-SID flavor comprises one or more

| C-SID containers. Each C-SID container is a fully formed 128-bit SID.

| It carries a Locator-Block followed by a series of C-SIDs.

 

> 29. In general, Section 4.1 is hard to parse. It just takes a lot of

>   effort to learn:

> 

>   - A C-SID container is exactly 128 bits long (i.e., only one entry

>     on the SID stack)

>   - The maximum number of C-SIDs carried in a C-SID container is

>     (128-LBL)/LNFL

>   - The "current" SID is constructed as LB+LNF (well, perhaps we know

>     that, but you could still say so)

>   - The LNF of the "next" SID is the first lefthand LNFL bits of the

>     Argument

> 

>   It would be really nice if the text made these points rather than

>   leaving the reader to have to work them out.

> 

>   Indeed, it seems probable that some of the text in 4.1 is incorrect

>   although the description of a sequence of SIDs may be different from

>   their encoding in the SRH (or maybe not!). It is notable, I think,

>   that the SIDs in the SRH appear (left to right) as last to first

>   while the C-SIDs in the container appear (left to right) as first to

>   last. It would really help the reader to have this said clearly.

>   This reader assumed that the C-SID container sequence follows the

>   same order as the regular SIDs in the SRH.

> 

>   Oh, then I got to Section 6.1 which seems very, very, very important!

>   Should you move 6.1 up into 4.1 to sort out loads of other issues

>   that I've raised (e.g. parts of #37 and #38)?

> 

> |  When processing a SID with the NEXT-C-SID flavor, while the Argument

> |  value is non-zero, the SR segment endpoint node constructs the next

> |  SID by copying the SID Argument value immediately after the Locator-

> |  Block, thus overwriting the previous SID Locator-Node and Function,

> |  and filling the least significant bits of the argument with zeros.

> |  When the Argument value is 0, the SR segment endpoint node instead

> |  copies the next 128-bit Segment List entry from the SRH to the

> |  Destination Address field of the IPv6 header.  In both cases, the SR

> |  segment endpoint node then forwards the packet to the new

> |  destination.  The C-SID sequence ends with the last C-SID container.

> 

>   a. "When processing a SID with the NEXT-C-SID flavor"

>      You have not indicated how a processor would know it is doing

>      this. I think it knows because it originated the SID (i.e.,

>      advertised it or let the control know it could use it).

> 

>   b. "by copying the SID Argument value immediately after the Locator-

>       Block"

>      I think you are talking about the destination not the source as

>      well as the source, so you are missing an important "to" and

>      probably a useful "entire", although that is an implementation

>      detail, not a functional thing - that is, the required function

>      is:

>      - copy the first LNFL bits of the Argument into the LNF

>      - "shuffle left" the C-SIDs in the Argument so that the first

>        is replaced with the second, and so on, and the last is replaced

>        with zeros

>      It is probably OK to use the "copy the Arguments" approach so long

>      as it is made clear as:

>      "by copying the entire Argument value from the SID into the SID at

>       the point immediately after the Locator-Block"

>   c. "and filling the least significant bits of the argument with

>      zeros"

>      Well, how many bits shall I fill with zeros? The text is ambiguous

>      and the overwrite doesn't automatically cause the correct number of

>      bits to be filled with zeros.

>   d. The text is coy about the fact that the C-SID shuffle is taking

>      place in the DA field

 

We significantly rephrased the text of section 4.1 in revision -09 to address your comments. We also followed your suggestion of moving the text of 6.1 into this section.

 

https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-09#section-4.1

 

> 30. 4.1 ends with

> 

> |  The C-SID sequence ends with the last C-SID container.

> 

>  But isn't it the case that each C-SID container is independent? That

>  is, each C-SID container looks like Figure 1 and starts with an LB. In

>  that case, this sentence is meaningless.

 

We removed this sentence in revision -09 and added a note that each C-SID container is independent.

 

| Each C-SID container for NEXT-C-SID is independent, such that

| contiguous C-SID containers in a C-SID sequence can be considered as

| separate C-SID sequences.

 

> 31. In 4.1.1, etc., I really wish you hadn't numbered your new lines of

>   code using numbers that already exist in the code block into which

>   you are making an insertion. The complete code block in once case

>   will now read:

>   S01.

>   S01.

>   S02.

>   S03.

>   S04.

>   S05.

>   S06.

>   S07.

>   S08.

>   S09.

>   S02.

>   S03.

>   :

>   :

>   That is frankly ugly.

>   And in the other case

>   S01.

>   S02.

>   S03.

>   S04.

>   S05.

>   S06.

>   S07.

>   S08.

>   S09.

>   S01.

>   S02.

>   S03.

>   :

>   :

>   which is just messy.

>   Neither case matches what is in Appendix B.1

 

We changed the pseudocode line numbering in revision -09 to N01, N02, etc. for the NEXT-C-SID flavor and R01, R02, etc. for the REPLACE-C-SID flavor, and updated Appendix B accordingly.

 

> 32. 4.1.2

> 

> |  The resulting pseudocode is inserted between lines S01 and S02 of the

> |  SRH processing in Section 4.2 of [RFC8986], and a second time before

> |  line S01 of the upper-layer header processing in Section 4.1.1 of

> |  [RFC8986], or prior to processing any extension header other than

> |  Hop-by-Hop or Destination Option.

> 

>  I cannot parse your "or prior". You have "A, and B, or C." I also

>  cannot tell how I would choose to pick the "or" alternative.

 

We rephrased this sentence in revision -09.

 

| The resulting pseudocode is inserted between lines S01 and S02 of the

| SRH processing in Section 4.1 of [RFC8986] after applying the

| modification described in Section 4.2 of [RFC8986]. In addition,

| this pseudocode is executed before processing any extension header

| that is not an SRH, a Hop-by-Hop header or a Destination Option

| header, or before processing the upper-layer header, whichever comes

| first.

 

> 33. 4.1.3

> 

> |  The resulting pseudocode is inserted between lines S01 and S02 of the

> |  SRH processing in Section 4.3 of [RFC8986], and a second time before

> |  line S01 of the upper-layer header processing in Section 4.1.1 of

> |  [RFC8986], or prior to processing any extension header other than

> |  Hop-by-Hop or Destination Option.

> 

>  4.3 of 8986 does not have a line S01 or S02. One might deduce the

>  meaning related to 4.3's implied use of code from 4.1 (8986 doesn't

>  make an explicit reference), but it would be helpful to make it

>  clear.

> 

>  Same problem with "or prior" as in 4.1.2

 

We clarified the reference to lines S01 and S02 in revision -09.

 

| The resulting pseudocode is inserted between lines S01 and S02 of the

| SRH processing in Section 4.1 of [RFC8986] after applying the

| modification described in Section 4.3 of [RFC8986].

 

We also rephrased the text as we did in section 4.1.2 to clarify when the pseudocode should be applied.

 

> 34. 4.1.4 and 4.1.5 took a lot of work to understand that the DA field

>  with the half-processed C-SID container will be in place and ready to

>  continue when the encapsulation caused by the B6-Encaps SID is

>  stripped. Perhaps I am just not familiar enough with these SIDs, but

>  it wouldn't hurt to add words to explain the situation at the tunnel

>  end.

 

This operation is similar to that described in sections 4.13 and 4.14 of RFC 8986, but we nevertheless added a paragraph in revision -09 at the end of section 4.1.4 to clarify it.

 

| Similar to the base End.B6.Encaps SID defined in Section 4.13 of

| [RFC8986], the NEXT-C-SID flavor variant updates the Destination

| Address field of the inner IPv6 header to the next SID in the

| original segment list before encapsulating the packet with the

| segment list of SR Policy B. At the endpoint of SR Policy B, the

| encapsulation is removed and the inner packet is forwarded towards

| the exposed destination address, which already contains the next SID

| in the original segment list.

 

> 35. 4.1.7

> 

> |  USD: The USD flavor is unchanged when combined with the NEXT-C-SID

> |  flavor.  The pseudocodes defined in Section 4.1.1, Section 4.1.2, and

> |  Section 4.1.3 of this document are inserted at the beginning of the

> |  modified upper-layer header processing defined in Section 4.16.3 of

> |  [RFC8986] for End, End.X, and End.T, respectively.

> 

>  Doesn't the latter part of this paragraph actually say that the USD

>  flavor processing *is* changed from 8986?

> 

>  s/pseudocodes/pseudocode/

 

We separated the pseudocode in the previous sections from the upper-layer header processing in revision -09. The packet processing remains the same, but this simplifies the text as the NEXT-C-SID and USD flavors are now independent from each other.

 

| USD: The USP flavor defined in Section 4.16.3 of [RFC8986] is

| unchanged when combined with the NEXT-C-SID flavor.

 

> 36. Figure 2 has the same caption issue as Figure 1

 

We clarified the figure caption in revision -09.

 

| Figure 2: Structure of a REPLACE-C-SID flavor SID (scaled for a

| 48-bit Locator-Block, 32-bit combined Locator-Node and Function, and

| 48-bit Argument)

 

> 37. 4.2 uses an example as a definition. Thus...

> 

> |  Each container is a 128-bit segment list entry holding a series of

> |  C-SIDs without the Locator-Block, as shown in Figure 3.

> 

>  But Figure 3 is "only" an example, and is not definitive. I think the

>  example is fine, but definitive would look like...

> 

>   +------------------------------------------------------------------+

>   |  nth C-SID   |  ......... |   2nd C-SID  |   1st C-SID  |  zero  |

>   |   (posn 0)   |            |  (posn n-2)  |  (posn n-1)  |  pad   |

>   +------------------------------------------------------------------+

>    <--- LNFL --->              <--- LNFL ---> <--- LNFL --->

> 

>  This seems important because it will not always be the case that

>  LNFL divides into 128 perfectly, and we need to show which end carries

>  the padding. I see from the pseudocode in 4.2.1 that there is an

>  expectation that this series of C-SIDs can be read as an array which

>  would require it to be left justified with any padding on the right

>  hand end.

>  I do also see in 4.2.1...

> 

> | S25.     Set DA.Arg.Index to (128/LNFL - 1).

> 

>  ... which implies that it is required that LNFL *does* divide into 128

>  perfectly.

> 

>  Clearly some clarification is required.

 

We clarified this text in revision -09.

 

| A C-SID sequence using the REPLACE-C-SID flavor starts with a C-SID

| container in fully formed 128-bit SID format. The Locator-Block of

| this SID is the common Locator-Block for all the C-SIDs in the C-SID

| sequence, its Locator-Node and Function are those of the first C-SID,

| and its Argument carries the index of the current C-SID in the

| current C-SID container. The Argument value is initially 0. When

| more segments are present in the segment list, the C-SID sequence

| continues with one or more C-SID containers in packed format carrying

| the subsequent C-SIDs in the sequence. Each container in packed

| format is a 128-bit Segment List entry split into K "positions" of

| LNFL bits, where K is computed as floor(128/LNFL). If LNFL does not

| divide into 128 perfectly, a zero pad is added in the least

| significant bits of the C-SID container to fill the bits left over.

| The second C-SID in the C-SID sequence is encoded in the least

| significant bit position of the first C-SID container in packed

| format (position K-1), the third C-SID is encoded in position K-2,

| and so on.

 

> 38. I am pretty sure that I can read 4.2 to say that multiple C-SID

>  containers per Figure 3 can be present following an initial

>  LB-carrying C-SID container so that the whole might look like...

> 

>   +------------------------------------------------------------------+

>   |      Locator-Block      | Locator-Node |        Argument         |

>   |                         |  + Function  |                         |

>   +------------------------------------------------------------------+

>   |  nth C-SID   |  ......... |   2nd C-SID  |   1st C-SID  |  zero  |

>   +------------------------------------------------------------------+

>   |  mth C-SID   | ..... | n+2nd C-SID  | n+1st C-SID  |  zero       |

>   +------------------------------------------------------------------+

> 

>  Although I am not clear how the wrapping happens when the 128 bits is

>  not cleanly filled with C-SIDs.

> 

>  It would be really helpful to say all this clearly.

> 

Seems to me clear from this text

> "the SR segment endpoint node decrements the index value in the Argument of the active SID or, **if it is 0, instead decrements the Segments Left value in the SRH and sets the index value in the Argument of the active SID to K-1.**"

 

You are correct that multiple C-SID containers can follow the initial one. The reworked first paragraph of section 4.2 should make this more clear (see the response to comment 37. above).

 

> 39. There is a nice feature buried in 4.2 that says that a C-SID in the

>  C-SID container can be of not REPLACE-C-SID flavor without it being an

>  error and with processing working correctly. I can see how this would

>  be helpful. I wish that was called out more clearly.

> 

>  I think the same could be the case for NEXT-C-SID (that when you copy

>  across the AL you end up with a SID (LB+LNF) that is not a NEXT-C-SID

>  flavor. Presumably this is also allowed and also brings the C-SID

>  container processing to a stop.

> 

>  It seems that there is a requirement in both cases that a C-SID of

>  one flavor must not appear in a C-SID container of the other flavor

>  even as a "last SID" as described in 4.2. That seems an important

>  thing to say.

 

We clarified in revision -09 that the last C-SID in a C-SID container can be bound to any behavior and flavor(s), including the other C-SID flavor.

 

In section 4.1,

 

| The last C-SID in the C-SID sequence is not required to have the

| NEXT-C-SID flavor. It can be bound to any behavior and flavor(s),

| including the REPLACE-C-SID flavor, as long as it meets the

| conditions defined in Section 6.

 

In section 4.2,

 

| The last C-SID in the C-SID sequence is not required to have the

| REPLACE-C-SID flavor. It can be bound to any behavior and flavor(s),

| including the NEXT-C-SID flavor, as long as it meets the conditions

| defined in Section 6.

 

> 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.

 

> 41. Can I just say that in 4.2.2, "Replace S18 and S29 with S01" is

>  not as clear as it could be.

> 

>  4.2.3 is even a little unclearer as it replaces two lines with two

>  lines. But it intends to replace each of the instances of one line

>  with a pair of lines.

> 

>  And so on in 4.2.4

 

We clarified the pseudocode modification in section 4.2.2 through 4.2.6 in revision -09.

 

| The pseudocode in Section 4.2.1 of this document is modified by

| replacing line R10 and R21 as shown below.

|

| R10. Submit the packet to the IPv6 module for transmission to the

|        new destination via a member of J.

|

| R21. Submit the packet to the IPv6 module for transmission to the

|        new destination via a member of J.

 

> 42. 4.2.4 S04 could usefully say to what these fields are set.

 

We added a note in revision -09 saying to these fields should be set as defined in RFC 8986.

 

| Note: the variables A and B, as well as the values of the Payload

| Length, Traffic Class, Flow Label, Hop Limit, and Next Header are

| defined in Section 4.13 of [RFC8986].

 

> 43. There is an obvious imbalance between NEXT-C-SID and REPLACE-C-SID

>  wrt the End.DX and End.DT SIDs. If those types of SID must not be

>  given NEXT-C-SID flavor, then something needs to be said.

 

We clarified at the beginning of section 4 that these SIDs are not defined with the NEXT-C-SID flavor because they are not useful (see the response to comment 21. above).

 

> 44. 4.2.7 has

> 

> |  As per Section 6.4, when allocating a C-SID value from a Local

> |  Identifiers Block (LIB), an extra prefix of

> |  Locator_block:FunctionID::/LBL+FL is required on the Segment Endpoint

> |  node to support LIB matching in forwarding.  The new behaviors with

> |  REPLACE-C-SID flavor explicitly require the node to do so in SID

> |  initiation.

> 

>  I don't think 6.4 uses a MUST so there is no requirement.

 

We deleted this paragraph in revision -09, since it was redundant with section 6.4.

 

> 45. Could you begin Sections 5.1 and 5.2 with full sentences?

 

We rephrased the first sentence of section 5.1 and 5.2 in revision -09.

 

In section 5.1,

 

| A global C-SID is a C-SID allocated from the GIB.

 

In section 5.2,

 

| A local C-SID is a C-SID allocated from the LIB.

 

> 46. 5.1 has

> 

> |  A Global C-SID typically identifies a shortest path to a node in the

> |  SRv6 domain.  An IP route is advertised by the parent node to each of

> |  its global C-SIDs, under the associated Locator-Block.  The parent

> |  node executes a variant of the End behavior.

> |

> |  A node can have multiple global C-SIDs under the same Locator-Block

> |  (e.g., one per IGP flexible algorithm).  Multiple nodes may share the

> |  same global C-SID (anycast).

> 

>  a. "typically" leaves the reader wanting to know about other possible

>     cases.

> 

>  b. If a Global C-SID identifies a path, how come a route is advertised

>     to a global C-SID? What does that mean?

> 

>  c. Please decide "Global C-SID" or "global C-SID"

> 

>  d. "a variant of the End behavior" Which variant?

> 

>  e. "IGP flexible algorithm" needs a citation.

> 

>  f. Should "(anycast)" be "(for example, anycast)"?

 

We reworked this text in revision -09 to address your comments.

 

| A global C-SID identifies a segment defined at the Locator-Block

| level. The tuple (Locator-Block, C-SID) identifies the same segment

| across all nodes of the SR domain. A typical example is a prefix

| segment bound to the End behavior.

|

| A node can have multiple global C-SIDs under the same Locator-Block

| (e.g., one per IGP flexible algorithm ([RFC9350])). Multiple nodes

| may share the same global C-SID (e.g., anycast).

 

> 47. 5.2 has

> 

> |  A local C-SID may identify a cross-connect to a direct neighbor over

> |  a specific interface or a VPN context.

> 

>  a. "may identify" makes the reader wonder how to decide what it

>     identifies and what other choices exist.

> 

>  b. The term "a cross-connect" is peculiar when talking about packet

>     routers. Is this just "a connection"?

 

We reworked this text in revision -09.

 

| A local C-SID identifies a segment defined at the node level and

| within the scope of a particular Locator-Block. The tuple (Locator-

| Block, C-SID) identifies a different segment on each node of the SR

| domain. A typical example is a non-routed Adjacency segment bound to

| the End.X behavior.

 

> 48. Section 6.1 looks like it is really important and should be moved

>  to Section 4.1.

> 

>  There are two uses of RECOMMENDED in this section. You need to clarify

>  whether this is a recommendation to the implementer or the deployer:

>  if to the deployer, how do they control this and what are the

>  implications for the implementation? if to the implementer, what are

>  the implications for interoperability?

> 

>  And in any case, using RECOMMENDED is like using SHOULD. You need to

>  give an indication of what alternatives exist (that's easy) and how

>  and why the alternative might be chosen.

 

We moved this text to section 4.1 and 4.2 in revision -09, and reworked it to clarify the recommendation.

 

| An implementation SHOULD support a 32-bit Locator-Block length (LBL)

| and a 16-bit C-SID length (LNFL) for NEXT-C-SID flavor SIDs, and MAY

| support any other Locator-Block and C-SID length. A deployment

| SHOULD use a consistent Locator-Block length and C-SID length for all

| SIDs of the SR domain.

 

> 49. Section 6.2 has...

> 

> |  The RECOMMENDED Locator-Block sizes for the NEXT-C-SID flavor are 16,

> |  32, or 48 bits.  The smaller the block length, the higher the

> |  compression efficiency.

> |

> |  The RECOMMENDED Locator-Block size for the REPLACE-C-SID flavor can

> |  be 48, 56, 64, 72, or 80 bits, depending on the needs of the

> |  operator.

> 

>  For both cases of RECOMMENDED, you are allowing other LBL values, but

>  you are not giving any guidance about how/why another value would be

>  chosen.

> 

>  For REPLACE-C-SID you say "can be" which doesn't sit right with

>  "RECOMMENDED".

 

We also moved this text to section 4.1 and 4.2 in revision -09, and reworked it as shown in the response to comment 48. above.

 

> 50. Another use of RECOMMENDED in 6.3 that needs discussion of variation

>  of the suggested values.

 

We added a sentence in revision -09 saying that any other allocation is possible.

 

| Any other allocation is possible but may lead to a suboptimal use of

| the C-SID numbering space.

 

> 51. Section 6.4 has

> 

> |  An SR segment endpoint node instantiating a NEXT-C-SID or REPLACE-

> |  C-SID flavored SID SHOULD install the corresponding FIB entry to

> |  match only the Locator and Function parts of the SID (i.e., with a

> |  prefix length of LBL + LNL + FL).

> 

>  This "SHOULD" needs guidance on the alternative (MAY): what is it,

>  why might it be chosen.

> 

>  The MAY in the subsequent paragraph is good in that it gives a reason,

>  but I note that it is "in addition" which suggests that it might not

>  apply if the SHOULD in this paragraph is violated.

 

We added a sentence at the end of this paragraph in revision -09 to indicate the alternative.

 

| Any other mean of identifying a locally instantiated SID is possible

| as long as it is compliant with Section 4.3 of [RFC8754] and accepts

| all valid Argument values for the SID.

 

> 52. 7.1 and source node SID validation

> 

>  I'm glad to see this section, but I'm puzzled. Perhaps I am missing

>  something. When a SID is advertised or explicitly configured for use

>  by a source node, I think it just shows up as a 128-bit blob. Have I

>  missed something important?

> 

>  If, for example per draft-ietf-idr-segment-routing-te-policy section

>  2.4.4.2.2 the SID is presented without interpretation, I don't see

>  how the source node can verify the SIDs. How does it know the various

>  LBL, LNL and FL (things that are well known at the node that initiated

>  the SID)?

> 

>  Is there a requirement that the SID Structure TLV is used with the

>  advertisement? Indeed, this seems to be implied in the example in 7.2,

>  but you should call this out much higher up the document as an

>  absolute "requirement that the source node is able to determine the

>  structure of the SID, for example using the SID Structure TLV [ref]."

>  Oh, wow, I found this in Section 9. Well, I suppose the implementer

>  is supposed to read the whole document, but some more text or a cross-

>  reference would help.

 

The SID behavior, flavor(s), and structure are advertised in the control plane (e.g., RFC 9252, RFC 9352). If the SID behavior/flavor information is missing, then the SR source node treats this SID as a generic (non-C-SID) SID. It does not validate the SID and pushes it as is (uncompressed) onto the compressed segment list.

 

We added in revision -09 a reference to section 8 at the end of this section.

 

| Section 8 discusses how the SIDs of this document and their structure

| can be advertised to the SR source node through various control plane

| protocols.

 

> 53. In 7.2

> 

> |  An SR source node MAY compress a segment list when it includes NEXT-

> |  C-SID and/or REPLACE-C-SID flavor SIDs.

> 

>  I appreciate that compression is optional even when C-SID flavor SIDs

>  are in use. However, I think this sentence is too terse.

>  - How/why would a source node decide to compress a segment list?

>  - What does a source node do if it decides to not compress? (that's

>    easy to answer)

>  - Are there any implications in the network to the choice that the

>    source node makes?

>  - In the case where the segment list is provided by a third party

>    (e.g., by a controller), can it be supplied already compressed?

>    See the final paragraph in Section 9.

>  - The "and/or" here turns out to be very important. I think it is the

>    first hint in the document that both flavors can be present in the

>    same SID stack. It needs more discussion.

 

We added text in revision -09 to clarify the source node operation. In particular,

 

| An SR source node MAY compress a segment list when it includes NEXT-

| C-SID and/or REPLACE-C-SID flavor SIDs in order to reduce the packet

| header length.

|

| The segment list that the SR source node pushes onto the packet MUST

| comply with the rules in Section 6.3 and Section 6.4 and result in a

| path equivalent to the original segment list.

 

We also clarified in several places through the document, in particular in section 4, that NEXT-C-SID and REPLACE-C-SID flavor SIDs can be combined in the same segment list.

 

| 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.

 

> 54. 7.2 gives guidance of how to do compression by means of an example,

>  and I think that is OK. But there are a few lines that are contained

>  within the example that are, I think, normative.

> 

> |  A SID is

> |  eligible for compression with this method if *all* the following

> |  conditions are met.

> |

> |  *  The SID behavior has the NEXT-C-SID or the REPLACE-C-SID flavor.

> |

> |  *  The SID is advertised with a SID structure.

> |

> |  *  The SID argument value is 0.

> 

>  Thus:

>  - s/with this method//

>  - Move to an earlier section of the document

> 

 

The eligibility criteria is specific to the compression method described in this document. Another compression method could use a different set of criteria to determine if a SID can be compressed.

 

We integrated the eligibility check in the compression algorithm in revision -09 for better clarity.

 

| *  When the compression method encounters a series of one or more

|    consecutive compressible NEXT-C-SID flavor SIDs, it compresses the

|    series as follows. 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.

 

> 55. 7.2

> 

> |  When the compression method encounters a series of consecutive

> |  eligible NEXT-C-SID or REPLACE-C-SID flavored SIDs, it compresses the

> |  series as follows.

> 

>  You have to love the English language! The use of "or" here is

>  ambiguous because it implies that the series {NEXT-C-SID,

>  REPLACE-C-SID, NEXT-C-SID} is eligible for compression. Fix as...

> 

> |  When the compression method encounters a series of consecutive

> |  eligible NEXT-C-SID flavored SIDs or a series of consecutive

> |  REPLACE-C-SID flavored SIDs, it compresses the series as follows.

> 

>  Funnily, however, your example process does not require a series of

>  consecutive eligible C-SIDs, and will work in the case of precisely

>  one such C-SID. Recognising that, makes my question go away (although,

>  obviously, it results in no compression).

 

You are correct that the algorithm also works with a single C-SID. However, we merged this paragraph into the two bullets below in revision -09 for improved clarity.

 

| *  When the compression method encounters a series of one or more

|    consecutive compressible NEXT-C-SID flavor SIDs [...]

|

| *  When the compression method encounters a series of REPLACE-C-SID

|    flavor SIDs [...]

 

> 56. 7.2

> 

> |  S01. Initialize a C-SID container as the first segment in the

> |         uncompressed segment list, with all argument bits set to 0,

> |         and initialize the remaining capacity to AL

> 

>  Could this usefully say how to initialize the LB and LNF fields in

>  the first segment in the segment list? What does it mean to refer to

>  "as the first segment in the uncompressed segment list"?

> 

>  Is the resolution to my two questions s/as/equal to/  ?

> 

>  On the other hand, it seems extreme to explicitly say that the

>  argument bits are set to 0 because of the constraint you have already

>  stated as:

> 

> |  *  The SID argument value is 0.

 

That's a good point, thanks! We simplified line S01 in revision -09 as follows.

 

| S01. Initialize a C-SID container equal to the first SID in the

|        series, and initialize the remaining capacity of the C-SID

|        container to the AL of that SID

 

> 57. The description of the process in 7.2 for REPLACE-C-SID seems to be

>  incomplete. It says...

> 

> |  *  For a series of REPLACE-C-SID flavor SIDs of the same C-SID length

> |     in the uncompressed segment list, the first segment is not

> |     compressed.  The SR source node then initializes an empty C-SID

> |     container with all bits set to 0 and inserts consecutive C-SIDs

> |     from the uncompressed segment list into the container.  When the

> |     container is full, it is pushed on the compressed segment list and

> |     a new container is initialized.

> 

>  This doesn't handle the case of the end of the sequence when:

>    - if the C-SID container is empty, it is not pushed

>    - the (not empty) not full C-SID container is pushed.

 

We detailed the compression process for a sequence of REPLACE-C-SID flavor SIDs in revision -09.

 

| *  When the compression method encounters a series of REPLACE-C-SID

|    flavor SIDs of the same C-SID length in the uncompressed segment

|    list, it compresses the series as per the following high-level

|    pseudo code. A compression checking function ComCheck(F, S) is

|    defined to check if two SIDs F and S share the same SID structure

|    and Locator-Block value, and if S has either no Argument or an

|    Argument with value 0. If the check passes, then ComCheck(F,S)

|    returns true.

|

| S01. Initialize the first C-SID container in full SID format equal to

|        the first SID in the series

| S02. Initialize the second C-SID container in packed format if there

|        are more than one SIDs, and initialize the remaining capacity

|        of the C-SID container to 128 bits

| S03. For each subsequent SID in the uncompressed segment list {

| S04.   Set S to the current SID in the uncompressed segment list

| S05.   If ComCheck(First SID, S) {

| S06.     If the LNFL of S is lower than or equal to

|            the remaining capacity of the C-SID container {

| S07.       Copy the Locator-Node and Function of S to the least

|              significant remaining bits of the C-SID container

|              and decrement the remaining capacity by LNFL  // Note

| S08.     } Else {

| S09.       Push the C-SID container onto the compressed segment list

| S10.       Initialize a new C-SID container in packed format with all

|              bits set to 0

| S11        Copy the Locator-Node and Function of S to the least

|              significant remaining bits of the C-SID container

|              and decrement the remaining capacity by LNFL  // Note

| S12.     }

| S13.     If S is not a REPLACE-C-SID flavor SID, then break

| S14.   } Else {

| S15.     Break

| S16.   } // End If

| S17. } // End For

| S18. Push the C-SID container (if it is not empty) onto the

|        compressed segment list

 

> 58. I don't think you should reproduce text from another RFC like you

>  do in 7.2. It makes it delicate in the case of any (accidental)

>  differences, and vulnerable to errata or modifications of the source

>  RFC. A reference should be enough.

> 

>  If you feel you must include the quote, can you mark it in some way so

>  that it is possible to see where the quote ends and this document's

>  text resumes. (Using the pipe '|' is often a neat trick.)

 

We fixed the formatting of the quoted text in revision -09.

 

> 59. In 7.4

> 

> |  2.  A series of REPLACE-C-SID flavor SIDs MUST contain at least two

> |      elements.

> 

>  Why? Surely it works perfectly well if the series has just one such

>  SID and it is presented in the SID list? In this case, there is no

>  distinction between this and the SID being in the list in uncompressed

>  form.

> 

>  This requirement places a considerable burden on the component that

>  computes the SR path because it has to look ahead at the next hop

>  before it works out which SID to use at the current hop. Further, it

>  is not clear how a source node would behave it was supplied with a SID

>  list by an external party, and that list contained a single REPLACE-C-

>  SID flavor SID.

 

We reworked rules 2. and 3. in revision -09 to clarify the requirements.

 

| 2.  All SIDs except the last one in a C-SID sequence for REPLACE-

|     C-SID MUST have the REPLACE-C-SID flavor. If the last C-SID

|     container is fully filled (i.e., the last C-SID is at position 0

|     in the C-SID container) and the last SID in the C-SID sequence is

|     not the last segment in the segment list, the last SID in the

|     C-SID sequence MUST NOT have the REPLACE-C-SID flavor.

|

| 3.  When a REPLACE-C-SID flavor C-SID is present as the last SID in a

|     container that is not the last Segment List entry (index 0) in

|     the SRH, the next element in the segment list MUST be a REPLACE-

|     C-SID container in packed format carrying at least one C-SID.

 

> 60. In 7.4

> 

> |  3.  End of a C-SID sequence can be indicated by:

> 

>  Is there also a case where the sequence is at the end of the segment

>  list?

 

Yes. The reworked rules (see above response to comment 59.) should now properly handle this case.

 

> 61. In 7.4 there are multiple examples of text like...

> 

> |  When receiving a 128-bit SID with NEXT-C-SID flavor, LNL=16, FL=16 or

> |  0, AL=128-LBL-NL-FL and the value of argument is all 0, the source

> |  node marks the SID supporting 16-bit C-SID.

> 

>  a. In just one case you have "marks the SID as supporting" but I think

>     all cases should use that additional "as" to make it clear.

>  b. In all cases, it is not clear where this marking is done.

 

We clarified in revision -09 that this marking is meant to determine the compression scheme (16-bit or 32-bit of a REPLACE-C-SID flavor SID).

 

| The SR source node determines the compression scheme of REPLACE-C-SID

| flavor SIDs as follows.

|

| When receiving a SID advertisement for a REPLACE-C-SID flavor SID

| with LNL=16, FL=0, AL=128-LBL-NL-FL, and the value of the Argument is

| all 0, the SR source node marks both the SID and its locator as using

| 16-bit compression. All other SIDs allocated from this locator with

| LNL=16, FL=16, AL=128-LBL-NL-FL, and the value of the Argument is all

| 0 are also marked as using 16-bit compression. When receiving a SID

| advertisement for a REPLACE-C-SID flavor SID with LNFL=32, AL=128-

| LBL-NL-FL, and the value of the Argument is all 0, the SR source node

| marks both the SID and its locator as using 32-bit compression.

 

> 

> 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?

> 

> 

> 63. Section 8

> 

>   s/corresponding the Locator-Block/corresponding to the Locator-Block/

 

Fixed in revision -09.

 

> 64. Section 8

> 

> |  Note: the way the Locator-Block B2 of the next routing domain is

> |  known is out of scope of this document.  As examples, it could be

> |  learnt via configuration, or using a signaling protocol either with

> |  the peer domain or with a central controller (e.g.  Path Computation

> |  Element (PCE)).

> 

>  This could use a citation for PCE. Perhaps, RFC 4655, but perhaps the

>  PCEP document that provides this feature.

 

We removed the reference to PCE in revision -09.

 

> 65. In Section 8

> 

> |  When End.XPS SID behavior is used, the restriction on the C-SID

> |  length for the REPLACE-C-SID flavor is relaxed and becomes: all SID

> |  the are part of a C-SID sequence *within a domain* MUST have the same

> |  C-SID length LNFL.

> 

>  a. Please add a back reference to where the C-SID length restriction

>     is defined.

>  b. The English is a bit mangled. Perhaps, "all SIDs that are part..."

>  c. The use of * to highlight text is non-standard and, I think, not

>     needed.

>  d. "within a domain" is ambiguous because all SIDs are always within

>     a domain. Perhaps, "within the same domain"?

 

We removed this paragraph in revision -09. It is no longer applicable with the reworked rules.

 

> 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]).

> 

>  a. "SID of this document" is probably "SID with a NEXT-C-SID or

>     REPLACE-C-SID flavor"

 

We added a definition for the term "a SID of this document" in section 4.

 

| In the remainder of this document, the term "a SID of this document"

| refers to any End, End.X, End.T, End.B6.Encaps, End.B6.Encaps.Red, or

| End.BM SID with the NEXT-C-SID or the REPLACE-C-SID flavor, and with

| any combination of PSP, USP, and USD flavor, or any End.DX6, End.DX4,

| End.DT6, End.DT4, End.DT46, End.DX2, End.DX2V, End.DT2U, or End.DT2M

| with the REPLACE-C-SID flavor. All the SIDs introduced in this

| document are listed in Table 1.

 

>  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.

 

>  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.

 

> 67. Section 9

> 

> |  Signaling the SRv6 SID Structure is REQUIRED for all the SIDs

> |  introduced in this document.

> 

>   a. I think you mean "for both SID flavors introduced in this

>      document".

 

We added a definition for the term "a SID of this document" in section 4 (see response to comment 66.a. above).

 

>   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).

 

> 68. Section 9

> 

> |  The length values

> |  in the SRv6 SID Structure advertisement MUST match the format of the

> |  SID on the SR segment endpoint node.

> 

>  Given that it is the segment endpoint node that is responsible for

>  doing the advertisement, I think this should read...

> 

> |  The SR segment endpoint node initiating the advertisement of a SID

> |  with NEXT-C-SID or REPLACE-C-SID flavor set the length values in the

> |  SRv6 SID Structure in the advertisement to match the format of the

> |  SID.

 

We rephrased this text in revision -09 based on your suggestion.

 

| Signaling the SRv6 SID Structure is REQUIRED for all the SIDs

| introduced in this document. It is used by an SR source node to

| compress a segment list as described in Section 6. The node

| initiating the SID advertisement MUST set the length values in the

| SRv6 SID Structure to match the format of the SID on the SR segment

| endpoint node. For example, for a SID of this document instantiated

| from a /48 SRv6 SID block and a /64 Locator, and having a 16-bit

| Function, the SRv6 SID Structure advertisement carries the following

| values.

 

> 69. Section 9

> 

> |  A local C-SID MAY be advertised in the control plane individually or

> |  in combination with a global C-SID instantiated on the same SR

> |  segment endpoint node, with the End behavior, and the same Locator-

> |  Block and flavor as the local C-SID.

> 

>  a. This "MAY" is a bit confusing. It would normally be assumed to

>     apply to the combination "a or b". You might fix this with

>     s/individually/either individually/

 

We clarified this text in revision -09.

 

| A local C-SID MAY be advertised in the control plane individually

| and/or in combination with a global C-SID instantiated on the same SR

| segment endpoint node, with the End behavior, and the same Locator-

| Block and flavor as the local C-SID.

 

>  b. When you have a choice like this, you should give the implementer

>     a clue about how to choose. Maybe it is a free choice, maybe it is

>     a configuration knob, maybe there are optimisations or benefits to

>     one approach or the other.

 

The following paragraph indicates why this option may be chosen:

 

| The local C-SID combined advertisement is needed in particular for

| control plane protocols mandating that the SID is a subnet of a

| locator advertised in the same protocol (e.g., Sec. 8 of [RFC9352]

| and Sec. 9 of [I-D.ietf-lsr-ospfv3-srv6-extensions] for advertising

| Adjacency SIDs in IS-IS and OSPFv3, respectively).

 

> 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.

 

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.

 

> 71. In 10.1 you, again and several times, have "a SID of this document"

>  and I think you need to say "a SID with a NEXT-C-SID or REPLACE-C-SID

>  flavor."

 

We added a definition for the term "a SID of this document" in section 4 (see response to comment 66.a. above).

 

> 72. 10.1

> 

> |  When pinging a SID of this document via a segment list, the SR source

> |  node constructs the IPv6 packet as described in Section 7 and

> |  computes the ICMPv6 checksum using the IPv6 destination address as it

> |  is expected to appear at the ultimate destination of the packet.

> 

>  I appreciate you calling this out, and I think it is the topic of a

>  thread on the mailing list, but this checksum comment seems odd to me.

>  I went back to RFC 9259 to see what it has to say about checksums in

>  the case of a ping with a segment list, and found nothing (especially

>  in Appendix A).

> 

>  If this is cunning magic, then the reader could use a clue about what

>  is going on.

 

This behavior is not related to RFC 9259. We added a "MUST" in revision -09 to clarify that this is a new requirement.

 

| When pinging a SID of this document via a segment list, the SR source

| node MUST construct the IPv6 packet as described in Section 6 and

| compute the ICMPv6 checksum using the IPv6 destination address as it

| is expected to appear at the ultimate destination of the packet.

 

> 73. 10.2

> 

> |  Section 5.4 of [RFC8754] defines the logic that an SR source node

> |  should follow to determine the ultimate destination of an invoking

> |  packet containing an SRH.

> 

>  Why is this "should follow"? RFC 8754 does not seem to make this

>  optional. I suggest s/should follow/follows/

 

Fixed in revision -09.

 

>  I presume that the logic in this section is exactly what would be

>  required in 10.1 to determine the ultimate DA that is being used to

>  compute the checksum?

 

That is indeed one possibility. However, it may be simpler for the source node to directly use the last segment of the uncompressed segment list.

 

> 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.

> 

> 

> 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.

 

> 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?

 

> 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.

> 

> 

> 78. Is Section 15 (IANA) missing registration for End.XPS with and

>  without flavors?

> 

> 79. I think Section 15 needs to also request that the Change Controller

>  is changed to "IETF" for all of the code points.

 

This is mentioned at the end of the first paragraph: "and transfer change control to the IETF".

 

> 80. I think that three references need to be moved from 17.2 to 17.1

>  because of how they are used in the text. I don't think any of these

>  causes a problem.

>    8200

>    9256

>    9259

 

We changed RFC 9256 and 9259 to normative in revision -09.

 

RFC 8200 is only used as part of a quoted text from RFC 8754, so it is not a reference at all in this document.

 

> 81. Hoping that Appendix A will be resolved

> 

> 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. 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).

 

> 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