Last Call Review of draft-ietf-l2vpn-evpn-08

Request Review of draft-ietf-l2vpn-evpn
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-10-14
Requested 2014-09-30
Authors John Drake, Wim Henderickx, Ali Sajassi, Rahul Aggarwal, Nabil Bitar, Aldrin Isaac, Jim Uttaro
Draft last updated 2014-10-16
Completed reviews Genart Telechat review of -10 by Martin Thomson (diff)
Secdir Last Call review of -08 by Hilarie Orman (diff)
Opsdir Last Call review of -08 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu 
State Completed
Review review-ietf-l2vpn-evpn-08-opsdir-lc-romascanu-2014-10-16
Reviewed rev. 08 (document currently at 11)
Review result Has Issues
Review completed: 2014-10-16


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.




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?




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




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?





 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.