Last Call Review of draft-ietf-bess-evpn-vpls-seamless-integ-05
review-ietf-bess-evpn-vpls-seamless-integ-05-secdir-lc-kent-2018-12-13-01

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)