RE: Compressed Routing Header idea

["Templin (US), Fred L" <[e-mail]>]

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

> -----Original Message-----
> From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
> Sent: Thursday, May 21, 2020 8:25 PM
> To: Brian E Carpenter <[e-mail]>; 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
> 
> 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
> --------------------------------------------------------------------