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

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Oct 2021 23:52:54 -0400

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Oct 2021 03:37:11 -0400

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Oct 2021 13:11:49 -0700

Just to be clear given the lack of responses, the 6MAN co-chairs would like feedback from the 6MAN working group on the questions Joel asked regarding <draft-filsfilscheng-spring-srv6-srh-compression>.

Bob & Ole

> On Oct 12, 2021, at 8:52 PM, Joel M. Halpern <[email-masked]> 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/.
> 
> 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.
> 
> 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,
> 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.
> 
> 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.
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Oct 2021 09:26:49 +1300

Joel,
On 13-Oct-21 20:37, Joel M. Halpern wrote:

<snip>

>> IPv6 architectural description of that field.

That's why I recently asked for a set of examples of the resulting
"addresses". I don't understand enough of SRV6 to understand what
the bit patterns in such addresses will actually be. And I don't care
about the details of SRV6, given that it will only be used in certain
special types of network. So I can only answer your question based
on concrete examples. Are they compatible with RFC4291 or not?

(There's a subsidiary question which IMHO is in some ways more important
than the architectural question: what existing code and devices will such
addresses break?)

>> destination address field represent a modification or extension of the 

Including semantics *of any kind* in an IP address is a very fundamental
change to the concept of IP. I may be wrong, but I'm not aware that any
RFCs prior to SRV6 have done this, and the founding reference for what 
an address *is* still seems to be IEN19 [1].

So I'm not concerned that srv6-srh-compression has any more fundamental
impact than basic SRV6 or RFC8986. (However, this aspect of SRV6 was
one of my primary motivations for RFC8799. What happens in SRV6 stays
in SRV6.)

[1] https://www.rfc-editor.org/ien/ien19.txt)

<more snip>

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Oct 2021 17:31:00 -0400

Bob Hinden <[email-masked]> wrote:
    > Just to be clear given the lack of responses, the 6MAN co-chairs would
    > like feedback from the 6MAN working group on the questions Joel asked
    > regarding <draft-filsfilscheng-spring-srv6-srh-compression>.

I've tried to say out of all things SRH.

I'm mostly annoyed at TLA overload between SRH "SID", and "YANG SID"
(from the CORE WG) :-)

My observation is that this document seems to amend the SRH locators,
which are defined in RFC8986.  I think that it all fits within SRH.
I don't really understand the recurring flame war among what I see as
dis-interested parties.

Pee happens, we have to manage it as well as we can.
I prefer the interested parties are within the IETF tent, peeing out,
rather than outside the IETF tent, peeing in.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Oct 2021 17:33:08 -0400

> one of my primary motivations for RFC8799. What happens in SRV6 stays

You said it better than I.

{Now, if a router wanted to announce it's SRV6-ness, and would it want to do
that in an RA, would it want to use the universal RA option to do so?}

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Oct 2021 10:41:47 +0100

On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter <
[email-masked]> wrote:

> change to the concept of IP. <https://www.ietf.org/mailman/listinfo/ipv6>

Would you mind elaborating what you mean by semantics in the statement
above?  Clearly there are semantics in things like the IPv4 multicast and
experimental address ranges (aka "Class D" and "Class E"); especially for
the multicast case, the very fundamental semantics of the distribution are
signalled using the address and there has been significant deployment using
those semantics.  Isn't that semantics in the meaning above?

Thanks for any clarification,

Ted

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Oct 2021 12:52:41 +0200

> an address *is* still seems to be IEN19 [1].

One reason may be that you don’t need an RFC to do that.

I don’t have the references handy, but people have been allocating a whole /64 to a single end-system (*) for quite a while.

E.g., see
https://serverfault.com/questions/936848/adding-a-whole-ipv6-64-block-to-a-server-using-netplan
for a discussion on how to do this with Linux.

The IID then becomes “Semantics” (like the port number already is).

Grüße, Carsten

(*) Not exactly a “host” any more, so maybe there is room for an RFC here…

---

From: Erik Kline <[email-masked]>
Date: Thu, 14 Oct 2021 10:04:23 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Oct 2021 10:06:24 +1300

On 14-Oct-21 22:41, Ted Hardie wrote:
> On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     change to the concept of IP.<https://www.ietf.org/mailman/listinfo/ipv6>
> 
> 
> Would you mind elaborating what you mean by semantics in the statement above?  Clearly there are semantics in things like the IPv4 multicast and experimental address ranges (aka "Class D" and "Class E"); especially for the multicast case, the very fundamental semantics of the distribution are signalled using the address and there has been significant deployment using those semantics.  Isn't that semantics in the meaning above?

Yes, I should have restricted my remark to *unicast* addresses. But there 
is a difference, I think, between semantics that describe the *type of address* and semantics that actively describe *what the recipient is going to do*. It's the latter that I was getting at.

(This applies to Carsten's comment too. Port numbers or multiple addresses per host are not actively describing what the recipient will do; they're just numbers.)

Also, I tried not to express shock and horror at the notion of semantics in address, but concern about how this will impact existing hardware and software.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 14 Oct 2021 16:32:49 -0700

> is a difference, I think, between semantics that describe the *type of address* and semantics that actively describe *what the recipient is going to do*. It's the latter that I was getting at.
Brian,

Joel's description is very good, and it makes me think that this
mechanism is best described as yet another form of NAT. Similar to a
NAT device, these devices are rewriting destination addresses per some
algorithm which is not necessarily exposed to the outside world. In
both NAT and Sid compression, packets are being routed to some
intermediate node which is performing address translation and
forwarding. The Sid compression method has the advantage that the
translation is  stateless. While SId compression is explicit as
encoded in the destination address set by the sender, it seems like
Sid compression would still be transparent to any intermediate node
that's not the destination address-- that would include the Internet
in packets that were leaked.

Given that NAT seems to work okay, I don't immediately see how SId
compression would be any more of a problem :-)

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 15 Oct 2021 06:17:00 +0000

Hi Joel , all, 

C-SID is no more than another mechanism that relies on some algorithmic mapping embedded in the IPv6 address. We do have already many of such algorithmic approaches: RFC6052, RFC7597, etc. 

The internal structure would be problematic if it requires that every intermediate node on the path has to parse it, but this is not the case. The packet is forwarded based on the DA following conventional procedures. The procedure to determine the next SR hop is internal to an SR-capable node.

Having examples of such SIDs in the draft would help to better understand the compression procedure, but no more than that as these will be displayed as IPv6 addresses! 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 <[email-masked]> De la part de Joel M. Halpern
> Envoyé : mercredi 13 octobre 2021 09:37
> À : [email-masked]
> Cc : [email-masked]
> Objet : Typo correction Re: Question from SPRING regarding draft-
> filsfilscheng-spring-srv6-srh-compression
> 
> 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
> 
> > 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.
> >
> > 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.
> >
> >  From my own reading, it appears that the REPLACE-C-SID flavor does
> > not raise issues requiring 6man leadership concurrence.
> >
> > Yours,
> > 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.
> >
> > 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
> > 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
> > 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.
> > 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
> > 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.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mark Smith <[email-masked]>
Date: Fri, 15 Oct 2021 18:12:29 +1100

On Fri, 15 Oct 2021, 17:18 , <[email-masked]> wrote:

> Hi Joel , all,
>
> C-SID is no more than another mechanism that relies on some algorithmic
> mapping embedded in the IPv6 address. We do have already many of such
> algorithmic approaches: RFC6052, RFC7597, etc.

That's not correct.

DAs aren't expected to change in fight, otherwise they will break all of
the transport layer protocols for which packet addresses are included in
the transport layer checksum.

In fight changing DAs also will break AH protection of the IPv6 header.

DA changing in flight is NAT. I'd have thought the IETF had learnt that
lesson by now.

Perhaps people need to read RFC2993 again.

>
> The internal structure would be problematic if it requires that every
> intermediate node on the path has to parse it, but this is not the case.
> The packet is forwarded based on the DA following conventional procedures.
> The procedure to determine the next SR hop is internal to an SR-capable
> node.
>
> Having examples of such SIDs in the draft would help to better understand
> the compression procedure, but no more than that as these will be displayed
> as IPv6 addresses!
>
> Cheers,
> Med
>
> have
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 15 Oct 2021 07:21:05 +0000

Hi Mark,

Not sure what is incorrect in what I mentioned.

Checksum neutrality is a distinct issue than the original question from Joel. That was discussed in the RFCs cited in the previous message.

That’s said, I’m not sure that’s an issue for SRH given that the encap will need to be updated anyway to allow to cross the appropriate SR nodes of a path.

Cheers,
Med

De : Mark Smith <[email-masked]>
Envoyé : vendredi 15 octobre 2021 09:12
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : Joel M. Halpern <[email-masked]>; 6man WG <[email-masked]>; SPRING WG <[email-masked]>
Objet : Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On Fri, 15 Oct 2021, 17:18 , <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel , all,

That's not correct.

DAs aren't expected to change in fight, otherwise they will break all of the transport layer protocols for which packet addresses are included in the transport layer checksum.

DA changing in flight is NAT. I'd have thought the IETF had learnt that lesson by now.

Cheers,
Med

