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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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= >>>>> [email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/spring >>>>> >>>>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
