RE: Compressed Routing Header idea

Hi Fred,

Great! A really straightforward idea. Actually, we did think about variable length SID compression, it may provide the best compression, but the complexities will be a problem, especially for hardware. You know, less choices for hardware, better forwarding efficiency we get. 

After discussing with many operators, we get a consensus that the 32 bits is the most appropriate length for the compressed SID. 
* Firstly, most hardware support mature 32 bits processing, for instance IPv4 and MPLS hardware. 
* Secondly, we need to consider the scalabilities when we discuss compression, 16 bits for node ID and function ID is apparently not scalable.  So if we want to limit the option into one size, then it is 32 bits. I guess most of the people in 6man will agree with that.

Also, it is important to provide the abilities to encode 128 bits SID and 32 bits Compressed SID a single SRH in many use cases. For example, 
* a Compressed SID list and a 128 bit VPN SID, we don't want to make modification of the Best effect VPN processing flow, which is very clear. Also, there will be many  VPN instances in a huge network.
* Also, when a node in the path does not support compression, then use a 128 bit SID in the SRH directly. So we do not need to modify the SR policy to avoid that node, but only change the SID encoding method in the SRH to encode Compressed SID and 128 bits SID together. In this way, the incremental deployment can be supported.

So we proposed Generalized SRv6 for Compression [1], which is fully compatible with SRv6, and it does not modify the format of SRH.

The method is really simple, we introduce a new flavor called COC(Continue-of-Compression) flavor to indicate the SRv6 compression processing.

Furthermore, from the aspects of deployment and operation, if SRv6 has been deployed, then we can reuse the allocated locator to allocate compressible SRv6 SID for SRv6 compression, which will not introduce any new route to the network, so not SRv6 security policies should be modified. Really simple.

Hope this info can help you, and welcome to comment the document.

Best Regards,
Cheng

[1]. https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-for-cmpr-01

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
Sent: Monday, May 18, 2020 10:04 PM
To: IPv6 List <ipv6@ietf.org>
Subject: Compressed Routing Header idea

Hi, I have a use case where some IPv6 addresses that would go into a routing header are more compressible than others and so I am wondering if some kind of "hybrid" compressed routing header would be possible. For example, if one address can be compressed down to
16 bits, then include only those 16 bits; if a different address can only be compressed down to 32 bits, then include the 32 bits; if yet a different address cannot be compressed at all, then include all 128 bits. And, there may be many more sizes in between.

RFC4191 Section 2.3 shows an example of how an IPv6 prefix/address can be compressed to a variable length. Essentially, a length byte followed by a variable-length prefix. That way there would still be "pretty good compression" albeit with an extra byte per prefix. And, it would be a generalized form that would only require a single routing header type value.
How would it be if we did something like that?

Fred

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------