> De : ipv6 <[email-masked]<mailto:[email-masked]>> De la part de Joel M. Halpern
> À : [email-masked]<mailto:[email-masked]>
> Cc : [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Oct 2021 11:39:54 +0100

On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> >
> >     change to the concept of IP.<
> https://www.ietf.org/mailman/listinfo/ipv6>
> >
> >
> is a difference, I think, between semantics that describe the *type of
> address* and semantics that actively describe *what the recipient is going
> to do*. It's the latter that I was getting at.
>
>
Thank you for the clarification, though I'm still struggling a bit with
understanding your concern.  Since we use address ranges for scope
semantics (e.g. ULAs for administratively determined scopes) even within
unicast addressing, I'm not quite seeing the line you are yet.

> (This applies to Carsten's comment too. Port numbers or multiple
addresses per host are not actively describing what the recipient will do;
they're just numbers.)

While this may theoretically be true, we actually associate significant
semantics with port numbers, both in the end hosts (e.g. the ports below
1024 being privileged ports) and in the network (where firewalls use ports
to start the process of analyzing the permissibility of a flow).  A
specific port number very much describes what the host will do:  port 25
will link to the SMTP service, for example.  So I guess I'm not following
this parallel too well either.

regards,

Ted

>
> Also, I tried not to express shock and horror at the notion of semantics
> in address, but concern about how this will impact existing hardware and
> software.
>
> >

---

From: Tom Herbert <[email-masked]>
Date: Fri, 15 Oct 2021 09:00:37 -0700

> DAs aren't expected to change in fight, otherwise they will break all of the transport layer protocols for which packet addresses are included in the transport layer checksum.

Mark, they already do change courtesy of routing headers. Transport
layer checksums are end to end and there's no requirement that the
intermediate nodes can correctly compute transport layer checksums.
NAT translation maintains the correct checksum, but routing headers do
not, so unless an intermediate node is able to discern the final
destination of the packet it won't be able to compute the correct
checksum (this is a practical problem we are seeing with NICs that
still insist on doing protocol specific checksum offload, in the
presence of routing headers these devices can fail to offload RX
checksum).
> In fight changing DAs also will break AH protection of the IPv6 header.

SRH already breaks AH ;-) It's fixable and changing DAs in flight is
compatible if it's prescribed that both the source and destination see
the same destination address for AH processing.

Tom

---

From: Andrew Alston <[email-masked]>
Date: Fri, 15 Oct 2021 18:35:48 +0000

Joel,

  1.  Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field.

To this I would say 100% yes – Section 2 of RFC8200 defines an address as “an IPv6-Layer identifier for an interface or a set of interfaces” and right above that it describes as an interface as “A node’s attachment to a link”.  The definition of link above that also does not in any way help the case.  When you place a list of SID’s in the DA of a field – you no longer have an address by these definitions – you have – something else.  Yes – it can be clearly argued that the DA does not need to represent the ultimate destination – but it is hard to get away from the fact that this does change the definition as per the terminology section, since the address is no longer representative of an interface that represents a node’s attachment to a link – be it virtual or otherewise.

  1.  Does the operation of shifting information around in the IPv6 destination address field represent a modification or extension of the IPv6 data plane.

I am at a loss to see how this cannot be seen as a modification of the data plane.  You are taking an ingress packet – modifying the DA based either on whats in the DA itself (which is a more clear cut case – since you are using the address to modify itself – and it is in no way in line with what is described in point 1) or in the case of when an SRH packet is applied – deriving the DA in part from the what is contained in the SRH and in part from what is configured on the device.  As such the SRH itself does not “list one or more intermediate nodes to be visted”, that is derived information and I would argue outside of the spec.  This is particularly relevant considering that the packets do not contain SID length and multiple SID lengths are possible, as such deriving this information is a flexible behavior inside the data plane that is modified by configuration.

As I stated in another email – irrespective of how complex the pseudocode gets – and if you are deriving the information from the SRH or from the DA itself – the ultimate consequence of the behavior can still be summarized as da[location_size] << sid_size.  If you copy that information out of the routing header in an obfuscated way or not – that does not change the outcome – and in fact I would argue that any statements that because you can copy parts of the DA out of the SRH and some how do this via a less efficient method to achieve the same result – do not solve the issue of if this is a modification – all they do is create a situation where to avoid a claim of of data plane modification, pseudocode is proposed that is unlikely to ever be seen in a real implementation because of efficiency reasons, and hence we are in all likelihood accepting standardization of a method that we know may well be violated in every implementation – for the sake of making a claim of lack of violation of another standard.  This doesn’t sit well.

Thanks

Andrew

From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
Date: Wednesday, 13 October 2021 at 06:53
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

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>.

Yours,

PS:

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Fri, 15 Oct 2021 21:55:18 +0000

Hello Erik,

You may find some examples here: https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/

Hope this helps.

Thanks,
Francois

From: spring <[email-masked]> on behalf of Erik Kline <[email-masked]>
Date: Thursday, 14 October 2021 at 19:06
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression
Joel,

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 <[email-masked]<mailto:[email-masked]>> 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/.

Yours,

PS:

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 15:35:58 -0400

> In fight changing DAs also will break AH protection of the IPv6 header.

AH is dead. It's been dead for decades.
I say this as an IPsec enthusiast who wishes this wasn't true.
But it is.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Oct 2021 10:19:32 +1300

Ted,

On 15-Oct-21 23:39, Ted Hardie wrote:
> On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >
>     >
>     >     change to the concept of IP.<https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>
>     >
>     >
>     > Would you mind elaborating what you mean by semantics in the statement above?  Clearly there are semantics in things like the IPv4 multicast and experimental address ranges (aka "Class D" and "Class E"); especially for the multicast case, the very fundamental semantics of the distribution are signalled using the address and there has been significant 
deployment using those semantics.  Isn't that semantics in the meaning above?
>     is a difference, I think, between semantics that describe the *type 
of address* and semantics that actively describe *what the recipient is going to do*. It's the latter that I was getting at.
> Thank you for the clarification, though I'm still struggling a bit with 
understanding your concern.  Since we use address ranges for scope semantics (e.g. ULAs for administratively determined scopes) even within unicast addressing, I'm not quite seeing the line you are yet.

I definitely did not express myself clearly enough. I want to draw a distinction between unicast address bits that are arbitrary numbers as far as 
the routing system is concerned -- such as the classical IID bits in IPv6 
unicast addresses, or the prefix bits following fc00::/7 -- and address bits that are meaningful to the routing system, such as fe80::/10 (which means "do not route this packet").

A glance at https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml shows that this distinction is not mathematically rigid, because of oddities like 100::/64, but I think it's generally valid.

Within an SRV6 domain, with RFC8986 and the current draft, we see something new: a field which has classically been an arbitrary 64-bit number for 
the routing system (the IID field) becomes meaningful to the routing system. That's an architectural change, and definitely was not envisaged by the IPv6 address architecture.

So, IMHO, the question behind SPRING's question to 6MAN is not whether there is an architectural change, but whether this changes matters. In particular, will it have impact on legacy devices and software within the SRV6 domain, and will it do any damage if it leaks outside the domain?

(To a certain extent, this question is linked to draft-bourbaki-6man-classless-ipv6.)

> While this may theoretically be true, we actually associate significant 
semantics with port numbers, both in the end hosts (e.g. the ports below 1024 being privileged ports) and in the network (where firewalls use ports to start the process of analyzing the permissibility of a flow).  A specific port number very much describes what the host will do:  port 25 will link to the SMTP service, for example.  So I guess I'm not following this parallel too well either.

I hope that it's clearer now that I'm making a distinction between bits that do or do not convey a semantic meaning to unicast routing mechanisms. 
What happens inside the destination host is really a different matter.

Regards,
   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Oct 2021 10:58:08 +1100

> I say this as an IPsec enthusiast who wishes this wasn't true.

Then all IPv6 field immutability while the packet is in flight is also dead.

"Controlled domain" == redefine any field, field semantics, and field
processing we like in an existing protocol, yet claim we're still
using the original protocol.

That has been tacitly endorsed via standards track RFC8986. The Next
Header field is not supposed to be modified in flight per internet
standard RFC8200, yet standards track RFC8986 specifies the behaviour
via PSP.

This SRH compression ID is redefining the IPv6 DA field semantics. It
encodes multiple network hop destinations in the single IPv6
destination address field.

Structured Flow Label -
https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/
is redefining the IPv6 flow label field.

This will be an operational nightmare in the future, when there are
multiple applicable RFCs that conflict with each other. I don't want
to have to spend time getting into arguments with vendors about which
protocol variant RFC their implementation should or shouldn't have to
comply with while I have 1000s, 10s or 100s of 1000s of customers
off-line.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Oct 2021 13:31:52 +1300

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.

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 <[email-masked]> on behalf of Erik Kline <[email-masked]>
> *Date: *Thursday, 14 October 2021 at 19:06
> *To: *Joel M. Halpern <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
> *Subject: *Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression
> 
> Joel,
> 
>  
> 
> (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.)
> On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ <https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/>.
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Oct 2021 14:29:35 +1300

> I can't find anywhere that an interface identifier of zero is forbidden

However, when I assign such an address to a Linux box, it is unpingable, so I'm guessing it breaks neighbor discovery.

Regards
   Brian Carpenter
On 17-Oct-21 13:31, Brian E Carpenter 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.
> 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.)
>>     The SPRING charter has text that is explicit that modifications to 
data
>>     Clearly, understanding the question requires some understanding of 
what
>>     In SRv6, as document in the current RFCs, these are 128 bits.  

>  As
first
>>     encapsulation options which omits the SRH that is not needed as it 
would

---

From: Andrew Alston <[email-masked]>
Date: Sun, 17 Oct 2021 05:38:51 +0000

Mark,

I seriously wonder as I see all this if it wasn’t a mistake to not declare srv6 an entirely new protocol with a new protocol number back at the start of this.

Because it looks more and more like Robert was right when he said that srv6 was not ipv6 - that or we seem to have forgotten the very basics of standardization.

The problem here is that it seems to be a slow drift - and the delta between these minor corruptions of each aspect of the specification in each new draft is small enough that we seem to be content to let it slide.  Unfortunately each time this happens - the delta between the original spec and whatever we have by the time we take all of this combined is well - rather large.

Sooner or later we are going to have to decide - continue to allow the protocol to mutate while still claiming it is ipv6 - or do what maybe should have been done in the first place - give it a new protocol number and let people decide if they want ipv6 or whatever this is.

Andrew

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: ipv6 <[email-masked]> on behalf of Mark Smith <[email-masked]>
Sent: Sunday, October 17, 2021 2:58:08 AM
To: Michael Richardson <[email-masked]>
Cc: 6man WG <[email-masked]>; SPRING WG <[email-masked]>
Subject: All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

Structured Flow Label -
https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/<https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label>
is redefining the IPv6 flow label field.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Oct 2021 16:57:58 +1100

> 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 i…

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.

---

