2.7.7 Provider Provisioned Virtual Private Networks (ppvpn)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Rick Wilder <rwilder@bbo.com>
Marco Carugi <marco.carugi@francetelecom.fr>

General Area Director(s):

Fred Baker <chair@ietf.org>

General Area Advisor:

Fred Baker <chair@ietf.org>

Technical Advisor(s):

Scott Bradner <sob@harvard.edu>
Rob Coltun <rcoltun@redback.com>

Mailing Lists:

General Discussion:nbvpn@bbo.com
To Subscribe: nbvpn-request@bbo.com
In Body: (un)subscribe
Archive: http://nbvpn.francetelecom.com

Description of Working Group:

Note: this WG is one of a set of WGs that comprise the 'sub-IP' pseudo-area that the IESG recently created. All of the sub-IP WGs are temporarily being housed in the General Area until the IESG decides on a final management structure for managing these groups. The Area Directors for the following areas acting as a group will be the Area Advisors: INT, OPS, RTG and TSV. The name(s) listed above under "Technical Advisor(s)" are the the responsible Area Directors for the working group.

This working group is responsible for defining and specifying a limited number of sets of solutions for supporting provider-provisioned virtual private networks (PPVPNs). The work effort will include the development of a framework document, a service requirements document and several individual technical approach documents that group technologies together to specify specific VPN service offerings. The framework will define the common components and pieces that are needed to build and deploy a PPVPN. Deployment scenarios will include provider-managed VPN components located on customer premises.
The service requirement document will detail the requirements individual PPVPN approaches must satisfy from a Service Provider (SP) perspective. Particular attention will be placed on SP requirements for security, privacy, scalability and manageability considering such factors as Service Provider's projections for number, complexity, and rate of change of customer VPNs over the next several years. The working group will make specific efforts to solicit this information from SPs. The service requirements document is not intended to define the requirements that all approaches must satisfy. Rather, it is intended to become a "checklist" of requirements, not all of which will necessarily be required in all deployment scenarios. A goal of the requirements document is to provide a consistent way to evaluate and document how well each individual approach satisfies the individual requirements.
The effort will produce a small number of approaches that are based on collections of individual technologies that already exist (see below for specifics). The goal is to foster interoperability among implementations of a specific approach. Standardization of specific approaches will be gauged on (I)SP support. Note that it is not a goal of this WG to develop new protocols or extend existing ones. Rather, the purpose is to document and identify gaps and shortcomings in individual approaches with regards to the requirements. In the case that specific work items are identified, such work will be done in an appropriate WG. Taking on specific protocol work items in this WG will require rechartering.
The working group is expected to consider at least three specific approaches including BGP-VPNs (e.g. RFC 2547), virtual routers and port-based VPNs (i.e., where the SP provides a Layer 2 interface, such as Frame Relay or ATM, to the VPN customer, while using IP-based mechanisms in the provider infrastructure to improve scalability and configurability over traditional L2 networks). Multiple approaches are being developed as each approach has particular characteristics and differing scope of applicability.
The working group will consider inter-AS (SP) VPN interconnects so that VPNs are able to span multiple ASs (SPs).
Each technical approach document will include an evaluation of how well it meets the requirements defined in the requirements document. In addition, technical approach documents will address scalability and manageability issues as well as their operational aspects. Individual approach documents will also analyze the threat and security aspects of PPVPNs and include appropriate mandatory-to-implement technologies and management mechanisms to ensure adequate security and privacy of user data in a VPN environment. This analysis will include cryptographic security from customer site to customer site using IPSEC.
An applicability statement will be developed for each approach that describes the environments in which the approaches are suitable for deployment, including analysis of scaling impact of the approach on SPs and threat analysis.
Coordination with the IETF PWOT and ITU-T efforts will be ensured.

Goals and Milestones:



Formulate a plan and begin approaching SPs for input on scaling and other requirements



Begin discussion (based on submitted IDs) on candidate approaches against the different service requirements.



Begin discussion of the framework and the service requirement documents. Identify a limited set of candidate approaches. Build appropriate design teams.

Mar 01


Begin discussion of applicability statements.

Aug 01


Submit the framework and the service requirement documents to the IESG for consideration as Informational RFCs.

Mar 02


Submit the candidate approaches and applicability statements to IESG for publication.

Mar 02


Charter update or WG disband

No Request For Comments

Current Meeting Report

PPVPN minutes (March 23rd - 9H-11H30)

