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.  :-(


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."


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.)


                                                           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.


    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/


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?


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/


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.


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/


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)


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.


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.


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).


                          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//.   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.


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.)


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/


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/


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.


    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/


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.


                 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?


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/


    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.


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.

[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.


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.)


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/


                    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)


    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.


    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.


    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/  ?


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.


                                        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/  ?


    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.


[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.


    The ability to use a standard VPN-ID format also allows unambiguous
    VPN identification across domains.

[md] s/standard/standard, globally unique/


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.

[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).


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.


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.


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/   ?


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.)

================================================