Last Call Review of draft-ietf-l2vpn-evpn-08
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.