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

slitkows.ietf@gmail.com Tue, 16 November 2021 08:53 UTC

Return-Path: <slitkows.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 763643A0141; Tue, 16 Nov 2021 00:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 SZTw44QOXGQv; Tue, 16 Nov 2021 00:53:11 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 6BC083A0139; Tue, 16 Nov 2021 00:53:10 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id z5so24553240edd.3; Tue, 16 Nov 2021 00:53:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=To0aiyQX8BnCg3MnqsYs0YSV8xqObPwlMDOir+b0VyA=; b=OT8Do0PbCv5Q8YHeT84hYoyIkuTkYbHl6CchlRLgwjWZlXrExRht8jPi16VNWYGl4w FL0ENcaAV1dZsdwK8SnL7ofkskEhBC4iHAkJJ1Lqfa7FttLPmuIC+pdP4gxoyogSdGM1 dY/bAOgfEgcNwQ60jbLyxlU9UWWqhhvk1mB/X++Hbs0m/fMmKb9JCl9CYKmAbx4E5A98 3vnpwAv85lgc4e4rVoW8/rhy9yk5dvYEMj3/mWc77GzGs6TT9dov8YRzhctdebZVstbR IrTrXsY+gyo+MGCxZU42KaEhhLHazKMOEndXWw8gN9YbkIBqDBOa5rSHtvDxtAh1C7xH mbbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=To0aiyQX8BnCg3MnqsYs0YSV8xqObPwlMDOir+b0VyA=; b=fKyzV4a+KBJhDIIVeBHVHgx0Ayl4TpzT35VvjBnAryes3QVMRyR+CDgHGV+wV07sCw oqr1Fvcusrggx1XN+5ySoJjZ47KBTaSR0Ey88rJeUSRI4dqYGn4gSxMHvXimeZBQ0IDO T7RSe1srgNUSEz6X17Bc/9IysJTdiymR1MeiiF7fxeqdtddxTQm2AUahLnaf1sBctDyo NBUWiYLgRTRfEhc3IbGyKyndZMjDOiqH7hpljaYB87aq47ZR2HJ9JoERfWQy0vZuMIfx yX8/gN/97vWOQkki3JleFElGqJ9v0XHEfJYThouqdY6zUg32xf0IVrUWwbouv8KfJfCA A2aA==
X-Gm-Message-State: AOAM533hmEahePomrjphvHFJE2+RGhzNiwAT9OkWxhNnyrr4PKHbqcN9 qPDubxhfjqC0f00hbMHuKg==
X-Google-Smtp-Source: ABdhPJz8DmFvijTBGCayoj/vVANDF7y3oNY0g5K3vEj+9ARR80wsydqvNwz1pRVjnl0Ieye9DVVnUw==
X-Received: by 2002:a17:906:80b:: with SMTP id e11mr7821338ejd.20.1637052788318; Tue, 16 Nov 2021 00:53:08 -0800 (PST)
Received: from CSCOWPF2QW8Y3 ([173.38.220.43]) by smtp.gmail.com with ESMTPSA id y6sm8968959edc.17.2021.11.16.00.53.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Nov 2021 00:53:07 -0800 (PST)
From: slitkows.ietf@gmail.com
To: "'Rabadan, Jorge (Nokia - US/Mountain View)'" <jorge.rabadan@nokia.com>, "'Dikshit, Saumya'" <saumya.dikshit@hpe.com>, 'Luc André Burdet' <laburdet.ietf@gmail.com>, 'Anoop Ghanwani' <anoop@alumni.duke.edu>, "'Patrice Brissette (pbrisset)'" <pbrisset@cisco.com>
Cc: "'Joshi, Vinayak'" <vinayak.joshi@hpe.com>, bess-chairs@ietf.org, 'BESS' <bess@ietf.org>
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> <CA+-tSzwHSkfuuHNFrJ2iLTMRJGMvgYvoiPBopf2=e++6t=VVyA@mail.gmail.com> <TU4PR8401MB12482F8EF3A2262B19D6D59894939@TU4PR8401MB1248.NAMPRD84.PROD.OUTLOOK.COM> <BY3PR08MB7060DDECC9FB5A2B0EDB35D1F7949@BY3PR08MB7060.namprd08.prod.outlook.com> <DM8PR02MB8139EF3C7E0426BC4CF3F92DAF959@DM8PR02MB8139.namprd02.prod.outlook.com> <TU4PR8401MB1248C51C034D01BC5C72B12994979@TU4PR8401MB1248.NAMPRD84.PROD.OUTLOOK.COM> <BL3PR02MB8130B38A5E2198CDB1DF2756AF989@BL3PR02MB8130.namprd02.prod.outlook.com> <TU4PR8401MB1248453AFB0D9ED81FC4DE2494989@TU4PR8401MB1248.NAMPRD84.PROD.OUTLOOK.COM> <BY3 PR08MB7060509ECAE1A3428705E5F0F7989@BY3PR08MB7060.namprd08.prod.outlook.com>
In-Reply-To: <BY3PR08MB7060509ECAE1A3428705E5F0F7989@BY3PR08MB7060.namprd08.prod.outlook.com>
Date: Tue, 16 Nov 2021 09:53:04 +0100
Message-ID: <02de01d7dac7$5eca1cd0$1c5e5670$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DF_01D7DACF.C092F1A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ6Wu0S/Z+/XdA9ydGYHWUy4D+EgAKQdFVAAaVSkH8B4i63gAEljKTTAuw8ZbUCcfUxxwIn+VpWAerMYIoCDCkIJwIdTxndArQkiOUBQuGrEwJenHN2AatgEuKp2hDYQA==
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/oAMji8kBPGV_1KxEVtSf6HIBa34>
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, 16 Nov 2021 08:53:17 -0000

