RE: Compressed Routing Header idea

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

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

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Thursday, May 21, 2020 7:50 PM
> 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-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
> >>> --------------------------------------------------------------------
> >>>
> >