Virtual Hub-and-Spoke in BGP/MPLS VPNs
draft-ietf-l3vpn-virtual-hub-08

examples should use documentation address ranges if possible.

assume IANA-SAFI is 

http://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

please fix that.

In 2. Overview

   Consider a set of PEs that maintain VRFs of a given VPN. In the
   context of this VPN we designate a subset of these PEs as "Virtual
   Spoke" PEs (or just Virtual Spokes), while some other (non-
   overlapping) subset of these PEs will be "Virtual Hub" PEs (or just
   Virtual Hubs), with the rest of the PEs in the set will be "vanilla"
   PEs (PEs that implement the [rfc4364] procedures, but do not
   implement procedures specified in this document).

I'm not parsing the second sentence. Should it be "... *while* the rest of the PEs in the set ..."? But I'm guessing.

In 5. Internet Connectivity, in the following two paragraphs:

   The first alternative is when a PE that maintains Internet routes
   also maintains a VRF of a given VPN. In this case the Internet
   connectivity for that VPN MAY be provided by provisioning in the
   VPN's VRF on that PE a default route pointing to the routing table on
   that PE that maintains the Internet routes. This PE MUST NOT be
   provisioned as a V-spoke for that VPN (this PE may be provisioned as
   either a V-hub, or as a "vanilla" PE). If this PE is provisioned as a
   V-hub, then this PE MUST originate a VPN-IP default route. The route
   MUST carry both RT-VPN and RT-VH of the V-hub (see section "Routing
   Information Exchange" for the definition of "RT-VPN" and "RT-VH").
   Thus this route will be imported by all the V-spokes associated with
   the V-hub, as well as by other V-hubs and "vanilla" PEs.  An
   implementation MUST support the first alternative.

Does this MUST apply to all PEs?

   The second alternative is when a site of a given VPN has connection
   to the Internet, and a CE of that site advertises an IP default route
   to the PE connected to that CE. This alternative has two sub-cases:
   (a) PE is provisioned as a V-hub, and (b) PE is provisioned as a V-
   spoke. An implementation MUST support the sub-case (a). An
   implementation MAY support the sub-case (b).

Does the sub-case (a) MUST *also* apply to all PEs? So, two MUSTs (and a MAY)?

In 7. Multicast Considerations

   The V-hub/V-spoke architecture, as specified in this document,
   affects certain multicast scenarios. In particular, it affects
   multicast scenarios where the source of a multicast flow is at a site
   attached to a V-hub, and a receiver of that flow is at a site
   attached to a V-spoke that is not associated with that same V-hub.
   It also affects multicast scenarios where the source of a multicast
   flow is at a site attached to a V-spoke, a receiver of that flow is
   at a site attached to a different V-spoke, and the set intersection
   between the V-hub(s) associated with the first V-spoke and the V-
   hub(s) associated with the second V-spoke is empty. It may also
   affect multicast scenarios where the source of a multicast flow is at
   a site connected to a V-spoke, a receiver of that flow is at a site
   attached to a different V-spoke, and the set intersection between the
   V-hub(s) associated with the first V-spoke and the V-hub(s)
   associated with the second V-spoke is non-empty (the multicast
   scenarios are affected if the I-PMSI/S-PMSI A-D routes originated by
   the first V-spoke are not imported by the second V-spoke).

Does everyone (except me) understand what is meant by the several "affects" in this paragraph? Are they all saying that the same thing happens in various situations, or does what happens in each situation differ?

I'm not convinced that there are no new security
considerations here. It may be true that there are no new
vulnerabilities, but that's not the same thing. For
example, presumably V-hubs are more attractive targets
for DoS or to subvert. That is, perhaps the impact of
existing vulnerabilites is increased for e.g. hubs which
could change the overall risk.  

And on the positive side, perhaps following this approach
might make it easier to start to deploy BGP security
mechanisms, e.g. if you start with hubs and then extend
out to spokes and vanilla PEs.  

However, I didn't really understand the thing enough for
this to be more than a fairly random passing comment:-)