That's not the case. You can map locator prefix to specific compression schema used as an example ... This is pure implementation choice - I would say vendor's secret sauce.
On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky <gregimir...@gmail.com> wrote: > I am not asking how to deal with the fact that the mode cannot manage > different flavors using just information that is in the packet. I am > pointing that out and you are trying to avoid to acknowledge that the > problem exists. That's your choice. > > Regards, > Greg > > On Tue, Oct 5, 2021, 15:07 Robert Raszuk <rob...@raszuk.net> wrote: > >> 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
