Last Call Review of draft-ietf-l2vpn-pbb-vpls-interop-05
review-ietf-l2vpn-pbb-vpls-interop-05-secdir-lc-lepinski-2013-10-10-00

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 primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

Summary: With the exception of the minor editorial issues below, I believe this
document is ready to publish

This is an informational document that describes how to use Hierarchical
Virtual Private LAN Service (H-VPLS) [RFC 4762] with the IEEE's 802.1ah
specification for Provider Backbone Bridging. In particular, the document lays
out four deployment scenarios and describes how the two
technologies inter-operate in each scenario (to achieve better scaling
propertires than one would get without use of 802.1ah).

The authors claim that the use of 802.1ah introduces no security concerns
beyond the general considerations in any H-VPLS deployment, which are
documented in RFC 4762 (and RFC 4111). I am inclined to agree. Although I don't
have a deep enough knowledge of H-VPLS to be certain, I think that some of the
security concerns documents in RFC 4762 (e.g., traffic isolation and certain
kinds of denial of service attacks) are actually somewhat alleviated through
the use of Provider Backbone Bridging.

EDITORIAL COMMENTS:

As someone who does not ordinarily read L2VPN documents, I would find it very
helpful if you could expand each acronym the first time it is used. In
particular, I would have found it very helpful if you had expanded VPLS when it
appears in the first sentence of the introduction. (I also would have found it
quite helpful to include a reference to 4762 early in the introduction as well.)

Additionally, In understanding the security considerations for this document, I
personally found it very useful to read portions of RFC 4111. RFC 4111 is
referenced by RFC 4762, but I think it would be helpful to provide a direct
reference to RFC 4111 in the security considerations for this document. (As
opposed to just referencing RFC 4762.) This is a small editorial point, but as
a reader, I would prefer a direct link to a document that is likely to be of
interest, as opposed to following a sequence of references.