Document: draft-ietf-l3vpn-as2547-05
Reviewer: Lucy Lynch
Date: June 8, 2004

draft-ietf-l3vpn-as2547-05.txt
Applicability Statement for BGP/MPLS IP VPNs (Informational)
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as2547-05.txt

No (major) Objection.

Well, this is the document I should have read before tackling
draft-ietf-l3vpn-rfc2547bis-01.txt (referred to here as BGP-MPLS-IP-VPN).

This covers many of the questions I had and fills the need for a top level
view of roles/assets/policies/etc. Not every case or question I had about
draft-ietf-l3vpn-rfc2547bis-01.txt was answered, but the framework is
clearer in this document. Is revised, VPN-IPv4 address family and the
Route Distinguisher Type Field could use more explanation.

Additional Notes:

Missing RCF 2119 text:

idnits-v1.31 results:

  * The document claims conformance with section 10 of RFC 2026, but uses
    some RFC 3667/3668 boilerplate.  As RFC 3667/3668 replaces section 10 of
    RFC 2026, you should not claim conformance with it if you have changed
    to using RFC 3667/3668 boilerplate.

  Checking conformance with RFC 2026 boilerplate...
  The document seems to lack an 2026 Section 10.4(C) Copyright Notice
  -- however, there's a paragraph with a matching beginning. Boilerplate
     error?
  The document seems to lack an RFC 2026 Section 10.4(C) Permission Grants
  Notice
  The document seems to lack an RFC 2026 Section 10.4(C) Disclaimer
  -- however, there's a paragraph with a matching beginning. Boilerplate
     error?

  Summary: 3 nits

Normative References

-  ALL the references are drafts.

2. SP Provisioning Model

   "In an IGP is run on the access links, the IGP MUST be a separate IGP"
          ^^^^^^
-  something missing here. The distinction among instances of IGP is
   also clearer here than in draft-ietf-l3vpn-rfc2547bis-01.txt.

5. Access Control and Authentication
   "It is possible for various sorts of "tunnel interfaces" to be
   associated with a VRF.  In this case, whatever authentication is
   natively used in the establishment of the tunnel interface may be
   used.  For example, an IPsec tunnel can be used as an "access link"
   to attach a remote user or site to a VRF.  The authentication
   procedure in this case is part of IPsec, not part of the VPN scheme.

   Where L2TP is used, each PPP session carried in an L2TP tunnel can be
   associated with a VRF.  The SP's AAA server can be used to determine
   the VPN to which the PPP session belongs, and then the customer's AAA
   server can be given the opportunity to authenticate that session as
   well."

-  this bit seems at odds with 6. Maintaining Proper Isolation of VPNs
   of draft-ietf-l3vpn-rfc2547bis-01.txt

6.3. Security Framework Template

-  The FAQ like structure of this section is a little odd
   Some questions are answered (yes) and then an explanation
   follows, some just have explanations. Strike the yeses?

12. Migration Impact
   "start giving the routes via the VPN backbone preference to routes via
    the legacy backbone:

-   not sure what this means.


13. Scalability
   "An important consideration to remember is that one may have any
   number of INDEPENDENT BGP systems carrying VPN routes.  This is
   unlike the case of the Internet, where the Internet BGP system must
   carry all the Internet routes."

-  This seems different from the VPN-IPv4 Address Family mechanism
   defined in draft-ietf-l3vpn-rfc2547bis-01.txt which I read as
   creating unique sets of addresses within BGP - I may be very confused
   here.

15. Management
15.1. Management by the Provider
15.2. Management by the Customer

-  provides additional detail on customer management.

Lucy E. Lynch				  Academic User Services
Computing Center					University of Oregon
llynch  @darkwing.uoregon.edu					   (541) 346-1774/Cell: 912-7998