[spring] Re: [Shepherding AD review] review of draft-ietf-spring-srv6-srh-compression-18

[Francois Clad <[e-mail]>]

 Hi Gunter,

Many thanks for your detailed review.

I will work on your comments with the co-authors and hope to provide a
reply during the week of Oct/14.

Thanks,
Francois

On 2 Oct 2024 at 15:58:10, Gunter van de Velde (Nokia) <
[e-mail]> wrote:

> # Gunter Van de Velde, RTG AD, comments for
> draft-ietf-spring-srv6-srh-compression-18
>
> # line numbers are derived with the idnits tool
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-18.txt
>
>
> #GENERIC COMMENTS
> #================
> # This document is an intense read. It took time to process and get
> familiar with the documented procedures and concepts. During my review
> process i had the unique experience to review the document through the
> looking glass as a person "new to C-SID details".  This is important as
> that gave me a greenfield understanding of the documented C-SID details.
>
> # terminology: the codepoint registrations use "CSID" in the flavor name
> but everywhere in the draft "C-SID" is used. Is that by intention?
>
> # The documented interpretation of the terms "flavor" and "behavior"
> appears to be unusual. In RFC 8986, behaviors such as End, End.X, etc., are
> defined, and flavors like PSP, USP, and USD provide additional information
> on how to process those behaviors. Specifically, Section 4.16 of RFC 8986
> describes flavors as variants:
>
> "The Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (USP)
> of the SRH, and Ultimate Segment Decapsulation (USD) flavors are variants
> of the End, End.X, and End.T behaviors. The End, End.X, and End.T behaviors
> can support these flavors either individually or in combinations."
>
> RFC 8986 suggests that the End, End.X, and End.T behaviors can be combined
> with flavors. This document defines new flavors that appear to exhibit
> different characteristics from what RFC 8986 considers to be a flavor. For
> example, the End behavior can be combined with the PSP and USP flavors,
> whereas the End behavior with the NEXT-C-SID together with REPLACE-C-SID
> flavors cannot be combined. This difference causes confusion regarding the
> understanding and distinction between "behavior" and "flavor" and needs
> clarification.
>
> # The draft specifies that C-SIDs should be used as the destination
> address of an IPv6 packet, with or without an SRH. However, it does not
> provide guidance on whether using a C-SID construct or container as a
> source address is valid, invalid, or forbidden.
>
> # This document contains valuable operational C-SID guidelines scattered
> throughout its sections, which may make it challenging for operators to
> locate relevant recommendations. Collecting all SRv6 C-SID guidelines,
> recommendations, and considerations into a single "Operational
> Considerations" section or, alternatively, into a separate SRv6OPS document
> would be a reasonable approach.
>
> # section "7. Inter-Domain Compression" describes a procedure to swap
> Locator-Blocks. This seems rather different from procedures about
> NEXT-C-SID and REPLACE-C-SID and is maybe better discussed in its own
> separate document.
>
> #DETAILED COMMENTS
> #=================
>
>
> 150   The Segment Routing (SR) architecture [RFC8402] describes two data
> 151   plane instantiations of SR: SR over MPLS (SR-MPLS) and SR over IPv6
> 152   (SRv6).
>
> GV> RFC8402 talks about the instantiation of SR *on* MPLS/IPv6
> *data-plane*, and not *over*.
> A more accurate text blob, using RFC8402 text would be:
>
> "
> The Segment Routing (SR) architecture [RFC8402] describes two data
> plane instantiations of SR: SR applied to the MPLS-architecture
> (SR-MPLS) and SR applied to the IPv6-architecture (SRv6).
> "
>
> 154   SRv6 Network Programming [RFC8986] defines a framework to build a
> 155   network program with topological and service segments (also referred
> 156   to by their Segment Identifier (SID)) carried in a Segment Routing
> 157   Header (SRH) [RFC8754].
>
> GV> This statement is not fully accurate. RFC8986 also describe Reduced
> SRH where a SID is carried outside the SRH to reduce the size of the SRH.
>
> 159   Some SRv6 applications such as strict path traffic engineering may
> 160   require long segment lists.  Compressing the encoding of these long
> 161   segment lists in the packet header can significantly reduce the
> 162   header size.  This document specifies new flavors to the SR segment
> 163   endpoint behaviors defined in [RFC8986] that enable a compressed
> 164   encoding of the SRv6 segment list.
>
> GV> This document seems to define additional behaviors, not only new
> flavors of existing behaviors.
> For example END.PS and END.XPS appear to be new behaviors, not new
> flavors of behaviors defined in RFC8986.
>
> 183   *  Locator-Node: The least significant bits of a SID locator that
> 184      identify the SR segment endpoint node instantiating the SID.  The
> 185      Locator-Node is referred to as "N" in Section 3.1 of [RFC8986].
>
> GV> section 3.1 describe "N" as the "N is the identifier of the parent
> node instantiating the SID".
> Is this difference in terminology "endpoint" vs "parent node" by intent?
>
> 187   *  Compressed-SID (C-SID): A compressed encoding of a SID.  The
> C-SID
> 188      includes the Locator-Node and Function bits of the SID being
> 189      compressed.
>
> GV> I wonder if this is accurate. When a CSID is a global node-level
> identifier, the function bits are set to zero and are therefore omitted.
> Similarly, when the CSID is a local identifier without an associated global
> node-level CSID, the Locator Node bits are also zero and omitted.
>
> 191   *  C-SID container: A 128-bit container holding a list of one or
> more
> 192      C-SIDs.
>
> GV> This may need some additional clarification for an accurate
> description.
> rfc8402 describe a SRv6 segment as an IPv6 address, in addition RFC8754
> describe a segment within the SRH as an 128-bit IPv6 address. The above
> CSID container says its simply a 128-bit thing. A more accurate description
> would be:
>
> "
> * C-SID container: A 128-bit IPv6 address that functions as a container
> holding a list of one or more C-SIDs.
> "
>
> 194   *  C-SID sequence: A group of one or more consecutive SID list
> 195      entries carrying the common Locator-Block and at least one C-SID
> 196      container.
>
> GV> Note that the verb "carry" is not entirely clear in above context.
>
> "
> *  C-SID sequence: A group of one or more consecutive SID list
> entries encoding the common Locator-Block and at least one C-SID
> container.
> "
>
> 187   *  Compressed-SID (C-SID): A compressed encoding of a SID.  The
> C-SID
> 188      includes the Locator-Node and Function bits of the SID being
> 189      compressed.
>
> GV> a *compressed* SID list can contain *uncompressed* SIDs
>
> 245   The compressed segment list encoding is fully compatible with and
> 246   builds upon the mechanisms specified in [RFC8754] and [RFC8986].
> The
> 247   compressed encoding leverages a SID list compression logic on the SR
> 248   source node (Section 6) in combination with new flavors of the base
> 249   SRv6 segment endpoint behaviors that process the compressed SID list
> 250   (Section 4).
>
> GV> In the draft -18 there are 56 instances of the term "SR source node"
> without an explicit definition of "what is" a SR source node from a C-SID
> perspective. This should be clarified and defined in terminology section 2
>
> GV> What about an editorial rewrite to make the text more accurate:
> "Building upon and fully compatible with the mechanisms specified in
> [RFC8754] and [RFC8986], the compressed segment list encoding leverages SID
> list compression logic at the SR source node (see Section 6) in combination
> with both new and existing flavors of the base SRv6 segment endpoint
> behaviors that process the compressed SID list (see Section 4)."
>
> 252   A segment list can be encoded in the packet header using any
> 253   combination of compressed and uncompressed sequences.  The C-SID
>
> GV> Line194 in terminology section introduce C-SID sequence. How does
> C-SID sequence correlate with uncompressed sequence? Could uncompressed
> sequence description be added in the terminology section?
>
> 252   A segment list can be encoded in the packet header using any
> 253   combination of compressed and uncompressed sequences.  The C-SID
> 254   sequences leverage the flavors defined in this document, while the
> 255   uncompressed sequences use behaviors and flavors defined in other
> 256   documents, such as [RFC8986].  An SR source node constructs and
> 257   compresses the SID list depending on the SIDs instantiated on each
> SR
> 258   segment endpoint node that the packet should traverse, as well as
> its
> 259   own compression capabilities.
>
> GV> There is an inconsistency. In the text is mentioned "leverage the
> flavors defined in this document", however in section 4.1 can be found:
>
> "
>   When a C-SID sequence comprises at least two C-SIDs, the last C-SID
>   in the sequence is not required to have the NEXT-C-SID flavor.  ***It
>   can be bound to any behavior and flavor(s)***
> "
>
> GV> s/packet should traverse/packet intended to traverse/
>
> 274   behaviors of [RFC8986].  A counterpart NEXT-C-SID flavor is not
> 275   defined for these SIDs because they can be included within a C-SID
> 276   sequence that uses the NEXT-C-SID flavor without any modification of
> 277   the procedure defined in [RFC8986].
>
> GV> What does "they can be included within a C-SID sequence" exactly mean?
> Can this be explained how this is intended to function?
>
> 297   SRv6 is intended for use in a variety of networks that require
> 298   different prefix lengths and SID numbering spaces.  Each of the two
> 299   flavors introduced in this document comes with its own
> 300   recommendations for Locator-Block and C-SID length, as specified in
> 301   Section 4.1 and Section 4.2.  These flavors are best suited for
> 302   different environments, depending on the requirements of the
> network
>