SECDIR review of draft-ietf-bess-evpn-vpls-seamless-integ-05 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This short document declares that it specifies procedures for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions (PBB-)VPLS. It also claims to provide mechanisms for seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce(PBB-)EVPN PEs in their brown-field deployments of (PBB-)VPLS networks. (Quite a mouthful!) Section 1 provides a discussion of the motivations for the procedures described I the document, i.e., a perceived desire by service providers to preserve an investment in older (layer 2) VPN technologies while offering new (layer 2) VPN interfaces at the edges of their networks. The authors note that not all combinations of the old and new technologies are described in the document, because there have been no indication that service providers want to support all of the possible combinations. Section 2 defines requirements (and a non-requirement) for backward compatibility. The definitions seem to justify the use of the phrase Óseamless.Ó Section 3 describes how the backward compatibility is achieved for VPLS integration with EVPN. IÕm concerned about whether all of the functions described here can be effected w/o any software changes to PEs. Perhaps existing software is known to offer the necessary configuration capabilities, but are such capabilities mandated by a set of RFCs? I note that two of the authors are affiliated with Cisco; I assume they are sufficiently familiar with Cisco products to be confident that those products have the requisite functionality. However, the IET needs to ensure that sufficient configuration functionality exists in analogous products by other vendors, preferably because it is mandated by RFCs. This question is beyond my ken. Section 4 describes how PBB-VPLS is integrated with PBB-EVPN. The structure for this section parallels that of Section 3, a nice organizational touch. Section 5 address security considerations, in two short paragraphs. The authors appropriately cite the security considerations sections of the RFCs that define the layer 2 VPN technologies that are the focus of this document. The Security Considerations section of RFC 4761 seems to be well-written and appropriate. The Security Considerations section of RFC 4762 is shorter, and vague in places. (For example, there is an admonition to limit the number of MAC address per site per VPLS, but no indication of how to achieve this.) RFC 7080 contains a trivial Security Consideration section, citing RFC 4111 (which is also cited in RFC 4762) and RFC 4762 (which is already cited here). RFC 7432 contains a meaningful Security Considerations section, a nice change! The Security Considerations section of RFC 7623 mostly cites 7432. The authors argue that no new security considerations are introduced here, because advertisement and processing of MAC address in BGP and processing of MAC address learned over PWs is addressed in the cited RFCs. This seems to be a reasonable argument, although one gets the sense that there are many, many ways to misconfigure the various tables used in these VPNs with adverse security results. Editorial issues: The readability of the document would be significantly improved by the introduction of a commas in many places, but I trust the RFC Editor will address this concern. There are also many instances of run-on sentences that should be fixed, to improve readability. Section 1: In Figure 1 the acronym PE is used, but it is not defined until Section 1.2 Section 2: - missing space in requirement #3 Section 4: "can be learnt" -> "can be learned" (preferable American English usage)