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

[Magnus Westerlund <[e-mail]>]

On Mon, 2020-07-27 at 05:12 +0000, Fabio Maino (fmaino) wrote:
> 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. 

This works for me. 

Cheers

Magnus Westerlund



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

Magnus Westerlund 


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