RE: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt

Hi Mark,

Thanks for the detailed comments.  Many responses below, marked [pk]...

> -----Original Message-----
> From: Mark Duffy [mailto:[email protected]]
> Sent: Wednesday, May 21, 2003 5:30 PM
> To: [email protected]; Knight, Paul [BL60:1A00:EXCH]
> Subject: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt
> 
> 
> Hi, here are comments on draft-ietf-ppvpn-vpn-vr-04.txt.
> 
> General comment:  Use of the VR approach in significant scale will require

> the use of tunneling mechanisms that efficiently support many tunnel links

> between a given pair of PEs, with some provision for binding a VPN-ID to 
> each tunnel link.  This document reasonably leaves that to other 
> documents.  However, the wg has no effort underway to produce 
> any such documents.  :-(
> 
[pk]  I think your draft (Framework for IPsec Protected Virtual Links for
PPVPNs, draft-duffy-ppvpn-ipsec-vlink-00.txt) is a good first step in the
direction of looking at the options for binding VPN-ID to tunnel links.  

[pk] However, it's clear from many of your comments that the current VR
draft has not fully communicated to you the functionality of the "backbone
VR," which provides an efficient way to multiplex many "tunnel links"
(although the binding of the VPN-ID is usually not explicit).  I'll try to
address this below.
> 
> In the Abstract, and similar text in the Introduction:
>                                                             Virtual
>     routers can be deployed in different VPN configurations, direct VR
>     to VR connectivity through layer-2 or by aggregating multiple VRs
>     into a single VR combined with IP or MPLS based tunnels.
> 
> [md] This idea of "aggregating multiple VRs ..." seems confusing at the 
> least.  (More comments on this below re sect 5.)  How about "... through 
> layer-2 or by tunneling over a shared IP or MPLS based network."
>
[pk] The text quoted above (from the Abstract) is unclear due to being
condensed too much.  I'll re-word it (similar to your suggestion).  The
similar text in the Introduction is correct:

   Virtual routers can be deployed in various VPN 
   configurations. Direct VR to VR connectivity may be configured 
   through layer-2 links or through a variety of tunnel mechanisms, 
   using IP- or MPLS-based tunnels. Multiple VRs may be aggregated over 
   a "backbone VR." 
 
> 
> 1. Introduction
>                                                That is, the routing
>     protocol between the VRs may be the same or it might be different
>     than the routing mechanism used between the CE and VR.
> 
> [md]  "... or it may be a different instance of the same protocol"   (The 
> point being that if ospf is used CE-VR and VR-VR, they may be the same 
> instance, or separate instances with only reachability (not topology) 
> information redistributed between them.)
>
[pk] This is a good point, not explicit in the draft.  I'll put it in
section 2.5.1 or 2.5.3, in order to avoid cluttering up the Introduction.
(The Introduction is not wrong, but does not cover all the possibilities.) 
> 
>                                                            Likewise,
>     since the VR-to-VR connectivity can use tunnels, the inter-VR
>     routing protocol can be independent of the routing used in the
>     backbone network(s) over which the VR-based VPN runs.
> 
> [md] I think it is a fundamental part of the VR model that the routing 
> within the VPN is independent of that in the shared backbone.  So I'd 
> suggest rephrasing the above more strongly:
>     Likewise, since the VR-to-VR connectivity uses tunnels or
>     independent L2 links, the inter-VR routing is independent of
>     the network layer routing used in the backbone network(s)
>     over which the VR-based VPN runs.
>
[pk] The VR-VR routing can potentially use 2547bis (BGP/MPLS), in which case
the inter-VR routing protocol is not independent of the backbone routing
(although the VPN routing is still separate from the backbone routing
information).  Although this makes it nice for service provider transitions
or interoperability, it also makes it difficult to phrase things very
strongly!  :^)  I'll probably keep this as it is in the Introduction, but
address it in more detail in section 5.3.2. 
> 
>     There are two fundamental architectures for implementing network-
>     based VPNs: virtual routers (VR) and piggybacking. The main
> 
> [md] s/network-based VPNs/network-based L3 VPNs/
>
[pk] right 
> 
> 2.1 Membership
>     All virtual routers that are members of a specific VPN MUST share
>     the same VPN identifier (VPN-ID). This should be the Globally Unique
>     Identifier (GID) defined in [VPN-GID] or the VPN-ID format defined
>     in [VPN-RFC2685].
> 
> [md] Accommodating two mechanisms here just muddies the
> water.  Can we please choose one?
> 
[pk] Yes, this has been made easier by the fact that the GID has been
resolved in section 4.2.1 of the BGP auto-discovery draft
(http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-bgpvpn-auto-05.txt) as
equivalent to RFC 2685, so the reference will now be only to 2685.
> 
> 2.2 Scalability
>                   The use of the "backbone VR" (Section 5.3) improves
>     the scalability of the PE, since many VRs on the PE may use the
>     backbone VR for connectivity to other VPN sites.
> 
> [md]  s/to other VPN sites/to other routers or VRs within the VPN/
>
[pk] No, since the backbone VR can be shared by multiple VPNs, this doesn't
quite work... maybe: "many VRs on the PE may share a single "backbone VR"
connection to peer VRs on another PE, rather than establishing multiple
separate per-VR (i.e., per-VPN) connections between PEs." 

