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, <markzzzsm...@gmail.com> wrote:
> On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter
> <brian.e.carpen...@gmail.com> 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/
> >
> > >
> > >
> > >
> > > Hope this helps.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Francois
> > >
> > >
> > >
> > > *From: *spring <spring-boun...@ietf.org> on behalf of Erik Kline <
> ek.i...@gmail.com>
> > > *Date: *Thursday, 14 October 2021 at 19:06
> > > *To: *Joel M. Halpern <j...@joelhalpern.com>
> > > *Cc: *spring@ietf.org <spring@ietf.org>, i...@ietf.org <i...@ietf.org>
> > > *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 <j...@joelhalpern.com
> <mailto:j...@joelhalpern.com>> 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
> > > spring@ietf.org <mailto:spring@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/spring <
> https://www.ietf.org/mailman/listinfo/spring>
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > i...@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
