Re: [Tsv-art] Tsvart last call review of draft-ietf-roll-useofrplinfo-25

[Colin Perkins <[e-mail]>]

Thanks, that addresses my concern.
Colin


> On 17 May 2019, at 10:34, Ines Robles <[e-mail]> wrote:
> 
> Hi Colin,
> 
> Thank you for your review and comments. We have added a new paragraph which addresses your concern.
> 
> New Text: "Since some of the uses cases here described, use IPv6-in-IPv6 encapsulation. It MUST take in consideration, when encapsulation is applied, the RFC6040 [RFC6040], which defines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IPV6-in-IPV6 tunnel. Additionally, it is recommended the reading of [I-D.ietf-intarea-tunnels]."
> 
> Best,
> 
> Ines
> 
> On Thu, Apr 11, 2019 at 1:46 PM Colin Perkins via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
> Reviewer: Colin Perkins
> Review result: Ready with Nits
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] <mailto:[e-mail]> if you reply to or forward this review.
> 
> The draft updates RFC 6553 to use a different IPv6 hop-by-hop option type for
> RPL packets, to avoid some issues discovered through deployment experience.
> This looks to require a flag day cutover, and hence has some potential
> interoperability concerns, but introduces no transport concern. The draft also
> describes a number of clarifications around when to use the RPL hop-by-hop
> option header and when to use IP-in-IP tunnelling, described based on a set of
> use case examples.
> 
> There do not look to be any new transport-related concerns with this draft.
> 
> The draft does not mention ECN when using IPv6-in-IPv6 tunneling. It is perhaps
> implied, but a reference to RFC 6040 would be helpful to clarify how ECN bits
> are copied between inner and outer headers when encapsulating and decapsulating
> packets from an IPv6-in-IPv6 tunnel. ECN is seeing increasing use in transport
> protocols, so correctly propagating this information is important.
> 
> 



-- 
Colin Perkins
https://csperkins.org/