Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[Brian E Carpenter <[e-mail]>]

Greg,

I would much prefer that one of the SRv6 experts answers that question.

Regards
   Brian

On 21-Oct-21 09:13, Greg Mirsky wrote:
> Hi Brian,
> I've got some questions about what you've said:
> 
>     For that reason, the fact that the bottom 64 bits in the
> 
>     "address" look funny or change is simply irrelevant. They are
>     invisible to routing (which is done based on the prefix)
>     and invisible to neighbor discovery (because it never happens).
> 
> As I understand it, what you describe is the case of a strict explicit path defined using one of the C-SID compression methods. But I am not sure that your conclusion also always applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the same 
prefix, how routing can be done based only on that prefix and not using a 
part of that "funny" bottom 64 bits? And if any part of the bottom 64 bits must be used, how one can guarantee that CIDR still works in that domain?
> 
> Regards,
> Greg
> 
> On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi,
> 
>     After reading a lot of messages, I'm going to offer my considered
>     opinion as a direct response to Joel's OP.
> 
>     Firstly, I don't believe that in the end this draft raises any
>     concerns that are *significantly* different than those raised
>     when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
>     of RFC 8754 explains that SIDs of any shape or size are only
>     meaningful within an SR domain. That applies to srh-compression
>     too.
> 
>     Secondly, I was concerned about how these strange looking
>     "addresses" would potentially interfere with normal IPv6
>     addresses and their handling by normal IPv6 nodes. Well, I
>     now believe that they won't. The reason is that in the SR model
>     these "addresses" are *never used for final delivery of IPv6
>     packets to a host.* All SRv6 participants are routers. The
>     last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
>     is *not* the last hop on a LAN, mediated by neighbor discovery
>     for 2001:db8:a:1900::. It's just a hop from one router to another,
>     using the entry for 2001:db8:a:1900::/64 in the FIB of the last
>     router that actually forwards the packet. 2001:db8:a:1900:: is
>     not assigned to a physical interface so RFC 4861 is never invoked.
> 
>     Another way to say it is RFC 7608 is the relevant architectural
>     standard. CIDR rules, even within an SR domain.
> 
>     For that reason, the fact that the bottom 64 bits in the
>     "address" look funny or change is simply irrelevant. They are
>     invisible to routing (which is done based on the prefix)
>     and invisible to neighbor discovery (because it never happens).
> 
>     I apologise if this is all obvious to everybody, but I needed
>     to spell it out for my own understanding.
> 
>     Now back to Joel's questions:
> 
> 
>     On 13-Oct-21 20:37, Joel M. Halpern wrote:
>     > There is a typo in the below which if not understood as a typo would be
> 
>     > quite confusing.   I wrote that I raised the issue with
>     > "with the Internet ADs and SPRING chairs".
>     > That should have read "with the Internet ADs and 6man chairs".
>     > The SPRING co-chairs are recused, and the charter requirement leads to
>     > the 6man chairs.  Which is who I talked to.
>     >
>     > Also, I am sending a courtesy copy to the routing ADs, which I should
>     > have done originally.
>     >
>     > Thank you and enjoy.
>     > Yours,
>     > Joel
>     >
>     > On 10/12/2021 11:52 PM, Joel M. Halpern 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.
> 
>     I think it should be noted explicitly somewhere that since the contents
>     of the DA field are *never* used for last-hop neighbor discovery,
>     the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
>     are irrelevant. Another citation is RFC 7608: for routing, all that
>     counts is the prefix, and it can be anything up to 128.
> 
>     Perhaps this should have been in section 5 of RFC 8754, but I leave
>     that to the wordsmiths.
> 
>     >> 2) Does the operation of shifting information around in the IPv6
>     >> destination address field represent a modification or extension of the
> 
>     >> IPv6 data plane.
> 
>     No. As my text above indicates, the SRv6 DA field is only ever used
>     by routing, where RFC 7608 rules. And of course it vanishes as soon
>     as the packet is decapsulated.
> 
>     Regards
>         Brian
> 
>     >>
>     >> 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.
>     >
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     > --------------------------------------------------------------------
>     >
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
<https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>