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
