Subject: Compressed Routing Header idea

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 18 May 2020 14:03:56 +0000

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 May 2020 14:55:20 +0000

Hello Fred:

Are you aware of RFC 8138? See https://tools.ietf.org/html/rfc8138#section-5.1 
The addresses in the source route header can be compressed as follows:

"

     +-----------+----------------------+
     |   6LoRH   | Length of compressed |
     |   Type    | IPv6 address (bytes) |
     +-----------+----------------------+
     |    0      |       1              |
     |    1      |       2              |
     |    2      |       4              |
     |    3      |       8              |
     |    4      |      16              |
     +-----------+----------------------+

                       Figure 7: The SRH-6LoRH Types

"
You need multiple SRH-6loRH if you have different sizes to accommodate. 

Keep safe

Pascal

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Templin (US), Fred L
> Sent: lundi 18 mai 2020 16:04
> To: IPv6 List <[email-masked]>
> 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.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 18 May 2020 15:12:09 +0000

Pascal, thanks I did not know about this but at first glance I do not believe RFC8138 fully
satisfies what I need. First, I want to be able to support both left-side (most significant
bits) and right-side (least significant bits) compression. Second, I want to be able to
compress to the byte granularity for any length from 0 to 16 bytes. And, third, I want
to be able to include an ancillary piece of information (e.g., an application port number)
with each IPv6 address. So, I submitted a short draft showing the format that I would
see as being flexible to support my use case and I think perhaps many other:

https://datatracker.ietf.org/doc/draft-templin-6man-crh-variable/

I did include a reference to RFC8138 - let me know your thoughts.

Fred

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Monday, May 18, 2020 7:55 AM
> To: Templin (US), Fred L <[email-masked]>; IPv6 List <[email-masked]>
> Subject: RE: Compressed Routing Header idea
> 
> Hello Fred:
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 18 May 2020 15:01:42 -0400

Pascal

In light of our recent extensive discussion on CRH WG adoption, glad you
mentioned the use cases of source routing with IPV6 Routing header for 6lo
and use cases that exist today with source routing within the 6MAN charter.

Even using the same acronym SRH where SRH in RFC 6554 refers to “Source
Routing Header” and not Springs “Segment Routing Header”.   Nice!!

Makes good sense for 6lo constrained nodes IoT etc to use SRH since they
cannot hold a routing table.

Nice and very good example that Spring does not own the concept of the
source routing architecture.

https://tools.ietf.org/html/rfc6554

Fred

Curious what would be the particular application use case for variable
compressed routing header to add ancillary info like port or other
miscellaneous info.

 I am guessing the final destination would have to extract the ancillary.
In a connection the tcp or udp source is the same unless using RPC or an
app using dynamic port allocation and want to save the port info somewhere
else.

Thanks

Gyan

On Mon, May 18, 2020 at 11:12 AM Templin (US), Fred L <
[email-masked]> wrote:

> > Are you aware of RFC 8138? See
> https://tools.ietf.org/html/rfc8138#section-5.1
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 20 May 2020 10:01:04 +0000

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:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: Monday, May 18, 2020 10:04 PM
To: IPv6 List <[email-masked]>
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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 21 May 2020 19:59:42 +0000

Hi, just seeing this question now (below). The idea is that the router that processes
the penultimate SID would “pair” it with the ultimate SID so that the penultimate SID
is written as the final IPv6 destination while the ultimate SID (which may include an
address and port number) is used as a destination for IPv6-in-IP encapsulation. So,
the final hop router before the final destination would be the one to extract it.

I had a somewhat related question – can the final hop router before the final
destination delete the Routing Header before forwarding?

Thanks - Fred

Fred

Curious what would be the particular application use case for variable compressed routing header to add ancillary info like port or other miscellaneous info.

 I am guessing the final destination would have to extract the ancillary.  In a connection the tcp or udp source is the same unless using RPC or an app using dynamic port allocation and want to save the port info somewhere else.

Thanks

Gyan

On Mon, May 18, 2020 at 11:12 AM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Fred

