Re: Compressed Routing Header idea

[Gyan Mishra <[e-mail]>]

Pascal

In light of our recent extensive discussion on CRH WG adoption, glad you
mentioned the use cases of source routing with IPV6 Routing header for 6lo
and use cases that exist today with source routing within the 6MAN charter.


Even using the same acronym SRH where SRH in RFC 6554 refers to “Source
Routing Header” and not Springs “Segment Routing Header”.   Nice!!

Makes good sense for 6lo constrained nodes IoT etc to use SRH since they
cannot hold a routing table.

Nice and very good example that Spring does not own the concept of the
source routing architecture.

https://tools.ietf.org/html/rfc6554

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/


Thanks

Gyan

On Mon, May 18, 2020 at 11:12 AM Templin (US), Fred L <
[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/
>
> I did include a reference to RFC8138 - let me know your thoughts.
>
> Fred
>
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> > Sent: Monday, May 18, 2020 7:55 AM
> > To: Templin (US), Fred L <[e-mail]>; IPv6 List <
> [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
> > 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]> On Behalf Of Templin (US), Fred L
> > > Sent: lundi 18 mai 2020 16:04
> > > To: IPv6 List <[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]
> > > 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
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]