From: Brian Carpenter <[email-masked]>
Date: Sun, 17 Oct 2021 19:04:51 +1300

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, <[email-masked]> wrote:

> > 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.
> >
>
> > > 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
> > >
> > >
> > >
> > > *Subject: *Re: [spring] Question from SPRING regarding
> draft-filsfilscheng-spring-srv6-srh-compression
> > >
> > > Joel,
> > >
> > >
> > >
> cases when, say, an SRH is not present, i.e. to see when typical unicast
> > > 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
> > >
> > >
> > >
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> <
> mis-represented
> > >     https://www.ietf.org/mailman/listinfo/spring <
> https://www.ietf.org/mailman/listinfo/spring>
> > >
> > >

---

From: Michael Richardson <[email-masked]>
Date: Sun, 17 Oct 2021 16:19:47 -0400

> However, when I assign such an address to a Linux box, it is
    > unpingable, so I'm guessing it breaks neighbor discovery.

If you put it on "eth0", it might break ND.

If you put as a /128 address on lo, and arrange routing, then it works just
fine.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sun, 17 Oct 2021 20:28:56 +0000

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.

Darren

On 2021-10-17, 2:06 AM, "ipv6" <[email-masked]> 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, <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter

Regards,
Mark.

> > *From: *spring <[email-masked]<mailto:[email-masked]>> on behalf of Erik Kline <[email-masked]<mailto:[email-masked]>>
> > *To: *Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> > *Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 17 Oct 2021 13:39:51 -0700

Mark,

I think you might be lumping together several disparate proposals in
your general claim that "IPv6 field immutability while the packet is
in flight is also dead".

When SRH was under discussion in 6man there was a lot of work to
define which fields were immutable and that is described in RFC8754.
Those definitions are sufficient to specify proper interaction between
SRH and AH, however RFC8754 knowingly breaks AH as that handling was
not specified. Some of us did object to that, but I suppose expediency
to publish the protocol won out. Nevertheless, there is nothing that
prevents someone from properly defining AH usage with SRH.

As for the IPv6 destination address, it was never defined to be an
immutable field inflight. In fact, the core operation of a routing
header is to overwrite the destination address at each intermediate
destination. NAT also changes the DA in flight, but there is a
significant difference between NAT and the routing header header
operation: when a routing header is set in a packet the sender knows
and indicates the destination address. For the purposes of AH or
transport checksum, both the sender and final receiver use this
address-- there is no ambiguity and the fact that the destination
address is mutable in flight doesn't adversely impact end to end
protocol operations that operate on the addresses.

We have seen various proposals to steal bits or redefine flow label
fields, but IMO it's unlikely any of those will ever get consensus.
Hosts routinely set the flow label as an unstructured value, and
redefining flow label semantics would be a massive retroactive change
in deployment. I would point out though, that the flow label is
technically not immutable in flight, RFC6437 allows it to be modified
by intermediate nodes for "only for compelling operational security
reasons".

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Oct 2021 11:15:03 +1300

> 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

> 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 
> On Sun, 17 Oct 2021, 18:58 Mark Smith, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     <[email-masked] <mailto:[email-masked]>> 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.
>     > > 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 <[email-masked] <mailto:[email-masked]>> on behalf of Erik Kline <[email-masked] <mailto:[email-masked]>>
>     > > *To: *Joel M. Halpern <[email-masked] <mailto:[email-masked]>>
>     > > *Cc: [email-masked] <mailto:[email-masked]> <[email-masked] 
<mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>     > 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.)
>     > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     > >
>     > >     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 fundamental mechanism of the draft is to 
use a single SRH entry
>     > as a
>     > >     32 bits.  Or whatever length.  The 
routing advertisements
>     > are arranged
>     > >     process repeats.  When all that is left 
are 0s, if there is an
>     > SRH, it
>     > >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
<https://www.ietf.org/mailman/listinfo/spring> <https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>>
>     > > [email-masked] <mailto:[email-masked]>
>     > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Oct 2021 11:22:40 +1300

> by intermediate nodes for "only for compelling operational security

Correct, because it was very clear that some firewalls were going to
clobber it whatever we wrote. So we tried to describe behaviour
that would not nullify the usefulness of the field for stateless
load balancing.

As for draft-filsfils-6man-structured-flow-label, the problems in https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc
remain unsolved.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 17 Oct 2021 23:38:43 +0100

> IPv6 architectural description of that field.

the draft, as I understand it, specifies that inside the srv6 limited 
domain, the DA is overwritten in-flight with a locator of configurable 
mask length, followed by a stack containing CSIDs.

On each node that the packet passes through, the router left-shifts the 
stack of CSIDs by a number of bits, which causes an implicit stack pop 
of the CSID list.  The locator remains unchanged.

Once the stack is empty, the DA field is reverted to the original DA.

The question from the point of view of IPv6 architecture is whether the 
modified DA a) represents the ipv6 address of an interface (rfc4291, 
section 2.1) and b) represents the "128-bit address of the intended 
recipient of the packet" (rfc8200, section 3).

The answer to both of these questions seems to be no.

--

If we take the examples in draft-clad-spring-srv6-srh-compression-illus, 
the locator is 2001:db8:000b (block length 48), normally written as 
2001:db8:b::/48.

At no point is there necessarily a node in the network with an interface 
which which is bound to an ip address constructed as 
[locator].[csid1]..[csidN].  It might happen that there was such an 
interface, but this is not necessary for the protocol to function as 
specified.

 From this point of view, the draft does not appear to comply with the 
definition of the destination address field of the ipv6 header, as 
defined in rfc8200.

--

Question b (i.e. whether the address represents the "128-bit address of 
the intended recipient of the packet").  It is presumed that the address 
space carved out by the operator allocates a unique block of IP 
addresses for the locator.  The modified DA will not generally (and 
probably not ever) represent the intended recipient of the packet, so on 
this basis it seems that the draft introduces a semantic change to the 
addressing architecture of ipv6 as defined in rfc4291.

--

In simple terms, the srh compression draft appears to repurpose the ipv6 
DA field as a temporary storage stack.  This changes the semantics of 
the DA field into something different that rfc8200 / rfc4291 aren't 
aware of.

Some people have brought up NAT and mutable ipv6 header fields.  I don't 
see an issue with modifying source or destination IP addresses / ports 
in-flight, as long as they represent actual endpoints as defined in 
rfc8200/4291.  We have 25 years of precedent in the form of NAT, so this 
simply isn't a problem.

What is a problem is changing the semantics of a well-known field to 
mean something else other than what's defined in 8200/4291.  The 
rationale for doing this is not relevant.

On a constructive point, I have no doubt that the authors need space to 
store the SID stack, so it may be better for them to consider using an 
EH for this purpose.  If this were handled in a similar way to how 
standard SRv6 forwards packets using EHs for SID lists, I don't believe 
that there would be an issue for 6man to be concerned about, and as 
there is already running code which uses EHs to determine next-hops for 
SRv6 packets, there is no reason not to do something similar for C-SIDs.

> destination address field represent a modification or extension of the 

Although the syntax remains the same, the draft proposes that the 
semantics of the ipv6 header be modified.  In a SRv6 domain, a packet 
modified as described will do one thing, and outside the domain it mean 
something quite different.

Rather than answering this question directly, let's take the 
heterogeneous brown-field network example provided in:

https://mailarchive.ietf.org/arch/msg/ipv6/LQyfNkJjCEijP0v8mHYIQPBT7-A/

In this network, if a packet has its DA modified as described in this 
draft, then the packet would not necessarily arrive at its endpoint if 
it needed to traverse a section of the network which wasn't srv6 aware. 
If no modification had been made to the ipv6 data plane, then the packet 
would be expected to arrive at its destination.

This is in contrast with standard srv6, which can apparently support 
this style of configuration.

It is true that SRv6 is defined only in terms of its rfc8799 limited 
domain and you could argue that as the limited domain is not properly 
specified according to what the I-D authors intended, that this is a 
configuration problem rather than a protocol problem.

Flip side, this example describes what happens when limited domains hit 
operational reality, i.e. this is an interesting example of why 
modifying data plane semantics is considered to be a red-flag issue from 
the point of view of baseline protocol semantics - things break.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Sun, 17 Oct 2021 17:35:15 -0700

Brian,

Thanks for the explanation concerning why the exception was created. For
the concern that the flow label could be used a a covert channel, was this
a hypothetical possibility or in response to some real events (sending
twenty bits at a time doesn't seem like a very effective covert channel
compared to other methods :-) )

Tom

> As for draft-filsfils-6man-structured-flow-label, the problems in
> https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc
> remain unsolved.
>
>    Brian
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 18 Oct 2021 01:30:01 +0000

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…

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 <[email-masked]>
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

   Brian

use a single SRH entry
routing advertisements
are 0s, if there is an

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Oct 2021 15:53:37 +1300

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

OK, that's helpful.

>> 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.

I'm not sure about that. Is there a risk that ICMP replies sent to such an address might get lost? Standard host stacks identify any such address as a router when they save it in the neighbor cache. My home router declines to answer ICMP pings sent to such an address. (Try pinging fe80::) However, that is not our problem here.

On the other hand, it seems that as the compressed SIDs are shifted out one at a time, we will end up with an effective zero IID at the final recipient. So the DA would then be a subnet router anycast address, according 
to RFC4291. That seems a bit strange and might have unexpected consequences, such as more than one box handling the packet and decapsulating it.

   Brian