[pk] More on the backbone VR below... (I think this answers several later
questions).
> 
> 2.4 Auto-discovery
>                                      It is required that the auto-
>     discovery mechanism take into consideration the case where the VPNs
>     are implemented across administrative domains. We assume in this
>     document that an auto-discovery mechanism which provides services
>     similar to BGP (as described in [VPN-BGP]) is used as the mechanism
>     to distribute membership, topology, and tunnel information among VRs
>     which are members of the same VPN.
> 
> [md] I don't see anything in this document that actually assumes that a 
> BGP-based discovery mechanism is used.  The server-based approach of 
> draft-heinanen-radius-pe-discovery-04.txt seems to me at least as 
> attractive for use with VRs.  In fact, I think that for those service 
> providers who chose a VR approach over a 2547 approach, not wanting to use

> BGP for VPN support may be one of their primary motivations!  I urge to 
> reference draft-heinanen in here also.
> 
[pk] This is definitely an area where future work in VR may lead, but after
discussing this with some other draft authors, we will not include this
reference for several reasons:
1) Having two mechanisms defined can lead to interoperability issues (as
noted above for VPN-ID)
2) There is not a draft describing how VR would use Radius (there is one for
BGP Autodiscovery; the one cited above)
3) As far as we know, there is no implementation of VR using Radius (there
are implementations using BGP Autodiscovery), and as a proposed standard,
the existence of implementations is quite important
4) As of this writing, the radius draft is not accepted as a working group
document (and Juha's unavailability as a future "shepherd" may weaken its
chances).