Agenda bashing, charter/milestones 5 min - chairs

Marco Carugi welcomed the attendees.
PPVPN now belongs to the new sub-ip area: ADs - Scott Bradner and Bert Wijnen.
The technical advisor will be Rob Coltun
Mailing list - changed this week, mailing list problems will be resolved by this:
Discussion: ppvpn@zephion.net
(un)subscribe: ppvpn-request@majordomo.zephion.net with (un)subscribe in body.
Archive: http://nbvpn.francetelecom.com to move to ppvpn (post-meeting note by Marco: done on March 27th).

Marco informed that his co-chair Rick Wilder was absent for family reasons.

- The speakers should focus on requirements and framework issues, no discussion on specific approaches/technologies. Marco said that this was the logical way to proceed with the meeting.
Marco went through the agenda and the charter outline.

- Objectives: defining and specifying a limited number of sets of solutions for supporting ppVPNs.
- development of a framework doc
- development of service provider requirements document
- development of several individual technical approach documents that group technologies to specify specific a VPN service offering. The main goal is to foster interoperability. Standardization of specific approaches would be gauged on service provider support. Non goal: developing protocols for specific aproaches. There are 3 approach currently: one based on RFC2547bis and 2 Virtual router approaches
- consideration of inter-AS (provider) VPNs
- each tech approach doc will be evaluated on how well it meets requirements document, addresses scalability and other important issues.
- an applicability statement would be developed for each approach
- coordination with the PWE3 WG and ITU-T are also within the charter goals.

As per the PWE3 BOF on Wednesday, March 21, the PWE3 charter proposal will clearly include work in coordination with the PPVPN WG, avoid overlapping and avoid mutual imposition of constraints.
It is important to clearly identify ASAP if and where overlapping may happen (a possible area is the l2VPN Kompella draft)

Goals and milestones:
What has been done since San Diego:
- formulate plan and begin approaching service providers for input on scaling and other requirements
- begin discussion of framework and requirements documents - 2 design teams formed, interim meeting was held in Boston in February 2001
- 2 internet drafts moved to WG documents in agreement with Area Directors - framework and requirements documents

What has not been done since San Diego (future work):
- identify a limited set of candidate approaches, build design teams
- mar 01 - begin discussion of applicability statements
- aug 01 - submit framework and requirements drafts to IESG for publication as informational RFCs
- submit applicability statements
- revise charter in mar 02.

The speakers were requested to respect time, and focus on issues related to requirements and framework, without detailed presentations.

PPVPN Service requirements 20 min - requirement team members

The draft was presented by Dave McDysan, co editor of draft (The other co-editor is Marco Carugi). The other co-authors are from service provider companies.
- define terminology - still in the process of aligning with the framework document
- identify requirements applicable to a number of approaches
- provide a checklist to evaluate applicability to individual approaches and identify gaps
- categorized requirements as : general, customer driven, service provider driven
- many requirements taken from ITU-T draft recommendations y.1311 and y.1311.1

definitions and terminology (Sec 2)
- what is private in a VPN - the word is used in an ownership sense
- customer/organization/subscriber is a set of sites
- intranet is a site of single customer
- extranet is sites of multiple customer/organization
- adopted taxonomy according framework doc in terms of layer 2 and layer 3 VPN service
- customer (facing) CE
- provider (facing ) PE
- VPN tunnels
- l3: MPLS, GRE, IPSec etc
- l2: Frame Relay, ATM, should we include ethernet VLAN?

Reference models were shown for CE based and PE based VPNs.

General requirements:
- support arbitrary topology - full mesh, partial mesh etc
- constrained distribution of data and routing info
- support overlapping IP addresses
- security for data, routing and access
- management of services and resources
- interoperability within the same solution
- interworking between solutions desirable.

Customer requirements:
- service provider independence
- support unicast and multicast traffic
- no restriction on CE routing protocol
- SLA support
- customer management
- security and integrity
- minimal migration impact
- dedicated and dial in access
- internet reachable over VPN access network
- hybrid VPN scenarios desirable.

Examples of dual homing arrangements were described - resilience and reliability are desirable. We need to explain what backdoor links will be used for.

