Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df

slitkows.ietf@gmail.com Mon, 31 August 2020 09:49 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 3885E3A1195; Mon, 31 Aug 2020 02:49:39 -0700 (PDT)
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 4Aychjn_0YhR; Mon, 31 Aug 2020 02:49:37 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 153603A116B; Mon, 31 Aug 2020 02:49:37 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id s13so4746614wmh.4; Mon, 31 Aug 2020 02:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=OOPGjpmf6pmvX+GMB3aZsuzx7jUoo3RZbs0g4vzZa+E=; b=rhyS82ilVX7Jw1NmKxcqPGUOclHQPSnBijTrbn9PlIQ7pjcsrABxmHy4+OBA+iXs00 K91BDfJZ47UTvusZ5/xDVCdm50fehw6buPOR76uu2qRDQzup5MgyjopKn0Pst7yKsfz4 C6Dvwd/KXX+Wnvm9ivIuXrwhPQ7woVIoqSqQ569spduuCrh1JlVRTTQHv2uIOn1M/7XX GSVZL4GZ95umunFJDUFRp1OGqlac/xulEDP/hcRG7unqLOE28TIg9A6NJQZjb7yTJNRt myI2W1y8T9C14xnE8jXFZAcOt7L/Ido97x+SUk+du/Dg0zSLBHXWa5Wx9Mj00iXqc6z0 BL+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=OOPGjpmf6pmvX+GMB3aZsuzx7jUoo3RZbs0g4vzZa+E=; b=NOMouwOq6H5ETFVYMTiwQbsSv4iNYOh/kLMIxzZmVWtndtvBBNsuOISTaOqFg4htbN E5k+vxVWgaKnHX/oCGL0+85DjWWf2jS2HNuKIVutk/ZsU2fIihAU9jIgPUX7TdeFHTcW Z1NZihMQpKSAi+UTN6ML0yj8V55GIzvn3ibX1mCGP9EW2eNJigidAP7ie1mXt6NfPsl0 +qK8F0xCZqltky210/CJ8bx7bb2UXeWlaelWOuRVODn5LB4ZUwz+mBGHhU/V7rfsqWy6 E2EU0S3o/dnm7/b2RWYPvWGYgCI/pB2IZyRKPeINBVzI3Uo/KdrffjQNxgTSTmF9lYoP hkJw==
X-Gm-Message-State: AOAM533Mblb9fmDwLng0+t/Z3HUS/c5UYp/urOW7bNEXTAsxmCUxStlq 9Slr4y/rdZjucsVCVErCfIVijS6kP3eU
X-Google-Smtp-Source: ABdhPJxQtI5YOk7sfRnI7tROPvQywwu4KhlMtibMIZnTce7lkn2d/HJi6RrY/LRSZkk9BIS6cqvgoA==
X-Received: by 2002:a7b:c084:: with SMTP id r4mr626136wmh.20.1598867375172; Mon, 31 Aug 2020 02:49:35 -0700 (PDT)
Received: from SLITKOWS3YYU6 ([173.38.220.59]) by smtp.gmail.com with ESMTPSA id u17sm10846526wmm.4.2020.08.31.02.49.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2020 02:49:34 -0700 (PDT)
From: slitkows.ietf@gmail.com
To: "'Rabadan, Jorge (Nokia - US/Mountain View)'" <jorge.rabadan@nokia.com>, draft-ietf-bess-evpn-pref-df@ietf.org, bess-chairs@ietf.org, bess@ietf.org
References: <041601d5ecaf$d3e46410$7bad2c30$@gmail.com> <477475D5-5521-48F8-850B-9DA353CEE297@nokia.com>
In-Reply-To: <477475D5-5521-48F8-850B-9DA353CEE297@nokia.com>
Date: Mon, 31 Aug 2020 11:49:32 +0200
Message-ID: <0b9301d67f7c$0809f1b0$181dd510$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B94_01D67F8C.CB94E490"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI3oG/GXmCXQJcgU+1BYM+1JeGCzwKJLN1TqHteb7A=
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/pW2YKcSCDWDl1zgflJ3VPOPqKJI>
Subject: Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df
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, 31 Aug 2020 09:49:39 -0000

Hi Jorge,

 

Please find additional feedback inline.

(Stripping things we agree on)

 

Stephane

 

 

From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com> 
Sent: vendredi 19 juin 2020 20:37
To: slitkows.ietf@gmail.com; draft-ietf-bess-evpn-pref-df@ietf.org; bess-chairs@ietf.org; bess@ietf.org
Subject: Re: Shepherd's Review of draft-ietf-bess-evpn-pref-df

 

Hi Stephane,

 