> 
> 2.5.1 Routing between PE and CE
>                      The routing protocol between the PE
>     and the CE can be independent of the PE-to-PE routing.
> 
> [md] s/PE-to-PE/VR-to-VR/
> 
[pk] Yes, I think the VR and PE terminology needs to be clarified in several
places... Thanks!
> 
> 2.5.3 Routing between PEs
>     Any existing routing protocol can be used between PEs. The routing
>     protocol between the PEs can be independent of the CE-to-PE routing.
>     As with any network design, care must be taken when multiple routing
>     protocols are used, due to differences in metrics, detail of
>     information, etc.
> 
> [md]  s/PEs/VRs/  (3 places in the above section, including the title)
> 
[pk] yes
> 
> 2.6 Security
>     The architecture MUST accommodate different levels of security for
>     data, routing, and other control information.
> 
> [md]  I hope this is intended to mean that different levels of security 
> must be accommodated, not that it must be possible to accommodate one
level 
> for data and another level for routing.  How about:
>     The architecture MUST accommodate security for VPN data, routing,
>     and other control information.  Different levels of security must
>     be possible.
>
[pk] good!  
> 
> 2.7 Topology
>     For example, in the case where the internal nodes (P devices) are
>     also VR aware (NOTE this is not required - see section
> 2.2) then it
>     is possible to have either tunnels from the PE or the CE 
> connecting
>     to these internal VRs. This type of VPN deployment can be useful
>     when the internal nodes are geographically suitable to be 
> a VPN hub.
> 
> [md] I would argue that VR aware P devices are actually not
> Ps at all but 
> PEs.  So I suggest removing the above paragraph.
>  
[pk] I agree, this needs clarifying... It may be best just to remove it.
> 
> 2.8 Tunneling
>                It should be possible to use IPSec, GRE [RFC-1701], IP in
>     IP, and MPLS tunnels.
> 
> [md] RFC 1701 is obsolescent.  This should reference RFC 2784
> (proposed standard).
> 
[pk] Agreed...
> 
>          It should also be possible to allow multiple
>     VPNs to share a tunnel across a backbone.  Therefore within a single
>     VPN, different types of tunnels can be used.
> 
> [md] I agree with the second sentence but I don't think it follows from
the 
> first sentence.  So s/Therefore//.   
[pk] yes, they are separate ideas.
>
> I think the first sentence is 
> misleading.  What matters to the VPN architecture is the virtual "links" 
> seen by the VRs.  These cannot be shared across multiple VPNs!  The
virtual 
> links (aka tunnel links) are facilitated by some tunnelling 
> mechanism.  Some tunnelling mechanisms support one or more levels of 
> multiplexing within the tunnelling mechanism itself (e.g. MPLS with 
> multiple-label stacks, L2TP).  Other tunnelling mechanisms do not 
> themselves provide multiplexing (e.g. IP-in-IP).  The fact that the 
> tunnelling mechanism may use the word "tunnel" to refer to an outer 
> aggregate (outer LSP, L2TP tunnel) containing multiple virtual links
(inner 
> label, L2TP session) is just a distraction.  I propose deleting the first 
> sentence.
> 
[pk] Actually, this is where a key function of the "backbone VR" comes into
play.  I can explain this using Figure 3 from the draft:

                PE                            PE 
         +---------------+            +---------------+ 
 +-----+ |               |            |               | +-----+ 
 |VPN-A| | +----+     MPLS/IP based Tunnels    +----+ | |VPN-A| 
 |sites|-|-|VR-A|\.......|<---------->|........|VR-A|-|-|sites| 
 +-----+ | +----+ +----+ | ---------  | +----+/+----+ | +-----+ 
         |        |VR-1|-|-(IP/MPLS )-|-|VR-2|        | 
 +-----+ | +----+/+----+ |(Backbones) | +----+\+----+ | +-----+ 
 |VPN-B|-|-|VR-B|        | ---------  |        |VR-B|-|-|VPN-B| 
 |sites| | +----+........|<---------->|........+----+ | |sites| 
 +-----+ |           MPLS/IP based Tunnels            | +-----+ 
         |               |            |               | 
         +---------------+            +---------------+ 
    
            Figure 3: VR-1 and VR-2 used as backbone VRs 

This diagram is not great; I should make it clearer.  But I think we can use
the current diagram for explaining how the backbone VR works.

The lines are clearer looking at VR-B on each side.  You can see that the
VR-Bs can either set up an MPLS/IP based tunnel directly from one VR-B to
the other...  OR they can connect through VR-1 and VR-2, the backbone VRs.
(Or do both simultaneously.)  If they connect through the backbone VRs, then
they can use a tunnel between VR-1 and VR-2.  This tunnel can provide
multiplexing for both VR-B to VR-B traffic and for VR-A to VR-A traffic.
(in the same way that VR-B provides multiplexing for multiple VPN-B sites.)

