[spring] short term plan regarding adoption call for draft-filsfilscheng-spring-srv6-srh-compression

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

Given this note from the 6man leadership, and its indication of more 
information by the middle of next week, I am going to leave the adoption 
call open till we get that information.  If their update is 
significantly delayed, I will have to decide what to do next.
Assuming they do update us, I will see what that update does to the 
adoption call.

Before I sign off, i want to explicitly thank all the working group 
participants who have responded to and discussed this adoption call. 
Whatever the difficulty of resolving this and finding a rough consensus, 
I very much appreciate and value the engagement.  It is what makes the 
IETF work.

Yours,
Joel M. Halpern, SPRING co-Chair

On 10/14/2021 1:04 PM, Erik Kline wrote:
> Joel,
> 
> Thank you for your email.  The ADs and chairs have been discussing.
> 
> One thing that would be very helpful to our discussions would be some 
> worked examples of the various C-SID behaviors, showing some SRv6 
> datagrams and what happens to their contents as they move across some 
> suitable example SR domain.
> 
> (It would also be helpful if they showed what happens to something like 
> an ICMPv6 Echo Request to a representative Destination Address in these 
> cases when, say, an SRH is not present, i.e. to see when typical unicast 
> semantics are preserved or when something more like anycast or multicast 
> behavior is to be expected.)
> 
> Assuming some forthcoming helpful examples, we have a goal to get a more 
> complete answer back to you by the latter half of next week.
> 
> Thanks,
> -Erik
> 
> On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     The SPRING working group is in the midst of an adoption call on
>     https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>     <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.
> 
>     _______________________________________________
>     spring mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>
>