2.3.12 Layer 3 Virtual Private Networks (l3vpn)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20


Rick Wilder <rick@rhwilder.net>
Ross Callon <rcallon@juniper.net>
Ronald Bonica <rbonica@juniper.net>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.com>

Technical Advisor(s):

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: l3vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l3vpn
Archive: http://www.ietf.org/mail-archive/web/l3vpn/index.html

Description of Working Group:

Alex Zinin is the routing advisor.

This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
Layer-3 (routed) Virtual Private Networks (L3VPNs).

The WG is responsible for standardization of the following solutions:
    1. BGP/MPLS IP VPNs (based on RFC 2547)
    2. IP VPNs using Virtual Routers
    3. CE-based VPNs using IPsec

The following VPN deployment scenarios will be considered by the WG:

    1. Internet-wide: VPN sites attached to arbitrary points in
      the Internet

    2. Single service provider (SP)/single AS: VPN sites attached to
      the network of a single provider within the scope of a single

    3. Single SP/multiple AS'es: VPN sites attached to the network
      of a single provider consisting of multiple AS'es

    4. Cooperating SPs: VPN sites attached to networks of different
      providers that cooperate with each other to provide VPN service

The WG will address deployment of the following features in a VPN

    1. IP Multicast
    2. IPv6

As part of this effort the WG will work on the following tasks
(additional work items will require rechartering):

    1. Requirements and framework for Layer 3 VPNs
    2. Solution documents for each approach listed above (including
      applicability statements)
    3. MIB definitions for each approach
    4. Security mechanisms for each approach

As a general rule, the WG will not create new protocols, but will
provide functional requirements for extensions of the existing
protocols that will be discussed in the protocol-specific WGs. L3VPN
WG will review proposed protocol extensions for L3VPNs before they are
recommended to appropriate protocol-specific WGs.

As stated above, the WG will define an IPv6 over BGP / MPLS VPN
solution.  This will include a forwarding plane component and a
control plane component.  In the forwarding plane, IPv6 datagrams will
be encapsulated within an MPLS header.  If any aspect of IPv6
forwarding over MPLS is as yet undefined, the L3VPN WG will defer to
the MPLS and appropriate IPv6 WGs.  On the control plane, BGP
extensions may also need to be defined. In this respect, the L3VPN WG
will defer to the IDR and appropriate IPv6 WGs.

QoS support is excluded from the charter at this time.  It may be
considered for inclusion in an updated charter at a later time. Future
work items may also include OAM support.

Goals and Milestones:

