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

"Fabio Maino (fmaino)" <fmaino@cisco.com> Mon, 27 July 2020 05:12 UTC

Return-Path: <fmaino@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535F23A0AA7; Sun, 26 Jul 2020 22:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gF+VzFdz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wDFZvw0a
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOfo8WTNIj1z; Sun, 26 Jul 2020 22:12:29 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80ED13A0AA6; Sun, 26 Jul 2020 22:12:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=260572; q=dns/txt; s=iport; t=1595826748; x=1597036348; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fjbu9fowlWUqOfiz3ChidvrSkghLVd1c5EYYj1Rmc14=; b=gF+VzFdz7O16WVtpmYe3eZil4zN4u3bSAWVuSECUTgcLJqSO3Fe8H7ZP 09QaVvnc7b0FqCbjXAoV5JOMAJjp51D2slqqcGqEelnyRzVrjMJzq/zG7 p/fN97TBGIr0CFU7ckpFOTN+7uK0yLoJ1F6BLu26CxckCWLYfPb/0fYBQ 4=;
X-Files: Screen Shot 2020-07-26 at 10.06.57 PM.png : 178657
IronPort-PHdr: =?us-ascii?q?9a23=3AymPWYBS8ZUkVsHXP042/dlYrrdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB92J5uhFgPHNtKamUmsFst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8XCo7DUJAR?= =?us-ascii?q?L5cwFyI7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CiBAD2YR5f/51dJa2FVrw4HAMGBIZVhjg6wGSQWIG8Jw
X-IronPort-AV: E=Sophos;i="5.75,401,1589241600"; d="png'150?scan'150,208,150";a="517721685"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2020 05:12:27 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 06R5CR0R018011 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2020 05:12:27 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 00:12:27 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 00:12:26 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 00:12:26 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WAEsE44zYBQO1fD2P0EBV4K7zSL0jwoI3UQBvq1Msht8K0SwYnFovhqrrwrG0E6JEOQVZAEUZYsPMF+cGIUrUPQKCeK8YLunMK/WHEMq+J2YhGxHjx7V3jACzSPVBiZgs612WARNns2YO1ZbkXlQhsAWZNySuAOl8piQzFH1q3vKoHN+EOLqQlMjq24UH/SgVmLnV2/uxZ9gEOVSqr6oY4W6UNU/Y/9bbA+gdEl0ubHAcAESc54Q5E8fqKsdJPcBUHu/KUgMbsqMgdELPuY3Qr/X5HE2cXeMhmHBIQDkSRdeoo3QHBh9c4AyKg03cOjTom7zuwNrxqVe0kbtCIuStA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X0f10Yj+0BUGXVCpFa4fgbj8wdwNvkr16sPj1sAKvlc=; b=XVF3AQt+A7+z2TJdceevyn2VqpqXIgF3Iq/QmlP/LS/mK4beBgGPPwPSednNQxxOwFR0orejJ7kQLnaeqzBsGK2BqRIfE5NZYdpAKqiRapf/x+9PwNy9LKtJoY4o41E3fxpr1nDeowpwF5RSywbJx2HmmHab4oim8KSEs/CfLPY1A/PIf3/CDu5WmXzZ0lv1qR4jWExbUKP7j3be28w8nqC8EJwJxchHUJHnDm6K7R0ZoHVk/hqaHFdgadXmuG96hSmEnGWBwV/9sTA8zRmQN4/biIT2SXALmG5cjbg9jS835Vymixk8cYwrB2g1WY+3tyU6BHvo5YikmAFs0ANt6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X0f10Yj+0BUGXVCpFa4fgbj8wdwNvkr16sPj1sAKvlc=; b=wDFZvw0abbcd8CBQre5OBCkqjSHS4SXn0PCCuUSeSy5rykHnFQQapdRpP7vPNWekzq02zjWC1nmu0QLuxwF3prbPmPjwH/Y2qc4bhDjh8DQ6CRpUVraRl6X8L26FO7ofN04zMe/4R0/cjCKFRTP5kyxUvQJ8d/KaQ5BocTSqv3U=
Received: from BY5PR11MB4369.namprd11.prod.outlook.com (2603:10b6:a03:1cb::25) by BY5PR11MB3942.namprd11.prod.outlook.com (2603:10b6:a03:188::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Mon, 27 Jul 2020 05:12:25 +0000
Received: from BY5PR11MB4369.namprd11.prod.outlook.com ([fe80::b8ba:cc41:e6f0:9cf4]) by BY5PR11MB4369.namprd11.prod.outlook.com ([fe80::b8ba:cc41:e6f0:9cf4%7]) with mapi id 15.20.3216.031; Mon, 27 Jul 2020 05:12:25 +0000
From: "Fabio Maino (fmaino)" <fmaino@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "ggx@gigix.net" <ggx@gigix.net>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
Thread-Index: AQHWVe6TrPTH1MNYQEGxO6dEGUBD7aj/AT+AgACFqYCAAAH5AIABTleAgASYSoCAAWuPgIATrLyA
Date: Mon, 27 Jul 2020 05:12:24 +0000
Message-ID: <AF12CC63-D541-4B30-8502-4210E422050D@cisco.com>
References: <159429861569.12326.4735174452265776723@ietfa.amsl.com> <1464C8A8-747A-45CB-8F62-9E96373C0D67@cisco.com> <54ee2cbb0c528b6c5aa36f88a8cf78d2d7d0ff09.camel@ericsson.com> <f6a3ce17-1033-01c3-2995-089845df1524@joelhalpern.com> <0bf2d991265c7d6db61b9a0493b5911e1bd6190c.camel@ericsson.com> <5D3EC015-D57E-4C39-AF8C-0592C2D72601@cisco.com> <c7b541053c33290d3a0b81d3a6e79bf618bf1e32.camel@ericsson.com>
In-Reply-To: <c7b541053c33290d3a0b81d3a6e79bf618bf1e32.camel@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [75.25.137.103]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 02446371-efc9-4a6c-7778-08d831eba65b
x-ms-traffictypediagnostic: BY5PR11MB3942:
x-microsoft-antispam-prvs: <BY5PR11MB394255DD44DE0F5EC434EF89C2720@BY5PR11MB3942.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FNNm2DBf/DcJtLgTfvLuBXXc6Rw8CvhkHTJIZaA8dWxgEGFvnuutEpm4ELkRhXBDvmCLcTPlyc5gS3mD67D9lFui8NrlXSjvcShFtXsjKjVFml+zE+D8PauzexQzlmiwrKsrixb5AC5jHOeggTPuoT536WQkP3thMsYv7k1CAL4v4ibOGh3OeCP4tsCXUkVOElBuf+PWT3J18q0lEordv5rnZqD30HvbPEdG2FcYGAyl7g+8RDi8R+GPfh4mtccl7/7fJESdDWQ3cRR1PWdGiIQfRAovD/xtCI8ULKjDD9dHC7Qqb7NF1UyYrfPd/l/6dfUXXaEqj7mQRJgY3T4tX6qoYYlsmF6EpGOtMmwXiPVso05qC292MqaEtaZEq/5THfxU5AWo/QsmDUF3FG+LOA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4369.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(136003)(376002)(366004)(346002)(66946007)(76116006)(110136005)(86362001)(83380400001)(2906002)(6486002)(316002)(36756003)(53546011)(4326008)(71200400001)(6506007)(8936002)(33656002)(66446008)(64756008)(66556008)(66476007)(66616009)(54906003)(478600001)(2616005)(5660300002)(6512007)(186003)(8676002)(26005)(966005)(99936003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: AuYk83bzo3EWleTTGX/EYX7PTtxIjMgw6v5XtC/mOP9oCImMh5B98t1UTIfQwvWxo1JiTYQuCcPUrePC2lc2WmmLCHKoI6OJ+rxVyGy4pfI2OTR/pYtocVdqbeYXVx7NEIZ3/N6QNUNPhKHd/34jTAQ48jM8bRqi8nzHnsxUg+yFRoPFKEkZxWJkrhf/UaePHW539oit9N0r8yMiSSOH9AYqaMaAAxlR1ttr7oyOS1T9NAk9wnHvsfiLtvcbfqGGEsbZnj7AuGd093wkQmh1dIzPeT8LQPDxnmLoTBPECudfHzjEuZ/vGBW5pUtpQkK+4TB5y0F3NzN6Tx5p6DPsvpSkpSyH5PUDLglPa/QgdD2ysTZ0v0dg6dtiBtPd+YlOtyXpjY02V7kDOEhaVV71wJli4nh2d1aDA3SbpNYSBswNVdj9gHwUk5QGFHfO7PIZBo4X7JXr8hbVu0BKlJvq5H3G++xy+WnzItVbxYXEWlI=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_AF12CC63D5414B3085024210E422050Dciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4369.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 02446371-efc9-4a6c-7778-08d831eba65b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 05:12:24.9983 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VO/tlhplotcsacZs3HSf69F8fXlCCMRg1NBTfkf/RtXDD+Nmwngx3oFiWAyjjt/neJWySEXPjDCM6FrzCyfFDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3942
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/43YgB225gEedCJHi96HsOv3Sp4g>
Subject: Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 05:12:32 -0000

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" <magnus.westerlund@ericsson.com> 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" <magnus.westerlund@ericsson.com>
    > 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" <
    > noreply@ietf.org
    >     > > > >
    >     > > > 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: magnus.westerlund@ericsson.com
    >     ----------------------------------------------------------------------
    > 
    > 
    > 
    -- 
    Cheers

    Magnus Westerlund 


    ----------------------------------------------------------------------
    Networks, Ericsson Research
    ----------------------------------------------------------------------
    Ericsson AB                 | Phone  +46 10 7148287
    Torshamnsgatan 23           | Mobile +46 73 0949079
    SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
    ----------------------------------------------------------------------