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