Hi Robert, that is a more elegant way to mitigate the problem. But the fact that you need to use the control or management plane to disseminate the mapping between the particular flavor and corresponding prefix still tells me that in the data plane these flavors are distinct and incompatible entities, i.e., different data plane solutions to the SRv6 SID compression.
Regards, Greg On Tue, Oct 5, 2021 at 3:39 PM Robert Raszuk <rob...@raszuk.net> wrote: > Greg, > > When you receive any packet you do a LPM on the dst address. The result of > that lookup reveals the secret on how to handle the packet further. > > What is non-interoperable here ? I see You would love to have a few bits > next to the locator prefix to specify verbatim what to do with the packet ? > What for ? To run out of those bits in no time and make a mess ? > > On Wed, Oct 6, 2021 at 12:20 AM Greg Mirsky <gregimir...@gmail.com> wrote: > >> "Secret sauce" is another way to say not-interoperable. And that is >> exactly the point I am making. >> >> Regards, >> Greg >> >> On Tue, Oct 5, 2021, 15:17 Robert Raszuk <rob...@raszuk.net> wrote: >> >>> 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
