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

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Brian,
> Would it change your examples if you used 2001:db8:a:1100::1 instead?

No it would not change the examples, any other assignment for loopback interfaces works the same.

> Still, using IID == 0 seems to be asking for trouble, since it's a reserved value and is definitely special-cased in some code. Unless, that is, you want exactly the properties described in RFC4291 section 2.6.1 (thanks, Mark Smith).

As Michael described, this assignment to loopback interfaces works fine.  The addresses are assigned as /128’s, not prefixes, the router subnet anycast concern is not applicable.

Thanks,
  Darren

________________________________
From: Brian E Carpenter <[e-mail]>
Sent: Sunday, October 17, 2021 6:15 PM
To: Darren Dukes (ddukes); Mark Smith
Cc: SPRING WG List; 6man WG; Francois Clad (fclad)
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On 18-Oct-21 09:28, Darren Dukes (ddukes) wrote:
> Hi Brian, the draft says:
>
>    Loopback interface addresses are allocated from the prefix
>    2001:db8:a::/48.
>
> In the examples 2001:db8:a:1100:: is the IPv6 address assigned to the loopback interface of node 11.


Still, using IID == 0 seems to be asking for trouble, since it's a reserved value and is definitely special-cased in some code. Unless, that is, you want exactly the properties described in RFC4291 section 2.6.1 (thanks, Mark Smith).

Would it change your examples if you used 2001:db8:a:1100::1 instead?

   Brian

>
>
>
> Darren
>
>
>
>
>
>
>
> On 2021-10-17, 2:06 AM, "ipv6" <[e-mail]> wrote:
>
>
>
> Ah, thanks, that's the sort of thing you can only know by knowing it :-). Ok, so my question about the examples supplied stands. Using this as a
source address has interesting implications.
>
> Regards,
>     Brian Carpenter
>     (via tiny screen & keyboard)
>
>
>
> On Sun, 17 Oct 2021, 18:58 Mark Smith, <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >
>     > Thanks for this draft.
>     >
>     > Question: where you show "Source address 2001:db8:a:1100::" is that intended to be the complete address, because it looks like a prefix? I
can't find anywhere that an interface identifier of zero is forbidden, but it's unusual, and can only exist once in a given subnet.
>     >
>
>     The IID value of all zeros is the subnet-router anycast address within
>     a subnet, and is required. See 2.6.1 of RFC4291.
>
>     For example, Linux automatically configures the subnet-router anycast
>     address for all prefixes on an interface if the interface is a
>     forwarding interface.
>
>     [mark@opy ~]$ ip -6 route show table local | grep anycast
>     anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium
>     anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium
>     [mark@opy ~]$
>
>     (The "local" route table is where the interface address and multicast
>     route route table entries are kept in Linux. They don't all show up
>     via the normal 'ip addr show' or 'ifconfig' commands).
>
>     Regards,
>     Mark.
>
>
>     > Regards
>     >    Brian Carpenter
>     >
>     > On 16-Oct-21 10:55, Francois Clad (fclad) wrote:
>     > > Hello Erik,
>     > >
>     > >
>     > >
>     > > You may find some examples here: https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ <https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/> <https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ <https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/>>
>     > >
>     > >
>     > >
>     > > Hope this helps.
>     > >
>     > >
>     > >
>     > > Thanks,
>     > >
>     > > Francois
>     > >
>     > >
>     > >
>     > > *From: *spring <[e-mail] <mailto:[e-mail]>> on behalf of Erik Kline <[e-mail] <mailto:[e-mail]>>
>     > > *Date: *Thursday, 14 October 2021 at 19:06
>     > > *To: *Joel M. Halpern <[e-mail] <mailto:[e-mail]>>
>     > > *Cc: *[e-mail] <mailto:[e-mail]> <[e-mail]
<mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>     > > *Subject: *Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression
>     > >
>     > > 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]> <mailto:[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/> <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]> <mailto:[e-mail] <mailto:[e-mail]>>
>     > >     https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring> <https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>>
>     > >
>     > >
>     > > --------------------------------------------------------------------
>     > > 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>
>     > > --------------------------------------------------------------------
>     > >
>     >
>     > _______________________________________________
>     > spring mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>
>