Last Call Review of draft-ietf-l2vpn-vpls-mcast-14
review-ietf-l2vpn-vpls-mcast-14-secdir-lc-meadows-2013-09-26-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.

This ID describes a method by which service providers for Virtual Private LANs
can use multicast trees for routing muilticast messages to customers in VPLS. 
This extends RFC's  4761 "Virtual Private LAN Service using BGP for
Auto-Discovery and Signaling" and 4762, "Virtual Private LAN Services over MPLS
Label Distribution Protocol (LDP) Signaling".  In these RFC's, the ingress
Provider Edge Device (ingress PE) replicates a copy of the message for each
relevant exit PE.  This can become a performance bottleneck when the number of
recipients is large.  This ID addresses this problem.

This ID addresses mainly internal network management, and so, as the authors
point out in the Security Considerations Section, it does not introduce many
security problems other than already discussed in those RFC's, which are mainly
addressed by the security features of BGP, upon which the protocols rely.  The
main security issue introduced by this draft is that neither BGP nor VPLS
provide for secrecy of the multicast tree data.  However, as the authors point
out, providing such security is the responsibility of the Service Provider
managing the LAN, and this is beyond the scope of VPLS.

I do not think any modifications or extensions need to be made to the security
section, but I have a couple of other questions:

This ID is described as being intended for use with RFC's 4761 and 4762, but
when I checked on 4761 in the ID tracker, it said that it is updated by 4762,
although 4762 itself says nothing about this.  In that case, is there any
reason to provide support for 4761?  Or was this an error in the ID tracker?

Likewise, the ID refers to both 4761 and 4762 for definitions of terms.  What
happens if the two RFC's don't agree on a definition?  Should one default to
4762, or to the RFC the implementer is using?  According to RFC 4762, the
protocol defined by the two RFC's, although they perform similar functions, are
independent and incompatible, so this could make possibly a difference.

Cathy Meadows