To me the easiest option here is to simply configure on each node selected compression schema for the domain. Do you see anything wrong with it ?
On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Robert, > sorry, but it doesn't seem to address my concern. My question is not > about mixing compression flavors in the same SRH (that is an interesting > case of its own). I am asking how a node that supports all the flavors > defined in the draft would parse an SRv6 packet with compressed SIDs in the > SRH. The impression I've got so far, is that is not possible for a node to > process a SID correctly without preconditions of "planning". In other > words, a controller constructs the list on the assumption that each node > supports one and only one flavor of CSID compression. Thus, I can conclude, > that the defined flavors are mutually exclusive and thus are different data > plane techniques of the SRv6 SID compression. > > Regards, > Greg > > On Tue, Oct 5, 2021, 14:41 Robert Raszuk <rob...@raszuk.net> wrote: > >> Greg, >> >> SRH should have an equal size SIDs. That notion applies to compress SIDs. >> Mixing multiple flavors in a single domain node to node seems of no use to >> me. Within your domain you are subject to the domain architecture which is >> the key factor what compression scheme is chosen. >> >> Across domains (say you own N domains) the compressed SID size may vary. >> >> Does this answer your and maybe Ron's question ? >> >> Thx, >> R. >> >> >> On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky <gregimir...@gmail.com> >> wrote: >> >>> 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
