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:

   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.

Thank you.

From: BESS <bess-boun...@ietf.org> on behalf of John E Drake 
Date: Tuesday, December 18, 2018 at 7:22 PM
To: Neeraj Malhotra <neeraj.i...@gmail.com>
Cc: "bess@ietf.org" <bess@ietf.org>
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

On Dec 18, 2018, at 12:33 PM, Neeraj Malhotra 
<neeraj.i...@gmail.com<mailto:neeraj.i...@gmail.com>> wrote:


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.
JD:  Actually vlan and Ethernet Tag are very different.  Please see the 
terminology section.  This is a significant difference from RFC 7432.



On Tue, Dec 4, 2018 at 4:59 PM The IESG 
<iesg-secret...@ietf.org<mailto:iesg-secret...@ietf.org>> wrote:

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
i...@ietf.org<mailto:i...@ietf.org> mailing lists by 2018-12-18. Exceptionally, 
comments may be
sent to i...@ietf.org<mailto:i...@ietf.org> instead. In either case, please 
retain the beginning of
the Subject line to allow automated sorting.


   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

IESG discussion can be tracked via

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

BESS mailing list
BESS mailing list
BESS mailing list

Reply via email to