Subject: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 09 Jul 2020 05:43:35 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-lisp-gpe-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.2:

To me it looks like this is normative reference:

Such new encapsulated payloads, when registered with LISP-
   GPE, MUST be accompanied by a set of guidelines derived from
   [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].

Section 4.3.1:

Thanks for writing relevant guidance on how to mitigate the risks with zero
checksum. Especially the one on traffic separation from other traffic so that
it can be caught on the boundaries of the network to prevent the risk to other
networks from corrupted traffic.

---

From: "Fabio Maino (fmaino)" <[email-masked]>
Date: Thu, 9 Jul 2020 16:51:46 +0000

Hi Magnus, thanks for your comments. 

Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the draft is expired, so making it normative might not be an option. 

Since it is meant to replace RFC3819, should we refer to RFC3819 instead? 

Thanks,
Fabio

On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker" <[email-masked]> wrote:

    Section 4.2:

    Section 4.3.1:

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 9 Jul 2020 17:50:09 +0000

Hi,

No, RFC 3819 is not a good replacement for the draft. I would note that only a
minor part of RFC 3819 is updated by draft-ietf-tsvwg-ecn-encap-guidelines.

So I contacted the TSVWG chairs to try to get an update on when the document
could be ready. The WG has not abandonded it. Actually I found an updated
version from March that simply failed to make it into the public archive at that
point. 

I will also note that the document has gone through one WG last call and appear
to be in descent shape. The only issue is that the main author been busy with
L4S that is a hot topic in TSVWG. 

We have requested an estimate for an update from Bob Briscoe so that we can get
this document going forward. 

So it might be possible to get this document approved before the end of the
year. 

As an alternativ there might be possible that you can reformulate the sentence
so that the high level requirement that the reader is expected to derive is
expressed in your document, and then you can get to a state where the reference
would only be informative?

Cheers

Magnus

On Thu, 2020-07-09 at 16:51 +0000, Fabio Maino (fmaino) wrote:
> Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the draft is
> expired, so making it normative might not be an option. 
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Jul 2020 13:57:12 -0400

Magnus, while it is possible we will still get hold ups on the LISP 
documents, I would really prefer to avoid creating a normative 
dependency on something that at best is 6 months away.  Particularly 
since the TSVWG has not cared enough to maintain the document.

Yours,
Joel

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Jul 2020 13:53:51 +0000

> since the TSVWG has not cared enough to maintain the document.

I can understand that. So then think you need to figure out what requirements
from that document that you thought was relevant to say that they MUST be
included in a future specification and include them in the GPE document so that 
the ecn-encap-guidelines would only be inforamtional reference. 

Cheers

Magnus

> > > On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker" <[email-masked]
> > > >
> > > wrote:
> > > 
> > >      Please refer to 
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > >      Thanks for writing relevant guidance on how to mitigate the risks
> > > with
> > > zero
> > >      checksum. Especially the one on traffic separation from other traffic
> > > so
> > > that
> > >      it can be caught on the boundaries of the network to prevent the risk
> > > to
> > > other
-- 
Cheers

Magnus Westerlund

---

From: "Fabio Maino (fmaino)" <[email-masked]>
Date: Mon, 13 Jul 2020 19:04:00 +0000

Magnus, 
here is how we modified the latest version of the draft trying to reflect your concerns, and to deal with the status of the ecn-encap-guidelines draft. 

4.2.  Congestion Control Functionality

   LISP-GPE does not natively provide congestion control functionality
   and relies on the payload protocol traffic for congestion control.
   As such LISP-GPE MUST be used with congestion controlled traffic or
   within a network that is traffic managed to avoid congestion (TMCE).
   An operator of a traffic managed network (TMCE) may avoid congestion
   by careful provisioning of their networks, rate-limiting of user data
   traffic and traffic engineering according to path capacity.

   Keeping in mind the recommendation above, new encapsulated payloads,
   when registered with LISP-GPE, should be designed for explicit
   congestion signals to propagate consistently from lower layer
   protocols into IP.  Then the IP internetwork layer can act as a
   portability layer to carry congestion notification from non-IP-aware
   congested nodes up to the transport layer (L4).  Such new
   encapsulated payloads, when registered with LISP-GPE, MUST be
   accompanied by a set of guidelines derived from [RFC6040] and SHOULD
   follow the guidelines defined in  [I-D.ietf-tsvwg-ecn-encap-guidelines].

Thanks,
Fabio

On 7/10/20, 6:54 AM, "Magnus Westerlund" <[email-masked]> wrote:

    Cheers

    Magnus

    -- 
    Cheers

    Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2020 09:45:11 +0000

Hi,

From my perspective the below is still a normative reference formulation. You
have to read the reference to be able to determine if you SHOULD follow them or
not. 

Maybe adopting the paragraph which draft-ietf-tsvwg-ecn-encap-guidelines
proposes to update RFC 3819 with: 

      By following the guidelines in [RFCXXXX], subnetwork designers can
      enable a layer-2 protocol to participate in congestion control
      without dropping packets via propagation of explicit congestion
      notification (ECN [RFC3168]) to receivers.

