Current Meeting Report
Slides


2.7.4 Provider Provisioned Virtual Private Networks (ppvpn)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/13/2002

Chair(s):
Rick Wilder <rwilder@masergy.com>
Marco Carugi <marco.carugi@francetelecom.com>
Sub-IP Area Director(s):
Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>
Sub-IP Area Advisor:
Scott Bradner <sob@harvard.edu>
Technical Advisor(s):
Alex Zinin <rcoltun@movaz.com>
Mailing Lists:
General Discussion: ppvpn@ppvpn.francetelecom.com
To Subscribe: sympa@ppvpn.francetelecom.com with
In Body: (UN)SUBSCRIBE ppvpn in message body
Archive: http://ppvpn.francetelecom.com
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
Internet-Drafts:
  • - draft-ietf-ppvpn-requirements-04.txt
  • - draft-ietf-ppvpn-framework-05.txt
  • - draft-kuwahara-cl-tunneling-vpn-00.txt
  • - draft-ietf-ppvpn-rfc2547bis-01.txt
  • - draft-ietf-ppvpn-ipsec-2547-01.txt
  • - draft-ietf-ppvpn-gre-ip-2547-01.txt
  • - draft-ietf-ppvpn-mpls-vpn-mib-04.txt
  • - draft-ietf-ppvpn-bgpvpn-auto-02.txt
  • - draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt
  • - draft-ietf-ppvpn-vpn-vr-03.txt
  • - draft-ietf-ppvpn-ce-based-02.txt
  • - draft-ietf-ppvpn-vr-mib-02.txt
  • - draft-ietf-ppvpn-tc-mib-01.txt
  • - draft-ietf-ppvpn-vpls-requirements-00.txt
  • - draft-ietf-ppvpn-as2547-00.txt
  • - draft-ietf-ppvpn-applicability-guidelines-00.txt
  • No Request For Comments

    Current Meeting Report


    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.


    Slides

    Agenda
    L2- VPN DT Report
    Requirements for Layer 2 VPN Services
    Ethernet OAM Update
    CE-to-CE Authentication for Layer 3 VPNs
    CE-based Virtual Private LAN
    Protocol actions required for BGP/MPLS VPNs (rfc2547bis)
    Framework for QoS in Provider Provisioned VPNs
    An Architecture for PPVPNetworks using IPsec
    DNS/L2TP Based VPLS
    Protocol actions - VR-based PPVPNs
    Layer 3 solution-specific Applicability Statements
    VPLS Solution using GRE
    VPLS-Discover
    Scalable Connectionless Tunneling Architecture and Protocols for VPNs
    HVPLS OAM
    Tuesday - Agenda
    CE-Based Virutal Private Lan