Let's look at the packet encapsulation from a VPN-B site on the left to a
VPN-B site on the right: It gets encapsulated in VR-B(left), with a source
of VR-B(left) and destination of VR-B(right).  Then it is passed to VR-1,
where it is encapsulated with a source of VR-1 and destination of VR-2.  At
VR-2, the outer encapsulation is removed, and the packet is routed to
VR-B(right).  There it is fully decapsulated and routed to a VPN-B site
(right).

It looks like the terminology and labeling need to be improved to simplify
the description, and I should include a discussion like the one above in the
draft. Also, I have used IP encapsulation in my example, but it could also
have used MPLS labels...

This also illustrates how the service provider can trade off greater
scalability (the backbone VR) against higher value "personalized service"
for VPN customers (the individual tunnels which may be provisioned with
higher QOS).

The key is that the "ordinary" VRs and the backbone VR can behave as if they
were separate devices.  The individual VRs in a PE (representing different
VPNs) can relate to the backbone VR as if they were the CEs of a single VPN
(with the backbone VR as the PE), so the VPNs can be multiplexed in a
hierarchical fashion, using IP encapsulation or stacked labels.  
 
> 
> 3. Network Reference Model
>     A VPN customer site is connected to the provider backbone by means
>     of a connection between a Customer Edge (CE) device, (which can be a
>     bridge or a router) and a virtual router (VR).
> 
> [md] s/can be a bridge or a router/can be one or more hosts
> or and\/or routers/ Bridges and other layer 2 things should 
> be transparent to the VR 
> scheme.  (See the 4th and 5th paragraph of section 1.2 of 
> draft-ietf-ppvpn-rfc2547bis-03.txt.  I think it is equally 
> applicable to this.)
>
[pk] yes, I agree.  
> 
> 3.1 Backbone
>     Not all VPNs existing on the same PE are necessarily connected to
>     the same backbone. A single VPN can be built from multiple transport
>     technologies.
> 
> [md] in general the VPNs are not "connected to" the backbone.
>  I would s/connected to the same backbone/using the same backbone/
>
[pk] Okay... 
> 
> 4. Virtual Router Definition
>     A given VR holds the routes only for the specific VPN configured for
>     that VR.
> 
> [md] s/configured for that VR/of which that VR is a member/
>
[pk] yes, much clearer. 
> 
> 5. How VPNs are built and deployed using VRs
>     Three main VR deployment scenarios can be used for building virtual
>     private networks:
>     1) VR to VR connectivity over a layer 2 connection.
>     2) VR to VR connectivity tunneled over an IP or MPLS network.
>     3) Aggregating multiple virtual routers over a "backbone virtual
>       router," which will provide connectivity over a layer 2, IP, or
>       MPLS network.
> 
> [md] I believe that #2 and #3, as discussed in the following sections, are

