WG LAST CALL on draft-ietf-ppvpn-as-vr-01.txt

Hi, here are comments on draft-ietf-ppvpn-as-vr-01.txt.

1. Introduction

[md] I would suggest adding the following to the list of situations for 
which VR-based PPVPNs are well suited:

- The VPN service provider does not own a backbone network but
wishes to provide PPVPN services over a backbone obtained
from some other provider.

- Several cooperating SPs desire to offer PPVPN service at points
that span multiple administrataive domains of the backbone, perhaps
over the public Internet.


2.1. Auto Discovery

    In the VR-based PPVPNS, various auto discovery mechanisms are
    supported.  VPN discovery can be achieved through directory servers,

[md] This should reference draft-heinanen-radius-pe-discovery-04.txt


               BGP-based auto-discovery is described in [VPN-BGP], and is
    used for membership, topology and reachability discovery.

[md] s/membership, topology and reachability/membership and topology/
(As discussed even in the following paragraph, BGP is not used for 
reachability in this case.)


5. Access Control and Authentication

    CE-PE authentication has not been specified for VR-based VPNs and is
    for further study.  The customer must provide appropriate mechanisms
    for CE-PE authentication.

[md] This could go a little further by saying the same thing as the 2547 
applic statement.  From draft-ietf-ppvpn-as2547-01.txt sect. 5:
   No particular means of PE/CE authentication is specified for 2547-
   style VPNs.  PE/CE mutual authentication may be done via any
   mechanism supported by the routing protocol in which the CE and PE
   are peers (e.g., use of the TCP MD5 authentication when the CE/PE
   protocol is BGP), or by any other mechanism that may be desired.


    Even with the use of IPsec, the security level offered is dependent
    on the scope of the IPsec security associations: encrypting on a CE-
    to-CE basis (as in CE-based VPNs) will offer a wider scope of
    protection than only encrypting on a PE-to-PE basis (as in PE-based
    VPNs), since the CE-PE link remains unencrypted in the latter case.

[md]  ... However, PE-PE IPsec offers substantial offsetting advantages in 
efficiency, outsourcing, and integration with the dynamic membership and 
dynamic routing nature of the PPVPN.  CE-PE IPsec can also be used to 
protect traffic on the CE-PE section of the network.  In this case the 
traffic is only unprotected by IPsec within the PE device.



11. SP Routing

    VR-based PPVPNs do not impose any additional requirements on the IGP
    used in the service provider core network.  However, the PE must
    implement the IGP used in the customer VPN.

[md]  I presume this refers to the PE implementing this IGP for use on the 
CE-VR adjacency?  This should be clarified if possible.  Also, It may not 
use an IGP there at all (could be BGP or static).  Maybe the 2nd sentence 
there can just be removed.


    >From the customers viewpoint of routing topology, the SPs network
    topology appears much simpler than it may actually be.  Depending on
    the VR implementation, the SPs service offering, and the SPs physical
    topology, it may appear as either a single large router with
    interfaces for each VPN site, as a full mesh, with two routers
    between any two sites, as a hub-and spoke topology (when the customer
    wants all inter-site traffic to pass through one or more specific
    sites, for application of services such as security filtering), or
    other arbitrary topology.

[md]  This topology may be hidden from the customer or not, depending on 
what routing protocols are used Vr-VR and VR-CE.  In general, the customer 
will see the VPN backbone topology (i.e. the topology of VRs operated by 
the provider) ONLY in the case where a link-state IGP is used on the CE-VR 
adjacency, and the same link-state IGP is used within the VPN backbone, and 
the same instance of the IGP is used within the VPN backbone.  So, except 
under those special circumstances, the CE device will see only reachability 
information, and not topology information.


14. QoS/SLA

    QoS mechanisms developed for physical routers can be used with VRs,
    on a per-VR basis. e.g., classification, policing, drop policies,
    traffic shaping and scheduling/bandwidth reservation. The
    architecture allows separate quality of service engineering of the
    VPNs and the backbone.

[md]  The above text appears twice in this section (paragraph 2 and 
paragraph 3).


16.3. Customer Management of VR

    Customer network management and troubleshooting systems will
    generally have less ability to gather information from the VRs than
    from the customers own routers, and will also have little or no
    ability to directly change VR configurations.  The customers systems
    should be planned so as to accommodate the restricted capabilities of
    the VRs to respond to customer network management processes.

[md]  This above text is repeated in sect. 11 on p. 10.