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