> 
>  
> 
> Thanks,
> 
>   Darren
> 
>  
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> *From:* Brian E Carpenter <[email-masked]>
> *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
> 
>  
> 
> 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).
>> On Sun, 17 Oct 2021, 18:58 Mark Smith, <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>
>>     <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> 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
>>     >
>>     > 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/>> <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 <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> on behalf of Erik Kline <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
>>     > > *Date: *Thursday, 14 October 2021 at 19:06
>>     > > *To: *Joel M. Halpern <[email-masked] 
<mailto:[email-masked] <mailto:[email-masked]>>>
>>     > > *Cc: [email-masked] <mailto:[email-masked] <mailto:[email-masked]>> <[email-masked]
> <mailto:[email-masked] <mailto:[email-masked]>>>, [email-masked] <mailto:[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
>>     > > *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
>>     > >
>>     > >
>>     > >
>>     > > 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 <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>> 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/>> <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
>>     > >     [email-masked] <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
>>     > >     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>> <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
>>     > > [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>     > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6> <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>
>>     > > --------------------------------------------------------------------
>>     > >
>>     >
>>     > _______________________________________________
>>     > spring mailing list
>>     > [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>     > https://www.ietf.org/mailman/listinfo/spring

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Oct 2021 16:16:01 +1300

On 18-Oct-21 13:35, Tom Herbert wrote:
> 
> 
> On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, <[email-masked] 
<mailto:[email-masked]>> wrote:
>     >>>
>     >>> Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>     > In fight changing DAs also will break AH protection of the IPv6 header.
>     >>>
>     >> https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/ <https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/>
> Thanks for the explanation concerning why the exception was created. For the concern that the flow label could be used a a covert channel, was this a hypothetical possibility or in response to some real events (sending twenty bits at a time doesn't seem like a very effective covert channel 

This was one of the crucial differences between RFC3967 and RFC6437. As I 
recall, it was started by anecdotal evidence of firewalls zapping the flow label, and then we discussed how to deal with this. For example:

https://mailarchive.ietf.org/arch/msg/ipv6/0T2gPgciSq6qG-2JGBzHvBuVKb8/

It was discussed at length but (almost inevitably) without input from
actual firewall vendors, I believe.

    Brian

> 
> Tom
> 
> 
>     As for draft-filsfils-6man-structured-flow-label, the problems in https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc <https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc>
>     remain unsolved.
> 
>        Brian
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 18 Oct 2021 06:14:37 +0000

Hi Bob, I believe the questions asked by Joel are not relevant to 6man, they are already answered by RFC8754 and RFC8986.

The draft does not place “a list of sids in the IPv6 DA field”.  It places an argument to the active SID in its argument as defined in RFC8986 section 3.1.
3.1<https://datatracker.ietf.org/doc/html/rfc8986#section-3.1>.  SID Format

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   ...snip...
   An SRv6 Endpoint behavior may require additional information for its
   processing (e.g., related to the flow or service).  This information
   may be encoded in the ARG bits of the SID.

   In such a case, the semantics and format of the ARG bits are defined
   as part of the SRv6 Endpoint behavior specification.

Re the IPv6 architectural description of that field, we should recall RFC8754 section 4.3 (below), i.e. the interface vs SID question was answered by 6man.

4.3<https://datatracker.ietf.org/doc/html/rfc8754#section-4.3>.  SR Segment Endpoint Node

   Without constraining the details of an implementation, the SR segment
   endpoint node creates Forwarding Information Base (FIB) entries for
   its local SIDs.

   When an SRv6-capable node receives an IPv6 packet, it performs a
   longest-prefix-match lookup on the packet's destination address.
   This lookup can return any of the following:

   *  A FIB entry that represents a locally instantiated SRv6 SID

   *  A FIB entry that represents a local interface, not locally
      instantiated as an SRv6 SID

2) Does the operation of shifting information around in the IPv6 destination address field represent a modification or extension of the IPv6 data plane.
This draft does not “shift information around in the IPv6 destination address field”
The draft defines a method of processing the active segment in the IPv6 DA, given a well-defined function and argument format.
This is *exactly* as described in RFC8986, and entirely up to the active SID definition.  Whether the active SID retrieves the next SID by
-          looking into the SRH at an offset identified by the argument field of the active SID
-          retrieving it directly from an argument of the active SID
-          looking up an identifier from the argument of the active SID in some stateful local table (ie like RSVP TE)
-          via any other method
it is irrelevant to the IPv6 data plane.

We have defined SRv6 SIDs such that they do not require an SRH be present, nor processed.  RFC8754 section 3.1 says an SRH is not required for an SR source to utilize SRv6 SIDs and their arguments.  The decision to include the SRH is entirely up to the SR source based on its needs.
3.1<https://datatracker.ietf.org/doc/html/rfc8754#section-3.1>.  SR Source Node

   A SR source node is any node that originates an IPv6 packet with a
   segment (i.e., SRv6 SID) in the destination address of the IPv6
   header.  The packet leaving the SR source node may or may not contain
   an SRH.  This includes either:

   *  A host originating an IPv6 packet, or

   *  An SR domain ingress router encapsulating a received packet in an
      outer IPv6 header, followed by an optional SRH.

We have further stated that it is up to an SR source (the thing sending a packet to a SRv6 SID) to determine when a SID list must be preserved or may be removed. For example, via the PSP behavior in RFC8986, or via the reduced SRH from RFC8754.

4.1.1<https://datatracker.ietf.org/doc/html/rfc8754#section-4.1.1>.  Reduced SRH

   When a source does not require the entire SID list to be preserved in
   the SRH, a reduced SRH may be used.

   A reduced SRH does not contain the first segment of the related SR
   Policy (the first segment is the one already in the DA of the IPv6
   header), and the Last Entry field is set to n-2, where n is the
   number of elements in the SR Policy.

Sincerely.
  Darren

On 2021-10-13, 4:12 PM, "ipv6" <[email-masked]> wrote:

Bob & Ole

---

From: Andrew Alston <[email-masked]>
Date: Mon, 18 Oct 2021 06:40:28 +0000

Darren,
 
> The draft does not place "a list of sids in the IPv6 DA field".  It places an argument to the active SID in its argument as defined in RFC8986 section 3.1.  

I agree this is the case with g-srv6 - but this seems to be a stretch in semantics when it comes to usid.

Lets look at the terminology in https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10

This refers to Active uSID, Next uSID and Last uSID - all of which end up in the DA address - that - is a list of SID's - and that - ends up in the DA of the IPv6 packet.

In fact - in section 1 - the introductory section - it says "Any SID in the SID list can carry micro segments" - so there is definitely a SID list - and it certainly ends up in the DA.

This is further demonstrated in section 4.1.1 of that document:

  flavor, when applied to a 48b uSID block and a 16b uSID length is as
   follows:

   2001:db8:0:0N00::/64 bound to the pseudocode shift-and-lookup:
       1.   Copy DA[64..127] into DA[48..111]                  ;; Ref1
       2.   Set DA[112..127] to 0x0000
       3.   Forward the packet to the new DA

So - to claim that there is no SID list in the DA - yeah - there can be some twisting of words and playing on semantics - but lets call a spade a spade - you have a bunch of SID's - in the DA - and you are doing a left shift as per the above example - to take one to active and then forward - and we can couch this in fancy obfuscated pseudocode and fancy words all we like - it doesn't change the reality of the behavior.

Andrew

---

From: [email-masked]
Date: Mon, 18 Oct 2021 08:48:52 +0200

> to RFC4291. That seems a bit strange and might have unexpected consequences, such as more than one box handling the packet and decapsulating it.

Just to be clear. An IPv6 node does not make any assumption about the prefix length. Ref RFC5942.
IID has no meaning unless both the address and associated subnet prefix length is known.

I agree with you though, there appears to be a need for clarification regarding the properties of these addresses.

RFC6052 updated 4291 and had the following:

   When a /32 prefix is used, an all-zero suffix results in an all-zero
   interface identifier.  We understand the conflict with Section 2.6.1
   of RFC4291, which specifies that all zeroes are used for the subnet-
   router anycast address.  However, in our specification, there is only
   one node with an IPv4-translatable IPv6 address in the /64 subnet, so
   the anycast semantic does not create confusion.  We thus decided to
   keep the null suffix for now.  This issue does not exist for prefixes
   larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that
   we recommend in Section 3.3.

Looks like this issue goes back to RFC8986 or even RFC8754(?)

If this is not partiuclar to the srh-compression draft,
could a separate document, updating RFC4291, and clarifying the particular properties of these addresses work?

O.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 18 Oct 2021 08:22:35 +0100

Hi Brian,

Thanks for the additional clarification.  I've cut below to the meat of
what I understand to be your question:

On Sat, Oct 16, 2021 at 10:19 PM Brian E Carpenter <
[email-masked]> wrote:

>  I want to draw a distinction between unicast address bits that are
> arbitrary numbers as far as
> unicast addresses, or the prefix bits following fc00::/7 -- and address
> bits that are meaningful to the routing system, such as fe80::/10 (which
> means "do not route this packet").
>
> Within an SRV6 domain, with RFC8986 and the current draft, we see
> something new: a field which has classically been an arbitrary 64-bit
> number for
> the routing system (the IID field) becomes meaningful to the routing
> system. That's an architectural change, and definitely was not envisaged by
> the IPv6 address architecture.
>
> So, IMHO, the question behind SPRING's question to 6MAN is not whether
> there is an architectural change, but whether this changes matters. In
> particular, will it have impact on legacy devices and software within the
> SRV6 domain, and will it do any damage if it leaks outside the domain?
>
>
Do I understand correctly that you see the same architectural question for
RFC 8986 ("will it have an impact on legacy devices and software within the
SRV6 domain and will it do any damage if it leaks outside the domain")?

Presuming so, the question for RFC 8986 seems to me to be answered within
the document with a reference to rfc8754, Section 5, which has the
deployment model for segment routing spelled out.  Would a similar
applicability statement here be something that helps resolve this?  At
least as far as I can tell, a shift in the formatting to a compressed
format doesn't change the basic difference you call out, so I believe that
it would be very similar if not identical.  But it certainly does no harm
to spell that out.

regards,

Ted Hardie

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 18 Oct 2021 14:42:31 +0000

Dear Andrew,

> The draft defines a method of processing the active segment in the IPv6 DA, given
>  a well-defined function and argument format.
> This is *exactly* as described in RFC8986, and entirely up to the active SID definition.
> Whether the active SID retrieves the next SID by

Sincerely,
  Darren

On 2021-10-18, 2:40 AM, "Andrew Alston" <Andrew.Alston=[email-masked]> wrote:

Darren,

Andrew

---

From: Andrew Alston <[email-masked]>
Date: Mon, 18 Oct 2021 15:10:27 +0000

Darren,

Lets stop playing semantics here.

What you are saying below - and what you said in your original email are not the same thing.  Your email stated that this does not place a list of SRv6 sids in the DA - when you have Locator:sid1:sid2:sid3:sid4 - that's a list of sids - well - in my eyes anyway.  So - let me ask you

In the case of USID - is there a list of sid's in the DA - or not - and if not - what do you call the stack of sids following the locator.
In the case of USID - does as per the above, sid2 -> sid4 move to positions sid1 -> sid3 - irrespective of if sid1 is processed followed by sid2 - does sid2 -> sid4 end up in position sid1 ->sid3 (and if its identical information copied out of the SRH at some point - doesn't matter to me - do you end up with a functional behavior that ends up with with that result)

Really simple yes or no questions with no obfuscation in them.

Andrew

From: ipv6 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, October 18, 2021 5:43 PM
To: Andrew Alston <Andrew.Alston=[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Dear Andrew,

> This draft does not "shift information around in the IPv6 destination address field"

Sincerely,
  Darren

On 2021-10-18, 2:40 AM, "Andrew Alston" <Andrew.Alston=[email-masked]<mailto:Andrew.Alston=[email-masked]>> wrote:

Darren,

Lets look at the terminology in https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10<https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10>

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Oct 2021 09:19:15 +1300

Ted,
On 18-Oct-21 20:22, Ted Hardie wrote:
> Hi Brian,
> 
> Thanks for the additional clarification.  I've cut below to the meat of what I understand to be your question:
> 
> 
> On Sat, Oct 16, 2021 at 10:19 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
>      I want to draw a distinction between unicast address bits that are arbitrary numbers as far as
> Do I understand correctly that you see the same architectural question for RFC 8986 ("will it have an impact on legacy devices and software within the SRV6 domain and will it do any damage if it leaks outside the domain")?

Yes, indeed. It's a bit clearer in my mind now than when we were debating 
that RFC as a draft, but it certainly applies there too.

> 
> Presuming so, the question for RFC 8986 seems to me to be answered within the document with a reference to rfc8754, Section 5, which has the deployment model for segment routing spelled out.  Would a similar applicability statement here be something that helps resolve this?  At least as far as I can tell, a shift in the formatting to a compressed format doesn't change the basic difference you call out, so I believe that it 
would be very similar if not identical.  But it certainly does no harm to spell that out.

In fact the current draft says (section 3):

>>    The compressed Segment List encoding is fully compliant with the
>>    specifications in [RFC8402], [RFC8754] and [RFC8986]

so from a logical point of view, it doesn't appear essential to add this. 
However, it might well help future readers to do so.

Thanks
   Brian

---

From: Andrew Alston <[email-masked]>
Date: Mon, 18 Oct 2021 21:14:50 +0000

Darren,

Just to clarify something about not putting a list of sid’s into the DA.

Firstly – taken from https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-02:

In the terminology:

Compressed-SID container (C-SID container): An entry of the SRH Segment-List field (128 bits) that contains a sequence of C-SIDs.

This is what you are promoting to the DA – how is that not a list.

Secondly – taken from an external source – namely – the lead authors PHD on this – where this first came from – that can be found at https://orbi.uliege.be/bitstream/2268/245292/4/network-programming-phd-final.pdf

Bottom of page 37 – section 4.10.1 in a section entitled “Intutive Idea:  :Program, Micro-Program, Shift and Forward”

It says:

A SID carrying a list of uSIDs is called a uSID carrier. When a uSID carrier is promoted to the outer destination address, the network routes on the uSID-block-Active-uSID prefix. Intermediate nodes on the path to the active uSID may be classic IPv6 nodes: all they see is a packet to a routed subnet.

That – is a list – landing in the DA.

Secondly – on the claim that there is no shift – I refer once again to that document – from which all the u-sid stuff came. Please note the second sentence of this quote: (Last paragraph of page 37)

Once the packet reaches the parent uSID node, the parent node recognizes that the active uSID is a local uN behavior. It then shifts the uSID list within the DA to the left by one uSID position. Hence the next uSID becomes active and the packet is sent on the path to its parent.

That – says it’s a shift.

So – what I would like to ask – is did somehow – a behavior that is defined very clearly in an external document, written by the lead author of the draft, that describes in detail the exact behaviors of uSID – suddenly become – something else – because of terminology – other than what is clearly stated in the above cited work?

Curious to hear the answer on this one

Andrew

Compressed-SID container (C-SID container): An entry of the SRH
      Segment-List field (128 bits) that contains a sequence of C-SIDs.

From: ipv6 <[email-masked]> on behalf of "Darren Dukes (ddukes)" <ddukes=[email-masked]>
Date: Monday, 18 October 2021 at 17:44
To: Andrew Alston <Andrew.Alston=[email-masked]>, Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Dear Andrew,

Sincerely,
  Darren

Darren,

Andrew

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 18 Oct 2021 22:36:36 +0000

Dear Andrew

The simple answer is; the local method a segment endpoint uses to determine the next SID is irrelevant to the IPv6 data plane.

Sincerely,
  Darren

On 2021-10-18, 11:10 AM, "Andrew Alston" <Andrew.Alston=[email-masked]> wrote:

Darren,

What you are saying below – and what you said in your original email are not the same thing.  Your email stated that this does not place a list of SRv6 sids in the DA – when you have Locator:sid1:sid2:sid3:sid4 – that’s a list of sids – well – in my eyes anyway.  So – let me ask you

In the case of USID – is there a list of sid’s in the DA – or not – and if not – what do you call the stack of sids following the locator.
In the case of USID – does as per the above, sid2 -> sid4 move to positions sid1 -> sid3 – irrespective of if sid1 is processed followed by sid2 – does sid2 -> sid4 end up in position sid1 ->sid3 (and if its identical information copied out of the SRH at some point – doesn’t matter to me – do you end up with a functional behavior that ends up with with that result)

Andrew

Dear Andrew,

Sincerely,
  Darren

Darren,

Andrew

---

From: Ron Bonica <[email-masked]>
Date: Tue, 19 Oct 2021 01:59:36 +0000

Darren,

Inline…..

                 Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, October 18, 2021 2:15 AM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[External Email. Be cautious of content]

[RB] And that argument just happens to have a list of SIDs in it! If I put a dozen sausages in a box, they are still sausages 😉

The draft does not place “a list of sids in the IPv6 DA field”.  It places an argument to the active SID in its argument as defined in RFC8986 section 3.1.
3.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8986*section-3.1__;Iw!!NEt6yMaO-gk!Ue_WZnZ8ITVVfoabHpKj-nhJKGVDQ9nJjDMZSDSLUebO5-k6DBhnXV_lNUiarnik$>.  SID Format

4.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8754*section-4.3__;Iw!!NEt6yMaO-gk!Ue_WZnZ8ITVVfoabHpKj-nhJKGVDQ9nJjDMZSDSLUebO5-k6DBhnXV_lNe6TnsRP$>.  SR Segment Endpoint Node

We have defined SRv6 SIDs such that they do not require an SRH be present, nor processed.  RFC8754 section 3.1 says an SRH is not required for an SR source to utilize SRv6 SIDs and their arguments.  The decision to include the SRH is entirely up to the SR source based on its needs.
[RB] RFC 8986 assumes that every packet that traverses multiple segments will have an SRH. With uSID, this is not the case. A packet can traverse a few segments without an SRH. This is described in Section 4.1.1 of the CSID document. And it certainly looks like bit shifting to me!

3.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8754*section-3.1__;Iw!!NEt6yMaO-gk!Ue_WZnZ8ITVVfoabHpKj-nhJKGVDQ9nJjDMZSDSLUebO5-k6DBhnXV_lNUVV81YD$>.  SR Source Node

4.1.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8754*section-4.1.1__;Iw!!NEt6yMaO-gk!Ue_WZnZ8ITVVfoabHpKj-nhJKGVDQ9nJjDMZSDSLUebO5-k6DBhnXV_lNT_Ead2L$>.  Reduced SRH

Sincerely.
  Darren

On 2021-10-13, 4:12 PM, "ipv6" <[email-masked]<mailto:[email-masked]>> wrote:

Bob & Ole

> On Oct 12, 2021, at 8:52 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!Ue_WZnZ8ITVVfoabHpKj-nhJKGVDQ9nJjDMZSDSLUebO5-k6DBhnXV_lNU0qHbri$>.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Oct 2021 17:50:10 +1300

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:

>> just from my as the responsible SPRING co-chair managing this adoption 

>> call.

>> 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.

>> 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

>> The fundamental mechanism of the draft is to use a single SRH entry as 
a

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Oct 2021 18:09:38 +1100

Hi Brian,

> not assigned to a physical interface so RFC 4861 is never invoked.

So I'm guessing you're probably thinking of a router as a physical
device (as most of us will by default), rather than as routing as a
function.

RFC8200 definitions:

"router       a node that forwards IPv6 packets not explicitly
                addressed to itself.  (See Note below.)

   host         any node that is not a router.  (See Note below.)"
(the note is about hosts having multiple interfaces)

(A node doesn't have to be a device, and a device doesn't have to be
physical, so the above are really function descriptions.)

If a router as a physical device has IPv6 addresses that are sent to
the device itself, then the router as a physical device is also
performing host functions. For packets with those "router addresses",
the router as a physical device is not "forward[ing] IPv6 packets not
explicitly addressed to itself. "

In a router as a physical device, the forwarding plane is performing
the router function above. In a router as a physical device, the
"control plane" (really just a fancy name for a host) is performing
host functions on packets that are directly to and from it (BGP, OSPF,
SSH, SNMP etc. packets).

The consequence is that all IPv6 addresses are host addresses, and all
processing of packets at the device that holds a packet's DA is host
processing of the packet.

It is the same in IPv4  - from RFC791, "The internet protocol provides
for transmitting blocks of data called datagrams from sources to
destinations, where sources and destinations are hosts identified by
fixed length addresses."

So these packets with CSID rotating IPv6 DAs are being host processed
by the router (as a device), after the forwarding plane in the router
(as a device) has forwarded the packet to the colocated host function.

(A more practical example to support the above observation. If a
router as a device is bought from a router vendor, and then is run as
a BGP route reflector, meaning it is never in a packet forwarding
path, and therefore never "forwards IPv6 packets not explicitly
addressed to itself" is the router device still a router? Functionally
no, it is a host, even though it looks like a router (as a device).)

Regards,
Mark.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Oct 2021 09:42:21 +0100

Hi Mark,

I updated the subject because I think this is a distinct question, and I've
tried to pull that question into focus by cutting to that text below.  I
hope that's okay.

> explicitly addressed to itself. "
In many deployments the packets sent to the router while it is "performing
host functions" are sent to a distinct interface (or distinct interfaces,
when there is one for each address family).  That interface or those
interfaces typically have distinct security controls and expose different
ports (so that you can ssh in, for example).

I think it would be reasonable to add text on using SID addressing to reach
administrative interfaces.  I think that would work along the lines already
laid out, with the administrative interfaces being outside the SR domain,
but additional thought and text on it might well be useful.

> processing of the packet.

I must disagree with this conclusion.  I think RFC 8504 was written the way
it was to highlight that there is some commonality between hosts and
routers and to set out the node requirements that unite the two.  But there
are clear differences between the processing of a packet by a router and by
a host, with forwarding behavior being chief among them.  To say that all
processing is host processing is to gloss over both an architectural
distinction and the deployed reality I mentioned before.  The reason people
maintain distinct administrative addresses is to ensure that the host
processing and router processing remain distinct.

I think Brian's note is maintaining a distinction that is both generally
important and important for understanding this case.  Speaking personally,
I'd like to retain that understanding.

best regards,

Ted Hardie

> .
> me
> not
> In

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Oct 2021 14:40:38 +0200

All,

I must say that I am not quite sure what is being discussed here.

Today the computer node says linux is also called host.

That host has in the kernel multiple routing tables.

The same very host (or node) is a home for the number of kube pods which in
turn are home for the number of containers. Those run apps.

Same for docker with its network interface of choice.

To further make it real kubernetes CNI can modify packets between
containers/pods and network interfaces in many places (system calls, socket
layer, L4 protocol layer, netfilter, RIB, TC, nic driver or even NIC
itself.

Anything can be changed in the packet as long as kernel helper API allows.

So all discussions that route can do that but the host can not are really
moot. Maybe 20 years ago they could take the floor but sorry no these days
:(

SRv6 IPv6 header can be produced by the end app and inserted into a packet
in the processing pipeline by BPF. Reverse direction can and does happen
too.

And none of the above is about the administrative interface of the hosts.
That's all together a completely different thing - but I am not sure is in
scope of this bigger thread.

Thx,
R.

On Tue, Oct 19, 2021 at 10:43 AM Ted Hardie <[email-masked]> wrote:

> Hi Mark,
>
> I updated the subject because I think this is a distinct question, and
> I've tried to pull that question into focus by cutting to that text below.
> I hope that's okay.
>
> I think it would be reasonable to add text on using SID addressing to
> reach administrative interfaces.  I think that would work along the lines
> already laid out, with the administrative interfaces being outside the SR
> domain, but additional thought and text on it might well be useful.
>
>
>
> I must disagree with this conclusion.  I think RFC 8504 was written the
> way it was to highlight that there is some commonality between hosts and

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Oct 2021 09:02:25 -0700

Mark,

On the other hand, when a node is processing a routing it header it does
forward packets addressed to it self (but not being the final destination).
Processing a router header is intuitively router functionality and not host
functionality. The RFC8200 definition of host and router don't seem to
consider routing headers, perhaps this should be amended to say that a host
is the final destination of the packet.

Tom

---

From: Andrew Alston <[email-masked]>
Date: Tue, 19 Oct 2021 16:11:13 +0000

So – Darren,

Please let me make sure I understand this – what you are saying is that only the active segment in the DA actually matters – there is no list.
You also say – that’s copied out of the SRH in the latest pseudocode you posted.

So – my question now becomes – Why if there is no list – if there is no shift – and if only the active segment matters – do we need the next behavior? Because what this sounds like – is replace – you are taking an active segment – putting it after the locator – and forwarding, and according to my reading of what you are saying – the rest – is pretty irrelevant.

So – why do we need two behaviors at all?

Andrew

From: "Darren Dukes (ddukes)" <ddukes=[email-masked]>
Date: Tuesday, 19 October 2021 at 01:37
To: Andrew Alston <[email-masked]>, Andrew Alston <[email-masked]>, Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Dear Andrew

Sincerely,
  Darren

Darren,

Andrew

Dear Andrew,

Sincerely,
  Darren

Darren,

Andrew

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 19 Oct 2021 17:56:56 +0000

Dear Andrew,

I fear I may be repeating myself. I’ll say once more.

Joel asked two questions, Bob asked for input from 6man, I replied that the answer to both questions is “no”.
The local method an SRv6 segment endpoint uses to determine the next SID, is *irrelevant to the IPv6 data plane*.
This is applicable to any SRv6 segment endpoint.

I provided details in my reply to Bob.
https://mailarchive.ietf.org/arch/msg/ipv6/-AMyz1I0dp22hAiWvmZIOJbVs-o/

Sincerely,
  Darren

On 2021-10-19, 12:11 PM, "Andrew Alston" <Andrew.Alston=[email-masked]> wrote:

So – Darren,

Andrew

Dear Andrew

Sincerely,
  Darren

Darren,

Andrew

Dear Andrew,

Sincerely,
  Darren

Darren,

Andrew

---

From: Andrew Alston <[email-masked]>
Date: Tue, 19 Oct 2021 18:41:06 +0000

And Darren,

Joel asked two questions – I happen to disagree with your view on the answers to those questions, and hence – I am questioning your response to ensure that my understandings are correct.  My understanding of the IETF – is that if someone states a viewpoint – that viewpoint is open to being questioned.  Protocol says – that an issue is valid until addressed – if not resolved.  If I, as a participant in this group, happen to disagree with your view and choose to question my own understanding so that I can be sure that my disagreement and opposition to what you say is correct – that – is perfectly valid.

It is entirely your right to not answer those questions – but – as I said – you and I have very different views on this – very different – and hence – I am asking questions – you can choose to refuse to answer those – that’s ok to – but ask them – I will

Andrew

From: "Darren Dukes (ddukes)" <ddukes=[email-masked]>
Date: Tuesday, 19 October 2021 at 20:57
To: Andrew Alston <[email-masked]>, Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Dear Andrew,

I provided details in my reply to Bob.
https://mailarchive.ietf.org/arch/msg/ipv6/-AMyz1I0dp22hAiWvmZIOJbVs-o/<https://mailarchive.ietf.org/arch/msg/ipv6/-AMyz1I0dp22hAiWvmZIOJbVs-o>

Sincerely,
  Darren

So – Darren,

Andrew

Dear Andrew

Sincerely,
  Darren

Darren,

Andrew

Dear Andrew,

Sincerely,
  Darren

Darren,

Andrew

---

From: Ron Bonica <[email-masked]>
Date: Tue, 19 Oct 2021 20:52:06 +0000

Folks,

In response to Joel's question:

- The placement of a list of SIDs in the IPv6 Destination Address field changes the IPv6 architectural description of that field
- Shifting information around in the IPv6 Destination Address field represents a modification or extension of the IPv6 data plane.

The NEXT-C-SID behavior places a list of SIDs in the IPv6 Destination Address field and shifts information around in that field. The following compression solutions do not exhibit this behavior:

- REPLACE-C-SID
- VSID
- UIDSR
- CRH

Given that four other compression solutions are available, and given that each satisfies the most significant requirements identified by the SPRING Design Team, I don't see the motivation to standardize NEXT-C-SID. Maybe somebody can explain? This question is not rhetorical.

Having made this bold assertion, I should probably justify it.  IEN19 (https://www.rfc-editor.org/ien/ien19.txt)  makes a distinction between an address and a route. An address indicates where something is (i.e., its location). A route tells you how to get to a location.

Data planes use addressing and routing information to send information from one node to another. The following distinguishes one data plane from another:

- The routing and addressing information that it encodes in each packet
- The headers that it uses to encode routing and addressing information in each packet
- The routing and addressing information that it stores in transit nodes

In traditional IPv6 (i.e., prior to RFC 8754):

- Addressing information is encoded in the IPv6 Source and Destination Address fields
- Some routing information is stored in transit nodes (i.e., in the FIB)
- Some routing information can be encoded in a Routing extension header.

Neither RFC 8754 nor RFC 8986 changed any of that. A classic SRv6 SID is still an address. It indicates the location of an instruction that is instantiated on a node. It does not indicate how to get to that instruction. So, it is still an address. It is not a route.

By contrast, the NEXT-C-SID changes the semantics of the IPv6 Destination Address. Consider an SR path that contains only a few segments. In RFC 8754:

- Addressing information is encoded in the IPv6 Source and Destination Address fields
- Some routing information is stored in transit nodes (i.e., in the FIB)
- Some routing information can be encoded in a Routing extension header.

When NEXT-C-SID is introduced, the Routing extension header can disappear entirely. So, where did the routing information that it once contained go? The FIB didn't change! We must be encoding it somewhere! So, any attempt to say that we are not encoding routing information in the IPv6 Destination Address field can be easily dismissed. Furthermore, encoding routing information in an address field *does* change the architectural description of that field.

We have heard that the Destination Address arguments are not a SID list. This claim is suspicious, at best. This routing information used to be a SID list when it resided in the SRH. Why is it no longer a SID list when we move it into Destination Address arguments? 

Shifting bits in the destination address is a necessary consequence of  changing the Destination Address semantics. It represents a modification or extension of the IPv6 data plane.

                                                                                               Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Wednesday, October 13, 2021 4:12 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Bob & Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Oct 2021 10:13:51 +1300

On 20-Oct-21 05:02, Tom Herbert wrote:
> 
> 
> On Tue, Oct 19, 2021, 12:10 AM Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Brian,
> 
> On the other hand, when a node is processing a routing it header it does forward packets addressed to it self (but not being the final destination). Processing a router header is intuitively router functionality and not host functionality. The RFC8200 definition of host and router don't seem to consider routing headers, perhaps this should be amended to say that a host is the final destination of the packet.

That is the case even if the host is also a router and if it recognises the DA of a packet delivered to it in its role as a router as a DA that it 
handles in its role as a host. (In Linux jargon, that means "if the DA is 
assigned to its loopback interface", but that is an implementation detail.)

The point here is that the *previous* router doesn't know that the DA is assigned that way; it just forwards the packet to whoever announced the longest-matching prefix. It *does not* send the packet to DA.

   Brian

>     > >> source of information is the draft itself.  I was asked to provide extra
<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Oct 2021 10:22:53 +0100

Hi Ron,

A couple of questions below,
On Tue, Oct 19, 2021 at 9:53 PM Ron Bonica <rbonica=

> - Some routing information can be encoded in a Routing extension header.
Just to confirm the scope of your comments, you're talking specifically
about unicast packets, is that right?

> Neither RFC 8754 nor RFC 8986 changed any of that. A classic SRv6 SID is
> still an address. It indicates the location of an instruction that is
> instantiated on a node. It does not indicate how to get to that
> instruction. So, it is still an address. It is not a route.
>

At least as I read it, RFC 8986 describes how to use segment identifiers to
encode something a bit more expansive than what you describe.  This is one
statement that leads me to that description:

    This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128, then
   the remaining bits of the SID MUST be zero.

   A locator may be represented as B:N where B is the SRv6 SID block
   (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the
   identifier of the parent node instantiating the SID.

   When the LOC part of the SRv6 SIDs is routable, it leads to the node,
   which instantiates the SID.

   The FUNCT is an opaque identification of a local behavior bound to
   the SID.

When you say classical SRv6 SIDs are addresses, do you mean that the whole
LOC:FUNCT:ARG should be understood as an address?

Thanks,

Ted Hardie

>
> By contrast, the NEXT-C-SID changes the semantics of the IPv6 Destination
> Address. Consider an SR path that contains only a few segments. In RFC 8754:
>
> When NEXT-C-SID is introduced, the Routing extension header can disappear
> entirely. So, where did the routing information that it once contained go?
> The FIB didn't change! We must be encoding it somewhere! So, any attempt to
> say that we are not encoding routing information in the IPv6 Destination
> Address field can be easily dismissed. Furthermore, encoding routing
> information in an address field *does* change the architectural description
> of that field.
>
> We have heard that the Destination Address arguments are not a SID list.
> This claim is suspicious, at best. This routing information used to be a
> SID list when it resided in the SRH. Why is it no longer a SID list when we
> move it into Destination Address arguments?
>
> Shifting bits in the destination address is a necessary consequence of
> changing the Destination Address semantics. It represents a modification or
> extension of the IPv6 data plane.
>
>
>                      Ron
>
>
> Subject: Re: [spring] Question from SPRING regarding
> activities regarding the document.  Therefore, this message is coming just
> from my as the responsible SPRING co-chair managing this adoption call.
> >
> 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.)
> >
> 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.
> >
> destination address field represent a modification or extension of the IPv6
> data plane.
> >
> 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.
> >
> 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.
> >
> behaviors (decapsulate and forward is one example).  They can have flavors
> such as where the SRH is removed.
> >
> packets on the wire.  The document under discussion provides three flavors
> of compression.
> >
> 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.
> >
> 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.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 20 Oct 2021 13:13:33 -0700

Hi Brian,
I've got some questions about what you've said:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2021 14:18:05 +1300

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:
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 21 Oct 2021 14:18:31 +0000

Hi Greg,

Your question is not clear to me.
Can you try to restate it with the flavors and behaviors from the draft in question?

Darren

On 2021-10-20, 4:15 PM, "ipv6" <[email-masked]> wrote:

Hi Brian,
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards
    Brian

a

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 21 Oct 2021 19:00:47 -0400

Brian

Thank you for very eloquently explaining at least how an adjacency sid
strict path end.x endpoint behavior does not violate any IPv6 specification.

Also that CSID draft at least for end.x strict paths does not in any way
change the IPv6 data plane.

Kind Regards

Gyan

On Tue, Oct 19, 2021 at 5:39 PM Brian E Carpenter <
[email-masked]> wrote:

> That is the case even if the host is also a router and if it recognises
> the DA of a packet delivered to it in its role as a router as a DA that it
> The point here is that the *previous* router doesn't know that the DA is
> assigned that way; it just forwards the packet to whoever announced the
> longest-matching prefix. It *does not* send the packet to DA.
>
>    Brian
>
> >
> > Tom
> >
> >
> >     Regards,
> >     Mark.
> >
> >     > > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> >     > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 21 Oct 2021 18:57:51 -0400

Hi Darren

What Greg is asking is if the SID is a prefix SID End and not adjacency SID
End.x, so now the common prefix is needed to ECMP steer the flow  to the
prefix SID which uses the common prefix,  which may in this case be mutated
due to shifting of SIDs in GSID container.

Kind Regards

Gyan
On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) <ddukes=
[email-masked]> wrote:

> 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
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 22 Oct 2021 03:12:00 +0000

Hi Gyan,

Sorry I don’t understand the case you mentioned. Could you please provide an easy example? How a SID will be shifting in a GSID container?

Respect,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Friday, October 22, 2021 6:58 AM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Darren

What Greg is asking is if the SID is a prefix SID End and not adjacency SID End.x, so now the common prefix is needed to ECMP steer the flow  to the prefix SID which uses the common prefix,  which may in this case be mutated due to shifting of SIDs in GSID container.

Kind Regards

Gyan
On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Darren

On 2021-10-20, 4:15 PM, "ipv6" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Regards,
Greg

Regards
    Brian

a

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 22 Oct 2021 05:05:44 +0000

Hi Gyan and Greg.

Gyan I’m sorry but i don’t see a question in your email. I’ll go back to Greg.

While I’m not exactly sure what is being asked, I will say that Brian is correct for every Srv6 SID behavior (not just csid flavors) when he says the following about their arguments (lowest 64 bits in the ipv6 Dest addr.

“They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens).”

I hope this helps.

Darren

________________________________
From: Gyan Mishra <[email-masked]>
Sent: Thursday, October 21, 2021 7:03 PM
To: Darren Dukes (ddukes)
Cc: Brian E Carpenter; Greg Mirsky; [email-masked]; [email-masked]
Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Darren

Kind Regards

Gyan

Darren

Hi Brian,

Regards,
Greg

Regards
    Brian

a

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

---

From: Erik Kline <[email-masked]>
Date: Fri, 22 Oct 2021 16:17:24 -0400

Joel,

I'm afraid we failed to meet this deadline, my apologies.  But we should
have an answer for you in the first part of next week.

Thank you (and everyone) for your continued patience,
-Erik, Eric, Bob, and Ole

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 Oct 2021 21:38:51 +0000

Folks,

According to RFC 8200, "The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination." However, when NEXT-C-SID is used, there are scenarios where:

- A packet contains an SRH
- The SRH does not contain list of one or more intermediate nodes to be "visited" on the way to a packet's destination.
- The SRH contains non-routing (i.e., OAM, Security) information.

Or, stated in a more general way:

- The routing header doesn't contain any routing information
- But the routing header does contain non-routing information

This seems to be a change to the IPv6 data plane.

                                                                  Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Wednesday, October 13, 2021 4:12 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Bob & Ole

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 23 Oct 2021 16:22:49 -0400

Hi Chengli

Please see my reply to Darren about the pseudocode update to the draft.

I highly recommend updating the draft per Darren’s updates,  as this change
will really helps us understand the next and replace pseudocode processing
as most of the questions all related to indexing of the bits within the SRH
SID being copied to DA.  I have been referring to uSID draft for my Next
and G-SID got replace which maybe slightly different then the C-SID draft.
So this update will be extremely helpful to the WG.

I believe what Greg and I were referring to is End versus End.x and how
End.x adj-sid there is no change as to what bits are referenced in SRH SID
when copied to DA, however with End prefix sid their is pseudocode change
as to bits referenced in the Argument portion of the SRH C-SID and both
next and replace reference different bit ranges within the Argument
container.

It has been mentioned on some of the threads that the 128 bit SID, argument
portion IID portion of the IPv6 address may appear as funky address as it
may contain multiple CSIDs.  So a question to 6MAN related to RFC 8200 IPv6
specification violations is being addressed by folks in the WG.

So an outstanding question is if the list of SIDs in the SRH as SID entries
in the SRH per IPv6 specification do they all have to be valid IPv6
address, does it have to be a valid address in the SRH for the active SID
or does only what is copied from SRH Active SID to DA, is it that  only
what is copied needs to follow IPv6 specification as far as IPv6 address
format.

Kind Regards

Gyan
On Thu, Oct 21, 2021 at 11:12 PM Chengli (Cheng Li) <[email-masked]> wrote:

> Hi Gyan,
>
>
>
> Sorry I don’t understand the case you mentioned. Could you please provide
> an easy example? How a SID will be shifting in a GSID container?
>
>
>
> Respect,
>
> Cheng
>
>
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Gyan Mishra
> *Sent:* Friday, October 22, 2021 6:58 AM
> *To:* Darren Dukes (ddukes) <ddukes=[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: Typo correction Re: Question from SPRING regarding
> What Greg is asking is if the SID is a prefix SID End and not adjacency
> SID End.x, so now the common prefix is needed to ECMP steer the flow  to
> the prefix SID which uses the common prefix,  which may in this case be
> mutated due to shifting of SIDs in GSID container.
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 24 Oct 2021 10:51:15 -0700

Hi Daren,
thank you for responding to my question. Is 64-bits routable prefix in the
DA an implicit prerequisite of the C-SID solution?

As to my question about what Brian referred to as a "funny" part. In
Section 6 we read:
   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths.  A
   C-SID length of 16-bit is recommended.
and then:
   The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are
   16, 32 or 48 bits.

Now, it seems to me that there are many possibilities of getting the
"funny" part of C-SID into a routable space of the DA. For example, an
operator, following the recommendation of the C-SID specification, uses
16-bit NEXT-C-SID in combination with, for example, 32 bits block size. As
a result, 16 bits of "funny" part, i.e., another NEXT-C-SID, are in the
routable space.
Am I missing something? Thank you for your consideration.

Regards,
Greg

On Thu, Oct 21, 2021 at 10:06 PM Darren Dukes (ddukes) <[email-masked]>
wrote:

> While I’m not exactly sure what is being asked, I will say that Brian is
> correct for every Srv6 SID behavior (not just csid flavors) when he says
> the following about their arguments (lowest 64 bits in the ipv6 Dest addr.
>
> “They are invisible to routing (which is done based on the prefix) and
> invisible to neighbor discovery (because it never happens).”
>
> I hope this helps.
>
> Darren
>
> ------------------------------
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Thursday, October 21, 2021 7:03 PM
> *To:* Darren Dukes (ddukes)
> *Cc:* Brian E Carpenter; Greg Mirsky; [email-masked]; [email-masked]
> *M 301 502-1347 *

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 25 Oct 2021 01:56:20 +0000

Hi Greg.

You ask “Is 64-bits routable prefix in the DA an implicit prerequisite of the C-SID solution?”

The answer is no.

In the rest of your query i think you are asking how IPv6 packet forwarding works (I.e, based on prefix).

Recall the compressed SIDs in the draft are SRv6 SID with a locator function and arg like any other. Rfc8986 section 3 does a good job of describing this for all SRv6 SIDs. If you see something missing, please elaborate.

Darren

________________________________
From: Greg Mirsky <[email-masked]>
Sent: Sunday, October 24, 2021 1:51 PM
To: Darren Dukes (ddukes)
Cc: Gyan Mishra; Brian E Carpenter; [email-masked]; [email-masked]
Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Daren,
thank you for responding to my question. Is 64-bits routable prefix in the DA an implicit prerequisite of the C-SID solution?

As to my question about what Brian referred to as a "funny" part. In Section 6 we read:
   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths.  A
   C-SID length of 16-bit is recommended.
and then:
   The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are
   16, 32 or 48 bits.

Now, it seems to me that there are many possibilities of getting the "funny" part of C-SID into a routable space of the DA. For example, an operator, following the recommendation of the C-SID specification, uses 16-bit NEXT-C-SID in combination with, for example, 32 bits block size. As a result, 16 bits of "funny" part, i.e., another NEXT-C-SID, are in the routable space.
Am I missing something? Thank you for your consideration.

Regards,
Greg

On Thu, Oct 21, 2021 at 10:06 PM Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan and Greg.

I hope this helps.

Darren

________________________________
From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 21, 2021 7:03 PM
To: Darren Dukes (ddukes)
Cc: Brian E Carpenter; Greg Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Darren

Kind Regards

Gyan

Darren

Hi Brian,

Regards,
Greg

Regards
    Brian

a

Gyan Mishra

M 301 502-1347

---

From: Erik Kline <[email-masked]>
Date: Mon, 25 Oct 2021 12:39:12 -0700

[replying on this thread as is has more folks cc'd]

Joel,

First: thank you to everyone who has commented, clarified, sat for
meetings, and reviewed and edited text, often repeatedly.  It is very much
appreciated.

This reply is on behalf of the 6MAN chairs and INT ADs.

-- Erik, Éric, Bob, Ole

[1] Does the placement of a list of SIDs in the IPv6 DA field change the
IPv6 architectural description of that field?

It is understood that from the perspective of an IPv6 transit node the DA
field remains a valid DA, and from the perspective of an SR-aware node the
DA remains a SID of the LOC:FUNC:ARG form of RFC 8986.  On the surface,
then, these would not appear to represent any change to the IPv6 data plane
from currently published specifications.  However, this new category of
address seems as though it can in fact go against current specifications in
certain circumstances.

SIDs of the RFC 8754 and RFC 8986 form can reasonably be expected to obey
general unicast semantics: RFC 8986 section 4.1.1 permits Endpoint handling
of any inner payload type that is “allowed by local configuration” and even
explicitly gives the example of “an operator might permit pinging of SIDs.”
 In the case of ICMPv6 Echo Replies specifically RFC 4443 section 4.2
places requirements on the source address of the reply: it MUST be a
unicast address and MUST be the same as the DA if the DA was unicast
otherwise another unicast SA is chosen if the DA was an anycast or
multicast address.

In the SR C-SID topology A--B--C--D, sending a ping from A to D, could in
theory be done two ways: (1) ping D via SR policy B,C or (2) ping
LOC:FUNC:B:C:D (the SID of B with a set of CSIDs as the argument). In the
first case the ping is sent to the final destination D, via an SR path. In
the second case, the ping is sent to the final destination LOC:FUNC:B:C:D.
The IPv6 destination address as observed on the wire between A and B
(LOC:FUNC:B:C:D) and on reception at D (D::) will be the same in both
cases.  In the first case, the ICMP checksum based on address D is valid
and an ICMP reply will be sent from D to A.  In the second case though, the
ICMP echo request packet will have an invalid ICMP checksum and will be
dropped.

Can an IPv6 destination address when it's a C-SID (an “End with Next SID
arguments”) behave like a normal IPv6 end-point? Based on this, we may have
some new category of addresses and we feel the characteristics of SRv6
C-SID addresses should be more clearly defined.  We think that any
architectural issues can be resolved with such a document as outlined in
[A] below.

[2] Does the operation of shifting information around in the IPv6
destination address field represent a modification or extension of the IPv6
data plane?

The use of a SID with an ARG with a series of C-SIDs to generate the next
SID (a.k.a. “shifting”) form of compression (NEXT-C-SID) has an additional
deviation from the expected behavior of unicast addresses in the IPv6 data
plane, primarily by introducing a mechanism that achieves the objectives of
an SRH without requiring the presence of an SRH (section 4.1 of RFC 8754)
or without requiring the existence of Segment List in an attached SRH
(reduced SRH per section 4.1.1 of RFC 8754).

With existing SIDs, with REPLACE-C-SID behavior, and with NEXT-C-SID
behavior with a complete SRH, an ICMP error packet generated in response
to, for example, a traceroute packet with an attached SR policy can
trivially be correlated by the error receiver if the invoking packet
payload contains a sufficient portion of the SRH (section 5.4 of RFC 8754).

In the case of C-SIDs, the original sender can correlate the ICMP error by
doing a lookup in the segment prefix list of the SRH or in the DA and
finding the last SID representing the final destination as the final
destination is guaranteed to always be present even in the absence of SRH.
The behavior required of the original sender needs to be described in the
C-SID draft.

Beyond the concerns and questions raised in this response so far, within an
SR domain or set of cooperating SR domains, where restrictions on behavior
can be clearly defined and documented, these changes are limited to the
SRv6 data plane.

To summarize: we do not object to C-SID behavior work continuing in SPRING,
we simply need a clarifying document described in [A].

---

Next steps for consideration:

[A] A separate 6MAN document to clarify and categorize SRv6 SIDs is
needed.  We are happy to work to find authors for this document.

The document should explain SIDs’ deviation from RFC 4291 (probably
likening them to other addresses within prefixes handled by some virtual
network function, like NAT64 prefixes, and clarify that they are not
assigned to an interface) and capture many of the observations like those
in Brian Carpenter’s recent email [BC].  We think the document should also
clarify when a SID can appear in the Source Address field vs. when it can
only appear in the Destination Address field, and whether such a
distinction should exist. It should describe the behaviour of IPv6
addresses in the case of C-SIDs (SIDs “End with Next SID args”). The
document should also make it clear which parts are documenting existing
behavior of RFC 8754 and RFC 8986 SIDs -- therefore not really up for
extended debate -- and hopefully lay the framework for understanding any
future categories of SIDs (like whatever is coming at us next after C-SIDs)
that are in development.

This proposed “SRv6 SID Addressing Clarifications” 6MAN document should be
a normative reference for final C-SID publication.

[B] We think there are also operational considerations that warrant
attention prior to standardization.  Primarily we are concerned that there
is no analog to the SRH. SegmentsLeft field, i.e., no “compressed segments
left” field. The definition of the SRH.SegmentsLeft field points to the
definition from RFC 8200 section 4.4, which says it’s the “number of
explicitly listed intermediate nodes still to be visited before reaching
the final destination.”  Previously, there was a 1:1 mapping between this
text and the list of IPv6 addresses in the SegmentList array.  This
definition should be reviewed and updated for the compressed information
case.

Relatedly, the semantic intent might be restored by adding some indication
in the SRH of the size and number of the compressed SIDs.  We suspect this
would aid the usefulness of analysis of a packet capture: a captured packet
in tcpdump/wireshark could be dissected to show helpful information without
additional control plane knowledge.  Otherwise some means of injecting
control plane information into network diagnostics would be needed.

[C] We also suggest that, as SID/C-SID behaviors could be confused with
existing unicast/anycast address behaviour, it might be worth considering
isolating SIDs to a dedicated prefix.  RFC 4291 and other documents (e.g.,
RFCs 6052, 7343, ...) put addresses with different properties into defined
prefixes, and SIDs/C-SIDs could be similarly compartmentalized into a
well-defined prefix (e.g., a /16 to be requested of the IANA).  If no
dedicated prefix is used then the rationale should be documented (probably
in the same document mentioned in [A]).

[BC] https://mailarchive.ietf.org/arch/msg/ipv6/37bH3Ag7jaNgKwnZY_mKIxWRwdM/

---

From: Erik Kline <[email-masked]>
Date: Tue, 26 Oct 2021 10:56:21 -0400

Joel,

One thing that could have been more clear (of many such things, no doubt)...

> needed.  We are happy to work to find authors for this document.

... we have taken this action item to find authors for the 6MAN SRv6 SIDs
document.  We'll start reaching out to folks shortly.