Re: [bess] WGLC, IPR and implementation poll on draft-ietf-bess-evpn-mh-pa-02

Luc André Burdet <laburdet.ietf@gmail.com> Mon, 05 July 2021 18:31 UTC

Return-Path: <laburdet.ietf@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE3E3A0C7D; Mon, 5 Jul 2021 11:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eaU8skIu-CdI; Mon, 5 Jul 2021 11:30:58 -0700 (PDT)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD143A0C5D; Mon, 5 Jul 2021 11:30:58 -0700 (PDT)
Received: by mail-qv1-xf2f.google.com with SMTP id m13so4123512qvv.11; Mon, 05 Jul 2021 11:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:accept-language:content-language:mime-version; bh=WF+P3SvdTLNuyGK35MUfpl+rLOlOBNsGtQ6zHD+Rqcw=; b=SIswnPqqFCcBSm2m1WoUMmCfvktDrgj8hqp6G4kvJCkBkIyV3iKH9dqDVAFbFOgwhr lGkAFEfy3wBtlQA4VXy3OHb/tQx0fmNaSr3f1agqXuv8j4uf+xnN52X5tESD/+GFUuhS DxTn9uoIl3pNM76YVR+mjvWCTWU5H1LxUepZdilPN1U61dTzhIukRVaCffqQcwxCJ7kT qJOQLJ9rA61WVFUvh6gJqmxg0ZBLX7dE0oMRETHQGsTmhyuoERE+O0xW4yHV7mni44o5 Wfd6cWyt3+afJBGvrCDaiSYOg2fPNOCfFWVDwwEaFhD7yQm61SzroVdcgDFJnrnO4qdm snmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:accept-language:content-language :mime-version; bh=WF+P3SvdTLNuyGK35MUfpl+rLOlOBNsGtQ6zHD+Rqcw=; b=N97nhzYbWuhht/BZJLyfPCaGcZCWj6alj9+6H8Xt4cb1Jz0UKED9P+xLd+YWZCOjUs RKxF0WBqISUcTzLCSyEbE23kmcoRDHszNqARbPqfIqUb7NL1gg4cs6YHIOnsnodnCWsx 1asKN7nih/p7UgXMhiAluPjnZMn9S3lTpeAEDifENkA5n3Y9Gg3sR4HsTkUrIIzcHvny oioVh6GPVD733DvzQ0evBIEr8L6wPM2CTREpEc3e1iQq2s88QmPpsQVfRnfEYQ6i3a9a b4gvk37xi7vIHfPBvPtIF5TgF8PEu3EipGBnrHTfT8gGcdlCo8J5L4RlCmlDv+VznZeE iDig==
X-Gm-Message-State: AOAM531JvZMDBwxf0IvU+0Ft4n9K/Ep0KbWvDK+Sfks74YmBUi3QZdFz Ym2mdU00W4ECFwb2bgI8HXxNO0mRv/s=
X-Google-Smtp-Source: ABdhPJzV5fn5e7CvoAjxd4YWv8fBD7YnOVCPksust8myHEOST9WIB3POgctBx6q4lZZjDHkOEdXOUA==
X-Received: by 2002:ad4:4d85:: with SMTP id cv5mr14260239qvb.46.1625509857071; Mon, 05 Jul 2021 11:30:57 -0700 (PDT)
Received: from DF4PR8401MB0650.NAMPRD84.PROD.OUTLOOK.COM ([2a01:111:f400:7509::5]) by smtp.gmail.com with ESMTPSA id c27sm3437628qkk.59.2021.07.05.11.30.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jul 2021 11:30:56 -0700 (PDT)
From: Luc André Burdet <laburdet.ietf@gmail.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>, "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
CC: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>
Thread-Topic: [bess] WGLC, IPR and implementation poll on draft-ietf-bess-evpn-mh-pa-02
Thread-Index: AddV7uUJiQ2tX+9USFeBi1lnYcR0KQ==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 05 Jul 2021 18:30:55 +0000
Message-ID: <DF4PR8401MB0650707D822943352E7FF8C2AF1C9@DF4PR8401MB0650.NAMPRD84.PROD.OUTLOOK.COM>
References: <0aad01d755ee$ed599f10$c80cdd30$@gmail.com> <CA+-tSzxxKWtLi2DsGy9EhBH1iT2cEKHO9BfW6nka7w=YjP0wVA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DF4PR8401MB0650707D822943352E7FF8C2AF1C9DF4PR8401MB0650_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/qLK0c_jsj4igUTiYmxSl0F-b2Z0>
Subject: Re: [bess] WGLC, IPR and implementation poll on draft-ietf-bess-evpn-mh-pa-02
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2021 18:31:03 -0000

