Last Call Review of draft-ietf-l2vpn-evpn-08
review-ietf-l2vpn-evpn-08-opsdir-lc-romascanu-2014-10-16-00

I have reviewed this document as part of the Operational directorate's ongoing

effort to review all IETF documents being processed by the IESG.  These comments

were written primarily for the benefit of the operational area directors.

Document editors and WG chairs should treat these comments just like any other

last call comments.



Summary: Ready with Issues



This document describes protocol extensions and devices behavior (the document
uses the terminology of ‘procedures’) for BGP MPLS based Ethernet VPNs. The
document is clearly targeting developers who will implement these extensions and
 has little information for operators. Basically any tentative to use RFC 5706
 in evaluating this document would result in a series of NO answers to the
 questions in Appendices A.1 and A.2. On the operational side there is no
 discussion about deployment, initial installation, migration path, impact on
 network operation, verifying correct operations, reporting faults. On the
 manageability side there is no discussion about management interoperability,
 information or functions. It is up to the OPS ADs to evaluate whether this
 issue is worth being raised in the IESG 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.





Regards,



Dan