Draft: draft-ietf-l3vpn-generic-reqts-03
Reviewer: Lucy Lynch
Date: March 30, 2004

* This draft is on the right track but has open issues,
  described in the review.

Well, not so much open issues as squishy language. The document
has multiple instances of "SHOULDS" followed by exceptional cases
or qualifiers (at least for multi-provider). I found it confusing.
I think such a requirements document would be useful, but this may be
TOO generic. Given the number of drafts listed as informative, I
wonder if this document is premature? Prehaps it would be useful to
seperate single-provider from multi-provider?

Generic Requirements for Provider Provisioned Virtual Private Networks
<draft-ietf-l3vpn-generic-reqts-03.txt>

Status of this Memo
- ok

NOTE: no copyright notice at top of document

Abstract
- OK
Conventions used in this document
- OK
Table of Contents
-OK

1.         Introduction

   "This document is an output of the design team formed to develop
   requirements for PPVPNs in the Provider Provisioned Virtual Private
   Networks (PPVPN) working group and provides requirements that are
   generic to both Layer 2 Virtual Private Networks (L2VPN) and Layer 3
   Virtual Private Networks (L3VPN)."
- ? title specifies l3vpn

1.1.       Problem Statement

paragrah 5 -

   "In order to achieve this, the mechanisms used to develop various
   PPVPN solutions SHALL be as common as possible with generic Internet
   infrastructure mechanisms like discovery, signaling, routing and
   management."
- odd use of the word "common" better language in 6.4

1.2.       Deployment Scenarios

   "There are three different deployment scenarios"
- this section actually describes four scenarios

3.         Definitions and Taxonomy
- NOTE: lots of dependencies on other draft documents

4.         Service Requirements

4.1.       Availability

   "It should be noted that it is difficult to guarantee high
   availability when the VPN service is across multiple providers,
   unless there is a negotiation between the different service providers
   to maintain the service level agreement for the VPN customer."
- while "high availablity" is a MUST, this text indicates that
  achiving that availablity may have requirements outside of a
  technical solution - out of scope?

4.4.       Data Isolation
   "The network MUST never deliver user data across"
-  ^MUST never^MUST NOT

4.7.       Addressing
   "Interconnection of two networks with overlapping IP addresses
    is outside the scope of this document."
- LOL

4.8.       Quality of Service
- this section is really confusing.

4.9.       Service Level Agreement and Service Level
           Specification Monitoring and Reporting

- some kind of diagram of the hierarchy of stringent guarantees
  might be useful

5.         Provider requirements

5.1.2.     VPN Scalability aspects
- this section contains a lot of useful detail

5.1.3.     Solution-Specific Metrics
   "Another metric is that of complexity. In a PE-based solution the PE
   is more complex in that it has to maintain tunnel-specific
   information for each VPN, but the CE is simpler since it does not
   need to support tunnels. On the other hand, in a CE-based solution,
   the CE is more complex since it has to implement routing across a
   number of tunnels to other CEs in the VPN, but the PE is simpler
   since it has only one routing and forwarding instance. Thus, the
   complexity of the PE or CE SHOULD be noted in terms of their
   processing and management functions.
- diagram?

5.2.       Management
   "A service provider MUST have a means to view the topology,
   operational state, service order status, and other parameters
   associated with each customer's VPN."

   "In the multi-provider scenario, it is unlikely that participating
   providers would provide each other a view to the network topology and
   other parameters mentioned above."
- conflicting MUST and multi-provider case example.

5.2.1.     Customer Management of a VPN
   "A customer SHOULD have a means to view the topology, operational
   state, service order status, and other parameters associated with his
   or her VPN."

   "A possible outcome of giving customers such capabilities is Denial
   of Service attacks on other VPN customers or Internet users. This
   possibility is documented in the Security Considerations section."

6.         Engineering requirements
6.1.       Forwarding plane requirements

   "For Layer 2 VPNs, solutions SHOULD utilize the encapsulation
   techniques defined by the Pseudo-Wire Emulation Edge-to-Edge (PWE3)
   Working Group, and SHOULD NOT impose any new requirements on these
   techniques."
- references?

   "PPVPN solutions MUST NOT impose any restrictions on the backbone
   traffic engineering and management techniques.  Conversely, backbone
   engineering and management techniques MUST NOT affect the basic
   operation of a PPVPN, apart from influencing the SLA/SLS guarantees
   associated with the service.  The SP SHOULD, however, be REQUIRED to
   provide per-VPN management, tunnel maintenance and other maintenance
   required in order to meet the SLA/SLS."
- double bind between traffic engineering & PPVPNs ???

7.         Security Considerations
- major, beyond my ability to second guess.

8.         References
8.1.       Normative References
-OK
8.2.       Informative References
- lots of uncooked stuff here
9.         Acknowledgements
-OK
10.        Editor's Address
-OK
11.        Full Copyright Statement
-OK, missing RFC editor text?

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