Thank you for your careful review Anoop;
I have uploaded -03 which I believe addresses all comments.

Regarding the section specifying procedures for all DF Election algorithms: it is included per a previous review comment, primarily to be comprehensive for all existing DF Algos.  I agree the result may generally not vary much but the details of the procedure need to be specified. I hope this clears up any confusion.

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.ietf@gmail.com  |  Tel: +1 613 254 4814


From: BESS <bess-bounces@ietf.org> on behalf of Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tuesday, June 1, 2021 at 19:23
To: "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
Cc: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>
Subject: Re: [bess] WGLC, IPR and implementation poll on draft-ietf-bess-evpn-mh-pa-02


I support publication of this document.  The following are my comments.

==
Abstract

- I think it would be better to list the RFC rather than say "EVPN standard", since EVPN standard is an evolving term.
- "support of port-active" -> "support for port-active"

- The last line of the abstract should be moved to the introduction.

Section 1

- "The determinism provided by active-standby per interface is also required for certain QOS features to work."
  Can you provide an example of this?
- Change
"A new term of load-balancing mode, port-active load- balancing is then defined."
to
"A new load-balancing mode, port-active load-balancing is defined."

- Change
"This draft describes how that new redundancy mode can be supported via EVPN"
to
"This draft describes how that new load balancing mode can be supported via EVPN"
(Just for consistency, I think it would be better to search the doc throughout and make sure that "redundancy" is not being used in place of "load balancing", since we are defining a new load balancing method, not a new redundancy method/topology.)

- Is "Bundle-Ethernet interfaces" a well-known term?  I think it may be better to drop Bundle.  I am not sure if what is meant here is "members of a LAG".

- "multi-homing to CE" -> "multi-homing to the CE".

Section 2

- Change
"form a bundle and operate as a Link Aggregation Group (LAG)"
to
"form and operate as a Link Aggregation Group (LAG)"
(In EVPN bundling normally refers to many:1 mapping of VLAN to VNI/service instance).

- Include reference for ICCP.

- Change
"CE device connected to Multi-homing PEs may has"
to
"CE device connected to multi-homing PEs may have"

- Change
"Links in the Ethernet Bundle"
to
"links in the LAG"

- Change
"Any discrepancies from this list is left for future study."
to
"Any discrepancies from this list are left for future study."

Section 3

- Missing period at the end of (b).

- Layer2 attributes -> Layer-2 attributes.

Section 4.2/4.3

I got a bit confused here.  The draft discusses Modulo, HRW.  Do we essentially end up with a single active link, but just that which link is chosen is dependent on the algorithm?  If so, what is the benefit of doing so?  I can see why multiple algorithms are of value when we are doing VLAN-based load balancing to multiple active links.

Section 5

- "Bundle-Ethernet" -> "LAG"

Section 5.1

- "per ES routes for fast convergence" -> "per ES route for fast convergence"

Section 5.2

- "per EVI routes" -> "per EVI route"

Section 7

- spurious 'g'.

- missing period under the second sub-bullet of point 'f'.


On Mon, May 31, 2021 at 12:31 AM <slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com>> wrote:

Hello WG,







This email starts a two weeks Working Group Last Call on

draft-ietf-bess-evpn-mh-pa-02 [1].







This poll runs until * the 7th of June *.







We are also polling for knowledge of any undisclosed IPR that applies to

this Document, to ensure that IPR has been disclosed in compliance with IETF

IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as an Author or a Contributor of this Document please

respond to this email and indicate whether or not you are aware of any

relevant undisclosed IPR. The Document won't progress without answers from

all the Authors and Contributors.



There is currently no IPR disclosed.







If you are not listed as an Author or a Contributor, then please explicitly

respond only if you are aware of any IPR that has not yet been disclosed in

conformance with IETF rules.







We are also polling for any existing implementation as per [2].







Thank you,



Stephane & Matthew







[1]

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-pa/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess