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

From: Dirk Steinberg <[email-masked]>
Date: Wed, 24 Jul 2019 18:20:05 +0200

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.

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

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Jul 2019 10:49:49 +1000

> be use cases where the additional overhead may be

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.

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Andrew Alston <[email-masked]>
Date: Thu, 25 Jul 2019 02:46:03 +0000

<Snip>

> ASIC efficiency, especially for low-FIB and legacy systems.

I don't agree with this - and here is why:

To use uSID - I either have to use a locator ID in additional to my normal loopback - or - in the alternative - renumber things such that my normal loopback numbering scheme would be such that shifting on the address would not break things on the network.  The latter option in a large network is entirely and totally impractical in my view - so - that means - I now need to add a second address to every router in order to use this.  This doubles the number of loopbacks in the IGP for every node that I wish to use a uSID on, since I now have the original loopback - and the address that I wish to use for steering.  In a CRH context - because of the de-coupling of the SID and the address - there is absolutely no problem with applying the SID's to the original loopbacks - and no increase in the IGP.

Furthermore, the additional locator addresses I am now applying - because they are in effect just another v6 address - will propagate through the IGP to every single device - irrespective of if that device needs to know about it or not - this means that on the legacy hardware that has low fib counts - I will see an impact.  I do not need locator SID's in addition to my normal loopbacks with CRH - so - in inflates the IGP in my eyes.

In a large network - where a lot of steering is happening - and you have a large number of devices through which you are going to need to steer - this can actually have quite a serious impact.

Thanks

Andrew

---

From: Dirk Steinberg <[email-masked]>
Date: Thu, 25 Jul 2019 14:32:44 +0200

> Am 25.07.2019 um 02:49 schrieb Mark Smith <[email-masked]>:
> 
> On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, <[email-masked] <mailto:[email-masked]>> wrote:
> Hi All,
> 
> 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).

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 26 Jul 2019 16:00:21 +0000

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 [[email-masked]] 代表 Dirk Steinberg [[email-masked]]
发送时间: 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 <[email-masked]<mailto:[email-masked]>>:

On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Cheers
Dirk

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Jul 2019 14:06:44 -0400

Hi Dirk, et al.,
I'd like to point to draft-mirsky-6man-unified-id-sr
<https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03> that
proposes the use of the SRH for identifiers of 20 and 32 bits-long.

Regards,
Greg