Current Meeting Report

2.6.6 Provider Provisioned Virtual Private Networks (ppvpn)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 19-Feb-02
Rick Wilder <>
Marco Carugi <>
Sub-IP Area Director(s):
Scott Bradner <>
Bert Wijnen <>
Sub-IP Area Advisor:
Scott Bradner <>
Technical Advisor(s):
Rob Coltun <>
Mailing Lists:
To Subscribe: with
In Body: (UN)SUBSCRIBE ppvpn in message body
Description of 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 PWE3 and ITU-T efforts will be ensured.

Goals and Milestones:
Done   Formulate a plan and begin approaching SPs for input on scaling and other requirements
Done   Begin discussion (based on submitted IDs) on candidate approaches against the different service requirements.
Done   Begin discussion of the framework and the service requirement documents. Identify a limited set of candidate approaches. Build appropriate design teams.
Done   Begin discussion of applicability statements.
Mar 02   Submit the layer 3 framework and the layer 3 service requirement documents to the IESG for consideration as Informational RFCs.
May 02   Submit the layer 2 requirement document to the IESG for consideration as Informational RFCs.
May 02   Begin submission of the candidate L3 approaches and related applicability statements to IESG publication
Aug 02   Begin submission of the candidate L2 approaches and related applicability statements to IESG for publication
Aug 02   Submit the layer 2 framework document to the IESG for consideration as Informational RFCs.
Dec 02   Charter update or WG disband
No Request For Comments

Current Meeting Report

Provider Provisioned Virtual Private Networks WG (ppvpn)

Thursday, March 21 at 0900-1130

CHAIRS: Marco Carugi
Rick Wilder

