2.7.5 Provider Provisioned Virtual Private Networks (ppvpn)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-03-04

Chair(s):
Rick Wilder <rwilder@masergy.com>
Marco Carugi <marco.carugi@nortelnetworks.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 <zinin@psg.com>
Mailing Lists:
General Discussion: ppvpn@nortelnetworks.com
To Subscribe: lyris@nortelnetworks.com
In Body: (UN)SUBSCRIBE ppvpn in message body
Archive: http://standards.nortelnetworks.com/ppvpn/index.htm
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  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
Internet-Drafts:
  • - draft-ietf-ppvpn-requirements-05.txt
  • - draft-ietf-ppvpn-framework-07.txt
  • - draft-ietf-ppvpn-ce-based-03.txt
  • - draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt
  • - draft-ietf-ppvpn-mpls-vpn-mib-05.txt
  • - draft-ietf-ppvpn-rfc2547bis-03.txt
  • - draft-ietf-ppvpn-ipsec-2547-03.txt
  • - draft-ietf-ppvpn-bgpvpn-auto-03.txt
  • - draft-ietf-ppvpn-vpn-vr-03.txt
  • - draft-ietf-ppvpn-vr-mib-04.txt
  • - draft-ietf-ppvpn-tc-mib-02.txt
  • - draft-ietf-ppvpn-vpls-requirements-01.txt
  • - draft-ietf-ppvpn-as2547-01.txt
  • - draft-ietf-ppvpn-applicability-guidelines-01.txt
  • - draft-ietf-ppvpn-l2-framework-03.txt
  • - draft-ietf-ppvpn-as-vr-01.txt
  • - draft-ietf-ppvpn-l3vpn-auth-03.txt
  • - draft-ietf-ppvpn-generic-reqts-02.txt
  • No Request For Comments

    Current Meeting Report

    
    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.
    
    
    

    Slides

    PPVPN WG status
    MPLS VPN Import/Export Verification
    Hierarchical VPLS
    PPVPN QoS
    Security Framework for Provider Provisioned Virtual Private Networks
    Radius Based VPN Discovery
    Hierarchy of Provider Edge Devices in BGP/MPLS VPN
    Hybrid Virtual Private LAN
    PPVPN Management and Operation
    GVPLS/LPE - Generic VPLS Solution based on LPE Framework Update version 01
    Signaling Tunnel Encapsulation Capabilities
    CE - Based L3 PPVPN's Progress