Adding to this Robert, indeed SRv6 defines many behaviors. The question asked about a single ‘behavior’ could really only be interpreted as asking about single ‘solution’, as you understood, since a single ‘behavior’ in SRv6 is non-sensical. The requirements draft section 4.2 alone requires multiple behaviors be supported, and multiple compression levels in 4.4.4.
Darren On 2021-10-05, 4:24 PM, "spring" <spring-boun...@ietf.org> 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 https://www.ietf.org/mailman/listinfo/spring
