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 is an early review of an experimental draft.

This document defines an experimental Outbound Route Filter (ORF) called the VPN Prefix ORF.

A number of acronyms are used without definition, including RBI, PE, and ASBR. VRF is used in the abstract, and then later defined in the "Terminology" section, but the others were not defined there. I'd suggest expanding all acronyms on first use.

Section 4 page 5 says "In order to more finely control VPN routing, when not all VRFs on a PE that are interested in VPN routes with a specific RD exceed the limit, the PE MUST NOT send a VPN Prefix ORF entry." This sentence doesn't make sense to me.

Section 6 page 15 says "Optional TLVs: carry the potential additional information to give the extensibility of the VPN Prefix ORF mechanism.  Its format is shown in Figure 6.  If one or more TLV(s) are not well formed, they should be ignored" -- a little further down, it says "According to [RFC5291], if any of the fields of a VPN Prefix ORF entry in the message contains an unrecognized value, the whole specified ORF previously received is removed."

Should there be a difference between handling of "not well formed" vs. "unrecognized"? What does "not well formed" mean? I found this a little confusing.

The Security Considerations section says 

"This draft does build upon [RFC5291].  A BGP speaker will maintain the VPN Prefix ORF entries in an ORF-Policy table, this behavior consumes its memory and compute resources.  To avoid the excessive consumption of resources, [RFC5291] specifies that a BGP speaker can only accept ORF entries transmitted by its interested peers."

The security considerations in RFC5291 simply state that it adds no security considerations beyond those of RFC4271 (BGP), and I was unable to find anything about resource consumption or interested peers in 5291 -- so I'm not sure what to make of this reference.

It might be good to explicitly state that this draft adds no new security considerations beyond those of 5291.