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

[Magnus Westerlund <[e-mail]>]

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. 
> 
> 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" <[e-mail]>
> wrote:
> 
>     On Thu, 2020-07-09 at 13:57 -0400, Joel M. Halpern wrote:
>     > 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.
> 
>     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
> 
>     > 
>     > Yours,
>     > Joel
>     > 
>     > On 7/9/2020 1:50 PM, Magnus Westerlund wrote:
>     > > 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:
>     > > > 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" <
> [e-mail]
>     > > > >
>     > > > wrote:
>     > > > 
>     > > >      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.
>     > > > 
>     > > > 
>     > > > 
>     > > > 
>     > 
>     > 
>     -- 
>     Cheers
> 
>     Magnus Westerlund 
> 
> 
>     ----------------------------------------------------------------------
>     Networks, Ericsson Research
>     ----------------------------------------------------------------------
>     Ericsson AB                 | Phone  [phone]
>     Torshamnsgatan 23           | Mobile [phone]
>     SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>     ----------------------------------------------------------------------
> 
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------