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 document defines a set of mandatory-to-implement features for L3 mcast BGP/MPLS VPN implementations, with the underlying motivation being that due to the current lack of a minimal necessary and sufficient set of mandatory features, currently deployed implementations may be compliant, yet not interoperate. 

I think the security ADs will want to pay attention to this document. The security considerations section is very brief:

  "This document does not by itself raise any particular security
   considerations."

After reading this, I was surprised to find a page-and-a-half discussion earlier in the document entitled "3.3.5  Security and robustness". This section seems to indicate that there *are* security considerations, although the section could really use some editorial attention. 

I would suggest a couple of things: first, thoroughly review 3.3.5 to ensure that it is complete. Second, try to make this section more intelligible. For example, here is the first paragraph:

   BGP supports MD5 authentication of its peers for additional security,
   thereby possibly benefit directly to multicast VPN customer multicast
   routing, whether for intra-AS or inter-AS communications.  By
   contrast, with a PIM-based approach, no mechanism providing a
   comparable level of security to authenticate communications between
   remote PEs has been yet fully described yet
   [I-D.ietf-pim-sm-linklocal][], and in any case would require
   significant additional operations for the provider to be usable in a
   multicast VPN context.

I've read this several times, yet I still have no idea what this is meant to communicate.

Third, it wouldn't hurt to refer the reader to other places where relevant security requirements are already discussed (e.g., RFC4834).

--Scott