Thanks for the review and my apologies for the delay.

We just posted a new revision.

 

As usual, very good points. Please see in-line.

 

Thx

Jorge 

 

From: "slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> " <slitkows.ietf@gmail.com <mailto:slitkows.ietf@gmail.com> >
Date: Wednesday, February 26, 2020 at 3:20 PM
To: "draft-ietf-bess-evpn-pref-df@ietf.org <mailto:draft-ietf-bess-evpn-pref-df@ietf.org> " <draft-ietf-bess-evpn-pref-df@ietf.org <mailto:draft-ietf-bess-evpn-pref-df@ietf.org> >, 'BESS' <bess@ietf.org <mailto:bess@ietf.org> >
Cc: "bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> " <bess-chairs@ietf.org <mailto:bess-chairs@ietf.org> >
Subject: Shepherd's Review of draft-ietf-bess-evpn-pref-df
Resent-From: <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org> >
Resent-To: <jorge.rabadan@nokia.com <mailto:jorge.rabadan@nokia.com> >, <senthil.sathappan@nokia.com <mailto:senthil.sathappan@nokia.com> >, <prz@juniper.net <mailto:prz@juniper.net> >, <wlin@juniper.net <mailto:wlin@juniper.net> >, <jdrake@juniper.net <mailto:jdrake@juniper.net> >, <sajassi@cisco.com <mailto:sajassi@cisco.com> >, <satyamoh@cisco.com <mailto:satyamoh@cisco.com> >
Resent-Date: Wednesday, February 26, 2020 at 3:20 PM

 

 

 

Section 4.1:

        “ Note that, by default, the Highest-Preference is chosen for each

       ES or vES, however the ES configuration can be changed to the

       Lowest-Preference algorithm as long as this option is consistent

       in all the PEs in the ES.

I don’t think it is a good idea to open this modification. People can play with preference values to achieve the required behavior while always keeping high pref.

We have no way to ensure consistency, except if we advertise the behavior as part of the exct. Consistency of DF election is key and needs to be ensured as much as we can.

[Jorge] the idea is have the highest preference as default (maybe use normative language?), which means that it will work fine. Opening to lowest is to give more flexibility, knowing that if the user has to change the config from the default, they will do it in all the PEs of the ES.

 

[SLI] I don’t think this is a good idea, consistency is really important, if you absolutely want to do both lowest and highest, you can allocate a new DF Alg for lowest so we ensure that everybody uses the same algorithm. But I don’t think this is necessary, having highest preference is enough. I don’t remember any feature using a preference that can do both highest and lowest, it is usually one or the other.

 

 

 
 
“When PE3's vES2 comes back up, PE3 will start a boot-timer (if
       booting up) or hold-timer (if the port or EVC recovers).  That
       timer will allow some time for PE3 to receive the ES routes from
       PE1 and PE2. »
 
Are you changing the way the DF election works ? Usually, PE advertises its route and then wait to receive other routes.
[Jorge] those timers are on top of the FSM defined in RFC8584, e.g. we need to give some extra time before the ES goes up and we advertise the ES route, if the ES is configured with the DP capability. This is because the advertised preference and DP values may not be the same as the configured ones, and the ‘in-use’ values will depend on the other ES routes in the ES. If we advertise the ES route immediately after the ES is up, we may not have received the other ES routes and we don’t know what “in-use” values to advertise in order to avoid preemption in the ES. I added some text on point 5 (section 4.3).
 
 
[SLI] As we are updating the FSM, could we have new state and events defined to update the FSM similarly as we have in RFC8584 ?
 
What happens if all PEs on the ES are failing at the same time or the ES booting up on all the PEs at the same time ? you have no way to hear what is the pref from the remote.
[Jorge] The non-revertive capability makes sense when there is at least one PE alive in the ES and we don’t want to preempt it so that there is no traffic impact. If all the PEs fail, there is traffic impact anyway, so there is really no non-revertive behavior, but an initialization in all the PEs.
 
[SLI] Let’s say that you have a CE attached to 3 PEs (same ESI). PE1 pref 100, PE2 pref 200, PE3 pref 300. PE1 to 3 are configured with DP set. PE4 is a remote PE.
T0:CE fails and boots up.
T1:PE1 to PE3 starts their HOLD_TIMER
T2: PE1 HOLD_TIMER expires,  advertises ES route and starts DF_TIMER
T3: PE4 discovers ES from PE1 and starts DF_TIMER
T4: PE2 HOLD_TIMER expires,  advertises ES route and starts DF_TIMER, does it advertises with Pref100 and DP=0 as it knows from PE1 route even if PE1 is not DF yet ?
 
 

 

Brgds,

 

Stephane