RE: Compressed Routing Header idea

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

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

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