Hi,

 

Speaking as co-chair, I agree with Jorge and Luc.

We have consensus to get the document moving forward.

WGLC is now closed.

 

Brgds,

 

Stephane

 

 

From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com> 
Sent: lundi 15 novembre 2021 19:08
To: Dikshit, Saumya <saumya.dikshit@hpe.com>; Luc André Burdet
<laburdet.ietf@gmail.com>; Anoop Ghanwani <anoop@alumni.duke.edu>; Patrice
Brissette (pbrisset) <pbrisset@cisco.com>
Cc: slitkows.ietf@gmail.com; Joshi, Vinayak <vinayak.joshi@hpe.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

 

Hi Saumya,

 

I agree with Luc that your points can be discussed in a different thread,
but they should not be discussed in the context of the
draft-ieft-bess-evpn-mh-pa last call, since none of them represent an issue
for draft-ieft-bess-evpn-mh-pa.

 

Thanks.

Jorge

 

From: Dikshit, Saumya <saumya.dikshit@hpe.com
<mailto:saumya.dikshit@hpe.com> >
Date: Monday, November 15, 2021 at 4:58 PM
To: Luc André Burdet <laburdet.ietf@gmail.com
<mailto:laburdet.ietf@gmail.com> >, Rabadan, Jorge (Nokia - US/Mountain
View) <jorge.rabadan@nokia.com <mailto:jorge.rabadan@nokia.com> >, Anoop
Ghanwani <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu> >, Patrice
Brissette (pbrisset) <pbrisset@cisco.com <mailto:pbrisset@cisco.com> >
Cc: slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com>
<slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> >, Joshi, Vinayak
<vinayak.joshi@hpe.com <mailto:vinayak.joshi@hpe.com> >,
bess-chairs@ietf.org <mailto:bess-chairs@ietf.org>  <bess-chairs@ietf.org
<mailto:bess-chairs@ietf.org> >, BESS <bess@ietf.org <mailto:bess@ietf.org>
>
Subject: RE: [bess] WGLC, IPR and implementation poll on
draft-ietf-bess-evpn-mh-pa-02

Hi Luc André,

 

