[spring] 答复: Approaches to MTU efficiency in SRv6 in todays SPRING session

["Chengli (Cheng Li)" <[e-mail]>]

Hi Dirk,

I really agree with on the explanation of SRv6 SID. We also think the design of 128-bits SRv6 SID is a good idea.

Also, we can not avoid the fact that 128 bits are a little bit long when the SID list is long , and the overhead can not be ignore.  We can use the binding SID to release the pressure.  But also, if you take a look from another angle, you will see that there are some redundant bits in the Segment that can be removed. Especially when the common prefix is long. So why not we just get rid of the redundant in SID list to get a smaller overhead without any affect on the functionalities of SRv6.

Also, one modification for now and the future, for all the SIDs. We only need to make once modification and it fits to all SRv6 functionalities. That is what we have done in draft https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00.


If possible, you can take a look of the section 7, which describes the benefits of this solution:
* Seamless integration with SRv6 Network Programming
* Supporting Full Set Functionalities of SRv6
* Control-Plane friendly
* Hardware-friendly
* Efficient MTU overhead(the most important part that all solutions would like to solve.)
* Scalable SR TE
* Saving IPv6 address(Burning /16 or 32/bit address in SID space is expensive)

Thanks,
Cheng




________________________________
发件人: spring [[e-mail]] 代表 Dirk Steinberg [[e-mail]]
发送时间: 2019年7月25日 20:32
收件人: Mark Smith
抄送: SPRING WG
主题: Re: [spring] Approaches to MTU efficiency in SRv6 in todays SPRING session


Am 25.07.2019 um 02:49 schrieb Mark Smith <[e-mail]<mailto:[e-mail]>>:

On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, <[e-mail]<mailto:[e-mail]>> 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.

It is important to understand that 128 bit SIDs in SRv6
in most cases are semantically equivalent to 2 SIDs in
SR-MPLS. This is because the SID contains both a
locator and a function part (and optionally also an argument).

For example, assuming a 64:64 bit split in SRv6 the 64 bit locator
identifies the router whereas the 64 bit function part identifies
the function (plus optional arguments) which could be a VPN
or an adjacency.

So one SID in SRv6 is equivalent to one transport label plus
one service label in MPLS. For a typical VPN use case that
would be a 2 label stack consisting of the LDP or SR transport
label leading to the egress PE and the VPN label.
The same use case in SRv6 uses only one single SID.

When doing an apples-to-apples comparison of SID sizes
to MPLS label sizes the proper comparison would be
64 bit  (for example, could also be longer or shorter) in SRv6
to 20 bit in MPLS.

The 20 bit label size in MPLS is a serious limitation for
large-scale networks and data centers.

Adding uSID into the picture allows the network architect to make
his own choice regarding the tradeoff between identifier length
and MTU overhead. He may choose to use 64 bits or he can choose
to use 16 bit SRv6 uSIDs. Note that the 16 bit size for uSID is
only an example and in principle the designer could also choose
to use a different length for uSID, i.e. 32 bit.

Also note that when using SRv6 uSID the semantics regarding
locator and function are again like in MPLS, meaning that one
uSID does NOT designate both locator and function but only one
of the two. For a VPN use case you would need 2 uSIDs just like
in MPLS.

Assuming the vendor implementation of 32 bit uSID in SRv6 in
addition to 16 bits uSIDs the network designer would have a full
choice of identifier length: 16 bit, 32 bit (uSID) and 64 bit
(full SRv6 SID).

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring