BGP MPLS-Based Ethernet VPN
draft-ietf-l2vpn-evpn-11

Ali has replied to my DISCUSS and promised fixes, so I'm moving the DISCUSS comments here, so Adrian can check them after the draft is updated:

-- Section 5 --

   In general, an Ethernet segment SHOULD have a non-reserved ESI that
   is unique network wide (i.e., across all EVPN instances on all the
   PEs).

Doesn't this SHOULD contradict the MUST in the definition of ESI in Section 3?

-- Section 23 (References) --

RFC2119 needs to be a normative reference, as it's required in order to understand the meaning of the MUST, SHOULD, and MAY key words.

Other non-blocking comments:

-- Section 1 --

   The procedures described here are intended to meet the
   requirements specified in [RFC7209].

But do they?  By the time we get to IESG approval, I should hope that it's more than an intent, but an assertion.  Please assert it.

-- Section 3 --

   Ethernet Segment Identifier (ESI):  If a CE is multi-homed to two or
   more PEs, the set of Ethernet links that attaches the CE to the PEs
   is an 'Ethernet segment'.   Ethernet segments MUST have a unique non-
   zero identifier, the 'Ethernet Segment Identifier'.

Aren't you defining two things here: Ethernet Segment and Ethernet Segment Identifier?  Shouldn't you make separate definitions for each?

Presuming that the segments don't all share the same ESI, the second sentence should say:

NEW
   Each Ethernet segment MUST have a unique non-
   zero identifier, the 'Ethernet Segment Identifier'.
END

   Single-Active Redundancy Mode: When only a single PE, among a group
   of PEs attached to an Ethernet segment, is allowed to forward traffic
   to/from that Ethernet Segment

I think the intent here is to refer to only one PE among *all* of the PEs attached... correct?  Or do I have that wrong?  As written, it doesn't say that.

-- Section 4 --

   An EVPN instance comprises
   CEs that are connected to PEs that form the edge of the MPLS
   infrastructure.

THANK YOU for a rare correct use of "comprises"!

-- Section 11.1 --

   The Originating Router's IP address MUST be set to an IP address of
   the PE.  This address SHOULD be common for all the EVIs on the PE

Why the SHOULD?  What are the effects to the protocol if the address is not common?  What are the considerations that have to be made in order to decide whether it's acceptable not to use a common address?

As noted by Dan Romascanu in his OPS-DIR review:

 

Here are a few observations that do not affect directly, but may impact indirectly the implementation of the procedures described in this document.

 

1.       The definition of a Broadcast Domain in the Terminology section is unclear.

 

Ø  Broadcast Domain: in a bridged network, it corresponds to a Virtual

   LAN (VLAN); where a VLAN is typically represented by a single VLAN ID

   (VID), but can be represented by several  VIDs.

 

 

One wonders – what combination of VIDs cannot represent a VLAN according to this definition?

 

2.       In many places acronyms are not expanded at first occurrence and some of them are never expanded. Just two examples: NRLI and SAFI in section 7

 

3.       In section 8.5 I could find one of the few cases when there is information targeting the operators who will deploy this type of solutions.

 

Ø     2. The PE then starts a timer (default value = 3 seconds) to allow

Ø     the reception of Ethernet Segment routes from other PE nodes

Ø     connected to the same Ethernet Segment. This timer value MUST be same

Ø     across all PEs connected to the same Ethernet Segment.

 

 

What is the impact of mis-configuring the timers on the PEs connected to the same segment at different values? Can this be a security attack to protect against?

 

 

4.   The IANA Considerations section says that the registry for “EVPN Route Types” has no maximum value. But then the Route Type field as defined in section 7 has 1 octet – so there should be a maximum value.

Please add some BGP security references, Adrian suggested the following:
RFC 4271 itself
RFC 4272 for a vulnerabilities analysis
RFC 2385 (ye olde MD5 for BGP)
RFC 6952 for an overview of security mechanisms

RFC 6480 doesn't really seem applicable

Thanks for addressing the SecDir review comments!
https://www.ietf.org/mail-archive/web/secdir/current/msg05120.html

I gave the document a *very* quick read. Nothing jumping out at me as either apps related or  worrisome. No objection unless someone thinks I should go through this more thoroughly.

Thanks for handling my discuss.