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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 14 July 2020 09:45 UTC

Return-Path: <magnus.westerlund@ericsson.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 53F163A07E6; Tue, 14 Jul 2020 02:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 mgn__KtKtmXa; Tue, 14 Jul 2020 02:45:14 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20078.outbound.protection.outlook.com [40.107.2.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304823A0853; Tue, 14 Jul 2020 02:45:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j6cT9W/RNF4jG/cpH3qsCwQm9o00C9dLl4Gsm4UzaDFdvRWOn0M+cDD6AootAoZEhAycFRObwy7dXF/C0kjrocJ4LDd6p7G800E3we7CjbCEywBqCGZUTcAxG5oJxXKtDk26AdpDb4leUmD55CkwoNcGFgTGbJ6aMhc95aMgiVAdfWCW2IRf3i+fwwr/iNzVXA+Iyvc6tU3rnOeZz6sLnklbekfI4twtjulJSNT6qX8uNZipuhkEVOO5amdBAghitrgVYlCATpTomPaVVWpRInTaGgH0AXuHZQ6fgtF2+a0YUUgDEPhZkkO5VrUldskso5gikjdpea5sz7N0NhfDQA==
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=cTyaTfDNijFccu9IdOmHMSz1XNZzuTXqAIQRb0xiz0Y=; b=cDlW0PPQz/yKJtEUJu57blPmq+lydg19YGlDeq0PlT3IipbaKfP1V42X8le3YBY3wZ8RuJ6StpI9Evv3BMPZvHV3YW/YfHKRWoaD5owAox/ZgYsB4BQXWd7oRq8/2c4Bvcq4w7DamjNU1Yw+XMmjkanZ1EhtdyigCKs+7eKwPLUFkPSYIMpCLhdkCRkyP7A+O5Ppj+DnFtSEhr180MeZg4npHuxkPzyDd4D5yWSowv6lAUvI+OoEHeHqhIrgmhCPsabUyfmsdpEkOhcVeGaS+/1CdH5vWpbPIS27XxcEcOxtpYWvuCTmJFeGz52pZmUADZU2jM6INwB+J/p9xb+Law==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cTyaTfDNijFccu9IdOmHMSz1XNZzuTXqAIQRb0xiz0Y=; b=WSAhGE6Gv7mDNBbTHhJ1iu0UHPVuKpN3w2FplFlW9Q8qA1Xudh5L6VOG6YRsjSsRLcMnmXSp+BaKOBVUkJrbv963z0Tnny93iKr2D9fGwNy7OGpFq2em1EJStBusaHwufUURumoytyhNebbhQd01hdvWho3bX2yUcZF98b5RsPQ=
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com (2603:10a6:803:10::30) by VI1PR07MB3501.eurprd07.prod.outlook.com (2603:10a6:802:17::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.10; Tue, 14 Jul 2020 09:45:11 +0000
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::886e:ca4c:f6c2:ed1f]) by VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::886e:ca4c:f6c2:ed1f%3]) with mapi id 15.20.3195.011; Tue, 14 Jul 2020 09:45:11 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "fmaino@cisco.com" <fmaino@cisco.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: AQHWVe6VGye2pzSCik2J/VoX/xyzaqj/dpkAgAAQTYCAAAH7AIABTlYAgAUNpwCAAPYoAA==
Date: Tue, 14 Jul 2020 09:45:11 +0000
Message-ID: <c7b541053c33290d3a0b81d3a6e79bf618bf1e32.camel@ericsson.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>
In-Reply-To: <5D3EC015-D57E-4C39-AF8C-0592C2D72601@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.202]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8f2101a4-bb92-4cea-bc23-08d827da9a48
x-ms-traffictypediagnostic: VI1PR07MB3501:
x-microsoft-antispam-prvs: <VI1PR07MB3501DA15B2A72674918869F995610@VI1PR07MB3501.eurprd07.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: 9LK95nGQkpHdnarnt2NB78tMdPHDARbzVTY/n1QJIM+WyX+/B3lmbsjTxd25g4Vu4nUI3RCun967mT/daVAMv9s7xBd/60HlDKst+UaOFCUmUmZ7qVYu4vCmMy3ot+E5XXYdhbFoNFwYCPHI9mVBYbHFTQ5saaZrd0v1YlaHck/C2i8c862fX3b4SKo007x0FBPwCh+3/wuzgH/c0L1xHXLPEEsfkP09jZkJJek/Emfpvw3h+Y2x31y0Nv+8LAieS07/zRw/GtEhqn2E9DU3rm9SwqfPbGqkXZC3D3VabnUjpeyzvqExRSCanpMCLClztMCFe3sBFaVGdFc4huT4x8ZDKCukjgLEAesoA4c5Ci41W9s5VTZvdUih1TfGXkxLqKmyLOtWK7Frow2txrHd5U0IIE5i3GqNsTKWreiD4urKbuAKGpNs3P7DO/JNVwTX+C4pmb+d17jyQn57txanGA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(71200400001)(36756003)(4326008)(66556008)(66946007)(53546011)(6506007)(5660300002)(91956017)(76116006)(64756008)(44832011)(66476007)(66446008)(86362001)(316002)(8676002)(2906002)(8936002)(966005)(83380400001)(478600001)(54906003)(6512007)(186003)(2616005)(26005)(110136005)(6486002)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: uG4PwsL9H5BhRGdwTJKJlYf4okq4zTd8zi9JQbSNS9+gBUBJ6kHzQgeKWNxkQ8zpka/iKH4yQauuRcclzSnrMhFGKpxNLazzZ3CAnLtHbyTgAFpwqftaGlHSX+zKbN7ZrQUiZtBZRDow3PgweA5f8sbtYI+AvL/zqgCCxiNScEm482o9gXQ1ODu9tt4j+PJ5u+9AjylfhfiIPTQ/4T/SgAyfg7oyUXPB9wYMZZiqPusUFLB/wa7lUmzEb76aainwUjYE8j26WJyeK2CmUMBxYcTWjcLzXBaoTq9PNj5HhhUKOvwVUpfQDKnoVw624yPQftnKQfeZMh1cNP6mY3YtnvGOKTqcLQCiUuvGQw/LX7qQb6memfOyEKXbjC11br03AzYqUhurqPwiPxj227BqNPB1KyGTgXQUvgNNbSO5/gimehs8UfkXqXEz8IGx7D/+SfuIwjjwF3pYUnBofwoSEDlZZFoFoOJw213PVx+sS37sTf6p845oyVDtbICxnY6U
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <910ADCEC527DD24588A26112B7BE5122@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR0702MB3775.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f2101a4-bb92-4cea-bc23-08d827da9a48
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 09:45:11.6087 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Yj6NlKhgktkkI0oVda2jJHVSkF8QfpOU4cfL9+Cg/P/jZwTJaMifN9acem/Eq2jAbXmwbP19KdsTPB+QpnPhF0mN8+yuvaGKz/16gqkY2oU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3501
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/pPA_BzhV1HaMq-NSznp2tbdPl3M>
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: Tue, 14 Jul 2020 09:45:16 -0000

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