RE: Compressed Routing Header idea

["Ketan Talaulikar (ketant)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Brian E Carpenter
Sent: 22 May 2020 08:20
To: Templin (US), Fred L <[e-mail]>; Ron Bonica <[e-mail]>; Gyan Mishra <[e-mail]>; 6MAN <[e-mail]>
Cc: Pascal Thubert (pthubert) <[e-mail]>; IPv6 List <[e-mail]>
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?

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.

> 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?

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

> Thanks - Fred
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: Thursday, May 21, 2020 3:43 PM
>> To: Ron Bonica <rbonica=[e-mail]>; Templin (US), 
>> Fred L <[e-mail]>; Gyan Mishra 
>> <[e-mail]>; 6MAN <[e-mail]>
>> Cc: Pascal Thubert (pthubert) <[e-mail]>; IPv6 List 
>> <[e-mail]>
>> Subject: Re: Compressed Routing Header idea
>>
>> 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-te
>> mplin-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-te
>> mplin-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*secti
>> on-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/ipv
>> 6__;!!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/ipv
>> 6__;!!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
>>> --------------------------------------------------------------------
>>>
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------