Following comment is a generic one, while others are w.r.t the proposed I-D
vs Port-Active

[SD] Do we need to call out explicit use-case of M+N port  (M-active,
N-standby)  redundancy and a generic method to realize that. 

Also a single PE can have more than 1 port (not bundled in a lag) carrying
all Vlans to the same PE, where-in one of them is active while other is
standby.

Can we address that case as well.

 

Regards,

Saumya.

 

From: Luc André Burdet [mailto:laburdet.ietf@gmail.com] 
Sent: Monday, November 15, 2021 9:06 PM
To: Dikshit, Saumya <saumya.dikshit@hpe.com <mailto:saumya.dikshit@hpe.com>
>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com
<mailto:jorge.rabadan@nokia.com> >; Anoop Ghanwani <anoop@alumni.duke.edu
<mailto:anoop@alumni.duke.edu> >; Patrice Brissette (pbrisset)
<pbrisset@cisco.com <mailto:pbrisset@cisco.com> >
Cc: slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> ; Joshi,
Vinayak <vinayak.joshi@hpe.com <mailto:vinayak.joshi@hpe.com> >;
bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> ; BESS <bess@ietf.org
<mailto:bess@ietf.org> >
Subject: Re: [bess] WGLC, IPR and implementation poll on
draft-ietf-bess-evpn-mh-pa-02

 

Hi Saumya,

 

It is hard to follow where you are suggesting Port-Active needs to change,
vs your I-D, or what is general feedback.

As with all DF-Election algorithms Port-Active elects a DF, a BDF and {0..n}
NDFs.

 

May we insist you start another, separate, thread to discuss the proposed
I-D and not on the Port-Active WGLC thread ?

 

Regards,

Luc André

 

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

 

 

From: "Dikshit, Saumya" <saumya.dikshit@hpe.com
<mailto:saumya.dikshit@hpe.com> >
Date: Sunday, November 14, 2021 at 13:50
To: Luc André Burdet <laburdet.ietf@gmail.com
<mailto:laburdet.ietf@gmail.com> >, "Rabadan, Jorge (Nokia - US/Mountain
View)" <jorge.rabadan@nokia.com <mailto:jorge.rabadan@nokia.com> >, Anoop
Ghanwani <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu> >, "Patrice
Brissette (pbrisset)" <pbrisset@cisco.com <mailto:pbrisset@cisco.com> >
Cc: "slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> "
<slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> >, "Joshi,
Vinayak" <vinayak.joshi@hpe.com <mailto:vinayak.joshi@hpe.com> >,
"bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> " <bess-chairs@ietf.org
<mailto:bess-chairs@ietf.org> >, BESS <bess@ietf.org <mailto:bess@ietf.org>
>
Subject: RE: [bess] WGLC, IPR and implementation poll on
draft-ietf-bess-evpn-mh-pa-02

 

Hi Luc Andre , Jorge,

 

Thanks for pointing out the proximity of
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/ 

with  l2-gw-proto
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto> 

 

I have the following comments on with tag [SD], as one of the few reasons I
asked for discussing
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/ in
context draft-ietf-bess-evpn-mh-pa-02:

 

>>> With per-port active/

   standby load-balancing, only one of the two interface I1 or I2 would

   be in forwarding, the other interface will be in standby.  This also

   implies that all services on the active interface are in active mode

   and all services on the standby interface operate in standby mode.

[SD]I intend to map the above argument to the draft, wherein the proposal is
to have ALL PEs as DF.

Do we need to suggest in the draft that active-standby from CE for the
use-case specified in the draft
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/ (As
that’s the case of Active-Active FW) may not be a fitting one.

 

>>> PEs in the redundancy group leverage the DF election defined in
       [RFC8584] to determine which PE keeps the port in active mode and
       which one(s) keep it in standby mode. 

[SD]it will good refer/call out the case where all PEs are DFs. A directive
should be added that in case all “PEs as DF”, “port-active” 

 