Done  Submit L3 VPN Requirements Document to IESG for publication as Info
Done  Submit Generic Requirements Document to IESG for publication as Info
Done  Submit L3 VPN Framework Document to IESG for publication as Info
Done  Submit VPN Security Analysis to IESG for publication as Info (draft-fang-ppvpn-security-framework-00)
Done  Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)
Done  Submit CE-based specification and AS to IESG for publication as PS (draft-ietf-ppvpn-ce-based-03, draft-declercq-ppvpn-ce-based-sol-00, draft-declercq-ppvpn-ce-based-as-01)
Done  Submit Virtual Router specification and AS to IESG for publication as PS (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01)
Done  Submit BGP as an Auto-Discovery Mechanism for publication as PS (draft-ietf-ppvpn-bgpvpn-auto-05.txt)
Done  Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-gre-ip-2547-02)
Done  Submit VPN MIB Textual Conventions to IESG for publication as PS (draft-ietf-ppvpn-tc-mib-02)
Done  Submit MPLS/BGP VPN MIB to IESG for publication as PS (draft-ietf-ppvpn-mpls-vpn-mib-05)
Done  Submit VR MIB to IESG for publication as PS (draft-ietf-ppvpn-vr-mib-04)
Done  Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-ipsec-2547-03)
Done  Submit specification of OSPF as the PE/CE Protocol in BGP/MPLS VPNs for publication (draft-ietf-l3vpn-ospf-2547-xx.txt)
Dec 2004  Submit specification of CE Route Authentication to IESG for publication as PS (draft-ietf-ppvpn-l3vpn-auth-03)
Done  Submit specification of IPv6 over BGP/MPLS VPNs for publication
Aug 2006  Submit specification of IPv4 multicast over BGP/MPLS VPNs for publication


  • draft-ietf-l3vpn-ce-based-02.txt
  • draft-ietf-l3vpn-bgp-ipv6-07.txt
  • draft-ietf-l3vpn-mpls-vpn-mib-07.txt
  • draft-ietf-l3vpn-rfc2547bis-03.txt
  • draft-ietf-l3vpn-ipsec-2547-05.txt
  • draft-ietf-l3vpn-ospf-2547-04.txt
  • draft-ietf-l3vpn-gre-ip-2547-05.txt
  • draft-ietf-l3vpn-bgpvpn-auto-06.txt
  • draft-ietf-l3vpn-vpn-vr-02.txt
  • draft-ietf-l3vpn-vr-mib-04.txt
  • draft-ietf-l3vpn-tc-mib-06.txt
  • draft-ietf-l3vpn-as2547-07.txt
  • draft-ietf-l3vpn-as-vr-01.txt
  • draft-declercq-l3vpn-ce-based-as-00.txt
  • draft-ietf-l3vpn-rt-constrain-02.txt
  • draft-ietf-l3vpn-ppvpn-mcast-reqts-02.txt
  • draft-ietf-l3vpn-vpn-verification-00.txt
  • draft-ietf-l3vpn-2547bis-mcast-00.txt

    Request For Comments:

    RFC3809 I Generic Requirements for Provider Provisioned Virtual Private Networks
    RFC4026 I Provider Provisioned Virtual Private Network (VPN) Terminology
    RFC4031 I Service requirements for Layer 3 Provider Provisioned Virtual Private Networks
    RFC4110 I A Framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
    RFC4111 I Security Framework for Provider Provisioned Virtual Private Networks (PPVPNs)
    RFC4176 I Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management

    Current Meeting Report

    L3VPN WG meeting:               November 10, 2005                 Vancouver
    Chairs: Ross Callon, Ron Bonica, Rick Wilder
    Status of the WG:
    Ron Bonica reviewed the WG status and docs. 
    .        While many drafts are in progress, by far the most active work area
    is multicast.
    *	The status of the L3VPN documents is summarized by the datatracker
    utility at https://datatracker.ietf.org/public/pidtracker.cgi
    Martin Halstead presented a draft on a proposed new Inter AS Option for
    *	Deals with VPNs spanning multiple service provider (SP) domains or a
    single SP with multiple ASes
    *	The two use cases have different requirements. When spanning SP
    domains, the concern is with hiding VPN topology information and allowing
    policy mediation, including supporting load balancing and path optimization.
    There is a possible need for multi-hop eBGP based VPN service extensions. A
    single SP with multiple ASs deals with requirements to segment the network
    for increased scalability.
    *	There are pros and cons for each of the three options. Option A
    gives you separation for various domains with the RD, RT, and PE addresses
    separated at the AS border. This is the most commonly deployed alternative
    by SPs despite its cons, which include scaling issues associated with per
    VRF attachment circuit BGP sessions and difficulty to support enterprise QoS
    transparency (due to dependencies on L2 media).
    	Option B is good for scaling of ASBR control and data plane with
    support for enterprise QoS Transparency. However, its disadvantage is that
    it requires agreement and coordination of route target values across SPs,
    including trust required between SPs as MPLS-based "global" interface
    exposures. There also is no per VPN route capping or summarization such that
    there are operational process separation issues.
    	Option C is not being used by service providers so it wasn't
    *	This draft is proposing a combination of Options A and B. Use MPLS
    based data plane between ASBRs with single MP eBGP peering between ASBRs. It
    hides intra-AS topologies and has enterprise QoS transparencies. 
    *	Asked if there is any working group interest in this option (e.g.,
    to update the draft). There wasn't time for the discussion so will be moved
    to the mailing list.
    Requirements for Multicast in L3 VPNs by Thomas Morin, Renaud Moignard and
    *	A Multicast VPN survey of 30 questions was put out on July 27th.
    Results were gathered in September 2005. Responses were of varying quality
    but did enable them to identify use cases and to identify deployment order
    of magnitude information. 
    	*	Number of VPNs should scale up to thousands of VPNs
    	*	Number of VPNs per PE should scale up to thousands of VPNs
    per PE.
    	*	Number of CEs per VPN per PE - scale to several hundreds
    (and target thousands)
    			*	Number of PEs connected to multicast sources
    ranged from 1, 2, 5 or 10 (e.g., for content distribution) to hundreds.
    			*	Should support hundreds or thousands of
    streams per VPN.
    	*	Their conclusion is that no solution should restrict the
    scope of multicast applications and deployments that can be one over a
    multicast VPN. They also identified some use cases that may impact the
    solution design.
    	*	They still have several open questions: (1) Inter-AS, (2)
    multi-homed sources and Inter-AS, and (3) Inter-provider security.
    	*	They reported that the draft is mature and nearing readiness
    for working group last call soon. 
    	*	Again, no time was allowed for questions.
    Eric Rosen's and Rahul's Multicast in BGP/MPLS VPNs
    Discussed MVPN improvements. Control plane needs to scale better and the
    data plane needs more aggregation as well as tunnels on a per-VPN or coarser
    basis. Question about the control integration is whether or not to reuse
    general L3VPN mechanism. Want to eliminate the requirement for
    Multi-directional Inclusive P-Multicast Service Interfaces (PMSIs)
    *	MI-PMSI-based control and have more flexibility in choosing
    tunneling technologies.
    *	There is a tension between scale verses optimality and the "known to
    work" versus "being invented now". On the control plane there is the issue
    of integration versus optimization. Also, what will the bottleneck be: the
    data or control plane. There is also the problem that multicast has
    unpredictable demands.
    *	The group is not trying to improve the multicast protocol itself or
    address non-MPVPN issues.
    *	Data MI-PMSI makes it easier to handle dense mode and flooding-based
    *	With MI-PMSI in the control plane, PIM Asserts can be used to create
    efficient routes by specifying "designated forwarder".
    *	Concerning BGP specifically, BGP is the L3VPN PE-PE signaling
    mechanism that gives it advantages for PE-PE multicast signaling. However
    the scaling needs to be carefully examined, together with dynamics.
    *	Presentation is trying to discourage over-enthusiasm for BGP such
    that other viable approaches should still be considered.
    *	Discussed Basic BGP interactions, including S-State and R-State
    scaling issues.
    Rahul then spoke about the functionality in BGP that they have built.
    Intra-AS is well understood but Inter-As has more issues. Uses MVPN
    auto-discovery with inter-AS tunnels being constructed by stitching together
    intra-AS tunnels between providers, even if each provider is actually using
    a different multicast protocol internally. MVPN PE-PE routing exchange
    between ASes only occurs at ASBRs or RRs. Use RT Constrain to limit the
    distribution of auto-configuration information. 
    These have BGP extensions for MCAST VPN NLRI consisting of the RD, Src PE
    address, C-Source length, C-Group length, and MPLS labels.
    Gargi: arch is cleaner if we separate discovery from binding
    Rahul: thanks for comment; if we can leverage same encoding then is
    reasonable, but functions are separate
    Xiaohu Xu (xuxh@huawei.com  ) discussed Multicast in
    BGP/MPLS VPN (draft-xu-l2vpn-2547bis-mcast-01)
    *	Discovery of MVPN membership is by auto-discovery, followed by the
    establishment of pseudo-wires. This is the main difference from Eric Rosen's
    *	Addressed questions he received over the mail list.
    .         Ron calls for hands, who read? <5, so discussion will continue on
    the email list. 
    Yiqun Cai, Mike McBride, and Chris Hall on MVPN Experience
    *	Describing their multicast experience to help ISPs with their
    *	Their current deployment uses the multicast domain model and uses
    PIM/IGMP/MSDP between the PE/CE. It uses PIM in the core and GRE (class D)
    encapsulation. There is a different mapping functionality between default
    MDT and Data MDT. Also used MDT SAFI for source discovery.
    *	Their draft discusses their lessons learned and best practices for
    RPF, load balancing, PIM modes most commonly used by service providers,
    addressing, filtering, upgrade, etc. 
    *	Their approach is well deployed and supports all of the known
    multicast applications and end-to-end multicast protocols of the ISP
    customers. It also leverages existing multicast protocols in the core and
    allows migration to future enhancements such as p2mp/mp2mp LSP and
    Join/Prune reduction.
    *	Yakov Rekhter said it is a very useful document but asked that
    quantitative analysis of scaling be added and that corrections be made to
    the QoS section. Ross Callon subsequently agreed, especially for documenting
    the scaling numbers.
    *	Ted Seely emphasized that multicast is not easy in service provider
    networks and it will be tougher yet to get it to work between service
    provider networks.
    .        Yiqun requested others with deployment experience to send results.
    .         Ross: (regular-guy hat) this doc assumes single approach
    (PIM-based). Yiqun: it is the only deployed approach. Ross: if other
    deployments exist, their input would be valuable too
    .        Ted Seely commented that some of the scaling numbers in the survey
    are too low
    .        Thomas Morin: we can still take responses, are interested in more
    MVPN PE-PE Signaling by Nidhi Bhaskar, Yiqun Cai and Gargi Nalawade. Gargi
    *	This presentation is part of a study concerning how to convey PIM
    information within BGP (e.g., to potentially migrate historic LAN-based PIM
    into the L3VPN BGP mechanism). Replaces PIM on LANs with a RR.
    *	PIM LAN procedures are well understood and well deployed. The
    authors suggest BGP for provider multicast routing in this working group.
    This is an analysis of the BGP enhancements and impact upon BGP/PIM.
    *	Identifies the changes to BGP needed to support the PE-PE multicast
    signaling. This includes new functions in BGP such as aggregating D-PE, U-PE
    based filtering, and RPF lookup on ASBR, Multicast PE-PE (overlay) SAFI,
    RT/RD Import/Export, filtering, PIM/BGP interaction, and Inter-AS procedures
    and interactions.
    *	A separate speaker then continued the presentation, discussing
    BGP-multicast routing state. The RR stores each multicast route as N * NLRI
    where N is the number of D-Pes interested in the multicast stream,  Putting
    PIM Join/Prune in BGP requires PIM Join/Prune to be routed as a BGP NLRI.
    This has latency implications. There are PIM State machine changes to
    interact with BPG such as no PIM hellos for option negotiation - options may
    be carried in BGP. BGP is really not appropriate for PIM Assert resolution.
    PIM-SM shared tree pruning is also difficult because BGP cannot preserve the
    full state nature of the PIM prunes. The BSR mappings also require a full
    state update.
    *	Other issues with BGP is that BGP will not restrict the Binding
    state to the multicast tree. There are also not enough bits to encode SAFI
    length for IPv6. Need to also define transition mechanisms from LAN
    procedures to BGP.
    *	Dino asked the authors concerning whether this approach is easier or
    harder than traditional PIM uses. Gargi answered that zero-configuration
    support will be a differentiating factor. Her partner said that the new
    environments will have environments without LANs with which to run PIM.
    *	Beau Williamson asked whether their approach has removed the upper
    bound limits as far as multicast consumption of ISP resources. This approach
    seems to support arbitrarily growing (possibly exponential) demands on
    service provider so that maybe the customers could bring the ISP down.
    Presenter agreed that there will be an additional load. Also there is a
    fundamental difference between how PIM joins and prunes would work.
    Bin Lee presented IPv6 VPN Address Format.
    *	Is a new L3 VPN solution based on the structure of IPv6. The goal is
    to reduce packet overhead.
    .        Bob Hinden: you're proposing to create site-local again, you should
    read about why it was deprecated, it's unlikely to be accepted by iesg/ietf;
    you're taking an amount of space equal to what all RIRs have today for this
    scheme, which is unlikely; I think you can do everything with Unique
    addresses, ULA inside
    .        Alain Durand: is like double NAT, so double the problems; is very
    .        Elwyn Davies: all of the above; also, you'll have trouble routing
    these non-aggregatable addresses globally
    .        Mark Townsley : what does this solve that normal L3VPN encapsulated
    over an IPv6 network can't solve?
    .        Discussion of this point to be continued on the mailing list.


    mcast reqs