> one and the same thing and #3 should be dropped.  More comments below.
>
[pk]  No, I hope I've explained this above. 
> 
>     The above VR deployment scenarios can coexist on a single PE and
>     they are not mutually exclusive.
> 
> [md] s/on a single PE/ on a single PE and\/or within a single VPN/
> 
[pk]  Good addition
> 
> 5.2 VR to VR Connectivity through IP or MPLS tunnels
>     Although it is clearly possible to use a topology similar to the
>     layer-2 model over an IP or MPLS backbone, the VR capability can
>     support a different network deployment besides full mesh tunnels
>     between VRs.
> 
> [md]  By "layer-2 model" I presume you are referring to "VR to VR
> Connectivity over Layer 2 Connections" as described in the preceding 
> section.  There is nothing in that approach that requires a full mesh of 
> tunnels between VRs.  The full mesh of tunnels may be used but is not 
> required, whether layer 2 connections or tunnelling over an IP or MPLS 
> backbone are used.
>
[pk] Yes, Layer 2 certainly does not imply full-mesh... I'll fix it. 
> 
>     This is the creation (on each PE) of another VR facing
>     into the backbone network, which is used to build a kind of backbone
>     VPN that may be shared among multiple customer VPNs. This is
>     described below as the "backbone VR."
> 
> [md] I do not understand the above text, nor section 5.3 "Virtual Router 
> Backbone Aggregation" which follows.  I think they are talking about the 
> same approach as 5.2 "VR to VR Connectivity through IP or MPLS tunnels" 
> which is to say, the VPN packets are tunneled across a shared (i.e. used
by 
> more than just one particular VPN) IP or MPLS backbone.  Presumably the 
> "outer packets" formed by the tunnel encapsulation are sent and received
in 
> the routing context, supported by the PE, that is the native routing 
> context of the backbone.  We can call this the "default router", "public 
> router", "backbone VR" or whatever.  But, this should all be true anytime 
> tunneling is used.  I.e. 5.2 and 5.3 are actually about the same approach.
No?
>
[pk]  No, I hope the backbone VR is clearer after the explanation above. The
backbone VR can add another layer of encapsulation or MPLS label.  This also
applies to the next point... 
> 
> 5.3.1 Tunneling
>     A tunnel can be established per VPN or shared among many
> VPNs (VRs).
> 
> [md] I do not believe the tunnel can be shared, unless you're taking
> advantage of the ambiguity in the term "tunnel" and using it here to refer

> to an aggregate entity containing multiple 'tunnel links'.  See my comment

> above at sect. 2.8.
> 
> 
>     The backbone VR makes it appear as if each VR within a VPN is
>     directly connected (full and partial mesh configurations supported).
>     Each VR within the VPN exchanges routing information directly with
>     the other VRs in the VPN.
> 
> [md] s/with the other VRs/with the adjacent VRs/
>
[pk]  yes, the adjacent ones in the "overlay topology"...  I'll reword this.

> 
>     Further work is needed to determine the requirements and usage of
>     the VPN-ID exchange within IPsec-based tunneling scenarios.
> 
> [md] actually within any tunneling scenarios, not just IPsec-based.
>
[pk] agreed... The use of multiple encapsulations/labels has its
limitations. 
> 
> 5.3.1.1 MPLS Tunnels
>     MPLS tunneling can be used in different forwarding scenarios. A
>     hierarchy of two labels can be used. One simple forwarding scenario
>     is where the inner label identifies the VR intended to receive the
>     private packet (to be forwarded to the CE).
> 
> [md] ok so far, although no one has so much as written a draft about how 
> the labels would be distributed and bound to VPN-IDs for this case...
>
> 
>                                                 Another forwarding
>     scenario is to distribute the inner label on a per-VPN basis across
>     the tunnel. In this case the label distribution process can be
>     achieved using BGP or an existing label distribution protocol on a
>     per-VPN basis. The inner label relates to the private VPN prefix.
>     The label and reachability distribution is done through the tunnels.
>     On the egress side traffic will be directed to the egress interface
>     by looking up the inner label.
> 
> [md]  I cannot tell if this is talking about distributing 1 inner label
per 
> VPN context, or one inner label per VPN route -- it seems to say both.
And 
> how is the label distribution done through the tunnels?  If MPLS is being 
> used to create the tunnels, they cannot exist until after the label has 
> been distributed.
>
[pk]  The BGP auto-discovery draft describes more details of how this is
done (see section 4.2), but I agree the context needs to be made more clear
in the paragraph above.  It is a three-step process: BGP can be used to
carry tunnel endpoint (VR) addresses or labels, allowing the VRs to build
tunnels between each other.  Then they can exchange reachability (routes)
across the tunnels.  We may need to break out the label and route handling
separately for clarity.
> 
> [md] I think this section needs some rewriting.  The key point in my mind 
> would be that MPLS technology is used to create tunnel links, whose 
> endpoints appear as logical IP interfaces to the routers (VRs) the tunnel 
> links terminate on.
> 
[pk] I think that having the backbone VR tunnel up can facilitate the label
exchange, so this may not be a case of lifting ourselves up by our
bootstraps, but it clearly needs to be clearer.  :^)
> 
> 5.3.2 Routing
>                              VPN sites exchange routing
>     information through the tunnels over the backbone.
> 
> [md] That isn't correct.  VPN sites exchange routing information with VRs 
> across CE-VR links, and VRs exchange routing information with adjacent VRs