>>> Bit 5: (corresponds to Bit 29 of the DF Election Extended
      Community and it is defined by this document): P bit or
      'Port Mode' bit (P hereafter), determines that the DF-Algorithm
      should be modified to consider the port only and not the Ethernet
      Tags.

[SD] Guidance should be added, that if all PEs as DF mode is set, then Bit 5
value should not  be set.

 

>>> Customers want per interface single-active load-balancing, but

       don't want to enable LDP (e.g. they may be running VXLAN or SRv6

       in the network).  Currently there is no alternative to this.

[SD] Do we need to call out explicit use-case of M+N port  (M-active,
N-standby)  redundancy and a generic method to realize that. 

Also a single PE can have more than 1 port (not bundled in a lag) carrying
all Vlans to the same PE, where-in one of them is active while other is
standby.

Can we address that case as well.

 

Thanks

Saumya.

 

From: Luc André Burdet [mailto:laburdet.ietf@gmail.com] 
Sent: Friday, November 12, 2021 8:34 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com
<mailto:jorge.rabadan@nokia.com> >; Dikshit, Saumya <saumya.dikshit@hpe.com
<mailto:saumya.dikshit@hpe.com> >; Anoop Ghanwani <anoop@alumni.duke.edu
<mailto:anoop@alumni.duke.edu> >; Patrice Brissette (pbrisset)
<pbrisset@cisco.com <mailto:pbrisset@cisco.com> >
Cc: slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> ; Joshi,
Vinayak <vinayak.joshi@hpe.com <mailto:vinayak.joshi@hpe.com> >;
bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> ; BESS <bess@ietf.org
<mailto:bess@ietf.org> >
Subject: Re: [bess] WGLC, IPR and implementation poll on
draft-ietf-bess-evpn-mh-pa-02

 

Hi Saumya,

 

I agree with Jorge, and do not see how that new I-D applies to the P-A
use-case nor how it should block the progress of P-A WG document?

Based on a quick reading of your use-case you may want to have a look at
l2-gw-proto
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto> .

 

Regards,

Luc André

 

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

 

 

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com
<mailto:jorge.rabadan@nokia.com> >
Date: Thursday, November 11, 2021 at 15:21
To: "Dikshit, Saumya" <saumya.dikshit@hpe.com
<mailto:saumya.dikshit@hpe.com> >, Anoop Ghanwani <anoop@alumni.duke.edu
<mailto:anoop@alumni.duke.edu> >, "Patrice Brissette (pbrisset)"
<pbrisset@cisco.com <mailto:pbrisset@cisco.com> >
Cc: "slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> "
<slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> >, "Joshi,
Vinayak" <vinayak.joshi@hpe.com <mailto:vinayak.joshi@hpe.com> >, Luc André
Burdet <laburdet.ietf@gmail.com <mailto:laburdet.ietf@gmail.com> >,
"bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> " <bess-chairs@ietf.org
<mailto:bess-chairs@ietf.org> >, BESS <bess@ietf.org <mailto:bess@ietf.org>
>
Subject: Re: [bess] WGLC, IPR and implementation poll on
draft-ietf-bess-evpn-mh-pa-02

 

Hi Saumya,

 

I fail to see why you are asking for a discussion on
draft-saumvinayak-bess-all-df-bum before draft-ietf-bess-evpn-mh-pa can pass
WG Last Call.

Your draft addresses a completely different use-case, that we can discuss
separately, but it has nothing to do with draft-ietf-bess-evpn-mh-pa, which
is already deployed in many networks.

 

Can you clarify what you meant, please?

 

Thanks.

Jorge

 

 