SP requirements:
There is an overlap between various service provider requirements, that needs to be cleaned up. There also needs to be a discussion on absolute numbers for scalability. The following are the service provider requirements in the current draft:
- scalability
- learn VPN membership dynamically
- SLA agreements and specifications
- QoS support
- inter AS(SP) support
- isolation of traffic and processing
- tunneling mechanism independence
- backbone technology independence
- provide protection and restoration options.
- Support carrier's carrier (i.e., PPVPN wholesale)
- Management - at least FCAPS
- Support for migration between solutions
- Isolation, security, authentication, identification
- Provisioning routing, access, security
- Provide access to value added services
- Interoperability between vendors
- Interworking between solutions.

Next steps:
- resolve overlap in outline, content, fill in TBDs
- clean up editorial comments
- clearly state and define which requirements are : must, should, may
- continued alignment with framework
- please comment on list as to what's missing, what's over specified, help resolve open issues
- WG charter goal is to submit Informational RFC after August '01

Open issues:
- precise definition of port based (l2) VPNs (are Ethernet VLANs within scope?), are only l2 VPNs implemented over IP (or MPLS) in scope? Are native Frame Relay and ATM networks out of scope?
- precise definition of CE and PE
- align definitions with framework
- give timeframe AND numerical scaling
- which identifiers are needed
- what items are important in SLAs - prioritize as to what we need versus what would be nice to have
- how should QoS be specified (have service level view as opposed to standards level view)
- agree on management requirements - detail service creation and provisioning, move policy management to framework document, need information model requirements
- should we include other tunneling technologies? - IP/optical, IP/switched circuit.

Q: You said that the management requirement should be at least FCAPS. What more do you want to manage that FCAPS doesn't provide?
A: The question is - is FCAPS the management structure we want to specify?

Q: Question on the specific numbers used in the draft in the section on scalability - support of very large providers within SP network. (There are at least 1 million per SP, this implies at least 50 million VPNs!) Is this realistic? What is the foundation of this number? Requirements have to be realistic for people building VPNs.
A: Suggest other numbers that are more realistic. This number came from ITU-T.
Marco: For example, a customer can have many organizations, so many VPNs per customer.
Q: We have 35,000 FR sevices today. Will IP VPNs replace these and much more?
A: Dave McDysan: Those numbers are low. See me after the meeting and I'll give you better FR numbers.

Comment: If you lower numbers, we are targeting smaller customers etc. Larger numbers may be cost prohibitive. This is mainly a design feature.

Comment: From a vendor perspective, this is an excellent initiative. Sets up very good data points. Regarding numbers, the definition of "unit" when specifying these numbers will be very useful.
A: Thanks.

PPVPN Framework 20 min - Ross Callon, Muneyoshi Suzuki

Presented by Ross Callon.

The previous draft had service provider authors. This one has NTT as the service provider and other vendors involved. This makes sense as the requirements document should come from the service providers and the framework should come from the vendors.
Framework document:
- discusses significant technical issues
- discusses range of possible solutions
- discusses tradeoffs
- doesn't make choices
- doesn't do protocol design

How did we get here?
- Merger of multiple -2 or 3- inputs (draft-suzuki-) and (draft-callon-) and a white paper on "framework for network-based VPN" by CoSine.
- Spent few months editing and merging after the December meeting in San Diego.
- This gives the WG a single document to work with.

- discussion of l3 VPNs is in decent shape (some updates needed)
- discussion of l2 VPNs is limited
- discussion of Provider provisioned CPE-based VPNs is MISSING
- we are "mostly" compatible with requirements - not entirely (emulated LAN type services)
- more work is needed

Where do we go from here?
- coordinate with requirements
- respond to WG comments
- fill in missing parts
- fix a few parts
- respond to ongoing work in the WG

1. introduction
- objectives and scope
- overview of VPNs
- types of VPNs
- terminology
- acronyms

2. brief overview of requirements (in order to align carefully with the requirements document)
3. reference models
- l3 VPNs
- Provider provisioned CPE-based VPNs
- l2VPNs
4. customer interface (customers need to read this section) (Comment: Clearly some large providers can offer this solution, but there are a large number of small organizations that will also offer this solution - so million is not an unreasonable number)
- VPN establishment at CE-PE boundary
- data exchange at CE-PE boundary
- customer visible routing
- QoS

5. network interface and service provider support (to be read by vendors and SPs)
6. security considerations
7. appendix

Rob: Like the requirements document, will this also be submitted to IESG post London?
Ans: Ross: This is a believable timeline - we could do that.
Ans: Marco: We will try to have 01 version for requirements document in mid June, taking care of stuff overlapping with framework document. We can consolidate in the remaining month and a half, to submit -02- version for London.