> in the same VPN across VR-VR links.  (Though I'm not sure if all of that
is 
> relevant in this section - maybe it is only trying to talk about the VR-VR

> routing.)
>
[pk]Yes, it's referring to the VR-VR routing.. I'll clarify. 
> 
> 6. VPN Auto-Discovery
> 
> [md] the above heading would tie better to the text if we s/VPN 
> Auto-Discovery/VPN Membership and Topology Auto-Discovery/
>
[pk] yes, that's better  
> 
>                     VPN topology represents the set of PEs and their
>     interconnectivity within the VPN. The topology can be a full-mesh of
>     PEs, a hub and spoke, or anything in between.
> 
> [md] s/PEs/VRs/    (2 occurrences)
>
[pk] yes, I think that works. 
> 
>     VPN discovery can be achieved through different mechanisms, for
>     example:
> 
>     - Directory server approach, in which VRs query a server to
>     determine their neighbors.
> 
> [md] draft-heinanen-radius-pe-discovery-04.txt would be good
> to reference here.
>
[pk] Makes more sense here than in the "requirements" section above. 
> 
>     In this document it is assumed that a mechanism that provides
>     services similar to BGP is used to achieve auto-discovery of VPN
>     members. As described in [VPN-BGP], VR addresses are exchanged,
>     along with the information needed to enable the PEs to determine
>     which VRs are in the same VPN ("membership"), and which of those VRs
>     are to have VPN connectivity ("topology").
> 
> [md] I don't think the document "assumes" BGP-based discovery in the sense

> that anything else in the document depends on that.  Please see my comment

