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" <[email protected]>
> 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" <
> [email protected]
> > > > >
> > > > 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 +46 10 7148287
> Torshamnsgatan 23 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email protected]
> ----------------------------------------------------------------------
>
>
>
--
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 protected]
----------------------------------------------------------------------
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
