Last Modified: 2003-03-04
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 | Begin discussion of the framework and the service requirement documents. Identify a limited set of candidate approaches. Build appropriate design teams. | |
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 applicability statements. | |
Done | Submit the layer 3 requirement and the layer 3 framework documents to the IESG for consideration as Informational RFCs. | |
MAR 03 | Begin submission of the candidate L3 approaches and related applicability statements to IESG publication | |
APR 03 | Submit the layer 2 requirement and the layer 2 framework documents to the IESG for consideration as Informational RFCs. | |
JUN 03 | Begin submission of the candidate L2 approaches and related applicability statements to IESG for publication | |
NOV 03 | Charter update or WG disband |
extensions.----------------------------------- ----------------- --------------------------------------------- PPVPN meeting - 56th IETF - March 19, 2003 - San Francisco, CA ---------------------------------------- -------------------- ------------------------------------- Minutes recorded by Ananth Nagarajan, some changes/additions by Marco Carugi 1. Marco - Agenda bashing and WG status ---------------------------------------- ---------------------- Marco started with agenda bashing, then gave a status report of the WG. The layer 3 requirements and framework drafts have been submitted to the IESG for consideration as Informational RFCs. The next step is to have WG last calls for the candidate L3 approaches before submission to IESG (2547bis and VR) for proposed standard in a few weeks. Complementary documents will follow this. Corresponding L2 documents would be progressed in the next months before the July meeting. The L3 framework and requirements documents received comments from IESG. The generic requirements draft also needs resolution of comments of IESG. All these drafts would be sent back to IESG in few days. Draft-ietf-ppvpn-ce-based draft will be discontinued as part of it has been integrated in L3 framework, other part in draft-declercq-ppvpn-ce-based-sol-00. WG last call of CE-based IPSec VPN solution ID is targeted before next IETF. Effective progress of the applicability statement guidelines draft is not clear, discussion is needed. The terminology draft and first l2 solution documents will be moved to WG soon after the meeting. The metrics draft will be discontinued (proposal of the L2 team, agreed by AD too), the L2 reqts draft becoming the single basic reference for solutions. The L2 requirements document (L2 team product) needs wider review by the whole WG. The l2 Framework document is in good shape. Both these documents are being targeted for IESG submission in the April-May 2003 timeframe. There are currently no WG documents in the L2 solution space. All design teams, except the L2 design team, have basically concluded their tasks. The L2 team will be closed now, although the team list will continue to live until completion of L2 reqts and L2 framework documents. Marco gave an update on L2 design team discussions. The functional decomposition recommended in Atlanta aimed to complete a set of functional documents, whose initial content was produced by 4 team members for the interim meeting in Billerica - January 2003. The result of discussions in Billerica (Scott attended too) was to discontinue the work on functional decomposition. Other meeting outcome : solutions documents will have to include a requirements compliance section; design team will not recommend any specific solution ID to the WG, discussions and decisions will be made based on mailing list input. Most of (not all) team members favoured the progress of the L2 solution documents as experimental, and not standard track, for now, but this needs to be discussed further by the whole WG. The status as of now for L2 documents is that the optional template has not been widely adopted, few solution IDs contain the reqts compliance section, WG list discussion on various solutions has not happened yet. Wide participation of WG is requested to progress this work soon, by selecting a number of solutions documents in L2 space (need that authors update their solution IDs with reqts compliance section, and start discussion on their document on the list). Current milestones indicate L2 solutions submission to IESG in June, but it will require confirmation (Applicability Statements and MIBs work has not started yet). There is a clear need to have strict relationships with protocol specific WGs for protocol extensions in PPVPN. To evaluate the interest of requesting rechartering of the PPVPN WG at a certain point in time to remove the restriction on protocol development. Alex: Clarified that there is no current intention to take the work of other WGs on protocol deployment and do it in PPVPN. Francois: Didn't mention IPv6 VPN document that is a WG document. Checking if the status has changed. Marco - No. Draft not mentioned explicitly for brevity, but it is in. Further work to be done in PPVPN in terms of QoS, security and management frameworks : WG input is needed to focus areas of development. L2 interworking and service OAM were brought up for discussion in the L2 team: Marco's proposals in this meeting on such items need to be discussed on the list. Other topics for future discussion include multicast, l1/optical VPN and wireless VPN. Alex: There is a lot of work that PPVPN needs to do, that it has not finished. So let us not extend the charter. Marco: It's agreed that multicast, l1/optical VPN and wireless VPN are not WG items for now. ----- 2. Jeremy DeClercq - CE-based L3 PPVPN progress ---------------------------------------- ------------------------------------ Jeremy gave an update on the CE-based L3 space. draft-declercq-ppvpn-ce-based-sol-00 is proposed as PPVPN CE-based IPSec solution document. Draft-ietf-ppvpn-ce-based will be discontinued and kept for reference only. Clarifications on management responsibility, routing realms and Internet access, auto-discovery were made. Future steps include making this a WG document and progressing the corresponding AS document. Joe Touch: We have running code that is similar to this draft, except it is push-based, and not pull-based. Also it has not been cited as reference. 90% is similar to this document, 10 % is different. We have running code. Jeremy : It will be discussed. Alex Zinin : Is there consensus on the 10% difference? Running code is not enough, need to come to the WG and ask for consensus. Joe Touch: Also need to read prior work and cite reference. Dimitri: What is meant by "what to do with draft-ietf-ppvpn-ce-based?" Jeremy: Parts of this document were moved to L3 framework document. The solution specific part has been taken into draft-declercq-ppvpn-ce-based-sol-00. ----- 3. Robert Jaksa - Hierarchy of Provider Edge Devices in BGP/MPLS VPN ---------------------------------------- -------------------- ---------------------------------------------- Robert Jaksa described the need for Hierarchy of Provider Edge (HoPE) for better scalability of PEs in RFC2547bis, and discussions that came up in the mailing list on this draft. Eric: Not exhibited any case of lack of interoperability at protocol level with 2547bis. You have only exhibited a deployment model. So it needs no consensus and should not be discussed here. Marco: I agree with Eric, draft doesn't seem to have protocol impact. Need to see now which is support from SPs and debate on the list on possible protocol impacts. Further, we could evaluate interest in progress as informational. Rahul: If people want to do this on 2547bis, pass a default route between CE and PE. This is deployment issue, and shouldn't be taken up by WG. ---- 4. Michael Behringer - MPLS VPN Import/Export Verification ---------------------------------------- ------------------------------------------------ This draft addresses Route Target misconfiguration prevention for 2547bis. Ron Bonica's draft was compared. Michael's draft does not require CE to participate, and does not allow verification by site, and requires routing from CE-PE. Not sure how sensible this is. ??: this is to prevent misconfiguration by SP. Is this enough justification to do this work? Michael - agree Alex: asked technical questions on the draft. Admitted he needs to read the draft to clarify. Marco: We should work with Bonica draft and security framework team. Also look for solutions that are not specific to 2547bis. ??: The potential attraction is to not require change on CEs. It may not be the best solution, but it is a viable solution. ----- 5. Vach Kompella - VPLS draft (draft-lasserre-vkompella) ---------------------------------------- ------------------------------------------ Vach discussed the history and recent updates on this draft. He also mentioned that there are live deployments and several trials, interoperability between 6 vendors. Request this to be a WG draft (been around long enough) Marco: extensive debate should be on mailing list. Support can be registered here, but to be considered that not all of the solutions drafts have a slot in agenda today. Vach: Didn't ask the other guys not to present at the meeting. Rahul: Why did VC type change? Vach: To show that behavior of pseudo wire is the same as the ethernet pseudo wire. Continue to discuss on mailing list. May be FEC type. Juha: Use application ID in L2TP. Vach: It's the same as that, but doesn't do L2TP. Eric: this is an MPLS specific solution. Could generalize several things. the fact that it has been around 2 years, and not been done yet. Vach: Should we not have a separate l2tp specific document? Eric: Doesn't make sense to have 2 documents that are 90% the same. Vach: propose to use a generic VPN ID TLV, instead of using VC ID. It is not fair to say we haven't considered this. We need a wider audience to participate. Marco: This further shows the need to discuss this on the list. But don't prolong the discussion too much. Alex: For a document to become a WG draft, it doesn't have to be 100% correct. It can become a WG document if it is a good start. Matt: I wanted to make the same comment. Rahul: to carry on what Eric said, the arguments should be applied to the entire L2 space (autodiscovery etc.). Marco: that's actually why functional documents were recommended in Atlanta. Rahul: I don't want functional documents, want it as a piece of solutions documents. Marco: If people commit this work within a targeted time, let's have it. Alex: When a document becomes a WG draft, it should be easier to have authors introduce changes to it. Because once it becomes a WG draft, the author becomes an editor. Marco: asked for show of hands to make this a wG draft. Strong interest was shown in room. Further discussion on the list. Vach informed having some overview slides on last ISOCORE Interoperability tests (Rajiv Papneja) : Will be submitted later for discussion on the list. ---- 6. Vasile Radoaca - GVPLS/LPE ----------------------------------------------- Vasile described the history of this document, and explained the characteristics of the GVPLS model. Future steps include convergence with rosen signaling document, integrate qos and resiliency, enhance oam capabilities, convergence with vpls. Rahul: want to clarify if this is not in opposition to the hierarchical VPLS text in Eric's document. Vasile: Convergence can be done pretty easily. Ali: Given that you use two sets of pseudowire, there is a chance of packet reordering. Would like to see some discussion on that. ----- 7. Cheng-Yin Lee - Hybrid Virtual Private LAN ---------------------------------------- ------------------------- Cheng-Yin described the draft. Ali: pseudowire doesn't have bridging. Cheng Yin: CLE can consider one VPL. Use spanning tree across core. Ali: Scalability of spanning tree over SP core is an issue. Eric: This should not be taken up. Cheng Yin: more scalable appproach. Marco: take it to the list. ----- 8. Juha Heinanen - Radius-based Discovery ---------------------------------------- ------------------------ Motivation - BGP-free VPN discovery and Wide support for RADIUS in current equipment. This also works in multi-provider cases. Juha explained the working of Radius-based discovery. Juha: IS there interest in working on this. would need co-authors. Room showed great interest. ---- 9. Experimental vs standard track discussion ---------------------------------------- ------------------------- Marco: For l2 solutions, how many people support them being proposed as experimental solutions (to allow deployment and feedback from the field). Just recall that most of team members (team includes the authors of main solution drafts) favoured the experimental option, but the whole WG has to express his view. To also note that one essential difference between experimental and standard track is that experimental docs cannot be normative references. Vach: As I remember, if there is no consensus around a particular solution, then take the solutions that are gaining momentum and make them experimental. If there is only one solution, no point in making that experimental. Alex: No such thing as a "design team decision". This should be taken up with the WG. Marco : Agreed. WG discussion is requested for this reason. Kireeti: I'd like to disagree with my brother :-). (Ananth's note : but went on to say the same thing as Vach said). Eric : That's been the problem with the design team. We come to some consensus within the DT, and then people individually remember differently. Alex : Requirements for experimental RFCs are clear in RFC 2026. I'd like to move forward with this and want to resolve it before next meeting. If this means an interim meeting of wG, let's do it. Kireeti: Agree with Eric on disagreement of Design Team. So let's pretend the Design team never happened. So let's run the idea of experimental by the WG, and progress all as experimental. Wait for some time to see which become adopted (2 or 3). Vach: The point of "not remembering that the design team decided this" was to exactly bring home the issue that there is disagreement within design team. So to reiterate, let's see if there is consensus on one approach, else we can have experimental. Alex: One missing point is that the WG should decide this. Marco: discussion on the list. ----- Time ran over and other presentations were continued beyond 1500 hrs (good attendance) 10. Fabio Chiussi - PPVPN QoS Framework (draft-chiussi and draft-declercq) ---------------------------------------- -------------------- --------------------------------------------------- Fabio described changes and updates on draft-chiussi. Content still needs to be refocused, reorganized and expanded. The next steps are to make the draft more readable (short), merge with draft-declercq-ppvpn-l3vpn-qos, address ppvpn-specific restoration, inter-AS QoS etc. Fabio went ahead and presented Jeremy's draft. The goal of both drafts after merging is to have a PPVPN QoS framework reference document for other QoS drafts defining solutions/QoS signaling extensions, QoS MIBs, etc. Mustafa Aissaoui: question about combining of 2 drafts, because the first draft talked about issues and guidelines for QoS, while Jeremy's draft separates guidelines from issues. Fabio: The merge plan is to keep the guidelines section, and the framework to be merged with Jeremy's draft (keep best of both). Dave McDysan: where does QoS framework document fit in charter? Propose merging necessary material in solutions documents. Marco : One of the issues with merging into existing basic solution documents (L3 solutions drafts) is the issue of extending the documents and therefore affect timeline. But we need to have WG's view on the list. ---- 11. Luyuan Fang - Security Framework for PPVPN ---------------------------------------- --------------------------------- Luyuan presented the draft and said Jeremy would be added to the authors' team in the next version. Luyuan described that there were different security levels expected in different PPVPN services. Therefore this framework gives guidelines for different implementation technologies. Ananth - suggest adding requirements to generic requirement draft and have the security features of each approach be described in applicability statements. --- Marco: we need to close here. Basic objective of presentations on frameworks was to stimulate input from the WG, to be continued on the list. All presentations will be available on the PPVPN informal server. |