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

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 09 November 2021 15:15 UTC

Return-Path: <ghanwani@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 D47AF3A0E26; Tue, 9 Nov 2021 07:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level:
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 ddq12fCKgopi; Tue, 9 Nov 2021 07:15:00 -0800 (PST)
Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (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 98AA83A0E1B; Tue, 9 Nov 2021 07:14:59 -0800 (PST)
Received: by mail-lj1-f171.google.com with SMTP id s24so36940836lji.12; Tue, 09 Nov 2021 07:14:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y+fppS3M+veWmd8kIdL+p6xm9f4WfIyZz/Fpy9kaBis=; b=0u0thLJI3PaT6gHw54cXMN4WBRY5v6jY3fS0lhV/QM2h9Enh83EXBSK1PdV0tPF3sj 5aFtkWCHExIX0S4M1ICXDJNP1XYwLlolGbeClAie0Vd5I1VE2TBybt6r0b8T9LAdkQHF vbdJJEAvLyE1qxbVwX7G2uSBiUSvwb4z+dkgJ+VcfogjNlrNnK/JbxSqzsgJ3F5WFo7z HDuEEIpYfABzDiE9sKYoh77CQPmZAaz+gYAK78Z1G7rJ21BtNe+740SLmvj5axv60z8l PqXjw9wbWfb6Es5dP0FHsXrhpz/MNHuRXRdXM8MLDXrz2jVp0ofDjDwjqtYpFbG0yjMO 0n9Q==
X-Gm-Message-State: AOAM533I0iRDA3zpOeJpU1DSqCP1Tfo3eajx1HWGy315XVGFMg5qAYuR Fz/2jhPuhG1dLiYbYYe8CezFBfOaiZ4npnqkQQP2vqf+wzc=
X-Google-Smtp-Source: ABdhPJzMzrKMPPK6OYTFc5WthFVmeMSI/hPyysxmhYiM2Jn7gaPYGfwmDruDgedVNFpo/ujOis4StpDS1c/m7CFQvWM=
X-Received: by 2002:a05:651c:17a6:: with SMTP id bn38mr8377617ljb.56.1636470897515; Tue, 09 Nov 2021 07:14:57 -0800 (PST)
MIME-Version: 1.0
References: <0aad01d755ee$ed599f10$c80cdd30$@gmail.com> <CA+-tSzxxKWtLi2DsGy9EhBH1iT2cEKHO9BfW6nka7w=YjP0wVA@mail.gmail.com> <DF4PR8401MB0650707D822943352E7FF8C2AF1C9@DF4PR8401MB0650.NAMPRD84.PROD.OUTLOOK.COM> <CA+-tSzwvBx3ScYpQ8T9Yz_ePvOngfWYWwoungyK9Gq0rz9LgVg@mail.gmail.com> <0b7d01d7d498$67ec0ec0$37c42c40$@gmail.com> <CA+-tSzyY5gqWrVL-G7eQMg+Hj2GYnqqrTAggj0k0K8vtj+0dJw@mail.gmail.com> <545FE1EA-64A0-4B7F-BA92-D2EC1B7E2FDF@cisco.com>
In-Reply-To: <545FE1EA-64A0-4B7F-BA92-D2EC1B7E2FDF@cisco.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 09 Nov 2021 07:14:45 -0800
Message-ID: <CA+-tSzwHSkfuuHNFrJ2iLTMRJGMvgYvoiPBopf2=e++6t=VVyA@mail.gmail.com>
To: "Patrice Brissette (pbrisset)" <pbrisset@cisco.com>
Cc: "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>, Luc André Burdet <laburdet.ietf@gmail.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088214405d05c9276"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/PnvF-Wobb2U7qwNxWwiA1tyhJok>
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: Tue, 09 Nov 2021 15:15:06 -0000

Patrice,

The one at the very top of the thread:

>>>
Would it be possible to add a line in section 4 along the lines of:

"While the various algorithms for DF election are discussed in Sections
4.2-4.4, unlike all-active load balancing, the choice of algorithm in this
solution doesn't impact performance in any way since there is only one
active link."
>>>
I think adding the above line will make it clear that the choice of the
algorithm for single active is inconsequential in terms of performance.

Anoop

On Tue, Nov 9, 2021 at 6:49 AM Patrice Brissette (pbrisset) <
pbrisset@cisco.com> wrote:

> Anoop,
>
>
>
> Which specifics haven’t we answer?
>
>
>
> Regards,
>
> Patrice Brissette, Principal Engineer
>
> Cisco Systems
>
>
>
> *http://e-vpn.io <http://e-vpn.io>*
>
> *http://go2.cisco.com/evpn <http://go2.cisco.com/evpn>*
>
>
>
>
>
>
>
>
>
> *From: *BESS <bess-bounces@ietf.org> on behalf of Anoop Ghanwani <
> anoop@alumni.duke.edu>
> *Date: *Tuesday, November 9, 2021 at 09:48
> *To: *"slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
> *Cc: *Luc André Burdet <laburdet.ietf@gmail.com>, "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
>
>
>
> Hi Stefane,
>
>
>
> Yes, the document is much improved.  There's the last exchange below which
> I didn't get a response to.  I think that would help convey the intent of
> the authors more clearly.
>
>
>
> Thanks,
>
> Anoop
>
>
>
> On Mon, Nov 8, 2021 at 4:01 AM <slitkows.ietf@gmail.com> wrote:
>
> Anoop,
>
>
>
> Could you confirm that you are fine with the changes proposed by Luc, so
> we can move the draft forward to next steps ?
>
>
>
> Thanks !
>
>
>
>
>
> *From:* Anoop Ghanwani <anoop@alumni.duke.edu>
> *Sent:* lundi 5 juillet 2021 21:39
> *To:* Luc André Burdet <laburdet.ietf@gmail.com>
> *Cc:* slitkows.ietf@gmail.com; bess-chairs@ietf.org; BESS <bess@ietf.org>
> *Subject:* Re: [bess] WGLC, IPR and implementation poll on
> draft-ietf-bess-evpn-mh-pa-02
>
>
>
> Thanks Luc.
>
>
>
> Would it be possible to add a line in section 4 along the lines of:
>
>
>
> "While the various algorithms for DF election are discussed in Sections
> 4.2-4.4, unlike all-active load balancing, the choice of algorithm in this
> solution doesn't impact performance in any way since there is only one
> active link."
>
>
>
> Anoop
>
>
>
> On Mon, Jul 5, 2021 at 11:31 AM Luc André Burdet <laburdet.ietf@gmail.com>
> wrote:
>
> 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> 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
> https://www.ietf.org/mailman/listinfo/bess
>
>