"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
