On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, <[email protected]> wrote:
> Hi All, > > in todays SPRING session we have heard concerns about > MTU efficiency in certain use cases involving SRv6. > > It is true that using 128 bit SRv6 SIDs trades scalability > and flexibility against MTU overhead. There will certainly > be use cases where the additional overhead may be > justified. > I can understand the convenience of SIDs being the same size as the underlying layer identifier. However, do they have to be? 128 bit SIDs is literally more SID values than there will ever be IPv6 unicast addresses (multicast has 1/8th the space). It's a larger space than the number of nodes than can be attached to the entire IPv6 Internet. What size would SIDs be if they were dimensioned only for the SR functions they're being and going to be used for, rather than just being sized to the lower layer identifier value? If MPLS based SIDs are 20 bits, and they do not have any SR functional constraints, I think that suggests SIDs can be far smaller than 128 bits, which then addresses the overhead problem 128 bit SIDs creates. > For other uses cases where MTU efficiency is a major concern > the answer within the SRv6 framework is SRv6 uSID. > > Another proposal to address the MTU efficiency problem today > advertised itself as basically using the same semantics as MPLS > encapsulated in IPv6 and also noted that SRv6 deviates from > legacy MPLS regarding label semantics. > > This is exactly the point. > > Not being dependent on the legacy MPLS label binding semantics > in SRv6 is a big advantage. > > And this advantage is carried forward in SRv6 uSID as well. > SRv6 uSID addresses the problem of MTU efficiency while > avoiding to fall back to MPLS label binding semantics. > > No separate mapping table is required to be able to forward uSID. > > It is also not true that uSID inflates the IGP and/or FIB tables > more than other approaches. A uSID is advertised just like > other SRv6 SIDs, although the prefix length will typically > be much shorter. The fact that no extra label mapping > table is required contributes to improved control and > data plane efficiency and provides excellent forwarding > ASIC efficiency, especially for low-FIB and legacy systems. > > Cheers > Dirk > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
