Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08

Separate comment on this text:

> B. Section 5.12:
> 
>     Nodes that may be deployed in environments where they would benefit
>     from such early congestion notification SHOULD implement [RFC3168].
>     In such cases, the updates presented in [RFC8311] may also be
>     relevant.

For the most part characterizing RFC 8311 as "may also be relevant" is ok,
as that RFC's primary purpose is to enable experiments.

There is one exception that deserves to be called out from Section 2.2
of RFC 8311 (https://tools.ietf.org/html/rfc8311#section-2.2): 

   3.  A network node MUST NOT originate traffic marked with ECT(1)
       unless the network node is participating in a Congestion Marking
       Differences experiment that uses ECT(1), as specified in
       Section 4.2 below.

That's a mandatory change.

Thanks, --David

> -----Original Message-----
> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Magnus
> Westerlund
> Sent: Wednesday, July 4, 2018 3:40 AM
> To: Brian E Carpenter; tsv-art@ietf.org
> Cc: draft-ietf-6man-rfc6434-bis.all@ietf.org; ipv6@ietf.org
> Subject: Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08
> 
> Hi,
> 
> Thanks for the rapid response.
> 
> 
> Den 2018-07-03 kl. 22:48, skrev Brian E Carpenter:
> > Hi Magnus,
> > On 04/07/2018 02:45, Magnus Westerlund wrote:
> >> Reviewer: Magnus Westerlund
> >> Review result: Ready with Issues
> >>
> >> I've reviewed this document as part of the transport area directorate'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 for
> >> their information and to allow them to address any issues raised.
> >> When done at the time of IETF Last Call, the authors should consider this
> >> review together with any other last-call comments they receive.
> >> Please always CC tsv-art@ietf.org if you reply to or forward this review.
> >>
> >> I have focused on the transport aspects of these node requirements and have two
> >> things I would like to flag that should be considered to be addressed.
> >>
> >> A. Section 5.7.1:
> >>
> >> Path MTU Discovery relies on ICMPv6 Packet Too
> >>     Big (PTB) to determine the MTU of the path (and thus these should not
> >>     be filtered, as per the recommendation in [RFC4890]).
> >>
> >> Considering that RFC 4890 recommendation for PTB is "Traffic That Must Not Be
> >> Dropped". I think using "should not" is weaking the recommendation.
> > Interesting point. This is a lower case "should" so actually I don't think
> > it is really a weakening, but by the same argument "must not" is OK too.
> 
> So, I don't consider it a major weakening, but non the less "must not"
> is stricter than "should not".
> 
> >
> >> B. Section 5.12:
> >>
> >>     Nodes that may be deployed in environments where they would benefit
> >>     from such early congestion notification SHOULD implement [RFC3168].
> >>     In such cases, the updates presented in [RFC8311] may also be
> >>     relevant.
> >>
> >> Why isn't this a MUST? A IPv6 node has no way of determining if it is has
> >> connectivity that will actively mark with ECN-CE.
> > I think the problem in that sentence is the "may be deployed..." clause.
> > The implementer of a stack can't possibly know that. So why not reduce it
> > to:
> >     Nodes SHOULD implement [RFC3168].
> > In RFC2119 terms that's fine, since it simply says "do this unless you
> > have a good reason not to."
> 
> I wished I had reviewed this earlier (during the WG process) because I
> think ECN is so stable and mature with a small implementation burden
> from the IP layer that it really should be mandated to implement. At the
> same time I do realize that a stack that simply ignores the bits and
> sets them to 00 on outgoing IPv6 packets are fully interoperable so that
> this is not an argument for mandating implementation. But, I really
> wanted to flag this for the ADs. From my perspective the SHOULD is the
> minimal level ECN should be required to be implemented at, and I had
> hoped for a MUST. And I think the only one that has a reason not to
> implement ECN in the IP layer are low performance minimal footprint
> implementation.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art