From: BESS <bess-bounces@ietf.org <mailto:bess-bounces@ietf.org> > on behalf
of Dikshit, Saumya <saumya.dikshit@hpe.com <mailto:saumya.dikshit@hpe.com> >
Date: Wednesday, November 10, 2021 at 12:32 PM
To: Anoop Ghanwani <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu> >,
Patrice Brissette (pbrisset) <pbrisset@cisco.com <mailto:pbrisset@cisco.com>
>
Cc: slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com>
<slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> >, Joshi, Vinayak
<vinayak.joshi@hpe.com <mailto:vinayak.joshi@hpe.com> >, Luc André Burdet
<laburdet.ietf@gmail.com <mailto:laburdet.ietf@gmail.com> >,
bess-chairs@ietf.org <mailto:bess-chairs@ietf.org>  <bess-chairs@ietf.org
<mailto:bess-chairs@ietf.org> >, BESS <bess@ietf.org <mailto:bess@ietf.org>
>
Subject: Re: [bess] WGLC, IPR and implementation poll on
draft-ietf-bess-evpn-mh-pa-02

Hello WG,

 

There is a draft published couple of months back and talks about All-PEs
(attached to a segment) elected as DFs and a corresponding use case to do
so.

https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/

I think a discussion is needed before proceeding with
draft-ietf-bess-evpn-mh-pa

 

A new version of I-D, draft-saumvinayak-bess-all-df-bum-00.txt

has been successfully submitted by Saumya Dikshit and posted to the IETF
repository.

 

Name:                 draft-saumvinayak-bess-all-df-bum

Revision:            00

Title:                    EVPN Mac Dampening Back-off

Document date:              2021-09-03

Group:                Individual Submission

Pages:                 7

 

 

Abstract:

   The Designated forwarder concept is leveraged to prevent looping of

   BUM traffic into tenant network sourced across NVO fabric for

   multihoming deployments.  [RFC7432] defines a prelimnary approach to

   select the DF for an ES,VLAN or ES,Vlan Group panning across multiple

   NVE's.  [RFC8584] makes the election logic more robust and fine

   grained inculcating fair election of DF handling most of the

   prevalent use-cases.  This document presents a deployment problem and

   a corresponding solution which cannot be easily resolve by rules

   mentioned in [RFC7432] and [RFC8584].

 

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Anoop Ghanwani
Sent: Tuesday, November 9, 2021 8:45 PM
To: Patrice Brissette (pbrisset) <pbrisset@cisco.com
<mailto:pbrisset@cisco.com> >
Cc: bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> ; Luc André Burdet
<laburdet.ietf@gmail.com <mailto:laburdet.ietf@gmail.com> >;
slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> ; BESS
<bess@ietf.org <mailto:bess@ietf.org> >
Subject: Re: [bess] WGLC, IPR and implementation poll on
draft-ietf-bess-evpn-mh-pa-02

 

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 <mailto: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 <mailto:bess-bounces@ietf.org> > on behalf
of Anoop Ghanwani <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu> >
Date: Tuesday, November 9, 2021 at 09:48
To: "slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> "
<slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> >
Cc: Luc André Burdet <laburdet.ietf@gmail.com
<mailto:laburdet.ietf@gmail.com> >, "bess-chairs@ietf.org
<mailto:bess-chairs@ietf.org> " <bess-chairs@ietf.org
<mailto:bess-chairs@ietf.org> >, BESS <bess@ietf.org <mailto: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
<mailto: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 <mailto:anoop@alumni.duke.edu> >

Sent: lundi 5 juillet 2021 21:39
To: Luc André Burdet <laburdet.ietf@gmail.com
<mailto:laburdet.ietf@gmail.com> >
Cc: slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> ;
bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> ; BESS <bess@ietf.org
<mailto: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
<mailto: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
<mailto:laburdet.ietf@gmail.com>   |  Tel: +1 613 254 4814

 

 

From: BESS <bess-bounces@ietf.org <mailto:bess-bounces@ietf.org> > on behalf
of Anoop Ghanwani <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu> >
Date: Tuesday, June 1, 2021 at 19:23
To: "slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> "
<slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> >
Cc: "bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> "
<bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> >, BESS <bess@ietf.org
<mailto: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/>
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-pa/
 
[2]
<https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw>
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