> From: Pascal Thubert (pthubert) [mailto:[email-masked]<mailto:[email-masked]>]
> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
> > From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Templin (US), Fred L
> > To: IPv6 List <[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 22:33:00 +0000

Fred,

When a node decrements Segments Left to 0, it causes all subsequent nodes to ignore the Routing header. So, I don't see a good reason to remove the Routing header. It will be ignored by all downstream nodes anyway.

                                                          Ron

Juniper Business Use Only
From: Templin (US), Fred L <[email-masked]>
Sent: Thursday, May 21, 2020 4:00 PM
To: Gyan Mishra <[email-masked]>; 6MAN <[email-masked]>; Ron Bonica <[email-masked]>
Cc: IPv6 List <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Subject: RE: Compressed Routing Header idea

[External Email. Be cautious of content]

the penultimate SID would "pair" it with the ultimate SID so that the penultimate SID

I had a somewhat related question - can the final hop router before the final
destination delete the Routing Header before forwarding?

Thanks - Fred

Fred

https://datatracker.ietf.org/doc/draft-templin-6man-crh-variable/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>

Thanks

Gyan

https://datatracker.ietf.org/doc/draft-templin-6man-crh-variable/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>

Fred

> Are you aware of RFC 8138? See https://tools.ietf.org/html/rfc8138#section-5.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8138*section-5.1__;Iw!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0b3-Gbz$>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 10:42:48 +1200

On 22-May-20 10:33, Ron Bonica wrote:
> Fred,
> 
>  
> 
> When a node decrements Segments Left to 0, it causes all subsequent nodes to ignore the Routing header. So, I don’t see a good reason to remove the Routing header. It will be ignored by all downstream nodes anyway.

Yes, quite apart from the disputed breach of RFC8200.

   Brian

> *From:*Templin (US), Fred L <[email-masked]>
> *Sent:* Thursday, May 21, 2020 4:00 PM
> *To:* Gyan Mishra <[email-masked]>; 6MAN <[email-masked]>; Ron Bonica <[email-masked]>
> *Cc:* IPv6 List <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
> *Subject:* RE: Compressed Routing Header idea
> 
>  
> 
> *[External Email. Be cautious of content]*
> 
>  
> 
> https://datatracker.ietf.org/doc/draft-templin-6man-crh-variable/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
> 
>  
> 
>  
> 
> Thanks 
> 
>  
> 
> Gyan 
> 
>  
> 
> On Mon, May 18, 2020 at 11:12 AM Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     https://datatracker.ietf.org/doc/draft-templin-6man-crh-variable/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
> 
>     > From: Pascal Thubert (pthubert) [mailto:[email-masked] <mailto:[email-masked]>]
>     > To: Templin (US), Fred L <[email-masked] <mailto:[email-masked]>>; IPv6 List <[email-masked] <mailto:[email-masked]>>
>     > Are you aware of RFC 8138? See https://tools.ietf.org/html/rfc8138#section-5.1 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8138*section-5.1__;Iw!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0b3-Gbz$>
>     > You need multiple SRH-6loRH if you have different sizes to accommodate..
>     >
>     > Keep safe
>     >
>     > Pascal
>     >
>     > > From: ipv6 <[email-masked] <mailto:[email-masked]>> On Behalf Of Templin (US), Fred L
>     > > To: IPv6 List <[email-masked] <mailto:[email-masked]>>
>     > > of "hybrid" compressed routing header would be possible.. For example, if one
>     > > [email-masked] <mailto:[email-masked]>
>     > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
>     [email-masked] <mailto:[email-masked]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
> Email: [email-masked] <mailto:[email-masked]>
> 
>  
> 
>  
> 
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 22 May 2020 01:43:34 +0000

Hi Ron,

What I am concerned with  is the case where the ultimate hop is over a very slow link
(e.g., 100Kbps or less). Any form of compression can help, and compressing away a
Routing Header could result in a small savings - but a savings nonetheless.

So, why not just truncate it? The final destination won't miss it and will never be
aware that it was ever there in the first place.

Thanks - Fred

From: Ron Bonica [mailto:[email-masked]]
Sent: Thursday, May 21, 2020 3:33 PM
To: Templin (US), Fred L <[email-masked]>; Gyan Mishra <[email-masked]>; 6MAN <[email-masked]>
Cc: IPv6 List <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Subject: RE: Compressed Routing Header idea

Fred,

                                                          Ron

Juniper Business Use Only
From: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 21, 2020 4:00 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; 6MAN <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: RE: Compressed Routing Header idea

Thanks - Fred

Fred

Thanks

Gyan

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 22 May 2020 01:48:13 +0000

Brian, yes I think it would require ignoring some "SHOULD/MUST NOT" or something
in RFC8200. Would that make me a bad person if I were to do that?

Or, to be true to the community I suppose the right thing to do would be to properly
update the normative references to cite the exception. Do you know if anyone has
already tried to do that?

Thanks - Fred

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, May 21, 2020 3:43 PM
> To: Ron Bonica <rbonica=[email-masked]>; Templin (US), Fred L <[email-masked]>; Gyan Mishra
> <[email-masked]>; 6MAN <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; IPv6 List <[email-masked]>
> Subject: Re: Compressed Routing Header idea
> 
> > When a node decrements Segments Left to 0, it causes all subsequent nodes to ignore the Routing header. So, I don’t see a good
> reason to remove the Routing header. It will be ignored by all downstream nodes anyway.
> 
> >  I am guessing the final destination would have to extract the ancillary.  In a connection the tcp or udp source is the same unless
> using RPC or an app using dynamic port allocation and want to save the port info somewhere else.
> >
> >
> >
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-
> gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
> >
> >
> >
> >
> >
> > Thanks
> >
> >
> >
> > Gyan
> >
> >
> >
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-
> gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
> >
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8138*section-5.1__;Iw!!NEt6yMaO-
> gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0b3-Gbz$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-
> gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-
> gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 May 2020 18:51:43 -0700

On Thu, May 21, 2020, 6:44 PM Templin (US), Fred L <
[email-masked]> wrote:

> Routing Header could result in a small savings – but a savings nonetheless.
>
>
>
> So, why not just truncate it? The final destination won’t miss it and will
> never be
>
Fred,

That's not guaranteed. For instance, if an AH is present then validation
will break at the final destination if the RH was deleted or it otherwise
modified in a non-conformant way. This is case of the ongoing discussion
about whether intermediate nodes can insert, delete, or process extension
headers is flight (RFC8200 states they cannot).

In your case, why not just encapsulate ip-ip with the routing header and
have the decap point be the penultimate node?

Tom

>
>
> Thanks - Fred
>
>
>
> *From:* Ron Bonica [mailto:[email-masked]]
> *Sent:* Thursday, May 21, 2020 3:33 PM
> *To:* Templin (US), Fred L <[email-masked]>; Gyan Mishra <
> [email-masked]>; 6MAN <[email-masked]>
> When a node decrements Segments Left to 0, it causes all subsequent nodes
> to ignore the Routing header. So, I don’t see a good reason to remove the
> Routing header. It will be ignored by all downstream nodes anyway.
>
>
>
>                                                           Ron
>
>
>
>
>
>
>
> *From:* Templin (US), Fred L <[email-masked]>
> *To:* Gyan Mishra <[email-masked]>; 6MAN <6man@ietf..org
> <[email-masked]>>; Ron Bonica <[email-masked]>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
>
>
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8138*section-5.1__;Iw!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0b3-Gbz$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 May 2020 18:51:43 -0700

Fred,

Tom

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 May 2020 02:22:27 +0000

Fred,

Typically, the CRH is very short. An 8-byte CRH can carry 2 SIDs. A 16-byte CRH can carry 6 SIDs.

It doesn't really save that much bandwidth.

                                                      Ron

Juniper Business Use Only
From: Templin (US), Fred L <[email-masked]>
Sent: Thursday, May 21, 2020 9:44 PM
To: Ron Bonica <[email-masked]>; Gyan Mishra <[email-masked]>; 6MAN <[email-masked]>
Cc: IPv6 List <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Subject: RE: Compressed Routing Header idea

Hi Ron,

Thanks - Fred

To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; 6MAN <[email-masked]<mailto:[email-masked]>>

Fred,

                                                          Ron

Thanks - Fred

Fred

Thanks

Gyan

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 14:49:56 +1200

> in RFC8200. Would that make me a bad person if I were to do that?

Well, I assume you have read all the threads about "penultimate segment pop", which is exactly the same thing in SRH-land, and draft-bonica-6man-ext-hdr-update.

> already tried to do that?

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-4.16.1 says:

  "This behavior does not contravene Section 4 of [RFC8200] because the
   current destination address of the incoming packet is the address of
   the node executing the PSP behavior."

But not everybody agrees with that, and there's already one appeal to the IESG in progress.

None of which makes you a bad person, of course. But it would presumably be just as controversial in your draft as it is in the Spring draft.

Regards
    Brian

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 03:24:49 +0000

Hi Fred,

I agree with what Brian says. 

You may be able to get some context from https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-4.16.1 but perhaps may not be the complete one since the SRv6 solution might not be something that could be understood by that one specific section alone. I would suggest to reach out to the authors of that document for details.

FWIW, the PSP solution has actually already been deployed in several production networks and supported by multiple vendors [1].

Unrelated to your specific question but might be applicable to your use-case as well - please also check out the proposal for insertion [2] which is again also implemented and deployed [1].

The SRH proposal does indeed expand the boundaries and application of IPv6 ... and unfortunately that does seem to make it's proponents seem like "bad persons" to some in the WG.

Thanks,
Ketan

[1] https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/
[2] https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: 22 May 2020 08:20
To: Templin (US), Fred L <[email-masked]>; Ron Bonica <[email-masked]>; Gyan Mishra <[email-masked]>; 6MAN <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Compressed Routing Header idea

On 22-May-20 13:48, Templin (US), Fred L wrote:
> Brian, yes I think it would require ignoring some "SHOULD/MUST NOT" or 
> something in RFC8200. Would that make me a bad person if I were to do that?

> Or, to be true to the community I suppose the right thing to do would 
> be to properly update the normative references to cite the exception. 
> Do you know if anyone has already tried to do that?

Regards
    Brian

>> To: Ron Bonica <rbonica=[email-masked]>; Templin (US), 
>> Fred L <[email-masked]>; Gyan Mishra 
>>> When a node decrements Segments Left to 0, it causes all subsequent 
>>> nodes to ignore the Routing header. So, I don’t see a good
>>> Curious what would be the particular application use case for 
>>> variable compressed routing header to add ancillary info like port 
>>> or
>> other miscellaneous info.
>>>
>>>
>>>
>>>  I am guessing the final destination would have to extract the 
>>> ancillary.  In a connection the tcp or udp source is the same unless
>>> On Mon, May 18, 2020 at 11:12 AM Templin (US), Fred L 
>>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>>>
>>>     > To: Templin (US), Fred L <[email-masked] 
>>> <mailto:[email-masked]>>; IPv6 List <[email-masked]
>> <mailto:[email-masked]>>
>>>     > > Administrative Requests: 
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>     Administrative Requests: 
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>> IETF IPv6 working group mailing list [email-masked] Administrative 
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 22 May 2020 13:09:15 +0000

Hi Tom,

>In your case, why not just encapsulate ip-ip with the routing header and have the decap point be the penultimate node?

I want the packet to traverse N IPv6 Internets via standard IPv6 routing before
the router in the N+1th IPv6 Internet performs IP-in-IP encapsulation to forward
to the final destination. It is in the AERO spec if you wanted to have a look. Also,
since I am doing segment routing within a mid-layer encapsulation header that is
guaranteed not to have an AH it should be OK.

Fred

From: Tom Herbert [mailto:[email-masked]]
Sent: Thursday, May 21, 2020 6:52 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Gyan Mishra <[email-masked]>; 6MAN <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Compressed Routing Header idea

On Thu, May 21, 2020, 6:44 PM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron,

So, why not just truncate it? The final destination won’t miss it and will never be
aware that it was ever there in the first place.
Fred,

That's not guaranteed. For instance, if an AH is present then validation will break at the final destination if the RH was deleted or it otherwise modified in a non-conformant way. This is case of the ongoing discussion about whether intermediate nodes can insert, delete, or process extension headers is flight (RFC8200 states they cannot).

In your case, why not just encapsulate ip-ip with the routing header and have the decap point be the penultimate node?

Tom

Thanks - Fred

From: Ron Bonica [mailto:[email-masked]<mailto:[email-masked]>]

Fred,

                                                          Ron

To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; 6MAN <6man@ietf..org<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>

Thanks - Fred

Fred

Thanks

Gyan

Fred

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 22 May 2020 10:10:19 -0400

Hi Fred

Replying to you original question regarding PSP.  So with SRv6 PSP is
enabled by default, however if the PSP option was disabled then the PSP
node will not remove the EH.  In that case the final destination USP node
will remove the SRH and deencap perform USD pseudocode and and forward to
L3 for processing.

Is that what you are trying to do - keep SRH intact in packet to final
destination?

Thanks

Gyan

On Fri, May 22, 2020 at 9:09 AM Templin (US), Fred L <
[email-masked]> wrote:

> *From:* Tom Herbert [mailto:[email-masked]]
> *Sent:* Thursday, May 21, 2020 6:52 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; Gyan Mishra <[email-masked]>;
> 6MAN <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>;
> IPv6 List <[email-masked]>
> *Subject:* Re: Compressed Routing Header idea
>
>
>
>
>

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 22 May 2020 17:03:21 +0000

Ron, in my application I will be using IPv6-in-IPv6-in-IP encapsulation. So, we have
an inner IPv6 layer, an IPv6 mid-layer and an outer IP layer (could be IPv4 or IPv6).
I want to apply Segment Routing at both the inner IPv6 layer and the IPv6 mid-layer.

It is the IPv6 mid-layer that I have been referring to in my past few messages, but
I am now of the opinion that what I need for that would be something more special
purpose and limited in scope in the spirit of Routing Header Type 2. I will define that
in my document in the same fashion as was done in RFC6275. For the inner IPv6
layer, I would apply a general-purpose Routing Header and I can make do with
just 16 bits so I believe your 16-bit CRH would be a good fit for that.

In terms of removing the Routing Header, it is the mid-layer RH and not the inner
CRH that I am proposing to remove. And since I control the insertion and deletion
of the mid-layer header (plus there will not be any AH) I don't see why I can't
remove the RH at the penultimate hop *at that layer*. The inner layer RH
could still be left alone and, as you say, it should be comparatively small.
What do you think?

Thanks - Fred

Sent: Thursday, May 21, 2020 7:22 PM

Fred,

                                                      Ron

To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; 6MAN <[email-masked]<mailto:[email-masked]>>

Hi Ron,

Thanks - Fred

Fred,

                                                          Ron

Thanks - Fred

Fred

Thanks

Gyan

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 22 May 2020 17:09:58 +0000

Brian, I think the reply I just posted to Ron also speaks to your points, but I do appreciate
the additional context. I think I would be OK to kick out my special-purpose mid-layer RH
at the penultimate hop since my service was the one that inserted the IPv6 mid-layer
header in the first place and controls what extension headers are included. The only
thing I need to be careful of is that the mid-layer header is also likely to include a
fragment header so I want to be sure that everything will reassemble correctly if I
remove the RH. But, I think I will be OK.

Thanks - Fred

> Sent: Thursday, May 21, 2020 7:50 PM
> To: Templin (US), Fred L <[email-masked]>; Ron Bonica <[email-masked]>; Gyan Mishra

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 22 May 2020 17:18:31 +0000

Ketan,

I did just a very quick search on the docs you provided and did not see anything about
RFC2473 encapsulation as a "mid-layer" encapsulation as I am doing in the AERO spec.
It is this mid-layer encapsulation where I want to insert and delete a special-purpose
RH that makes the final transition to the ultimate destination. You can probably find
more details in my previous replies to Tom, Ron and Brian.

Thanks - Fred

> From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
> Sent: Thursday, May 21, 2020 8:25 PM
> To: Brian E Carpenter <[email-masked]>; Templin (US), Fred L <[email-masked]>; Ron Bonica
> <[email-masked]>; Gyan Mishra <[email-masked]>; 6MAN <[email-masked]>
> You may be able to get some context from https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-4.16.1
> but perhaps may not be the complete one since the SRv6 solution might not be something that could be understood by that one
> specific section alone. I would suggest to reach out to the authors of that document for details.
> 
> Unrelated to your specific question but might be applicable to your use-case as well - please also check out the proposal for insertion
> [2] which is again also implemented and deployed [1].
> 
> The SRH proposal does indeed expand the boundaries and application of IPv6 ... and unfortunately that does seem to make it's
> proponents seem like "bad persons" to some in the WG.
> 
> Thanks,
> Ketan
>