Muneyoshi Suzuki (reference models for ppVPN)

- this document has been produced by the framework team
- showed reference model for layer 3 network-based VPN (similar to the model shown for PE-based VPN by Dave McDysan). The relationship between various entities was described.
- showed reference model for provider provisioned CPE-based VPNs (similar to the CE reference model shown by Dave McDysan)
- reference model for l2VPN - TBD

A PPVPN Layer separation 10 min - Tom Worster

issues in relation with framework document

- in framework document, the tunnel definition shown in Figure 3.2 and Figure 3.3 are different.
- In Fig 3.2 tunnel is from VFI to VFI
- In Fig 3.3 tunnel is bw pe to pe
- Therefore, in this draft, VPN tunnels are defined as - Tunnels keep packets destined to different VFI's separate. (VFI is the politically correct terminology for VR or VRF)
- Proposed layering - makes a clear distinction between core connectivity services and VPN client application (how to get packet from PE-to-PE vs client applications. Client applications talk via a "VPN control protocol", connectivity services talk via core protocols. Interface between VPN client application and core connectivity is via SAP.
- For example

+ - - +---------------------------+--------+-------------+
| Private | VPN | Core |
| CPT | User | Tunnel | Protocol |
| Payload | Header | Headers |
+ - - +---------------------------+--------+-------------+
CPT: core protocol trailer

- Benefit: PPVPN solutions must support, without layering, n-by-m matrix of protocol interactions
- With layering, we only need to deal with encapsulation into the VPN tunnel and off the VPN tunnel
- Control protocols only refer to VPN tunnels.
- VPN application uses core connectivity.
- Applauds ascii art in framework doc

Commments: what is the specific proposal? Where do you intend this draft to go?
A: This draft specifies layering approach that can be cut and paste into the framework doc.

Comments: Dave McDysan: Explanation of a "tunnel" is clear in fig 3.3 of the draft. The core connectivity is a tunnel.
A: Tom: Core connectivity may not require tunnel, but can use it.

Comment: Dave McDysan: There is a two level stack in the framework doc, you are calling it differently.
A: Tom: names must be used in consistent manner

Comment: Ross: I have occasionally given short talks on VPN terminologies. I agree with this separation.

Comment: This is an interesting draft in terms of framework. Few changes in terminology (for example, core technology) are required. Question: You are talking about separating control from core protocol. There is no such thing in some approaches, for example - rfc2547.
A: rfc2547 does use layering.
2nd question - MPLS lsp is not necessarily the only example.
A: agreed.

Comment: Instead of calling it layering, why not call them VPN links and VPN network addresses? Also, how does this layering work in CPE-based VPNs.
A:Marco: The current comments are specific to network based VPNs and can be extended to Cpe-based.

Comment: Eric Rosen: layering is fine - but this is only a clarification of terminology, what is new?
Tom: although obvious, this can't be immediately realized.
Eric - It could be misleading if there is a strict separation between layers.
Tom: I am not suggesting this.

Comment: is this model for both l2 and l3 VPNs?
Ans: works for both.
Comment from Marco: This should be made clear for both models.

Use of IPSEC with PPVPN 10 min - Bryan Gleeson
security issues

This talk is very similar to talk in San Diego, except it wasn't an internet draft then.

Outline IPSec scenarios.

- IPSec can be used between CE-CE, CE-PE or PE-PE.
- CE-PE provides secure remote access to Network-based VPN - compulsory L2TP/IPSec tunnel.
- PE-PE - can be used for both layer 3 and layer 2 network-based VPNs.
- CE-CE - the backbone could be - non-VPN aware, L2 VPN or L3 VPN - standards-based technology for CPE-based IPSec VPNs has been around for a long time.

Routing over IPSec tunnels: This is a useful feature. Discussed a sample scenario of redundant CE-PE connectivity (failure scenario). Routing can also be used between CE-CE or PE-PE. Issue with IPSec specifications - prefixes determined before, as opposed to routing where prefixes are determined later.
Comment - Joe Touch: This has been addressed in my draft. Read draft-touch-IPSec-VPN-01.txt (used IP-in-IP encapsulation within IPSec transport mode).

Association of IPSec tunnel within VPN - signaling IPSec tunnels between providers, IPSec address needs to distinguished.

Comments: Dave McDysan: Good draft. Second figure should be given to the "ascii artists" for framework document to construct hybrid VPNs. (CE-PE IPSec tunnels)
Comment: Marco: Separate security requirements from specific solution. Discussion of extension to protocols is not in the scope of the charter.

Comment - Do you think all kinds of tunnels (CE-PE, PE-PE and CE-CE) can occur simultaneously?
A: yes.
Comment: Packet header changes may lead to going to incorrect tunnel when simultaneous tunnels exist.
A: I don't see that as a problem. Multiple layers of IPSec tunnels have already been dealt with in the IPSec WG.
Comment: Tom Worster's layered approach can solve this problem. Do IPSec in two different layers. Won't work if you run multiple link layers etc.

Comment: putting IPSec with null authentication and encryption is a no-no.
A: Although it doesn't make too much sense to do IPSec with null authentication and encryption, it is possible. You don't need to do anything.
A - Marco: let's see if this requirement is a requirement.

Security analysis of MPLS architecture 5 min - Michael Behringer
just VPN-specific requirements

Marco: MPLS is just one technology - not the technology
Michael: Service Providers ask about MPLS service and compare it with Frame Relay and ATM. My customers doubt that MPLS provides proper security.

1. scope and requirements
2. security requirements of MPLS network :
- address space, routing and traffic separation
ñ hiding of MPLS core structure
ñ resistance to attacks
ñ impossibility of label spoofing
3. analysis of MPLS security (each of the points in 2 above)
4. what MPLS doesn't provide
5. Summary and conclusions : MPLS provides the same security as ATM/Frame Relay.

- Is this work of interest?
- Should it become a WG draft?
- More feedback?

Comment: Marco - We should address elements that are specific to this WG. MPLS is seen as just one technology. Let's put this to the mailing list. This draft can't be taken as WG document as it is at present.
A: Section 2 could be taken as part of requirements.

Comment: Dave McDysan: There is significant overlap with the requirements document. Some text in this document is better than what we have. We can use it in the requirements document.
Comment: Bryan Gleeson: This draft does a good analysis of security aspects. But it is limited to the security aspects of the RFC 2547 approach, not of MPLS in general.

BGP/MPLS VPN security extensions 5 min - Jeremy De Clercq

- Additional security requirements for PPVPN. - co-authored by folks from Alcatel and CoSine.
- Scope:
- tunnel (focus on PE-PE part of the architecture).
- Data separation inherent to VPN mechanism
- Encryption needed in some scenarios.

- allow for different "granularities" in the security offering (PE-PE, per VFI/VPN, per route)
- allow for different "levels" of security (data separation only, authentication, encryption)
- a way to dynamically advertise the security related info
- all this shouldn't affect scalability.

- does this WG want to address specific security requirements for PPVPNs. This is a big topic in itself? May need a separate document for this.
A: Marco - It is not the intention of the WG to have a separate document for security. The agenda wanted to catch different views on security requirements. We need to consolidate all the opinions into the requirements draft.
Rob Coltun: It is an organizational issue on how to organize the security requirements.
Marco: If there is sufficient material, we may have a separate draft in the future. That's not the intention though.

Q - The draft mentions the RFC 2547 IPSec security issue. This is a misrepresentation of RFC 2547.
A: Jeremy: Since this question is solution specific and not what I talked about now, we will take it offline.

Whither L2 VPN 5 min - Ron Bonica (co-authored with Kireeti Kompella)

- To outline the salient features of L2VPNs
- To address scaling and other issues.

Big picture
- Layer 3 interface between CEs
- customers view the PE as providing layer 2 service.

Some details:
PEs map customer-facing ports to L2 tunnels.

Routing properties:
- routing privacy (provider carries customer routing traffic, provider doesn't participate in customer routing domain)
- routing scalability
- router adjacencies (customer may require full mesh, or less than full mesh of routing adjacencies)
- multicast
- customer does replication
- customers maintain state
- provider network oblivious of this
- customer may prefer to use less than full mesh of adjacencies for bandwidth saving.

Operational characteristics:
- single infrastructure (routers provide l2 and l3)
- migration (small change for many customers)
- most important point : ease of configuration
- avoid n-squared provisioning problem
- goal: add a PE port to the entire VPN mesh by provisioning a single PE router
- solution : signaling between PEs:

Comment: Marco - how do you intend to proceed this draft?
Ans: Kireeti: Since this should be a provider-driven effort, I should go out of authors list. Add more providers. Why do we need l2 VPNs? Add to requirements draft.
Marco: Organizational issue: in June, we will have a checkpoint on consistent requirements etc. If we come to a conclusion, we will use this.

Rob: What's needed to standardize this? The reason is important. This should be part of requirements.
Kireeti: Signaling is needed to standardize this.
Rob: That is a more general requirement for tunnels
Kireeti: Yes, but I am talking about specific signaling stuff like how do I terminate link etc. We also have a notion of Layer 2 and a half. No. That's not MPLS. That's layer 2 and 1/3!
Would like SPs to think about it.

Dave McDysan: Ron had 4 requirements. Need to elaborate what's in the document. Need to specify QoS, traffic level etc.
Kireeti: we are coming up with a new version of the L2VPN draft - talking about VLANs, ethernet etc. will also propose layer 2 and 1/3 VPN. Will talk about Frame Relay DLCI, overprovisionng etc.

Ross: This has some relationship with the framework/requirements document. Content may be pulled into these docs.
Marco : This is also an organizational issue. We will try to consolidate for London.

Vinai Sirkay: Encapsulation is an important part of L2VPN, and needs to be coordinated with the PWE3 WG. How does this relate to PWE3?
Comment: End-to-end signaling is part of PWE3. But VPN membership is part of this.
A: Agreed with comment on coordination with PWE3. Will be starting work on this.

BGP-based auto-discovery mechanism for Optical VPNs 5 min - Don Fedyk
Optical VPN reference model and related requirements
Hamid Ould-brahim presented this draft:
- How should autodiscovery mechanism using BGP work within the context of OVPNs

- define BGP-based autodiscovery to allow client devices (CD), members of the same VPN to discover themselves and to request CD-to-CD optical connections across the service provider optical infrastructure
- given that the service provider could support mutiple OVPNs.
- Port is defined as collection of channels. A chanel could be a lightpath, sdh/sonet channel
- Not all ports on the PE must belong to the same OVPN
- Important goal - support single ended provisioning
- Should be pssible to reconfigure OVPN without requiring configuration changes in any of the providers Optical Network Elements (ONEs).

Reference model presented.

Mode of operations:
- within a given OVPN, each port has an identfier unique within that OVPN (called customer port identifier - CPI)
- within a service provider network, each port will have a provider port identifier (PPI)
- each PE ONE maintains port information table (PIT)

- a PIT on a given PE ONE is populated from two sources - from other ONE and via BGP.

Described how mechanism works. (GMPLS is required)

VPN topology is not known to the SP, controlled by CDs.

Comment: Marco: comment on list if there is any interest in O-VPN.
Comment: these are layer 1 networks. Why use BGP?
A: Marco: this is a solution. Let us go to the list.

Virtual Metropolitan Internetworks 10 min - Tissa Senevirathne
Requirements, issues, models for VMI

Agenda - what is a VMI? - Provider provisioned - LAN like service
- point-to-point, point-to-multipoint, multipoint-to-multipoint, hierarchical, multi domain (AS spanning)

VMI taxonomy
LAN services:
- common broadcast medium (ethernet model). L2 MAC learning/forwarding. VLAN oriented.

VMI requirements:
- protocol agnostic (sub IP)
- scalable service provisioning - automatic, end-to-end manual provisioning
- unrestricted multisite VLAN span
- security
- mandatory, optional
- issues: scaling, reconvergence, recovery (must be like LAN). Some work with MSEC WG (anycast security)

Forwarding is transparent to end user.

Comments: Dave McDysan: There is considerable overlap with requirements document. VLAN may be within scope. Need to do work on solutions and requirements in parallel. Can use this wording in requirements doc. Won't support the taxonomy part, though.
A: Tissa: what about hierarchy - is it ok for design document?
Dave McDysan: that is specific to metro services.

Comment: Adding deployment scenarios as annex to the requirements document would be helpful.

VPN tunnel systems 5 min - Heinrich Hummel

All existing VPN models have full mesh intersite tunnel systems. No need to administer many virtual topologies.
Alternative model
- a SP entity does administer one virtual topology with optimally tailored intersite VPN tunnel subsystems
- or a customer may do it online or offline

Tunnels may be CE-CE, PE-PE or a mix of both.
Tunnels can also be used as "transit" tunnels.

Heuristic approximation algorithms
- minimal tree rather than dijkstra
- minimal ring (ring tunnel, also for optical)

Tunnel weight - number of hops, inverse traffic load, price, etc.
The algorithm was demonstrated with a large network scenario to show the efficiency of the algorithm. The minimal tree and ring showed a striking improvement in hops required. A further cost reduction can be achieved by rollout or teardown on demand.

The algorithm can generate a notation which reflects the shape of tunnel system, and roll out according to notation. Can find out if it works through testing.

Summary: only physical full mesh is an even worse overkill than virtual full mesh. Apply all the best of networking technology to where it pays off most - to tunnel networks between sites (routing, multiplexing etc).

Comment: Bryan - The point that existing schemes are "full mesh only" is incorrect. Also, the presentation didn't capture hierarchy of tunnels for scalability.

Comment: Marco: This draft doesn't touch requirements at all. Why do we need this draft. Discuss on list. If there's a requirement to minimize tunnels, can include this.

PPVPN interworking 5 min - Junichi Sumimoto

Inter-AS VPN interconnections are explicitly stated to be considered in the PPVPN WG. Various technical approaches are already on the market for achieving interoperability.

From the service provider's pt of view, multivendor PPVPN interworking must be supported.

Interworking interface is based on reference model. Base approach may be different too (BGP-MPLS in one and virtual router in other)

Junichi explained the difference between 3 types of interface: interworking interface, customer interface, network interface.

Overview of proposed method:
- GRE, IPSec, FR or ATM-AAL5 used.

Summary and follow up:
- from service provider's point of view, PPVPN interworking is strongly demanded
- interworking interface should be considered
- proposed simple method satisifies the typical VPN service requirements.

May not be ideal right now, hope it will become working item.

Comment: Marco: Submit the solution as a separate document, requirements part already mentioned in requirements doc.

IP VPN Policy info model 10 min - Mahadevan Iyer
draft-iyer-ipvpn-infomodel-req-00.txt, draft-iyer-ipvpn-infomodel-00.txt
Issues in relation with requirements and framework

The first draft is a requirements draft.
Context: The draft describes the translation from a service goal to network policy. IP VPN policies capture the network requirements.

Requirement: - to have a mutual understanding between service level agreements and network on how the service needs to be provisioned in the network.
- standardized means of communicating requirements from the service level to the provider network.

VPN requirements: policing, VPN forwarding instance, traffic trunk.
Usage: service clients push requirements to the policy information model, which then sends it to the policy server.

- The proposal has used policy constructs and domain specific classes as defined in the Policy WG.

An example of service description was given, including connectivity requirement, QoS requirements, etc. The author is currently working on an implementation involving a LDAP repository.

Question from author: Do Service Providers think this is useful?

Marco: Please send your comments to the mailing list. This could go into the framework document, possibly in the management section. Personally, I feel there is interest in this work.

PPVPN info model 10 min - Riccardo Scandariato
Issues in relation with requirements and framework

Quote of the day: "in order to facilitate the service management, a logical view of the network indicating VPN topology above the backbone topology is useful."

The reference model is a little different from the model in the framework document. The approach in this draft can lead to an increase in manageability from a provider's perspective.
Riccardo discussed the notion of physical topology versus virtual topology.

The information model describes physical devices, interfaces, topological links (virtual part to physical part interfaces). The model captures the relationship between virtual and physical entities.

Due to lack of time, the future working group items were discussed before the rest of the agenda.
Future WG items (Applicability Statements, WG documents, plan for
London,..) 10 min - chairs

- According to our milestones, the requirements and framework I-Ds will continue work towards informational RFCs after London. This represents a very tight schedule.
- Please comment on list on the other drafts.
- Objective : integrate all agreed stuff in the two I-Ds before the London cutoff date of July 20.
- Related contributions and the version-01 of the requirements and framework I-Ds submitted by June 15.
- Comments on list and finalization of the I-Ds (version-02) before the cutoff date of July 20.

Current missing/open items
- As mentioned in Dave McDysan's presentation slides on "open issues", and Ross Callon/Muneyoshi Suzuki's presentations.
- Comments on virtual metropolitan internetworks draft and the optical VPN draft are invited.

Work on various individual approaches: There are a lot of existing approaches. At this point, it is quite premature to select the candidate approaches. So let's advance the requirements and framework documents as quickly as possible, so that we can select approaches. There is a wide consensus among providers and customers to move the identified approaches to standards track.

A possible plan from now: (in agreement with Scott Bradner)
- selection of candidate approaches before London - in mid June.
- Select one (hopefully) basic WG document for each candidate approach.
- Current issue: There is no Provider Provisioned CE-based VPN basic document. Work on this subject should start now
- The working group should group the individual I-Ds into one set for each candidate approach.
- Start work and discussion on I-Ds related to the various candidate approaches.
- Make a clear distinction of protocol specifications section inside each candidate approach set of documents, as this will help for the future (this WG has no mandate to validate protocol enhancements)
- Align with framework and requirements documents.

Plan for London and further:
- agreement on deliverables (for each approach)
- continue discussion on candidate approaches, integrate new agreed contents inside the respective set of candidate approach docs (make a clear separation of protocol specifications for each additional content)
- One applicability statement for each candidate approach to be finally produced.

What to do in the meanwhile:
- before selection of approaches, produce first version of applicability statement, based on the current framework classification of CPE-based, Network-based L3 and Network-based L2 PPVPNs.
- Applicability statement is definitely one of the ultimate goals of the PPVPN effort.
- The goal is to have the first applicability statement documents for London cutoff date.

What is due for London?
- consolidate requirements and framework documents based on other contributions and comments
- One Working Group document for each candidate approach
- 3 starting applicability statement drafts (CPE-based, Network-based L3, network-based L2)
- other contributions expected - all work related to various candidate approaches based on the produced requirements.

Please send your comments on the list.

ITU related work (SG2 VPN TE, SG13 Y.1311.1/1311 update) 10 min - Wai Sum
Lai, Marco Carugi

Wai Sum Lai : SG2 VPN TE

- VPN Traffic Engineering is being studied in the ITU-T Study Group 2.
- The draft recommendation that is being developed is E.ipVPN. The objectives of this recommendation are:
- It describes generic methods for traffic control and dimensioning of the Service Provider's network in supporting VPNs so that site to site performance may be assured.
- Aims at achieving multivendor interoperability of traffic engineering implementations in service provider networks.

Work has just started in Working Party 3 of Study Group 2. Further development requires input from the IETF PPVPN WG and ITU-T Question 11/Study Group 13.

We are looking for input to move this forward.

Marco Carugi: Update on IP VPNs in ITU-T Study Group 13

This is being studied in Q11/13 (study period: end 2000-end 2003). Q11 focus is on mechanisms to allow IP-based services using MPLS to operate in public networks. Two recommendations are being developed in parallel. They are Y.1311 (more general, but currently less advanced) and Y.1311.1 (specific to MPLS, but more advanced).
Y.1311.1 describes some requirements, which will be moved to Y.1311 (as generic requirements) in a later version.

The next SG13 meeting is in May '01 in Caracas, Venezuela. An updated version of Y.1311.1 has been sent as a contribution for May '01 to evaluate consent at the meeting. Y.1311.1 will anyway continue to live, and further versions are expected after this possible first consent.
The main difference between the scope of the PPVPN WG and Y.1311.1, is that Y.1311.1 doesn't cover non-MPLS technologies, CPE-based and L2 approaches. Also, there is no distinction between generic, customer and service provider requirements as described in the PPVPN requirements I-D. Currently, only two technical approaches have been identified for Y.1311.1 - one based on BGP-MPLS VPNS (rfc2547bis), and the other based on Virtual Routers.

Synergy between the ITU-T and the IETF is clearly stated in PPVPN charter and Y.1311 (.1) introduction text.
Marco presented the IETF PPVPN WG context in the ITU-T meeting in Boston in Feb '01. Most service provider requirements produced inside the ITU-T have been used in the PPVPN requirements I-D.
To continue this mutual exchange and cooperative effort, Marco plans to submit the last versions of the framework and requirements document to the ITU-T (for information purposes). The draft ITU-T recommendations can be obtained from http://nbvpn.francetelecom.com/ituRelated.html. (again, now moved to ppvn URL)


Analysis of the Security of the MPLS Architecture
Layer 2 VPNs
A Framework for Provider Provisioned Virtual Private Networks
Update from San Diego meeting on IP VPN work in ITU-T SG13
Additional security-related requirements for PPVPN
Uses of IPSEC with VPNs
IPVPN Information Model
ITU-T Activities on Traffic Engineering of IP VPNs
Service Requirements for Provider Provisioned Virtual Private Networks
"BGP based Auto-Discovery Mechanism for Optical VPNs"
An Information Model for PPVPNs
Virtual Metropolitan Internetworks (VMI)
PPVPN Interworking
Reference Models for PPVPN
framework fig 3.2