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
