Hi Francois, you've said that different flavors of C-SID can be present not only in the same SRH but also in the same C-SID container. The latter case got me thinking about several potential scenarios. Have to admit that I got stuck trying to understand how they can work. I hope you can help me out. Please consider the two cases described below.
Consider, for all cases, that we are handling a container with entries A, B, C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors. Case 1: Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID flavor. When A is processed, B will be copied into the IPv6 DA, retaining the prefix before A in the container. So far, so good. Then, when the packet arrives at the node that processes B, it will say "NEXT". The remaining bits will be? I thought zero, but actually, it will presumably be two bits with the value two? So the subsequent behavior will shift that two up? Even if the NEXT-C-SID flavor guesses that the two should be zero, it would skip C and D and pick up the entry from the next C-SID container in the SRH. So it seems to either work wrong or work oddly? Case 2: Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D upwards in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will interpret the upper bits of the C C-SID as the arg for selecting the position in the C-SID container to pull an entry from. It will also modify the C C-SID to perform the decrement it thinks it needs. It will then overwrite itself with the randomly chosen entry from the container. It seems that neither scenario works. At least, I cannot figure out how it can work. I would greatly appreciate it if you could have a look and clarify it for me. Regards, Greg On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad) <fc...@cisco.com> wrote: > Hi Greg, > > > > Thank you for the confirmation. I am glad that the matter of combining > C-SIDs of different flavors is clear now. > > > > Thanks, > > Francois > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Thursday, 7 October 2021 at 20:15 > *To: *Francois Clad (fclad) <fc...@cisco.com> > *Cc: *Robert Raszuk <rob...@raszuk.net>, Ron Bonica <rbonica= > 40juniper....@dmarc.ietf.org>, James Guichard < > james.n.guich...@futurewei.com>, SPRING WG <spring@ietf.org>, > spring-cha...@ietf.org <spring-cha...@ietf.org> > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > > thank you for your detailed response and confirming that C-SIDs of > different flavors/behavior may be present in the same SRH and even the same > CSID container. I've noticed Ron's proposal as I was trying to formulate my > question. His proposal highlighted what I am trying to understand - the > relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The > WG has adopted the compression analysis draft > <https://datatracker.ietf.org/doc/draft-ietf-spring-compression-analysis/>, > and the updates and an additional analysis Ron proposed will keep the > discussion and decision-making process on the firm technical foundation. > > > > Regards, > > Greg > > > > On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) <fc...@cisco.com> > wrote: > > Hi Greg, > > > > It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the > segment list in the SRH. It learns about the available SIDs in the network > with their associated behavior and flavors via control plane and/or > management plane protocols, as described in Section 8 of RFC 8986, and > selects the SIDs that are the most appropriate for the segment list. > > > > Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes > the pseudocode of a locally instantiated SID when it receives a packet > matching that SID. The SR Segment Endpoint Node does not need to bother > about the behavior/flavor of the subsequent SRv6 SIDs. > > > > This SRv6 logic applies to the C-SID flavors as well. The choice of > flavors for the SIDs in the SID List is up to the SR Source Node. > > > > It is indeed possible to mix SIDs of different C-SID flavors in the same > SRH, and even in a single C-SID container. > > > > Thanks, > > Francois > > > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Wednesday, 6 October 2021 at 19:19 > *To: *Francois Clad (fclad) <fc...@cisco.com> > *Cc: *Robert Raszuk <rob...@raszuk.net>, Ron Bonica <rbonica= > 40juniper....@dmarc.ietf.org>, James Guichard < > james.n.guich...@futurewei.com>, SPRING WG <spring@ietf.org>, > spring-cha...@ietf.org <spring-cha...@ietf.org> > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > > thank you for the clarification. It is still not clear how a node selects > which flavor of CSID to use on the next compressed CSID that may happen > also be in the next CSID container. As I understand it, a CSID container > must use the same flavor of compression but CSID containers with different > compression flavors in the same SRH are allowed. Is that correct > understanding? > > > > Regards, > > Greg > > > > On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) <fc...@cisco.com> > wrote: > > Hi Greg, > > > > A node that supports this draft in its entirety can instantiate SRv6 SIDs > (e.g., End and End.X SIDs) with any of the three C-SID flavors. > > > > In particular, a node can instantiate multiple SRv6 SIDs bound to > different C-SID flavors, possibly with different C-SID lengths. It can also > instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986. > > > > As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, > upon receiving an IPv6 packet with a destination address matching a FIB > entry that represents one of these locally instantiated SIDs, the node > processes the packet according to the behavior (and flavor(s)) (i.e. > pseudocode) of that SID. > > > > RFC 8754 and 8986 have already standardized these mechanisms and the C-SID > draft only leverages the same SRv6 dataplane to introduce new endpoint > flavors for compression. > > > > > > Francois > > > > *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Tuesday, 5 October 2021 at 23:37 > *To: *Robert Raszuk <rob...@raszuk.net> > *Cc: *Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>, James Guichard < > james.n.guich...@futurewei.com>, SPRING WG <spring@ietf.org>, > spring-cha...@ietf.org <spring-cha...@ietf.org> > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Robert, > > as I understand it, you believe everything that is written in the draft. I > hope you can help me find an answer to one simple question: > > Can a node that supports this draft in its entirety, i.e., supports all > "flavors" defined in the document, process received SRv6 packet with the > SRH encoded according to the specification? > > So far, the proponents of the draft referred to "planning" how flavors of > SRv6 SID compressed. To the best of my understanding, that is is a clear > demonstration of the incompatibility between flavors defined in the CSID > draft. Regardless of what is written in it. > > > > Regards, > > Greg > > > > On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <rob...@raszuk.net> wrote: > > Ron & SPRING WG chairs, > > > > Through this discussion we first have seen a debate if we need one or more > data planes to compress SIDs in SRv6. WG clearly stated we need one. > > > > Following that we have observed a first terminology shift to see if asking > how many solutions should be supported will work any better. To that many > WG members clearly stated that they support one solution. > > > > Well please notice that the draft in question in its introduction states: > > > > Abstract > > This document defines a compressed SRv6 Segment List Encoding in the > Segment Routing Header (SRH). *This solution* does not require any SRH > data plane change nor any SRv6 control plane change. *This solution* > leverages the SRv6 Network Programming model. > > > > So based on my understanding of English the entire draft talks about a > single solution. > > > > Then suddenly a new question popped up: how many behaviours are > acceptable. > > > > I bet number of folks including myself said "one" keeping in mind previous > discussions and the definition of "one" meaning based on the SRv6 data > plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. > > > > Interestingly enough the draft in question defines not behaviours but > flavors as new variants of the already defined behaviors in Standards Track > RFCs. Namely it defines: > > > > 4.1. NEXT-C-SID Flavor > > 4.2. REPLACE-C-SID Flavor > > > > The newly defined behaviour End.XPS is optional. > > So if there is anything to ask here is to check if WG is ok with two > flavors or not. I do not recall that question has ever been asked formally > during the WG adoption call. > > > > With that let's note that optimal compressed SID size may be different > network to network. One size does not fit all. Draft says: > > 6.1. C-SID Length > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > * C-SID length of 16-bit is recommended.* > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > * A C-SID length of 32-bit is recommended.* > > > > While I personally think 8-bit should be an option, if we choose a single > flavor we will introduce suboptimality for no good reason. Hardware > capable of supporting any flavor clearly can do LPM on locator. Also > hardware capable of supporting one flavor can support few other flavors as > this is pretty much just an offset game. > > > > Kind regards, > > Robert > > > > > > > > On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica= > 40juniper....@dmarc.ietf.org> wrote: > > Pablo, > > > > Ae you sure? Please look at the question as Joel asked it ( > https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ > ). > > > > > Ron > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