Minutes recorded by Ananth Nagarajan (
These minutes and all presentations will be available (soon) at

1. Agenda bashing - chairs
Marco presented the agenda and details of WG subscription, archive etc.

2. PPVPN WG status - 10 min - Marco Carugi

ID status, milestones, work items, design teams, progress expected before next meeting, issues and missing work.

Current milestones :
done - formulated a plan, approach SPs for input on scaling and other requirements. Started discussion of framework and requirements and discussion of candidate approaches against requirements. AS discussion has also started.

Submission of Framework and Reqts docs planned for informational RFCs at end of this meeting, and L2 requirements to IESG for informational RFC in May 02.
May 02 - submit l3 approaches and related AS
Aug 02 - submit l2 framework as info RFC
Aug 02 - begin submit l2 approaches

Work is delayed because of separation of layer 2 and layer 3 specific requirements and framework. Above milestones will be changed according to current progress.

Marco also presented details of current design teams:

- the requirements and framework teams' work on l3 has almost been completed and editors are in charge of the last phase of completion. They may also support, on individual basis, the layer 2 solutions DT on framework and requirements.

- the design team for requirements for VPLS will be closed (almost all members moved to the L2 solutions design team).

- the design team for requirements for PPVPN discovery schemes will be closed officially (already closed unofficially). They produced a discussion document that identified other schemes such as DNS-based discovery.

- the L2 VPN solutions design team will continue its work. Current work is on l2 framework and metrics draft (00 versions), L2 requirements (not yet done) and PPVPN terminology (00 version). The first proposal for L2 VPN candidate solutions also needs to be done.

Marco's post-meeting note : the PPVPN terminology document was not officially assigned to the team.

- the design team for L3 applicability statements, that will continue its work on guidelines and solution-specific AS drafts.

- a CE-based IPSec solution(s) design team will be officialized soon ; an existing informal team will be input to this design team.

Some specific items are:
- L3 solutions should have one document per approach listing all requirements for protocol extensions or new protocols, justification, and, where present, solution proposal.
- 00 draft for CE-based IPSec is needed for next meeting, although there is no clear schedule for proceeding as standards track
- L3 applicability statements should be advanced quickly, so request comments on list. Especially the sections on scalability and security.
- draft-luciani-ppvpn-vpn-discovery-02 (DNS based) may be progressed as WG ID, with the BGP and DNS-based discovery IDs to follow a similar path (path is TBD). Discussion before approving it as WG document will be started on the list.
- draft-ouldbrahim-ppvpn-gid-00 needs comments on the list (global unique identifier format for l3 and l2 vpns)

Within L2 solution space, clarification of terminology and stability of terminology is required for all the drafts in this space. A certain level of solution convergence and integration is expected, so that a limited number of solutions are identified. Discussion is expected on this.

Furthermore, future work may include ppvpn management and ppvpn QoS (working process and precise objectives still TBD).

Finally, Marco discussed the progress of Q11/13 in ITU-T :
- Y.1311 Recommendation was approved in January 02
- a new work item on L1/Optical VPNs was proposed in January 02, and
this will be further discussed in a joint Study Group 13 and 15 Rapporteurs' meeting in Geneva on May 6, 2002.

An estimated progress schedule for the IDs was then listed.

Status of current WG documents (this slide was actually skipped and presented later, at the end of the AS DT slot):
- l3 reqts and l3 framework WG last call completed 1 week ago. New target : WG last call delayed (in 3-4 weeks from now) because some folks have requested an extension for comments.
- new WG docs after SLC : VPLS requirements, tc-mib
- draft-ietf-ppvpn-l2vpn-00.txt : to be integrated in L2 framework
- draft-ietf-ppvpn-ce-based-01.txt : to evolve to a solution document

Comment: Hamid - If a network is deploying multiple types of VPNs, it may useful to identify the issues if we have all these types on a network. So we need a generic framework, in addition to l3 and l2 specific frameworks.

Marco - A discussion few months ago on separation of l3 and l2 framework and requirements also opens up the possibility of generic framework and requirements documents (at a common higher level). it will be important to bring this up on the mailing list.

Hamid: It is important to maximize commonality across different types of solutions, in addition to the same type.

Rick: this is probably a good idea for the AS drafts.

3. Report of the "L3 Applicability Statements" Design Team

Guidelines - 5 min - Junichi Sumimoto
Update, open issues, future steps

Junichi presented the AS guidelines draft. The main changes from 01 are that it is focusing on delivery of L3 applicability statements, and focused on providing a list of key requirements and metrics. A comparison of different approaches was out of scope. The new outline was discussed.

Open issues include key requirements and metrics for L2 VPNs, and management sections.

Future steps include enhancement of requirements and metrics for L2 VPNs, fill out management sections, finalize the classification/outline (may be only common, L3 and L2) to reduce redundancy, alignment with AS IDs, incorporation of list comments and moving to WG document.

Solution-specific IDs - 15 min - Ananth Nagarajan, Jeremy De Clercq
ID overview, issues, future steps

Ananth and Jeremy presented the status of these drafts. Requested that they be accepted as WG drafts.

Marco suggested that the ce-based draft needs to wait before it becomes a WG document, because of the relative immaturity of the CE-based solution space. The other two drafts (2547 and vr-based AS) may proceed as WG drafts, based on comments received on list.

4. L3 VPN solution space
- Dynamic routing for CE-based IPSec VPNs - 8 min - Paul Knight

ID overview, issues, future steps

Paul Knight presented the draft. Signaling and routing dynamically makes CE-based IPSEc VPNs scalable. This draft describes an implementation of IP in IP Transport mode (IIPTran) as described in draft-touch-ipsec-vpn-03.txt

IPSec security associations have selectors that constrain the use of IP routing. The IPSec tunnel mode is incompatible with dynamic routing.

Basic solution is to remove the tunnel's static routing by using "wild card: in tunnel SAs or using encapsulation like GRE/L2TP or IIPtran to make traffic fit static route.

Related IPSec developments are planned updates to RFC 2401 (rfc2401bis), and the submisison of draft-touch-ipsec-vpn-04 as informational RFC.

Future steps : will provide input into IPSEc CE-based ppvpn drafts, and provide implementation proof and applicability demonstration for Touch draft.

Eric Rosen: Will two IPSec security associations between same end points work?

Paul - will work, will discuss offline.

Joe Touch gave a background for dynamic routing for IPSec transport mode. Didn't go to standards track to avoid confusion to already existing RFC 2401 (and therefore informational).

- CE auto-configuration for CE-based VPNs - 5 min - Cheng-Yin Lee
ID overview, issues, future steps draft-lee-ppvpn-ce-auto-config-00.txt

Cheng-Yin presented the draft.
CE autoconfiguration is needed because:
- manual configuration leads to error
- not cost efficient to provision all affected CE sites

The draft describes various provisioning issues and autoconfiguration options. An overview of an example approach using DHCP was presented.

Next steps - get WG consensus on the VPN parameters to be configured as described in FW document.

Marco: is it intended to discuss these options in solutions document?

A: no. this is for the f/w draft

Marco: CE-based f/w has commonality with other l3 framework. this could go into a generic section.

Juha - we considered dhcp when we discuss provider-based DNS based l2 solution. how does dhcp server get information regarding other sites of vpns? do you envision a centralized dhcp server.

A: that's out of scope

Juha : then, there's a problem. you need to know info about the other sites.

Eric Rosen: same question as Juha.

A: Standardization going on in dhcp group.

Eric: that's separate issue. This should be addressed in dhcp group.

Yu-Shun Wang: DHCP usually provisioned from single administration for a LAN. modification is probably needed for large scale implementation.

will discuss offline.

- CE-to-CE authentication for RFC2547 PPVPNs - 5 min - Ron Bonica
Update, issues, future steps

Ron bonica presented the draft. "Accidental" authentication problems may happen, where a customer accesses a VPN he is not authorized to. CE-based authentication involves magic cookies on each VPN site, being sent to the SP. The CE authenticates these cookies. BGP may be used to send them.

Limits of trust: the VPN customer must trust the SP to implement the solution correctly, but not against misconfiguration.

Next steps proposed - adopt as WG document, implement and obtain operational experience.

Hamid: does it apply to VR also?

A: not considered yet, but no reason it shouldn't apply.

Joe Touch: What if a customer wants to be on two VPNs at once. Wil the cookies work?

A: Two (any number) of cookies can be advertised from a site. CE at remote end can decide which cookies to accept. Either end can send or receive multiple cookies. So it works.

Ross Callon: Simple mistakes happen. This is a simple way to solve such problems.

Marco: this is a simple mechanism, but needs to go to the list before approval as WG document.

Scott Bradner : currently compartmentalized. needs to be broader in scope (e.g., VR).

5. L2 VPN requirements and framework

- VPLS requirements - 5 min - Waldemar Augustyn

Issues and future steps, integration in a general L2 requirements ID draft-augustyn-vpls-requirements-02.txt

Waldemar presented the L2 requirements draft.
Status overview was presented.
Current contents are fairly stable. Draft has been resubmitted as WG draft (draft-ietf-ppvpn-vpls-requirements-00.txt)
Future updates include align terminology, clarifications and evolution towards a common L2 VPN requirements document.

6. Report of the "L2 VPN solutions" Design Team - 20 min - Loa Andersson

Team work status, issues, L2 framework, process to a "candidate solutions" team proposal, future steps (work items, objectives)

Loa presented the L2VPN design team. Juha and Hamid don't have time, but they will not be excluded from mailing list. One new member (at this stage), Vasile Radoaca, added.

In addition to above two drafts, draft-andersson-l2-ppvpn-framework-00.txt was prepared, but not yet submitted (didn't meet the ID deadline).
This is comparable to l3 framework. Needs slight restructuring.

The proposed L2 vpn documents structure:
1 Framework, 1 requirements, 1 metrics and multiple solutions.

The plan is to produce l2 requirements, considering the vpls requirements ID also. In addition, improvement of metrics and framework and start classifying existing IDs. There are really too many IDs today.

The framework draft will also receive input from the L3 framework team.

The schedule is to have requirements by May 1st, l2vpn framework 00 after the meeting, 01 of framework in mid May, framework and metrics ready for WG last call in Yokohama (together with a team proposal of candidate solutions).

A matrix for the various drafts, capturing various attributes, has been initialised. Request to authors of these drafts to verify this matrix, so that they are properly considered/incorporated in the design team work. The matrix is at

Marco: It will be useful to receive input from authors of individual drafts to see alignment with DT.

Dave McDysan: Metrics are good, but there is a mix of framework and metrics in the " metrics " draft. These need to be structured properly.

Loa: agreed.

Dave: These metrics can also be used for AS. Because of the large number of drafts in this space, names and terminologies are confusing and overlapping with some L3 drafts. This needs to be resolved.

Loa: The same mistake has been done in the terminology draft ! The most commonly used names will be used in the next version. Document history of all names.

Dave: not sure if documenting history of all names is a good idea.

Loa: No, it will be useful.

Marco: how do you intend to progress the candidate solutions work ?

Loa: Our intention is to do this. But the first step is the matrix, to see commonalities. For example, there is one document that no other document addresses (RSVP-TE signaling). There are other drafts that have info that would go into framework. It will be an intensive period until Yokohama, and intend to keep the info "semi" public for input. Hopefully, we can get this done before early summer.

Marco: Regarding RSVP-TE, this concerns one single attribute. Similarly, there are other attributes. The matrix will be probably useful to produce the list of candidate solutions to be submitted to the group.

Loa: I didn't see RSVP-TE becoming a WG draft. It doesn't clash with other IDs.

Marco: Currently no request to move as WG drafts?

Loa: Too early to move framework draft to WG draft. Metrics document is a possibility after discussion on list. Terminology draft needs one more re-spin before becoming a WG draft. Would like a process to do this before a meeting.

Marco: Discussion on list is encouraged to identify important attributes, metrics, criteria to progress these drafts as WG draft.

Dave - a suggestion for terminology is to use Framework draft as first step, instead of creating a new draft.

Marco - good suggestion.

7. - VPLS architectures - 10 min - Ali Sajassi

ID overview, issues, future steps

Ali presented the draft. This draft defines vpls architecture in terms of its logical components, so that VPLS can be discussed for different architectures. Architectures for Ethernet edge device-based VPLS (low cost), MPLS/IP edge device-based VPLS, and VLAN considerations for PE are discussed.

Tissa: what's new in the draft?

A: No previous draft has described VPLS. MPLS label assignment etc.

Vach: Default behaviour of VPLS (unqualified learning).

A: unqualified learning doesn't involve VLAN. Qualified learning involves looking into VLAN. VLAN-awareness is important.

Vach: Need a single VLAN per VPLS, but this is configuration issue not a protocol issue.

Marco: This may be of interest to align with design team for framework draft and other inputs and criteria to L2 solutions.

8. - VMI framework - 10 min - Tissa Senevirathne

Update, issues, future steps

Tissa presented this draft. VMI is a combination of VPLS and point to point l2 vpns. The requirements and framework are now decoupled in this 02 version. VMI taxonomy has been defined, based on services plane, management plane and infrastructure plane.

Next steps include updating acronyms, alignment with design team documents and merge and integrate work with DT work.

Marco: First step is to clearly address with the DT, what are requirements and what are framework points. There is still some redundancy. A single converged joint effort is expected for framework.

9. Discussion on the L2 VPN space (requirements, framework, solutions) - 10 min - all

Dave: We have a framework for VPLS now. What about other L2VPNs?

The framework draft discusses interworking of this with other types, but we need a requirements set and framework for other types of pseudowires.

Marco: the intention is in fact to do this : generic l2 requirements document, generic l2

(PW and VPLS) framework document.

10. L2 VPN solution space

- ARP Mediation for IP interworking of Layer 2 VPN - 10 min - Himanshu Shah

ID overview, issues, future steps

Himanshu presented this draft. This draft addresses IP Layer 2 interworking on heterogeneous access circuits which leads to disruption of ARP mechanisms used by the CE routers. This may require the SP to meddle with CE routers and PE devices.

The draft offers three alternatives to learn locally attached CE's IP address, and also describes the exchange process between PEs for both martini and kompella signaling. This draft reduces configuration complexity. Suggest this to be adopted as WG document.

Juha: This is far too complicated. Who builds networks like that?

Question the usability of building sites that have some sites as ethernet and some as FR.

Andy Malis: Respond to Juha. Have seen demand for this. And see this is important.

Marco: What demand - generic interworking or IP specific?

Andy - some of both.

Dave : If it is not generic, then there is limited value. If it is IP only, then you can do it on another type of network-based VPN. If it is not IP, don't do it in the IETF.

Scott - Interworking of FR with ATM and things like that is out of scope. It may be interesting, but right now it is out of scope of charter. urge discussion on mailing list. if sufficient support is observed (in spite of complexity), then we can talk to ADs to modify charter. Predict that this is not seen as work item in IETF.

Joe Touch: Good engineering is when you avoid doing what you shouldn't do. So solving a problem that comes up because you don't do things right, is not recommended.

Marco: discuss this further on list.

- PE-L2PE/MTU signaling for Decoupled and Hierarchical VPLS - 7 min - Himanshu Shah

ID overview, issues, future steps

Himanshu presented this draft. LDP based signaling is defined for decoupled and hierarchical VPLS.
Request adoption as WG draft.

Joel Halpern: Please change the name MTU (doesn't mean multi-tenant units). Let's describe first what the protocol issues are.

Juha: this also is too complicated. why don't you make the PE do MAC address learning as a simpler alternative? You need a new protocol only because PE is dumb? Don't buy such PEs.

Scott: I share Juha's lack of imagination! Also, not good to define only MPLS-based approach in this WG.

A: this is solution-specific.

Scott: but this is a generic issue whether or not you use mpls.

Marco: This is one of the models that needs to be considered for moving forward.

Eric Rosen: All SPs that have PEs that have already been bought that are not smart enough, need such a solution instead of buying new equipment. not saying this is the right way to do it, but such a problem is important to solve.

Juha - making a core box an edge box used to work in earlier days, but today it is senseless, because an edge box needs to do lots of stuff.

Himanshu: there is a need for such functionality. This is specific-solution.

Scott: not part of the IETF goal to preserve existing infrastructure. Take this to list.

- QoS support in VPLS over MPLS - 5 min - Fabio Chiussi

ID overview, issues, future steps

Fabio presented this draft. This draft addresses the need to identify endpoints for automatic QoS provisioning and proposes the use of VCID field to refer to the VPN endpoint rather than the VPN, and one VC label per VPN endpoint pair.

Other issues include automatic VPN discovery using QoS, signaling extensions for binding inner and outer label, automatic QoS provisioning of both outer and inner tunnel, QoS of VPN and QoS within VPN.

Marco: Need clear definition on this problem, and how this can augment framework and requirements.

Juha: This again is far too complicated. Assuming an ATM-VC like functionality to do hard QoS. If someone wants to do that, let them do it. This WG shouldn't try to say that this is the right way to do it. Diffserv is simpler. No signaling or VC functionality is needed for QoS.

A: A range of solutions from very simple to very complex solutions is needed.

Juha : use TDM!

Dave: Align with more standard terminology. A lot of this is also done in DS-TE in TE WG. Again, this is MPLS specific solution, and therefore not enough to fit in this charter.

?: What problems are you trying to solve? There are ways today to do QoS. So this presentation is not solving anything that is not already solved. Too complex for an edge solution (simpler ways available today).

A: This provides automatic QoS provisioning for especially VLAN VPNs. Our intention is not to redefine QoS.

Marco: TE WG also asked for input from possible applications such as PPVPN. So this may be important once issues are clarified.

11. Overview of multicast in VPNs - 5 min - Jeremy De Clercq

ID overview, issues, future steps

Jeremy presented this draft. this discusses the applicability of multicast to VPNs. Multicast support in various VPN approaches is always TBD. Multicast is used to connect multicast-enabled sites, and also for broadcast in VPLS services.

This draft identifies multiple methods and tradeoffs, and requirements imposed to SP network. The goal is to get feedback from the WG on whether this is needed (or only needed for VPLS).

Tissa: you are proposing a separate multicast tree for VPLS. This is too complicated for VPLS.
Jeremy: if you have a tree per PE and per VPN, it is useful. Need comments like this on the list.

Marco: this is for mpls. It could evolve as informational document.

Jeremy - not specific to mpls. only one slide on mpls.

12. LSP setup for Inter-AS VPNs - 5 min - Michael Mroz

ID overview, issues, future steps and how to deal with this ID

Michael presented the draft. This draft is specific to MPLS, and uses BGP to distribute inter-AS labels, and describes an example to set up an inter-AS LSP. Future steps are to merge this draft with draft-menezes-inter-city-man-mpls-00.txt. RSVP-TE is not addressed, and is LDP centric. LDP targeted peer session scalability is not addressed.

Marco: Does it apply to other approaches, apart from draft-menezes?

You may consider giving input to the matrix.

13. Recap of action points and conclusion - 5 min - chairs

Continue progressing L3 applicability statements and document on listing protocol extensions for specific solutions, design team for L2 requirements/framework.




Requirement For Virtual Private LAN Services
Report from the L2vpn Design Team
CE-to-CE Authenticaion for RFC 2547 VPNs
Extensions for QoS Support in Transparent VLAN Services over MPLS
Overview of Multicast in VPNs
A Method to Signal and Provide Dynamic Routing in IPsec VPNs
CE Auto-Configuration for Provider Provisioned CE-based VPN
Inter-AS LSPs
Layer 3 solution-specific Applicability Statements
VPLS Architectures
A Framework for Virtual Metropolitan Internetworks
ARP-Mediation draft
PE-MTU Signaling
Guidelines of Applicability Statements for PPVPNs