Subject: [bess] Last Call: <draft-ietf-bess-evpn-df-election-framework-06.txt> (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 04 Dec 2018 16:57:08 -0800

The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Framework for EVPN Designated Forwarder
Election Extensibility'
  <draft-ietf-bess-evpn-df-election-framework-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-12-18. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   The Designated Forwarder (DF) in EVPN networks is the Provider Edge
   (PE) router responsible for sending broadcast, unknown unicast and
   multicast (BUM) traffic to a multi-homed Customer Equipment (CE)
   device, on a given VLAN on a particular Ethernet Segment (ES). The DF
   is selected out of a list of candidate PEs that advertise the same
   Ethernet Segment Identifier (ESI) to the EVPN network. By default,
   EVPN uses a DF Election algorithm referred to as "Service Carving"
   and it is based on a modulus function (V mod N) that takes the number
   of PEs in the ES (N) and the VLAN value (V) as input. This default DF
   Election algorithm has some inefficiencies that this document
   addresses by defining a new DF Election algorithm and a capability to
   influence the DF Election result for a VLAN, depending on the state
   of the associated Attachment Circuit (AC). In addition, this document
   creates a registry with IANA, for future DF Election Algorithms and
   Capabilities. It also presents a formal definition and clarification
   of the DF Election Finite State Machine.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 7 Dec 2018 01:00:50 -0800

I have reviewed the doc and I have mostly editorial comments.

Thanks,
Anoop

==

Throughout

VLAN Bundle, VLAN bundle, VLAN-Bundle, VLAN-bundle -- make consistent
VLAN Aware Bundle, VLAN-aware bundle, VLAN-Aware Bundle -- make consistent
bridge table, Bridge Table -- make consistent (also add definition to
terminology section)
DF election, DF Election -- make consistent
Default DF Election, default DF Election -- make consistent
non-DF -> NDF

Section 1

double Q-in-Q tags -> Q-in-Q tags

double is redundant

Section 2.1

Fig 1 is a bit confusing.  If the idea of the rectangle is to show a
core, then why have connections between PE1 and PE2, PE3, but not
between PE1 and PE4?

Change
Layer-2 devices are particularly susceptible to forwarding loops
because of the broadcast nature of the Ethernet traffic.
to
The effect of forwarding loops in a Layer-2 network is particularly
severe because of the broadcast nature of Ethernet traffic and the
lack of a TTL.

Section 2.2.1

a v4 or v6 peering -> an IPv4 or IPv6 peering

>>>
>From a forwarding perspective, this is
a churn, as it results in re-programming the PE ports as either
blocking or non-blocking at potentially all PEs when the DF changes.

Why would the reprogramming change at all PEs?  It should change for
at most 2 PEs for each (ES,EVI) being reprogrammed.  Maybe authors
were trying to convey something else?

Section 2.3

DF Election procedure Generally
Missing a period.

Section 3

specification in EVPN -> EVPN specification

Section 3.1

DF WAIT, DF_WAIT -- make consistent
DF Wait timer -- where is this defined?
Ethernet Segment Route -> Ethernet Segment route
stop DF timer ->  stop DF wait timer (?)
start DF timer -> start DF wait timer (?)

Section 4

rather than the state of the server states -> rather than the state of
the server (?)

Section 4.2

Si is the IP address of server i -> Si is the IP address of PE i
operator chooses so -> operator so chooses
Note 0 <= i,j <= Number of PEs -- should this be "< Number of PEs"?
Weight(V, Es, Sk) -> Weight(v, Es, Sk)
Pseudo-random -> pseudo-random
efficient deterministic -> efficient and deterministic
V4 -> IPv4
V6 -> IPv6

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Fri, 7 Dec 2018 17:09:14 +0000

Hi Anoop,

Thank you very much for your editorial comments and review.
We will take care of it.

Best,
--Satya

On 12/7/18, 1:01 AM, "BESS on behalf of Anoop Ghanwani" <[email-masked] on behalf of [email-masked]> wrote:

    Thanks,
    Anoop
    
    ==
    
    Throughout

    Section 1

    double is redundant
    
    Section 2.1

    Change
    to
    
    Section 2.2.1

    

    Section 2.3
    
    Missing a period.

    Section 3

    Section 3.1

    Section 4

    Section 4.2

    _______________________________________________
    BESS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/bess

---

From: Neeraj Malhotra <[email-masked]>
Date: Mon, 17 Dec 2018 11:48:18 -0800

Hi,

Very solid and understandable. Couple of minor comments [NM]:

Section 2.1: Layer-2 devices are particularly susceptible to
forwarding loops because of the broadcast nature of the Ethernet
traffic.

[NM]: better to refer to "Layer-2 services" instead of "Layer-2
devices" as the CE or PE devices themselves may be layer-3 capable.

Section 4.2: Note that while the DF election algorithm in [RFC7432]
uses PE address and vlan as inputs, this document uses Ethernet Tag,
PE address and ESI as inputs.

[NM]: I think the text in this context uses "vlan" and "Ethernet Tag"
interchangeably. Since the above is trying to emphasize the use of
"ESI" in this document as the key differentiation, clearer to have
other two variables (vlan and PE address) read the same, or else it
makes you wonder if there is a difference between vlan and ethernet
tag in this context.

Thanks,

Neeraj

---

From: Neeraj Malhotra <[email-masked]>
Date: Tue, 18 Dec 2018 09:32:33 -0800

Hi,

Thanks,

Neeraj

---

From: John E Drake <[email-masked]>
Date: Tue, 18 Dec 2018 18:22:22 +0000

Comment inline

Sent from my iPhone

On Dec 18, 2018, at 12:33 PM, Neeraj Malhotra <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Section 2.1: Layer-2 devices are particularly susceptible to forwarding loops because of the broadcast nature of the Ethernet traffic.

[NM]: better to refer to "Layer-2 services" instead of "Layer-2 devices" as the CE or PE devices themselves may be layer-3 capable.

Section 4.2: Note that while the DF election algorithm in [RFC7432] uses PE address and vlan as inputs, this document uses Ethernet Tag, PE address and ESI as inputs.

[NM]: I think the text in this context uses "vlan" and "Ethernet Tag" interchangeably. Since the above is trying to emphasize the use of "ESI" in this document as the key differentiation, clearer to have other two variables (vlan and PE address) read the same, or else it makes you wonder if there is a difference between vlan and ethernet tag in this context.

JD:  Actually vlan and Ethernet Tag are very different.  Please see the terminology section.  This is a significant difference from RFC 7432.

Thanks,

Neeraj

On Tue, Dec 4, 2018 at 4:59 PM The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2018-12-18. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

The file can be obtained via
https://datatracker.ietf..org/doc/draft-ietf-bess-evpn-df-election-framework/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Ddf-2Delection-2Dframework_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=l5qLwILLDWh53LIZmZZi3M9lhVxAfqF3LVsW8jtXLxQ&s=lSHVTMGZo7u6c93YRuV3E1PoHCI5blaDvP4J166SNZQ&e=>

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ballot/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Ddf-2Delection-2Dframework_ballot_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=l5qLwILLDWh53LIZmZZi3M9lhVxAfqF3LVsW8jtXLxQ&s=B0Isb3my1RRZNjdfFCaxzQkYpvhpb39wg0p0EO-NWP4&e=>

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=l5qLwILLDWh53LIZmZZi3M9lhVxAfqF3LVsW8jtXLxQ&s=tQCKfBP8NR4zagJVtyXPZv7w_RP4y0y0hSFGltxYHlM&e=>
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=l5qLwILLDWh53LIZmZZi3M9lhVxAfqF3LVsW8jtXLxQ&s=tQCKfBP8NR4zagJVtyXPZv7w_RP4y0y0hSFGltxYHlM&e=

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 19 Dec 2018 09:18:28 +0000

Hi Anoop,

Thank you for your review. We took all your comments.
Please see in-line how we are resolving them in rev 07.

Thanks.
Jorge

-----Original Message-----
From: BESS <[email-masked]> on behalf of "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Friday, December 7, 2018 at 6:09 PM
To: Anoop Ghanwani <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] Last Call: <draft-ietf-bess-evpn-df-election-framework-06.txt> (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

    Hi Anoop,

    Best,
    --Satya

        
        Thanks,
        Anoop
        
        ==
        
        Throughout
        
[JORGE] done, thx
        
        Section 1

        double is redundant
[JORGE] done, thx
        
        Section 2.1
        
        Fig 1 is a bit confusing.  If the idea of the rectangle is to show a
        core, then why have connections between PE1 and PE2, PE3, but not
        between PE1 and PE4?
[JORGE] good point, fixed it, thx
        
        Change
        to
[JORGE] done, thanks.
        
        Section 2.2.1
        
[JORGE] done, thanks.

        Why would the reprogramming change at all PEs?  It should change for
        at most 2 PEs for each (ES,EVI) being reprogrammed.  Maybe authors
        were trying to convey something else?
[JORGE] changed to: 
***From a forwarding perspective, this is
   a churn, as it results in re-programming the PE ports as either
   blocking or non-blocking at the PEs where the DF state changes.***

        Section 2.3
        
        Missing a period.
[JORGE] done, thanks.

        Section 3
        
[JORGE] done, thanks.

        Section 3.1
        
[JORGE] done, thanks.

        DF Wait timer -- where is this defined?
[JORGE] This is defined in [RFC7432]. I added a reference.

[JORGE] done, thanks.
        
        Section 4
        
[JORGE] done, thanks.
        
        Section 4.2
        
[JORGE] done, thanks.

[JORGE] done, thanks.

[JORGE] all of them changed. Thanks.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 19 Dec 2018 12:19:46 +0000

Hi Neeraj,

Thank you very much for reviewing.

Besides John’s reply to your second comment, about the first comment, based on the feedback from the reviewers, we changed that sentence to:

Thank you.
Jorge

From: BESS <[email-masked]> on behalf of John E Drake <[email-masked]>
Date: Tuesday, December 18, 2018 at 7:22 PM
To: Neeraj Malhotra <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] Last Call: <draft-ietf-bess-evpn-df-election-framework-06.txt> (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

Comment inline
Sent from my iPhone

Hi,

Thanks,

Neeraj

Abstract

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 19 Dec 2018 17:51:40 -0800

Thanks Jorge!

On Wed, Dec 19, 2018 at 1:18 AM Rabadan, Jorge (Nokia - US/Mountain