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

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

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


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

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