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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks, that addresses my concern.
Colin


On 17 May 2019, at 10:34, Ines Robles <mariainesrobles@xxxxxxxxxxxxxx> 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 <noreply@xxxxxxxx> 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
tsv-art@xxxxxxxx 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/





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux