RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Darren

Since you mentioned RPL, I felt invited. We’ve had the same problems of RH insertion and saturating MTU as you guys, and been chewing them it for a very long time (like, ~ 15 years).


To make a long story short, we went through the hassles of inserting routing headers in the RPL domain, many implementations still do that (see for historic purpose https://tools.ietf.org/html/draft-hui-6man-rpl-headers-00).
We used a HbH header (0x63) that was supposed to ensure that an escaping packet would be discarded outside the domain. As you know, RFC8200 made it clear that we cannot count on it.
We also tried smaller tweaks like use the flow label in our own way inside the RPL domain (see https://datatracker.ietf.org/doc/draft-thubert-6man-flow-label-for-rpl/)

So yes we went to 6MAN a good number of times to get IPv6 optimizations in our very constrained environments and the response was usually negative, with the exception that you point out (the HbH header).

So where are we now?

The key thing is that we have provided a compressed routing header.  And by routing we do not mean the SRH but all thing sthat the router needs to look at. It’s RFC 8138, the 6LoWPAN Routing Header (6LoRH).  RFC 8138 compresses both the IP-in-IP and the source routing headers. It also compresses the HbH header we wanted to place in the flow labels, and that gives us multi-topology routing and micro-loop avoidance. That’s how we made IP-in-IP and the HbH acceptable on highly constrained MTUs.

The consequences of RFC 8138 are:
- inside a RPL domain, the RH is compressed statelessly based on common prefix with the previous hop
- the compressed packet is logically equivalent to the full IPv6 packet, but easier to handle when forwarding (e.g., no swapping games in the source routing header like RH0 does);
- outside the RPL domain, the compression format is not recognized and the packet is dropped as invalid so, to Stewart’s point and like for MPLS, there’s no escapees;
- as imposed/suggested/whatever by IPv6 we use IP in IP to protect the RH encapsulation, as it goes that improves the compression since the encapsulator (the RPL root for us) in the same domain shares a prefix with the SRH next hops. https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ details how we do all those things now, and the complexity of resulting spec says a lot.

You’ll note that 6LoRH is not linked to anything else 6LoWPAN, and could be made to apply in a domain that is not a RPL. Maybe part of defining something new should be to look at the existing art.

I hope this helps,

Pascal


From: ipv6 <[e-mail]> On Behalf Of Darren Dukes (ddukes)
Sent: dimanche 17 mai 2020 05:27
To: Andrew Alston <[e-mail]>
Cc: IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Andrew.  You say...

That 6man – does refer to this working group right?  Or am I confused.

I think you are confused, but that’s OK, it’s easy to explain.
SPRING defined segment routing, the terminology, usecases, problem statement, and protocol extensions.
6man defined the routing header.
See section 1 of https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-00 where this context was given when 6man adopted the document.



RPL appears similar, see section 1.

https://tools.ietf.org/html/draft-ietf-6man-rpl-option-00



I hope this helps.

  Darren

________________________________
From: Andrew Alston <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, May 16, 2020 10:44 AM
To: Darren Dukes (ddukes); Bob Hinden; IPv6 List
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Darren…

Can you please explain the double standard here – where the additional development on segment routing was done in other working groups (IDR/LSR/SPRING etc) – but – last I checked –

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26

That 6man – does refer to this working group right?  Or am I confused.

Now – let me be very clear before someone claims we’re trying to replace the SRH – which is not the case – I am merely contrasting your arguments to another case where a routing header was developed – and the rest of the work – was done elsewhere as needed, and which you had nom issue with.

So – to be frank – from my perspective  and speaking only for myself – I see this as yet another red herring popped out of thin air.

Thanks

Andrew

From: ipv6 <[e-mail]<mailto:[e-mail]>> on behalf of "Darren Dukes (ddukes)" <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>
Date: Saturday, 16 May 2020 at 17:00
To: Bob Hinden <[e-mail]<mailto:[e-mail]>>, IPv6 List <[e-mail]<mailto:[e-mail]>>
Cc: Bob Hinden <[e-mail]<mailto:[e-mail]>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Bob and Ole.

I’m not supporting the draft for adoption by 6man. I know you’re shocked ;).

I have one main concern with 6man adoption that I think many can agree with.

This draft will require substantial work related to the 16/32bit identifier (CP and OAM) that is not ipv6 nor ipv6 maintenance and for which this working group does not have a mandate nor, traditionally, expertise to drive.

Others have said “this is not 6man’s concern” and I agree because 6man is an ipv6 maintenance WG, not the segment mapping working group.  I believe the authors should find a WG with that concern to drive this work. I know starting work without requirements is fun and exciting, but you will likely end up at the wrong destination.

Brian had one suggestion on this topic.

In the past I’ve suggested SPRING, or if the authors desire, a BOF to build consensus and gather requirements for its parent SRm6 work or some variant of it.

I hope the authors, WG, chairs and AD consider these points during this adoption call.

Thanks
  Darren


________________________________
From: ipv6 <[e-mail]<mailto:[e-mail]>> on behalf of Bob Hinden <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 15, 2020 6:14 PM
To: IPv6 List
Cc: Bob Hinden
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

This message starts a two-week 6MAN call on adopting:

 Title:          The IPv6 Compact Routing Header (CRH)
 Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
 File Name:      draft-bonica-6man-comp-rtg-hdr-21
 Document date:  2020-05-14

 https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr

as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.

Please note that this is an adoption call, it is not a w.g. last call for advancement, adoption means that it will become a w.g. draft.  As the working group document, the w.g. will decide how the document should change going forward.

This adoption call will end on 29 May 2020.

The chairs note there has been a lot of discussions on the list about this draft.   After discussing with our area directors, we think it is appropriate to start a working group adoption call.  The authors have been active in resolving issues raised on the list.

Could those who are willing to work on this document, either as contributors, authors or reviewers please notify the list.   That gives us an indication of the energy level in the working group
to work on this.

Regards,
Bob and Ole