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.
| 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. | |
| Feb 02 | Submit the framework and the service requirement documents to the IESG for consideration as Informational RFCs. | |
| Apr 02 | Begin submission of the candidate L3 approaches and related applicability statements to IESG for publication. | |
| Aug 02 | Begin submission of the candidate L2 approaches and related applicability statements to IESG for publication. | |
| Dec 02 | Charter update or WG disband |
Current Meeting Report
Provider Provisioned Virtual Private Networks WG (ppvpn)
Minutes recorded by Ananth Nagarajan.
Wednesday, December 12 at 0900-1130
==================================
Agenda bashing - chairs
Marco presented the agenda.
Shai - ppvpn.francetelecom.com site gives errors when clicking on draft links.
Marco - it was OK two days before, don't know what happened.
1. Marco Carugi - PPVPN work status
Marco presented the PPVPN charter overview.
Goals and milestones were presented, along with work items that have been completed and those that have not : Informational RFCs on framework and requirements will be done after an IESG submission in Feb 02; L3 and related applicability statements will be done by April 02; L2 and related applicability statements by Aug 02. Marco also described the current candidate approaches - BGP-based and VR based. Other possible approaches include CE-based IPSec and port-based. As per the last sub-ip directorate meeting, optical VPNs will not be done here (it's not clear at IESG level if the work belongs to the IETF).
Design teams include : requirements, framework, VPLS requirements, requirements for PPVPN discovery schemes. Recent design team formed on L2VPN solutions (pt2pt and vpls): objective for March 02 is to make a first proposal of l2vpn candidate solutions. Another design team will start (to be announced to the list soon after the meeting) on l3vpn applicability statements : objective by March 02 is to complete AS guidelines ID (section on l2vpn, l2 vs l3 tradeoffs) and also release the first version of the l3vpn AS ID.
Marco described the expected progress of the IDs in 2002 such that the working group would be re-chartered or disbanded by 12/02.
A list of current WG documents was presented. Marco was informed by authors that updates of rfc2547bis and bgvpn auto-discovery drafts are planned (based respectively on some questions for clarification on the list and input from Tissa's BGP layer 2 VPN discovery draft). An update of draft-ietf-ppvpn-l2vpn-00 is also planned (it will include removal of any solution-specific content, the draft was approved as WG document just from an architectural perspective).
------
2. Dave McDysan - PPVPN Service requirements
Dave McDysan presented updates on the requirements draft. Changes from 02 version include removal of reference model (since covered in f/w), aligned definitions and responded to comments on the list. Open issues include completion of alignment with f/w, alignment with vpls/l2vpn and discovery drafts. Aim is to proceed to WG last call in mid-January 2002.
----
3. Ross Callon - PPVPN framework update
Ross presented a summary of differences from 02 version - editorial improvements, improved alignment with requirements document, missing sections filled, improved descriptions of CE-based and l2 vpns.
Ross listed the changes by section number. The draft is almost done. A section on network management will be added. Final version will be submitted early 2002 and go to WG last call in Jan 02.
----
4. Jeremy DeClercq - CE-based PPVPNs using IPSec
Jeremy presented the update to the draft. This draft has progressed from a framework document to a solution document (architectural concepts have been moved to the f/w document). The major changes include : alignment with framework document, config of security info, vpn-id from rfc 2685, routing issues dealt with (to be presented by Cliff) and added sections on vpn resilience. Open issues include the choice of management protocol, security info, constant vs traffic-driven IPSec tunnel, IPSec in tunnel vs transport modes, IPSec tunneling working with Customer routing. Next steps include: solution for routing issue via draft-wang-cevpn-routing, solution for topology via draft-wang-cevpn-group, and other issues.
Cliff Wang presented draft-wang-cevpn-routing and draft-wang-cevpn-group. The routing draft aims to provide for customer needs for site-to-site connectivity. Alternative approaches were described, and proposed a possibility of using external route distribution (e.g. BGP).
The group draft addresses the issue of device level IPSec configuration in a large scale VPN deployment. This draft has also been presented to IPSP WG. The draft proposes one way to support complex topologies by breaking VPNs into smaller groups, thus providing scalability, manageability and connectivity control.
Q: Liam - What problem is the routing draft going to solve w.r.t ATM/FR etc.?
A: Need to know what kind of address is used at remote end and IPSec doesn't address this. (providing local routing info to remote end).
Bryan Gleeson - Need to express syntax of a wild card, so that it can be represented appropriately in IPSec
Brajesh Kumar - ospf is being run across ipsec.. that's a solution.
Cliff - that's one specific solution, encourage participation to get a general right solution.
----
5. Jeremy - AS guidelines draft
Jeremy presented the motivation for the draft - assist development of individual App Stmts. Still a lot of editorial issues in 01 version (02 will be published soon after this meeting). L2vpns are not yet covered. A design team will start and it will also develop a specific document on AS for l3 vpns. Jeremy described changes from 00 version (new sections, progress on existing sections). Main open issue is to cover l2vpns, engineering tradeoffs, services.
Joel Halpern - as a general comment, L2vpns are not equivalent to bridged vpns. Need to cover both.
Jeremy - you mean, both in and out of charter? Pt2Pt is covered.
Joel - Pt2pt and bridged p2p are separate
Kireeti Kompella - bridged and p2p are different.
Vijay Bhagavath - Need to point architectural and scaling issues wrt p2p and vpls. Please contact me.
Marco - welcome to join discussion on L2vpns and bring input to the architectural work.
Possible next step is to make this a wg document after 02 version.
-----
6. Matt Squire - VPN discovery design team discussions and options
Discovery - determination of a-priori knowledge required to signal other endpoints within a VPN. Current solutions include multicast (rfc 2917) bgp (rfc 2547). A strong majority of the members of Design team felt additional mechanisms were required, some felt no new mechanisms were required. Main requirements were presented. Discussion on "timely fashion" - how quickly should the PEs know of changes.
There was also no decision reached on the concept of "extended discovery" - what is the scope? And where does discovery end and signaling begin?
Conclusion - need to merge reqts with ppvpn draft and come to decision on pending issues.
Q: Brajesh - why do we need new discovery mechanisms?
A: BGP is not ideal for L2vpns. Adding more stuff into BGP.
Brajesh - Reworded question - Why are the minority not supportive of new mechanisms.
Yakov Rekhter - minority said that we have 2 mechanisms - if you don't like bgp, use multicast. If you don't like x, use y - doesn't lead to a converged solution.
Marco - planning last call on requirements ID in Jan. So please provide the discovery requirements soon to the requirements team.
Vijay Bhagavath - Extreme - Query-based approaches like DNS/LDAP vs control based approaches? SP's raise reliability concern about query-based vs control based.
Matt - valid concern.
7. Juha Heinanen - how to use DNS/LDP for ethernet transparent VLAN service and VC-based VPNs.
Adds PE discovery and label distribution mechanism to draft-lasserre-vkompella. Simplicity and BGP-free nature, support for inter and intra AS and ability to work over non-MPLS tunnels were the main justifications. Juha described the configuration, protocol actions, data plane actions. Proposed adoption as WG document as one PE discovery/label distribution technology for transparent VLAN services.
Brajesh - Problems associated with consistency of replicated info.
Juha - this is only one approach. Don't want to argue all the aspects associated now.
Juha went on to present the applicability of dns/ldp to vc-based vpns.
Basic conclusion - less complicated than current approaches.
? - Won't scale because of fully meshed nature.
Kireeti - Did borrow some (*&(L(& in the case when you add another site to a PE.
Marco - These 2 drafts will be discussed in the L2VPN design team and considered appropriately. Can't accept as WG document right now. Additionally, another draft on this from Jim Luciani need to be considered.
Show of hands on how many people are interested in this - more for than against.
Marco - noted support, this means that the approach needs to be investigated further. Still take into account that we want to limit the final number of solutions for standard track.
----
8. Ron Bonica - CE-CE authentication for 2547bis VPNs
Problems associated with accidentally provisioning one customer's interface into another customer's VPN. The breach is not communicated to the second customer. Fixed by using "magic cookies" submitted from CE to PE, which are communicated to all other CE's within that VPN. Alternatives for doing this include using BGP extended communities or another "new" protocol. New protocol needs to be determined, but is based on TCP, is simple and needs authentication. Propose acceptance as WG draft.
Mark Townsley - not trusting PE's to do their job correctly, and then relying on cookies, which themselves may be untrustworthy.
A : agreed. We need additional discussions on list.
Brajesh - questions utility of this approach - since you are not trusting PE. Traceroute and Ping to your site gives you the answer.
Ron - Have tested in labs, intruder knows first, affected VPN knows later.
Yakov - the purpose is to reduce misconnectivity due to misconfiguration. Whether useful or not, this is a good option to have.
? - Asking for a new protocol instead of looking at overall security is not worth it.
Shai - Don't think "optional" means a new mechanisms that is good or bad, but rather doing something heavy, but not having enough utility. This is not a good engineering solution, not a good security solution.
Yakov - It would be wise to let the market decide on the utility. A SP may find this useful, and he has customers.
Mark Townsley - don't classify this as security, but rather an honest man's mistake!
Marco - discuss on list.
----
9. Tom Nadeau - RFC 2547 MIB
Changes since previous version - compilation errors fixed, other changes made. Assigned IANA experimental 118.
Open issues : Are the examples sufficient? Currently received feedback from 3 implementations, need more. The document is ready for last call by next meeting.
Marco - What is the commonality with VR MIB?
A: Consult with Elwin, commonality will be published and sent out.
----
10. Valdemar Augustyn - VPLS Requirements design team
Valdemar presented the vpls requirements draft (integration of 3 drafts).
This work has been completed. Haven't received a lot of comments. Speculation that the requirements draft has been received well, since most comments are directed to solutions.
Future steps include possible updates, use for the solution work along with the L2 VPN solution design team. Request acceptance as WG document.
Room consensus is to accept as WG document. Marco suggests 3 weeks on the list for comments before approval as WG document.
---
11. Waldemar - Architecture and Model for VPLS, Bandwidth Management for VPLS
Waldemar presented the two drafts. These documents will help the solutions work, in terms of redundant networks and functional element description. Future steps include possible integration with other L2 architecture documents to form a single architecture document, use of these documents as working documents for L2 solution design team. Also propose extending this work to include delay, jitter etc.
Vijay Bhagavath - What will be the requirements to support partial mesh vs. full mesh?
A - Partial mesh mentioned in bandwidth document - just because connectivity is full mesh, doesn't mean partial mesh configurations are precluded.
Vijay - Real life SP scenario may lend itself better to partial mesh connectivity with logical full mesh.
A - Agreed. VPLS looks at the LAN character of a VPN. But there's no question about your concern - it is valid.
Marco - Should we have one single L2 arch document or one for VPLS and another for Pt2Pt? Solicit comments on list.
Liam - Any benefit in having one document since there is a confusion between vpls and pt2pt?
A - Single architecture document, but different requirements document. Will determine if we need separate documents.
Marco - basic requirements document is the same. Need to determine if we need separate reqts for L2 pt2pt vs l2 vpls.
----
12. Vach Kompella - L2VPN Design Team goals
DT formed to bring order to multiple proposals in this space.
Aim to clarify "bridge" terminology, deployment scenarios, functional descriptions of service, scalability issues, bandwidth issues, complexity, security issues, etc.
Vach listed the various proposals related to BGP-based L2VPNs, LDP-based L2VPNs, RSVP-signaled L2VPNs, Hierarchical/Distributed VPLS. Tissa's draft on GRE encapsulation for L2VPN may be outside the scope of the design team, as it describes encapsulation, not signaling. Propose moving this draft to PWE3.
Vijay Bhagavath - need to see more work on generalized signaling framework between PE's and CE's.
A : Models looking at functional description between PE and CE, with the CE actually being a L2-PE. If the CE is a pure "vanilla" CE, this is outside scope.
Vijay - This is important, does this mean it would necessitate a new protocol? Are there aspects beyond QoS or label distribution being considered?
Kireeti - There are abstracts of provisioning - specify ports belonging to VPLS, how does it related to services provided in the SP network.
Scott Bradner - signaling from customer point of view is outside the scope (not provider-provisioned). Anything not controlled by SP, is outside the scope.
? - What about service discovery for L2VPNs ?
A - offline.
Kireeti - Interworking of ATM and FR only in the IP case (routing based on L2), is discussed in Kompella draft. It would be good to know if this is outside scope.
Brajesh - If you are interworking FR and ATM, why do you need L2? It can be done in L3VPN.
Yakov - makes a lot of sense to have both - customers want to buy l3 and l2.
Brajesh - customers don't make logical choices!
Marco - As overall comment, need to separate what is to be done here vs PWE3. Objectives for design team for next months need to be precised more in detail.
Vach - Not had enough discussion to produce time frame. Will try to do it by January. Will try to produce a "pre-applicability" type of document (in Marco's words).
-----
13. PPVPN using L2TP - Elwin Eliazer
Both L2 and L3 VPNs can be based on L2TP.
Main features - layered solution by decoupling tunnelling from learning of VPN tables, can work with (but doesn't need) MPLS or IPSec.
Yakov - Is this more scalable in autodiscovery than DNS?
A - This is based on control protocol
Andy Malis - L2TP v2 or v3?
A - v3, but can use v2.
Bryan - Does a middle router need to distribute information to edge routers? Will have looping problems.
Kireeti - Is it within scope to talk about tunnel setup.
A - can consider this is as a discovery mechanism, so it is within scope.
Kireeti - Different issue, question is - is tunnel setup within scope ?
A - so far l2tp is forgotten in ppvpn, and very valid.
Kireeti - valid in pwe3.
Yakov - why is this vpn membership better than any other method already done in this WG?
A - doesn't need BGP
Yakov - If you don't like BGP, use multicast.
? - clarification on control tunnels - are they configured or discovered?
A - Configured.
? - Need mechanism to set up arbitrary topology - every mechanism for fixed topology would be wrong.
? - Does L2TP support QoS tunnels?
A - yes.
Brajesh - this can coexist with existing or use a new discovery mechanism.
Marco - Need a clearer representation of what requirements it addresses, and then determine the interest to progress this work.
----
14. Hienrich Hummel - Partially meshed base tunnels plus hierarchical mp2p tunnel sequence LSPs.
- overcomes n-squared problem. Hierarchical tunnels need to switch LSP within LSP.
MP-BGP used to distribute info about base tunnels to the right VRFs, and redistribute this info along with LSP-Ids to aid tunnel establishment. Showed significant reduction in number of tunnels that need to be maintained.
Q - Liam - how useful is this in VR approach?
A - many applications.
Marco - SPs should comment on the need for developing such techniques, if they address real problems for SPs. Then, we'll see if and how to progress this work (much of this stuff seems for CCAMP).
---
15. Marco - wind-up
Marco summarized the I-D expected progress.
Comments on the list requested on MIB IDs, discussion on magic cookie, extended l2tp, directory/dns based approach and CE-based IPSec approach.
-----
Slides
Agenda
CE-to-CE Authentication for RFC 2547 VPNs
Requirements For Virtual Private LAN Services
Provider provisioned CE-based VPNs using IPsec
Service Requirements for PPVPN
VPN Discovery
Framework document update
Guidelines of Applicability Statements for PPVPNs
DNS/LDP Based VC VPNs
DNS/LDP Based Transparent VLAN Service
VPN Endpoint Discovery
PPVPN using L2TP
L2VPN Design Team Goals
Architecture and Model & Bandwidth Management for VPLS
Requirements For Virtual Private LAN Services
Provider provisioned CE-based VPNs using IPsec
Service Requirements for PPVPN
VPN Discovery