Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

["Joel M. Halpern" <[e-mail]>]

The SPRING working group is in the midst of an adoption call on 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.

The SPRING charter has text that is explicit that modifications to data 
planes and architectures standardized by other working groups may not be 
modified in SPRING unless the chairs and ADs responsible for that data 
plane and / or architecture agree.

To complete the context, as my SPRING co-chairs are co-authors on the 
document in question, they have recused themselves from decisional 
activities regarding the document.  Therefore, this message is coming 
just from my as the responsible SPRING co-chair managing this adoption call.

As you have seen, multiple questions have been raised about the 
relationship of the document to the IPv6 defined data plane and 
architecture (particularly RFC 4291 and 8200). In particular the 
questions seem to revolve around what the document describes as the 
NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 
standards.  (For those seeking more context without reading the full 
document, a paraphrase and simplification of the NEXT-C_SID flavor is 
provided as a postscript.)

I raised the question of concurrence as required by the SPRING charter 
with the Internet ADs and SPRING chairs.  They quite reasonably asked me 
to write a note to 6man explaining the concerns as clearly as a can, so 
that they can then determine how to proceed.

The questions that prompted my inquiry are:

1) Does the placement of a list of sids in the IPv6 DA field change the 
IPv6 architectural description of that field.
2) Does the operation of shifting information around in the IPv6 
destination address field represent a modification or extension of the 
IPv6 data plane.

On a related note, the document in question also defines two other 
flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The 
NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID 
flavor operation, so seems to be affected by the same question.

 From my own reading, it appears that the REPLACE-C-SID flavor does not 
raise issues requiring 6man leadership concurrence.

Yours,
Joel M. Halpern for the SPRING working group


PS:
Clearly, understanding the question requires some understanding of what 
the NEXT-C_SID flavor does.   This explanation is a simplification for 
length and context.  Really, the best place to understand it is the 
draft.  However, to give you enough information to let you decide 
whether you care, I will try to provide a fair summary.  My apologies in 
advance to the authors for necessary liberties for length.  Also, 
discussion of the draft contents (as distinct from the interaction with 
the IPv6 data plane and architecture) belongs on the SPRING list, and 
should not clutter up 6man.

SIDs are the identifiers used in segment routing.
In SRv6, as document in the current RFCs, these are 128 bits.   As 
defined in the relevant RFCs, SIDs which identify endpoints to which 
packets are directed are identified by endpoint SIDs.  These can have 
behaviors (decapsulate and forward is one example).  They can have 
flavors such as where the SRH is removed.

The topic under discussion is means to compress these SIDs in the 
packets on the wire.  The document under discussion provides three 
flavors of compression.

The fundamental mechanism of the draft is to use a single SRH entry as a 
container for multiple SIDs.  In the NEXT-C_SID mechanism, when it is 
first encountered the entire container is copied into the desination 
address of the IPv6 packet.  The container has a common routing prefix 
used for all the NEXT-C-SID SIDs.  It is followed by a sequence of 
compressed SIDs of a configured length.  One could configure 16, 24, or 
32 bits.  Or whatever length.  The routing advertisements are arranged 
so that the IPv6 packet is directed to the node represented by the first 
compressed SID on the basis of longest prefix match matching the 
combination of the common routing prefix and that compressed SID.

When the packet arrives at that node, it looks up the configured 
portion, the compressed SID, and determines the behavior and flavor.  In 
the case of the NEXT-C-SID flavor, the resulting operation is to shift 
the entire remaining contents of the IPv6 address (the bits past the 
first compressed sid) so as to over-write the first compressed SID.  0 
bits are shifted into the low order positions.  If the result is a 
non-zero new first compressed SID, then the packets is forwarded and the 
process repeats.  When all that is left are 0s, if there is an SRH, it 
is consulted to find the next SRH entry, which is, per normal SRv6 
processing, put into the IPv6 DA.
Note that in the common case where the SIDS needed all fit in to a 
single container, the analysis also assumes the use of the reduced 
encapsulation options which omits the SRH that is not needed as it would 
have no entries.  This the packet contains a normal IPv6 header, with a 
sequence of compressed SIDs (what one might or might not call a source 
route) in the IPv6 destination address field.

PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented 
the work, please, send clarifications or corrections.   Again, the best 
source of information is the draft itself.  I was asked to provide extra 
context in this email.