Into the below text can make it inforamtive. 

   Keeping in mind the recommendation above, new encapsulated payloads,
   when registered with LISP-GPE, should be designed for explicit
   congestion signals to propagate consistently from lower layer
   protocols into IP.  Then the IP internetwork layer can act as a
   portability layer to carry congestion notification from non-IP-aware
   congested nodes up to the transport layer (L4).  Such new
   encapsulated payloads, when registered with LISP-GPE, MUST be
   accompanied by a set of guidelines derived from [RFC6040]. 
   Following the guidelines in [I-D.ietf-tsvwg-ecn-encap-guidelines],
   designers of new LISP-GPE encapsualtions can enable LISP GPE and the 
   encapsulated payload to participate in congestion control without dropping 
   packets via propagation of explicit congestion notification (ECN [RFC3168]) 
   to receivers.

Please word smith. I still think this is borde line case for a informative
reference but at least it is not directly part of an RFC 2119 language sentence.

Cheers

Magnus

On Mon, 2020-07-13 at 19:04 +0000, Fabio Maino (fmaino) wrote:
> Magnus, 
> here is how we modified the latest version of the draft trying to reflect your
> concerns, and to deal with the status of the ecn-encap-guidelines draft. 
> 
>     > > No, RFC 3819 is not a good replacement for the draft. I would note
> that only
>     > > a
>     > > version from March that simply failed to make it into the public
> archive at
>     > > that
>     > > point.
>     > > 
>     > > I will also note that the document has gone through one WG last call
> and
>     > > appear
>     > > to be in descent shape. The only issue is that the main author been
> busy
>     > > with
>     > > We have requested an estimate for an update from Bob Briscoe so that
> we can
>     > > get
>     > > >      email addresses included in the To and CC lines. (Feel free to
> cut
>     > > > this
>     > > >      ---------------------------------------------------------------
> ------
>     > > > -
>     > > >      COMMENT:
>     > > >      ---------------------------------------------------------------
> ------
>     > > > -
>     > > > 
>     > > >      Section 4.2:
>     > > > 
-- 
Cheers

Magnus Westerlund

---

From: "Fabio Maino (fmaino)" <[email-masked]>
Date: Tue, 14 Jul 2020 15:35:49 +0000

Hi Magnus, 
sounds good, I'll update that text as soon the publication window reopens. 

Thanks!
Fabio

On 7/14/20, 2:45 AM, "Magnus Westerlund" <[email-masked]> wrote:

    Hi,

    Cheers

    Magnus

    -- 
    Cheers

    Magnus Westerlund

---

From: "Fabio Maino (fmaino)" <[email-masked]>
Date: Mon, 27 Jul 2020 05:12:24 +0000

Hi Magnus, 
Here is how we phrased it in rev -19. 

   "Keeping in mind the reccomendation above, new encapsulated payloads,
   when registered with LISP-GPE, MUST be accompained by a set of
   guidelines derived from [I-D.ietf-lisp-rfc6830bis].  Such new
   protocols should be designed for explicit congestion signals to
   propagate consistently from lower layer protocols into IP.  Then the
   IP internetwork layer can act as a portability layer to carry
   congestion notification from non-IP-aware congested nodes up to the
   transport layer (L4).  By following the guidelines in
   [I-D.ietf-tsvwg-ecn-encap-guidelines], subnetwork designers can
   enable a layer-2 protocol to participate in congestion control
   without dropping packets via propagation of explicit congestion
   notification (ECN [RFC3168] ) to receivers."

Let us know if we should do any other change. 

Thanks,
Fabio

    Hi,

    Cheers

    Magnus

    -- 
    Cheers

    Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jul 2020 10:06:50 +0000

> Let us know if we should do any other change. 

This works for me. 

Cheers

Magnus Westerlund

>     > On 7/10/20, 6:54 AM, "Magnus Westerlund" <[email-masked]
> >
>     > wrote:
>     > 
>     >     included in a future specification and include them in the GPE
> document so
>     > that 
>     >     > > So I contacted the TSVWG chairs to try to get an update on when
> the
>     > document
>     >     > > could be ready. The WG has not abandonded it. Actually I found
> an
>     > updated
>     >     > > So it might be possible to get this document approved before the
> end
>     > of the
>     >     > > year.
>     >     > > 
>     >     > > As an alternativ there might be possible that you can
> reformulate the
>     >     > > sentence
>     >     > > so that the high level requirement that the reader is expected
> to
>     > derive is
>     >     > > expressed in your document, and then you can get to a state
> where the
>     >     > > reference
>     >     > > > Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the
> draft
>     > is
>     >     > > > Since it is meant to replace RFC3819, should we refer to
> RFC3819
>     > instead?
>     >     > > > 
>     >     > > > Thanks,
>     >     > > > Fabio
>     >     > > > 
>     >     > > >    
>     >     > > > 
>     >     > > >      When responding, please keep the subject line intact and
> reply
>     > to all
>     >     > > >      The document, along with other ballot positions, can be
> found
>     > here:
>     >     > > >      Thanks for writing relevant guidance on how to mitigate
> the
>     > risks
>     >     > > > with
>     >     > > > zero
>     >     > > >      checksum. Especially the one on traffic separation from
> other
>     > traffic
>     >     > > > so
>     >     > > > that
>     >     > > >      it can be caught on the boundaries of the network to
> prevent
>     > the risk
>     >     > > > to
>     >     > > > other
-- 
Cheers

Magnus Westerlund