PPVPN meeting - 54th IETF, July 16, 2002 - Yokohama, Japan ---------------------------------------------------------- Minutes recorded by Ananth Nagarajan 1. Agenda bashing, status update: Marco introduced the agenda and gave a status update of various WG drafts. Other co-chair, Rick Wilder, unable to make it to meeting. Marco explained that the current mailing list does not control spam very well and has the problem of automatic replies to the sender. 2. Scott Bradner and Alex Zinin - AD message IESG had a lot of discussions on work in this WG, especially L2VPN. There is concern about getting solutions before requirements. IESG would like to see clean and clear requirements before deciding to change routing protocols. There is concern about using routing protocols (BGP) for VPNs as they are supposed only to distribute routes and not "other things". Not precluding the use of routing protocols if it is justified, but need to clarify requirements and be high level - without focusing on a particular type (l2 or l3) vpns. IESG does not want the concern about routing protocols to affect any decisions on 2547bis - it is on the charter and it won't be blocked, but discussions will be had. Alex Zinin joked about using BGP extensions for distributing DNS extensions, and wanted to get coauthors by April 1. Alex said that one must do a detailed analysis before deciding on BGP. Kireeti - can we use BGP for routing Scott - yes Vach - are there any problems using LDP? Alex - solution has to be scalable, irrespective of mechanism. Scott - requirements need to be clear and clean. Valdemar - Understand concerns about bgp. Are you saying that the current requirements suggest use of BGP? Scott - nothing specific in requirements, but l2vpn uses it. Loa - What has not been done properly is problem discussion. This needs to be done before deciding which protocol to use. Scott - how to deal with overlapping private addresses? These kind of problems need to be explored before deciding how to distribute information. Marco - summarizing - we had a discussion with ADs and L2 team. We will not work on solutions right now as WG documents. We will realign solutions with revised requirements. 3. Marco - WG update Marco described milestones. There is some delay because of recent IESG directions on requirements and framework. First comments on these documents from IESG have been received. Milestones will be updated after the meeting. First comments on L3 requirements from IESG - MUST/SHOULD/MAY should be normalized - Provide or enhanace existing reqts for VPN membership discovery, Internet transparency, routing scalaibility and stability, address overlapping management. - The document seems to be biased towards PE-based solutions (versus CE-based). This could be just a wording problem. Since SPs wrote this, there is no intention to be biased. - PE-based scenario seems to favor a particular solution. This also is not intentional. WG documents - reqts and framework have been sent to IESG for review. AS documents are in progress for Layer 3 (2547bis and VR). Expired WG documents include draft-ietf-ppvpn-l2vpn-00.txt that has been merged into L2 framework, and Core VPN (RFC 2917) based work. CE-based solution document is being evolved. Other WG documents are expected according to work in the L2 space per Marco's "pragmatic proposal" on the mailing list. No progress is expected in the L2 (vertical) solutions, as it needs to be aligned with requirements. It is possible to include draft-bonica-l3vpn-auth as WG draft after discussions. Marco described the design team status. There was an issue with low participation of some members in the L2 space. Marco asked for active commitment to participate in design teams. PPVPN service requirements team is reactivated - including SPs from the original L3 team as well as other SPs. According to IESG comments, an umbrella reqts document (common to l3 and l2) will be developed. Improved specific L3 and L2 reqts will be developed and protocol requirements for analysis of l2 solution space will be done. The current L2 metrics draft will be enhanced. The initial target for design team output is September 10, 2002. Framework team will be progressed per IESG comments. L3 AS team work is in progress. Discovery team has been closed. No plan for official design team related to the CE-based IPSec work. Marco described a proposal for L2 design team: No official team for Ex-L2 solutions and vpls reqts teams. Objectives include: - improvement of L2 framework (Loa editor) - classification of various L2 drafts - restructure the L2 vertical solutions based on functional decomposition (e.g signaling, discovery etc.) After Sep 10 and before Atlanta deadline, consider reqts, improve vertical solutions and produce a list of L2 candidate vertical solutions. Progress each AS in parallel. Current L2 solutions are in VPWS, VPLS (IPLS) spaces. Regarding martini-trans draft, this will be kept in PWE3, as per Scott's advice, for the time being. But all VPN-related functions will be discussed in ppvpn. Need strong cooperation between ppvpn and pwe3 in order to progress in parallel. Marco also described L3 solutions and AS status and possible future review according to revised requirements. CE-based solution space schedule needs to be discussed. Some issues for future progress are terminology, vpn-id, L2 IPLS, L2 interworking, multicast, QoS, management, security framework. Finally, Marco described the ITU-T joint Q11/13-Q12/15-Q14/15 meeting and the successive Q11/13 meeting to discuss L1/Optical VPNs. Progress expected in October 02 includes a first version of a new draft Recommendation. IETF people are invited to contribute. 4. L3 Applicability Statements - Ananth Nagarajan Ananth gave an update on L3 guidelines draft, 2547bis and VR ASs. CE-based AS will be described by Jeremy. 2547 and VR ASs accepted as WG drafts. VR AS needs to be resubmitted as WG draft. Guidelines draft has also been accepted as WG document, but needs to be update to reflect revised requirements 5. L3 solutions space - Jeremy De Clercq/Paul Knight Jeremy described the solutions in the L3 space, including 2547bis and its related drafts. The main mechanism is based on BGP and extensions. Not many protocol actions needed to progress 2547bis. OSPF has also been proposed as a PE/CE protocol. No extensions on IPSec are needed. Alex - are we going to see the OSPF draft in the ospf working group? Marco - yes, this will be done. Will also progress the other OSPF draft to PPVPN WG doc soon. Vach - Does anything go coupled with 2547? Scott - 2547 is not a "get-out-of-jail" card. Need "cover letter" to OSPF group to describe the problem that is being solved and determine if OSPG wg is in agreement. Alex - Any individual contribution that use a particular specification has to go through the WG that owns the specification. Paul Knight described the VR-based ppvpn. The key requirement is to exchange vpn id between VRs : it can be done for auto configuration (not needed if configuration done by network management), auto discovery can do this using bgp. The proposal is to work with IPSec WG to determine IPSec-based exchange of VPN-Id. Marco - A draft similar to that produced for 2547bis (draft-rosen-ppvpn-2547bis-protocol-00.txt) should be written. Jeremy then continued to described the CE-based space. The work "framework" has been replaced by "architecture" to clarify that this is a solution draft. Recent mailing discussions raised some issues that need to be clarified in updates. These include clarity on management of CE, addressing, CE address and core routing, access, interoperability, server-based configuration model etc. Next steps include turning this to solution draft. Can't comment on timeframes right now. Regarding CE-based AS draft - the structure has been aligned with 2547bis AS. comments that need to be addressed include the case where the SP is not the Network Provider, mixed customer/provider management, scalability of PKI. This draft will also continue to go parallel with the CE-based solution draft. Jeremy also described the draft on CE-autoconfiguration draft. 6. Address allocation for PE/CE links for 2547bis - Wang Reina (draft-guichard-pe-ce-addr-00.txt) This proposal supports "certain types" of VPN customers, only on 2547bis. It is proposed to IANA to allocate an IPv4 globallly unique address block for exclusive use by SPs that provide L3VPN services. Scott - The likelihood of setting aside a /8 for VPN providers is close to zero. Joe Touch - What does this try to do that is not solved by RFC 1918 or by global assignment per VPN? A - 50k CE endpoints currently can't be handled. Joe Touch - You need to look at alternate architectures Ross Callon - You are proposing these separate addresses for PE-CE links only? A. Yes. (to be discussed further) 7. CE-to-CE authentication for L3 VPNs - Ron Bonica The draft has been updated for generality to include other L3 VPNs (in addition to 2547bis). Implementers are waiting for BGP extended community attribute assignment from IANA. Next steps include implementation and operational experience and suggest accepting as WG draft. Scott - Need to specify what WG charter reqt this satisfies in order to progress as WG draft. Ron - Will see what it satisfies. 8. Scalable connectionless tunneling architecture and protocols for VPNs - Muneyoshi Suzuki. The draft specifies a connectionless architecture for PE-based L3 VPNs. This uses a connectionless hub and spoke topology and specifies a new protocol called CTCP. Muneyoshi described the draft in detail. Proposal : publish as proposed standard RFC. Marco - Apart from issue resolution, need to discuss whether this should be an informational or proposed standard RFC. This has to be clarified with ADs and IESG. 9. L2 space - Valdemar Augustyn L2 VPLS requirements draft has received comments. Valdemar described these comments and the plans to address these. The document is stable, but not complete. Need input from SPs and others. Future steps include enhancing the structure of the draft, specifically functions like signaling and discovery. Would like to close this draft soon. Marco - Terminology inconsistencies between framework draft and this draft need to be addressed. Structure of document and other materials that didn't meet submission deadline need to be done. 10. L2VPN Design team report - Loa Andersson Four documents currently (l2vpn requirements, l2 framework, l2 metrics, terminology) L2 Framework is now shorter, reorganized and has received feedback from 802.1 people on bridging capabilities. Also solicit help on security section. Asked if this should be a WG document. L2 metrics draft has made limited progress. It now has more contributors with experience. L2 terminology draft has recommended terminology and provide cross references. This is in good shape, but work will continue. Suggest that this be a WG draft too. This can be made informational, but can be withdrawn after the work is done. Marco suggests that the terminology draft needs one more pass before making it a WG draft. Loa - if we wait for everything to be solved, this will never be a WG draft. The terminology is actually well aligned. Marco - We are seeing multiple drafts with new terminology. Therefore this needs to be aligned. 11. DNS/L2TP based VPLS - Juha Heinanen Convinced that IP should be used as opposed to MPLS. This work started as DNS/LDP based, but now uses L2TP. Discovery based on DNS as described in the Luciani draft. Signaling uses L2TPv3 spec with a minor change. Data plane according to draft-so-pwe3-ethernet-01.txt. This draft is for providers that don't use MPLS. This is also "cleaner and simpler" and leverages existing work. Future work: - only allow l2tp sessions without control word for simplification - specify l2tp result codes - look at session level tie breaker - can the new vpn id avp be avoided ? - could radius be used instead of DNS ? Marco - alignment with PWE3 Juha - already there 12. VPLS Solution using GRE - Tissa Senevirathne No explicit tunnel setup is required, and relies on existing vpn discovery methods for key distribution. Suggest that today's discovery mechanisms are tied in to MPLS somehow. This proposal suggests generic discovery methods, and VPN application level OAM. Mark - Juha's proposal takes care of issues you point out. Scott - OAM point is not related. Tissa - Useful point, I believe Scott - OAM spelt differently in ITU than here. So a little fuzzy here. 13. CE-based Virtual Private LAN - Cheng Yin Lee Cheng Yin described the draft. This proposal supposedly reduces provisioning overhead, by not requiring stackable VLAN tags. It is also access technology agnostic. Cheng Yin also described some other advantages. Next steps include evaluation of other tunneling technologies and associated overhead, and selection of a small number of suitable ce auto provisioning methods. Marco - Scalability of VPLS when you add more customers is not clear Cheng Yin - New customers can be added independent of number of vlan tags available. Marco - Discussion on the list. 14. VPLS Discovery - Olen Stokes Olen described the draft. Future steps include defining additional service capabilities, adding support for qos requirements and understand how this relates with other discovery drafts. Mark Townsley - Any reason why this discovery method can't be applied to other point to point signaling protocols? Olen - no reason. 15. HVPLS OAM - Vach Kompella OAM spelt as PING [:-)] Problem statement - how does a SP monitor or debug connectiviy of HVPLS ? Answers include check transport tunnel connectivity (using LSP ping), and check VC LSP connectivity (proposal in draft). Vach continued to describe the requirements for OAM in HVPLS. Issues include how to identify a ping packet. Vach described potential solutions to this. Future steps include input from SPs on VPN testing and mailing discussions on suggested solutions and potential IPR issues. Kireeti - What is meant by impacting the fast path Vach - Customer ping packet. Kireeti - LSP ping does this. But HVPLS may have other requirements. Scott - Carriers (traditional voice carrier types) need additional stuff than ping and traceroute, as seen in MPLS case. Proposals should may be include the possibility of extensive OAM. Having a requirements document that has solutions is not strategically a good thing. These need to be separated. Overall, good stuff. Vach - Struggled with whether to use the y.1711 kind of proposal to reserve an OAM label. Didn't do that but left option open for ITU to do it. Scott - agree. People working in this area should describe extensions required, but very carefully. IETF should have control on IP extensions. Marco - Lot of work has to be done in the requirements. Good number of providers already involved in this stuff. 16. OAM work relevant for PPVPNs in other standards bodies - Mina Azad Other bodies like IEEE 802.ah(EFM), ITU, MEF etc. focus on end to end aspects of OAM, especially for Ethernet like services. MEF met last week and is working on a baseline draft. Next meeting of EFM in July-Aug in Montreal. There is an opportunity to provide input and influence directions. Marco - are these vpn over ethernet specific or more generic ethernet oam requirements Mina - more generic Dinesh - Service specific OAM aspects will be done later. Mina continued, describing ITU SG 13 and SG15 work. Ethernet OAM work has been initiated. Contributions are welcome. Q3/13 is the specific question working on OAM. Mina described the meeting schedules for ITU meetings. Marco - so summarizing, we need input from ppvpn to these other bodies to influence the work there. 17. Discussion on QoS for ppvpn - Jeremy De Clercq Jeremy described the QoS framework draft. PPVPNs have optimized scalability but not QoS. The draft covers l2 and l3 vpns, pe based and ce based, all tunneling mechanisms etc. Planned sections include scenarios for qos, automatic provisioning, signaling, scalability and advanced QoS issues. Questions for WG - is this useful? if so, is this a good start? Scott - Currently QoS is not in the charter. But this doesn't mean it shouldn't be at some point. A draft like this may be the motivation to include it in charter. Jeremy - should this be a charter item? Scott - this need not be a WG item right now, but can motivate charter update discussion. Marco - based on this we can identify specific items to improve services. Juha - QoS is supported by Diffserv. Don't need this WG to tell how to use Diffserv. It could be different for the l2 work. Scott - That's fine if all vpns have the same qos. Some extra mechanisms may be needed. Rahul Aggarwal - One thing that is not spelt out is a definition of models for mapping diffserv to exp etc. Jeremy - proposed scenarios may take care of this. Alex - QoS is important for VPN. Even if this WG doesn't specify any new mechanisms, but describes how to use the existing ones, it will be useful. Juha - mapping of ethernet priority field to DSCP is all that needs to be set. Nothing else needs to be done. How to set DSCP is up to the provider - even the Diffserv group couldn't specify this. Marco - Further discussion on list. Also, there is a management framework. This also needs to be discussed along with the QoS draft. Meeting adjourned.