Provider Provisioned Virtual Private Networks WG (ppvpn) Thursday, March 21 at 0900-1130 ================================ CHAIRS: Marco Carugi marco.carugi@francetelecom.com Rick Wilder rwilder@masergy.com Minutes recorded by Ananth Nagarajan (ananth.nagarajan@mail.sprint.com) These minutes and all presentations will be available (soon) at http://ppvpn.francetelecom.com 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 draft-sumimoto-ppvpn-applicability-guidelines-02.txt 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 draft-rosen-ppvpn-as2547-00.txt draft-nagarajan-ppvpn-vrbased-applicability-00.txt draft-declercq-ppvpn-ce-based-as-00.txt 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 draft-knight-ppvpn-ipsec-dynroute-00.txt 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 draft-bonica-l3vpn-auth-02.txt 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) draft-andersson-ppvpn-metrics-00.txt draft-andersson-ppvpn-terminology-00.txt 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 http://62.119.0.68/~loa/slide.pdf 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 draft-sajassi-vpls-architectures-00.txt 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 draft-senevirathne-vmi-frame-02.txt 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 draft-shah-ppvpn-arp-mediation-00.txt 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 draft-shah-ppvpn-vpls-pe-mtu-signaling.txt 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 draft-lau-ppvpn-qos-tls-mpls-00.txt 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 draft-ooms-ppvpn-mcast-overview-00.txt 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 draft-mroz-ppvpn-inter-as-lsps-00.txt 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. Thanks. ---Adjourn---