Current Meeting Report
Slides
Jabber Logs


2.7.6 Provider Provisioned Virtual Private Networks (ppvpn)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 07/15/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 <zinin@psg.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-02.txt
  • - draft-ietf-ppvpn-ipsec-2547-02.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
  • - draft-ietf-ppvpn-l2-framework-00.txt
  • - draft-ietf-ppvpn-as-vr-00.txt
  • - draft-ietf-ppvpn-l3vpn-auth-00.txt
  • No Request For Comments

    Current Meeting Report

    PPVPN WG meeting at 55th IETF, Atlanta, GA - Nov 20, 2002
    
    Minutes recorded by Ananth Nagarajan  (few additions/changes by  Marco 
    Carugi)
    
    Marco started with introducing the agenda. Meeting related documents will be 
    posted on Nortel-maintained web site.
    
    1. WG status
    ------------
    
    Milestones have been recently updated. Layer 3 reqts and framework have 
    been submitted to IESG. We are now at second round of comments, before they 
    move towards Informational RFC.
    
    L3 approaches and applicability statements : submission to IESG for 
    publication will be hopefully started in December.
    
    Marco also described the status of various documents (these updates have 
    been sent to the mailing list).
    
    Last call on 
    draft-ietf-ppvpn-cl-tunneling-vpn-00.txt not successful. 
    Solicited input on whether this should be progressed in the WG. Little 
    support, but most didn't care.
    
    Scott - Lack of strong opposition does not mean support.
    
    Under WG consideration - generic requirements, l2vpn requirements, vpn 
    DNS-based discovery documents, terminology and metrics.
    
    Kireeti - Move to WG - does it mean that it is moved to WG status? If so, it 
    needs call for consensus.
    Marco - yes, the normal process will be followed.
    
    Scott - CL tunneling:  Is there support for publishing this as a 
    informational RFC, as opposed to BCP? ASk for consensus on BCP RFC, Info RFC 
    or is against publication?
    Yakov - BCP means best current practice. Since it is neither, there 
    should be no such option.
    Scott - Disagreed.
    
    Consensus - support from authors for info RFC. None for BCP. About 10 
    people against publication. A lot of agnostics.
    Decision - need more discussion on mailing list.
    
    Scott - IESG has enough info to take this off the WG agenda.
    
    WG last call for 
    draft-nagarajan-ppvpn-generic-reqts after it becomes a WG ID, to be done by 
    end of 2002.
    
    Conditional to IESG approval of L3 reqts and framework, 2547bis and VR 
    approaches to be advanced to Proposed standard.  Protocol 
    dependencies to be solved and submitted in parallel, together with 
    applicability statements.
    
    Other 2547-based solution documents, VR extensions, L3 
    solution-specific MIBs etc will be advanced in reasonable timing.
    
    CE-based IPsec solution has not been updated since Yokohama, along with 
    corresponding AS.  Would like to progress this quickly.
    
    Design teams:
    Requirements team task on generic requirements and improvement of L3 and L2 
    requirements is being done.
    
    Some issues: Cooperation terms with IEEE 802.1 need to be figured out.  
    Interaction with related WGs in IETF needs to be done for PPVPN, 
    independently from whether sub-ip area survives or not.  Layer 2 
    interworking for like-to-like is ok, while any-to-any is not currently ok 
    (out of scope), apart from possible specific scenarios.
    
    Other work to be progressed includes QoS, management, security 
    framework, multicast etc. for PPVPNs. Input from community is 
    solicited.
    
    Liaison received from ITU-T on L1 VPNs was discussed.
    
    
    2. Generic Requirements - Ananth Nagarajan
    
    -------------------------------------------
    
    Ananth described the generic requirements draft and solicited input, 
    especially for the scalability section.  Loa talked about the 
    terminology draft that is being simultaneously developed.  There was a word 
    of caution on the way this terminology draft would be progressed 
    separately, as it would create problems for proposed solutions if they 
    don't comply wih this.
    
    Request acceptance of generic requirements as WG draft. 
    General consensus was for this acceptance.
    
    3. CE-CE Authentication - Ron Bonica
    -----------------------------------
    
    Ron made a short presentation on main issues related to this work.
    
    Process considerations - need BGP extended community type. Need UDP port 
    number for new protocol.
    Vach expressed a procedural concern about whether PPVPN can do 
    protocols.
    
    
    4. CE autoconfiguration for CE-based PPVPN - Cheng Yin Lee
    
    ----------------------------------------------------------
    
    Cheng Yin described the draft.
    
    Issues - is being able to push/update necessary? Is polling 
    sufficient? 
    Combining polling with receive-trigger-then-pull or push approach may be a 
    good compromise (may then reduce polling interval)?
    
    5. IPsec protected Virtual Links for PPVPNs - Mark Duffy
    
    --------------------------------------------------------
    
    Virtual Link - point to point link across IP network implemented via 
    tunneling. This is envisioned for CE-based and PE-based vR solutions. This 
    can also be done between CE and PE.  It is also useful for 2547, and 
    hybrid networks for securing links between PEs running 2547 and VR.
    
    Requirements - multi-context support (multiple virtual links between a 
    given pair of systems).
    
    Eric - Does it make sense to have one security association for all vpns, as 
    opposed to separate associations for different vpns.
    Mark - Yes.
    
    Why this is needed? Current efforts don't address the multi context needs of 
    network based VPNs.
    Issues : How does IPsec policy fit where forwarding decisions are made by 
    best-matched prefix?  How should VPN-ID like context be conveyed when a 
    tunnel is established.
    
    Draft describes various approaches using combinations of either IPsec 
    tunnel mode or IPsec transport mode with other tunneling schemes.
    
    Applicability to ppvpn - standards-based virtual links for adequate 
    security for interoperability between approaches.
    
    Eric - There is already a draft on IPsec with 2547. Why is this 
    different?
    Mark - this is not objecting to that draft, but that is specific to 2547 
    context. This is more generic.
    
    Marco - Is this mandatory before progressing VR? Or is it 
    complementary?
    Mark - There is no mechanism defined today for securing VR tunnels. If you 
    simply say "use IPsec tunneling between VRs", everyone will be doing it in a 
    different way.
    
    Marco - Need further discussion on this.
    Mark - There is no alternative available in current drafts.
    
    Yu-cheng Ren (ISI) - This topic has been addressed by various drafts.  Why do 
    we need another (e.g. draft-touch, draft-knight).
    Mark - these drafts talk about using ipsec tunnels, but doesn't talk about 
    securing multiple links.
    One of the authors of draft-touch - this is not the case. It talks about 
    ip-in-ip draft.
    Yu-cheng - Nothing against this draft. Can this not be integrated into 
    framework or requirements drafts?
    Mark - some part of this can be added. Need discussion on what needs to be 
    included.
    
    6. Use of multiple instance OSPF for PE-CE - Kunihiro Ishiguro
    
    ----------------------------------------
    ----------------------
    
    Kunihiro presented this draft - "simple way to use ospf for ce-pe".
    Procedure - Assign OSPF instance to VRF.
    
    Benefit - much simpler, can coexist with ospf configurations, and can be 
    applied to is-is.
    
    This draft complements Rosen draft 
    (draft-rosen-vpns-ospf-bgp-mpls-05.txt) and overlaps a little bit.
    
    Eric - Don't need different procedures to do the same thing. Hoped this 
    would eliminate complicated things in existing mechanisms.
    
    7. L2 VPN design team report - Loa Andersson and others
    
    ---------------------------------------------
    
    Documents - metrics, terminology, framework (not much work done on these 
    three). L2vpn requirements - significant progress. There was a design team 
    debate on emulated LANs versus bridges.
    
    The design team has 22 members, plus several others who contributed that are 
    not on the team.  Recommend that design team structure be 
    discontinued and work be continued separately.
    
    Requirements - Yetik Serbest
    ------------
    
    Status - evolving towards common l2vpn requirements (as opposed to 
    individual requirements for vpws, vpls etc.)
    Aligned with generic requirements draft, definitions moved to 
    terminology draft, sections added on referencing generic reqts, 
    addressing, network resource partitioning/sharing, access control, 
    interoperability.
    
    Future work - clarify any issues with what a vpls is, and what it does, and 
    clarify vlans in vpls.  Also request feedback.
    
    Request moving it to WG status.
    
    Loa: The document has a "point-to-multipoint" VPWS, which is wrong and 
    needs to be removed.
    A: Agreed.
    
    Cheng Yin: Is VPLS emulating a bridge or LAN?
    Yetik - wait for Eric's presentation.
    
    Architectural Model - Eric Rosen
    --------------------------------
    
    Eric described the architectural model, and addressed points of 
    disagreement between IETF and IEEE people, and 
    inter-relationships between VPLS and IEEE bridge/LAN emulation.
    
    Other issues - Spanning tree, presumed LAN properties including packet 
    order preservation, reliability, non-duplication, low latency.
    
    Loa - Nice powerpointing picture will be converted to ASCII art and used in 
    requirements and framework drafts.
    
    Issues of VPLS - Muneyoshi Suzuki
    ---------------------------------
    Muneyoshi discussed issues related to customer views, provider views, vpls 
    support etc, routing for LAN/bridge emulation.
    
    Norm Finn - IEEE 802.1 unofficial liaison
    
    -----------------------------------------
    
    Project authorization request (amendment to 802.1q VLANs) - enable a SP to 
    offer the equivalent of separate LAN segments, bridged or virtual 
    bridged LANs (network of bridges doing l2vpn type services).
    
    Name of project - 802.1AD.
    MAC-in-MAC not possible with this amendment.
    
    Confident that IETF L2vpn and 802.1AD will be interoperable, 
    compatible etc if mailing discussions are carried through.
    
    Q: how to solve MTU in 802.3 problem?
    A: Make it longer. This is possible.
    
    Cheng Yin - There should be minimum of overlap with vpls and IEEE work.  But 
    there will be overlap as IEEE defines Q-in-Q and IETF defines other 
    encapsulation.
    A: Outer Q tag can be used as Pseudowire header. So there won't be a 
    problem.
    This is exactly VPLS - just a different way of looking at it.
    
    Marco - intention from both sides to minimize overlap.
    
    Vach - there is no standard q-in-q way to identify customer packets.  What 
    the IEEE is doing in standardizing this may be a good thing.
    
    
    8. CE-based Virtual PRivate LAN - Cheng Yin LEe
    
    ----------------------------------------------
    
    Previous version described use of l2tpv3 for this application. l2tpv3 
    signaling and tunneling will be taken to l2tpext WG.
    
    This model describes the transport of Ethernet over IP tunnels 
    (CE-based).
    
    Future work includes failure scenarios, monitoring of vpl 
    connectivity and other l2tpv3 specifications to be done in l2tpext WG.
    
    Eric Rosen - Why not IPsec as it is CE-based?  Why do use l2tpv3?
    Cheng Yin - No protocol number for use of ipsec.
    
    9. Identify PW endpoints signaling - Eric Rosen
    
    -----------------------------------------------
    
    It is possible that PWE3 owns the signaling portion. l2vpn can be built 
    over pwe3 pseudowires.
    
    Problem statement: L2vpn has various autodiscovery. Martini signaling 
    presupposed provisioning models. This solution identifies ways to use 
    martini signaling and make it more applicable to l2vpn.
    
    Forwarders will be identified by vpn-id.
    
    Eric described various techniques (e.g. Distributed VPLS, VPWS full mesh, 
    switched connection i.e., ATM SVCs to pseudowires).
    
    RAhul Aggarwal - Support this as it solves real issues with martini 
    approaches.
    Marco - need clarification from ADs about this space, and where this needs to 
    be done.
    Eric - Some of these also apply to l2tp signaling, in addition to 
    martini
    
    Yakov - Can you use the form of identification used by the Route Target BGP 
    Extended Community
    Eric - yes.
    Hamid - suggested to use global unique identifiers instead of VPN-IDs
    Marco - Global ID issues need to be taken to list.
    
    
    10. Scalability issues with VPLS - Andrew Sodder
    
    ------------------------------------------------
    This draft has various parts, one part belonging to ieee (mac in mac), 
    other parts to ietf.
    The draft also proposes vpn identifier and control word use.
    
    Many issues left to be addressed - vpls interoperabilty, oam ID work to be 
    done in IEEE.
    
    Request continued discussion on list.
    
    Rahul Aggarwal - Don't understand motivation for the draft. There is no 
    scaling issue with current mechanisms. This draft request changes to wire 
    format, and requires changes to hardware.
    A: Depends on who you talk to.
    Rahul: Depends on which specific vendor box you are talking about.
    
    11. GVPLS/LPE - Dinesh Mohan 
    -----------------------------
    Goal - support seamless integration of both distributed and 
    non-distributed vpls models. Allow integration of different access 
    topologies, in a hierarchical way.
    
    Other objectives - scalability and performance, optimizaton of 
    replication and support for multicast applications, 
    interoperability with other vpls solutions, integrated oam capability in 
    data plane.
    
    The complementary 
    draft-chen-ppvpn-dvpls-compare-01.txt describes comparisons of vpls 
    approaches. Andersson's metrics draft was also mentioned.
    
    Future steps - convergence with solutions drafts, signaling, 
    QoS/resiliency, enhance oam capabilities.
    
    Marco - comparison draft and metrics draft should be used by the design 
    team.
    
    12. VPLS based on IP multicast - Ali Sajassi
    
    ----------------------------------------------
    
    Multicast, if supported on backbone, can be leveraged for vpls.
    mp2p PW for unicast and mp2mp PW for multicast is proposed.
    
    Encapsulation is GRE or l2tpv3. pw signaling is not needed.
    Issues - packet reordering may occur.  Inter AS and IP address 
    management.
    
    Sasha Vainshtein - PPVPN scalability parameters in requirements draft not 
    enough for feasability of this draft. Also, all routers in provider core 
    would need to learn routes to all these addresses.  Text of the draft 
    doesn't say how unicast addresses are treated by the device 
    (pingable, or something else).
    A: RFC 1918 specifies private address space. This scheme can be used in 
    hierarchical way (access, core etc.) and thus may tackle scaling issues. 
    Regarding router issues, these can be taken to the list.
    
    Eric - VPLS depending on IP multicast sounds foolish.  learning based on 
    source address is also not a good idea (fragile).
    A: Discussion on list
    
    Juha - One of the requirements is operability in multi provider 
    environment. 
      Multicast may not be stable in this scenario.  We need to take that 
    requirement into account.
    
    13. L2VPN Interworking - Ali Sajassi
    -------------------------------------
    
    Local attachment circuit termination proposed for various attachment 
    circuit types including ATM, ip, ppp, multiprotocol. Need two new PW types 
    for IP and multiprotocol.
    
    Rahul - It may be useful to consider the idea of a "raw" pseudowire that can 
    be used for multiprotocol case.
    Ali - wouldn't apply for multiprotocol, as it needs 
    identification of protocol.
    
    Scott - Interworking out of scope of, when sub-ip was set up.
    Ali - purpose is not to reinvent the wheel. Just suggesting what 
    pseudowire to use.
    Marco - Scott, should this continue to be discussed in the Working group.
    Scott - if it is restated as it was by Ali, it can be done.
    
    14. Summary - Marco
    -------------------
    
    In Yokohama, it was agreed to propose solutions based on functional 
    structure proposed in L2 solutions design team.  Next work steps on L2 were 
    discussed.  Functional decomposition of l2 is strongly recommended. No 
    protocol development in ppvpn.  Limited set of solutions, so it is not 
    recommended to progress "all theoretically possible solutions". So we need to 
    determine a pragmatic set of alternatives.
    
    Main functional blocks identified by DT (various options per block)
    - discovery, signaling, pw tunneling/data plane forwarding, 
    informational model.  
    Therefore, the functional documents should have a requirements section, 
    option specification section(s), a section on interactions with other 
    functions.
    
    Possible organization of deliverables :
    - N documents per each functional block, one per option
    - one doc per each functional block (N option-specific sections).
    
    A number of mono-option documents is almost done.
    
    Different solutions using same option for a specific function should rely on 
    the same functional document.
    
    Aggressive plan for L2 DT is to have a DT meeting in January 2003 (1-2 
    days). Tasks to be completed were identified.
    
    It is possible to have another design team (in addition to this one) 
    before the next IETF meeting.
    

    Slides

    Agenda
    Issues of VPLS
    CE Auto-Config for Provider Provisioned CE-based VPN
    CE-based Virtual Private LAN
    CE-to-CE Authentication for Layer 3 VPNs
    Requirements For Layer 2 VPN Services
    Multi-Protocol Encapsulation Over MPLS
    L2VPN Interworking
    VPLS based on IP Multicast
    IPsec-Protected Virtual Links for PPVPNs
    Generic Requirements for PPVPN
    GVPLS/LPE - Generic VPLS Solution based on LPE Framework
    'draft-sodder-ppvpn-vhls-00'
    IP over LAN Services
    L2VPN Design Team Report
    Use of Multiple Instance OSPF for PE-CE
    Signaling: Identifying PW Endpoints
    VPLS Architecture Model