Hi Greg, Your understanding is correct. The C-SID flavors cannot be randomly mixed within the same C-SID container.
We can clarify the details related to the combination of flavors in a C-SID container in an upcoming version of the draft. For example, the last entry of a C-SID container can carry a C-SID bound to any behavior, including one with another C-SID flavor. Thanks, Francois From: Greg Mirsky <gregimir...@gmail.com> Date: Friday, 8 October 2021 at 22:21 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, 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<mailto: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<mailto:gregimir...@gmail.com>> Date: Thursday, 7 October 2021 at 20:15 To: Francois Clad (fclad) <fc...@cisco.com<mailto:fc...@cisco.com>> Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>, James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>, spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> <spring-cha...@ietf.org<mailto: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<mailto: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<mailto:gregimir...@gmail.com>> Date: Wednesday, 6 October 2021 at 19:19 To: Francois Clad (fclad) <fc...@cisco.com<mailto:fc...@cisco.com>> Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>, James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>, spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> <spring-cha...@ietf.org<mailto: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<mailto: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<mailto:spring-boun...@ietf.org>> on behalf of Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Date: Tuesday, 5 October 2021 at 23:37 To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Cc: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>, James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>, spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> <spring-cha...@ietf.org<mailto: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<mailto: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<mailto: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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
