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

Team Ops Directorate (opsdir)
Title Last Call Review of draft-ietf-l2vpn-evpn-08
Request Last Call - requested 2014-09-30
Reviewer Dan Romascanu
Review result Has Issues
Posted at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00538.html
Last updated 2014-10-16

Review
review-ietf-l2vpn-evpn-08-opsdir-lc-romascanu-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.





 




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