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

["Fabio Maino (fmaino)" <[e-mail]>]

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]
    ----------------------------------------------------------------------