Subject: Re: Tsvart last call review of draft-ietf-roll-useofrplinfo-25

From: Ines Robles <[email-masked]>
Date: Thu, 2 May 2019 10:16:27 +0300

Hi Colin,

Thank you for your comments, we will work on it and get back to you.

Cheers,

Ines

On Thu, Apr 11, 2019 at 1:46 PM Colin Perkins via Datatracker <
[email-masked]> 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
> [email-masked] 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.
>
>
>

---

From: Ines Robles <[email-masked]>
Date: Fri, 17 May 2019 12:34:24 +0300

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