Re: Compressed Routing Header idea

[Brian E Carpenter <[e-mail]>]

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

> 
>  
> 
>                                                           Ron
> 
>  
> 
>  
> 
>  
> 
> Juniper Business Use Only
> 
> *From:*Templin (US), Fred L <[e-mail]>
> *Sent:* Thursday, May 21, 2020 4:00 PM
> *To:* Gyan Mishra <[e-mail]>; 6MAN <[e-mail]>; Ron Bonica <[e-mail]>
> *Cc:* IPv6 List <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>
> *Subject:* RE: Compressed Routing Header idea
> 
>  
> 
> *[External Email. Be cautious of content]*
> 
>  
> 
> 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.   
> 
>  
> 
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     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/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
> 
>     I did include a reference to RFC8138 - let me know your thoughts.
> 
>     Fred
> 
>     > -----Original Message-----
>     > From: Pascal Thubert (pthubert) [mailto:[e-mail] <mailto:[e-mail]>]
>     > Sent: Monday, May 18, 2020 7:55 AM
>     > To: Templin (US), Fred L <[e-mail] <mailto:[e-mail]>>; IPv6 List <[e-mail] <mailto:[e-mail]>>
>     > Subject: RE: Compressed Routing Header idea
>     >
>     > Hello 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$>
>     > 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Templin (US), Fred L
>     > > Sent: lundi 18 mai 2020 16:04
>     > > To: IPv6 List <[e-mail] <mailto:[e-mail]>>
>     > > 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
>     > > [e-mail] <mailto:[e-mail]>
>     > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
>     > > --------------------------------------------------------------------
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
>     --------------------------------------------------------------------
> 
> -- 
> 
> Gyan  Mishra
> 
> Network Engineering & Technology 
> 
> Verizon 
> 
> Silver Spring, MD 20904
> 
> Phone: [phone]
> 
> Email: [e-mail] <mailto:[e-mail]>
> 
>  
> 
>  
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>