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" <[email protected]> > 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" <[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] > ---------------------------------------------------------------------- > > -- 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