> at sect. 2.4.
> 
[pk]  We tried to avoid saying it had to be BGP ("provides services similar
to BGP"), but it does need to exchange VR addresses, identify a VPN mapping,
and specify the overlay topology.  The existing auto-discovery
implementations use this.
> 
>     It is important to note that, for the VR architecture, the auto-
>     discovery mechanism is only used to automatically exchange VPN
>     control information between VRs.
> 
> [md] shouldn't that be  s/between VRs/between PEs/  ?
> 
[pk] Since there may be more than one VR in a PE running auto-discovery
(potentially across multiple backbones) I think this should stay as it is. 
> 
> 8. VPNs across Domains
>                                                          The main
>     requirement on the service provider in order to achieve end-to-end
>     cross-domain VPN connectivity is the ability for both domains to
>     support a common tunnel technology.
> 
> [md]  ... plus the ability to support a common membership and topology 
> discovery technology.
> 
[pk] Agreed.
> 
>                                Once the tunnel is established,
>     private data (e.g., routing information, and private  customer data)
>     can flow from one domain to the other with the same level of
>     security as is provided in a single service provider network.
> 
> [md]  s/security/isolation/  ?
> 
[pk] maybe, but people usually want security rather than just isolation.
Maybe something like:
"... same level of security or isolation as is provided by that tunnel
mechanism when it is used entirely within a single service provider
network."
> 
>     Another possible scenario is to use two virtual routers configured
>     on each PE at the interconnection point.
> 
> [md] I would clarify that as follows:
>     Another possible scenario is to deploy PE devices at each side
>     of the interconnection point, with a virtual router configured
>     on each PE for each VPN that spans the interconnection point.
>
[pk] I think the VR-per-VPN may be overkill, depending on the granularity of
filtering needed.  The idea is not to terminate the VPNs, but to provide
ingress/egress filtering for all the bidirectional tunneled VPN traffic
crossing the boundary.  The VPN traffic should be opaque at the boundary, so
it would normally be filtered all-or-nothing (by VPN) based on the visible
packet identifiers (which could be mapped to a VPN by each service provider,
for instance using the VPN-ID).  I'm not sure what other policies would be
applied by the service providers on the VPN traffic transiting the boundary,
but I don't think they would normally require a VR per VPN on the boundary.

> 
> [md]  I think this section (8) should also contain something
> along the 
> lines of:
>     An important consideration for VPNs spanning multiple
>     administrative domains is whether the domains involved are
>     always adjacent or whether there may be intervening domains
>     that are unaware of the VPN.  Transitive techniques such as
>     deploying VPN-aware PE devices at the domain boundaries will
>     not work in the latter type of case.
>
[pk] I think that as long as an IP or MPLS tunnel can be built across the
intervening domains, it will be okay.  The key point is whether tunnels can
be built from end to end.  The discussion of using VRs at the
interconnection point is only intended to allow the service providers to
provide ingress/egress filtering if they desire, but it is not needed for
transporting the traffic.
> 
>     The ability to use a standard VPN-ID format also allows unambiguous
>     VPN identification across domains.
> 
> [md] s/standard/standard, globally unique/
>
[pk] yes, that's needed. 
> 
> 9. Internet Access
>     There are a number of ways to provide Internet access to a VPN using
>     the VR model. One way of providing VPN Internet access is to
>     configure the backbone VR to steer private traffic to the VPN VR,
>     and Internet traffic to the normal backbone/Internet forwarding
>     table.
> 
> [md] I don't understand that.  My understanding of the backbone router 
> concept is that the relationship between a tunnel link within a VPN and
the 
> backbone is an overlay one -- VPN packets only enter the backbone after 
> being encapsulated in a backbone-context packet and vice versa for packets

> in the other direction.  See my comment at sect. 5.2.
>
[pk] Yes, I think this explanation needs more work.  It's worth taking a few
more sentences or paragraphs to describe at least one of the methods to
support Internet access in detail.
> 
> [md] An important way to provide Internet access, which I don't think is 
> included in the descriptions in this section, is simply to create a link 
> (real or virtual or internal or whatever) between the VPN-context VR and 
> any router (or virtual router) that is in the Internet context.  Note that

> this would be a routing adjacency relationship between the VPN and
Internet 
> (virtual) routers as opposed to the overlay relationship used to tunnel 
> packets across the Internet (or SP backbone).
>
[pk] Yes, this works, but I believe the goal of using the backbone VR is to
provide some filtering functionality which can be shared among multiple
VPNs.  I think this could be clarified...
But your key point of avoiding the overlay with its encapsulation is
necessary.  Thanks! 
> 
> 10. Carrier's Carrier Case
> 
> [md]  It is very difficult to understand this section.  I think this is 
> because it is difficult to tell whether each use of the terms (VPN, CE,
VPN 
> service, etc.) refers to entities in the carrier's network or the
carrier's 
> carrier's network.
>
[pk] noted... I'll work on it.  I think a diagram will help, too. 
> 
> 11. Operations and Management
>                                                  In some
>     implementations, it may be possible for a VR to be "rebooted" by a
>     customer without affecting other VRs.
> 
> [md] I suggest removing the words "by a customer", since it
> might just as 
> well be the service provider or an attacker :-) that would 
> reboot the VR.
>
[pk] Yes, although that is a nice capability, the identity doesn't add to
this draft. 
> 
> 11.2 Troubleshooting
>                           This access may provide only the privilege to
>     monitor (with no privilege to change) the layer 3 status of the
>     customer's VPN.
> 
> [md] s/VPN/VR/   ?
> 
[pk] Well, it is the VR's view of the routing across the whole VPN (for
instance, the OSPF LSDB).  I'll try to clarify it.
> 
> 13. Scalability
>     Only the PEs are handling the VPN type information. The internal
>     backbone routers (the P routers) are usually not VPN aware.
> 
> [md] s/usually//    (If it is VPN-aware than it _is_ a PE router.)
> 
[pk] yes.

[pk]  Thanks a lot Mark!!