+1 Agreed. As the the goal of the SRv6 compression work is a solution for encapsulation header size MSD issue for long strict paths, the focus on SRH header compression of the SRv6 128 bit SID.
>From the analysis draft is stated that each compression solution has marginal differences and all meet the compression primary objective listed first in section 6. https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02#section-6 As all the proposals are even as far as encapsulation header size, the compression analysis results end up boiling down to other factors shown below. 6 <https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02#section-6>. Conclusions Encapsulation Header Size o All proposals meet the requirement to reduce the size of the SRv6 encapsulation header. Variances between proposals are negligible. Forwarding Efficiency o Overall, the CSID parses the fewest headers. When per packet state is processed per segment, CSID, VSID and UIDSR proposals may include it in the routing header, CRH may include it in a destination option preceding the CRH. o CSID, VSID, and UIDSR require a single lookup to process an adjacency or VPN segment. CRH always requires 2 lookups for VPN segments, and 2 and sometimes 3 lookups for adjacency segments. All proposals require two lookups to process a prefix segment and the next segment. State Efficiency o CSID, VSID and UIDSR minimize forwarding state stored at a node. CRH moves per segment state from the packet to the FIB. SRv6 Based o CSID is SRv6 based, requiring no updates to existing SRv6 standards, VSID and UIDSR require updates. CRH is not strictly based on SRv6 but is able to provide equivalent functionality. SRv6 Functionality o CSID supports SRv6 functionality. CRH VSID and UID support SRv6 functionality or equivalent with some new specifications. Heterogeneous SID lists o All proposals support heterogeneous SID lists. CSID and UIDSR support heterogeneous SID lists in the SRH, while CRH and VSID require installation of binding SIDs at midpoint nodes. SID List Length o All proposals support segment lists of at least 16 segments. SID Summarization o VSID, CSID and UIDSR support segment summarization, CRH does not. Thanks Gyan On Sat, Sep 18, 2021 at 12:29 PM Bob Hinden <[email protected]> wrote: > Hi, > > I think Tony makes an excellent point. The main purpose of this work is > to compress the SRv6 header. I agree with Tony that the w.g. should focus > on the solution that provides the best header compression. > > Bob > > > > On Sep 16, 2021, at 3:23 PM, Tony Li <[email protected]> wrote: > > > > > > Hi all, > > > > We now seem headed to be adopting both the requirements and analysis > drafts and thoughts start to turn towards the debate for selection. > > > > The requirements draft has done a good job documenting our requirements > and the analysis draft gives us a perspective on how the various proposals > fulfill those requirements, but a deeper nuance is needed to guide us to > making an optimal choice. > > > > To that end, it seems to me that three of the requirements are paramount: > > > > - Encapsulation Header Size > > - Forwarding Efficiency > > - State Efficiency > > > > Of these three, Forwarding Efficiency and State Efficiency seem like > they will be overcome by hardware technology. Continued growth in > semiconductors will help us scale here, so the remaing requirement of the > Encapsulation Header Size would seem to predominate, and we should > therefore optimize for that. > > > > Regards, > > Tony > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
