Subject: Re: [Roll] Éric Vyncke's Discuss on draft-ietf-roll-useofrplinfo-25: (with DISCUSS and COMMENT)

From: "C. M. Heard" <[email-masked]>
Date: Mon, 6 May 2019 03:02:55 -0700

On Wed, 01 May 2019 23:13:15 -0700 Éric Vyncke wrote:
> I am balloting a DISCUSS for two reasons:
>
> 1) in section 3.1,  I am failing to understand the link between RFC8200 HbH
> behavior and why the RPI code needs to be changed to 0x23.  => a clear
> explanation is required on why the option 0x23 is linked to RFC 8200: I fail
> to understand the authors' logic. At first sight, with the new RFC8200 HbH
> handling, there is no need to change the RPI code from 0x63 as most routers
> will ignore HbH anyway.

The change is not really linked to RFC 8200, but it is necessary nonetheless.

The relevant use case is the one in Section 6.2.1, storing mode flow from
RPL-aware-leaf to the general Internet. In this case an RPL-aware leaf
originates a packet whose destination is a host in the general Internet,
and that packet contains the RPI hop-by-hop option.

Suppose there is a router in the general Internet part of the path that either
(a) is RFC 2460 compliant or (b) is RFC 8200 compliant and is configured to
process the HbH Options extension header and (c) does not recognize the RPI
option (as is expected of most routers in the general Internet, whether they
process other HbH options or not). If the RPI option type is 0x63, that router
is required to drop the packet. If the RPI option type is 0x23 (or any option
type whose two most significant bits are 00), that router will skip over the
RPI option. The latter behavior is what is desired, hence the need to change
the option type.

> 2) the document deserves a better text as there are too many nits, unexpanded
> acronyms, ... the reader has hard time to understand the document.

Indeed, some work on the table formatting to get rid of the wrapped words
would be especially helpful.

Mike Heard

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 May 2019 12:03:21 +0000

Hello Mike

> -----Original Message-----
> From: C. M. Heard <[email-masked]>
> Sent: lundi 6 mai 2019 12:03
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Peter Van der Stok
> <[email-masked]>; Alvaro Retana <[email-masked]>;
> roll-chairs <[email-masked]>; roll <[email-masked]>
> Subject: Re: Éric Vyncke's Discuss on draft-ietf-roll-useofrplinfo-25: (with
> DISCUSS and COMMENT)
> 
> > 1) in section 3.1,  I am failing to understand the link between
> > RFC8200 HbH behavior and why the RPI code needs to be changed to 0x23.
> > => a clear explanation is required on why the option 0x23 is linked to
> > RFC 8200: I fail to understand the authors' logic. At first sight,
> > with the new RFC8200 HbH handling, there is no need to change the RPI
> > code from 0x63 as most routers will ignore HbH anyway.
> 
> The relevant use case is the one in Section 6.2.1, storing mode flow from RPL-
> aware-leaf to the general Internet. In this case an RPL-aware leaf originates a
> packet whose destination is a host in the general Internet, and that packet
> contains the RPI hop-by-hop option.
> 

There are also cases where the source has no clue whether the packet will stay confined within a RPL domain, but yes, this is exemplary.

> process other HbH options or not). If the RPI option type is 0x63, that router is
> required to drop the packet. If the RPI option type is 0x23 (or any option type
> whose two most significant bits are 00), that router will skip over the RPI
> option. The latter behavior is what is desired, hence the need to change the
> option type.
> 

True. Used to be the reverse. That was when the expectation with IPv6 was that all routers would examine it and waste resources unduely. We'd use IP in IP extensively and decapsulate the HbH at the border router (root) to avoid a leak, at the expense of constrained bandwidth/energy. Now that RFC 8200 clarified that most core routers ignore the HbH, we can afford to use it without IP-in-IP and live with the risk of a leak.

> > 2) the document deserves a better text as there are too many nits,
> > unexpanded acronyms, ... the reader has hard time to understand the
> document.
> 

Well noted, Mike. Many thanks.

All the best

Pascal

> Mike Heard

All the best,

Pascal