2.3.13 Layer 3 Virtual Private Networks (l3vpn)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-24


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

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.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)
Aug 04  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)
Aug 04  Submit VR MIB to IESG for publication as PS (draft-ietf-ppvpn-vr-mib-04)
Aug 04  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 04  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
Dec 04  Submit specification of IPv4 multicast over BGP/MPLS VPNs for publication


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

    Request For Comments:

    RFC3809 I Generic Requirements for Provider Provisioned Virtual Private Networks

    Current Meeting Report

    IETF 62 - L3 VPN

    March 7 at 13:00 CST


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

    Ross Callon - Document Status Review

    Generic Requirements have been published as RFC 3809.

    L3 framework is waiting on a normative references on and therefore should be published soon.

    L3 Requirements is about to be published as RFC.

    L3 VPN requirements draft is going to be published soon as RFC4031.
    It's currently in the RFC Editor's 48 hours authors stage.

    Security Framework has been approved and is in the RFC editor's queue.

    BGP-MPLS L3 VPN's is in the RFC editor's queue. IANA considerations related to this draft are currently being worked out.

    VR and CE/IPSec architecture documents are all under IESG consideration.

    Draft-ietf-l3vpn-bgp-ipv6-05.txt has been forwarded to IESG with request for publication.

    AS Guidelines are "done"

    Terminology is also about to be published as an RFC.

    The MIBs need a little more work.
    -The Framework for L3VPN O&M is being updated based on comments received during the IESG review.
    -Textual Conventions is done
    -MPLS / BGP MIB is being updated based on comments received during IESG and MIB Doctor review.

    Virtual Router MIB timed out but has been recently updated. There is an intellectual property issue. This needs guidance from the working group.

    Multicast is one of the things where we are doing current work. The Requirements Draft has just been accepted as a WG document. There are also other individual drafts.

    (see discussions later in this same working group meeting).

    Other WG documents

    OSPF needs to be updated to respond to IESG comments.
    PE-PE IPSec for 2547 needs updates based on last call comments.

    PE-PE GRE is under discussion with the IESG.

    BGP Autodiscovery has been sent to the IESG


    Thomas Morin - Multicast Requirements

    draft ietf-l3vpn-ppvpn-mcast

    Context : First draft was presented in Washington, now a L3 VPN WG document. Integration of comments from new contributors.

    This added 6 pages. Many areas of the document are now quite stable.
    Noteworthy changes are Security, QOS, Internet Multicast, RP engineering.

    Internet Multicast is currently only mentioned as a possible requirement, so if the group has strong feelings about this, the group should speak up.

    Fragmentation issues - special care is needed here for multicast.

    Recently, added text about supporting multicast in a "Carrier's Carrier".

    The service providers side requirements have evolved.

    - control mechanisms
    - security
    - tunneling requirements - need to cleanly separate the control plane and the forwarding plane
    - TE & OAM

    A terminology session has also been added.
    A new term, Multicast Distribution Tunnels, or MD tunnels, has been added.

    What's next ?

    There is a need for data about the types of applications, orders of magnitude

    However, need to consider not just current deployments but also future deployments.

    Also, support for the Carrier's Carrier model needs to be added.

    Open questions include the scope of the document. Should the scope be reduced ? Should IPv6 be added ?

    He requests review and comments from the WG. He also wants to do an ISP survey.

    Multicast VPN Architecture

    Eric Rosen (erosen@cisco.com)
    and Rahul Aggarwal (rahul@juniper.net)

    Multicast Support for RFC 2547 VPNs has 2 components

    control plane - exchange vpn multicast routing information

    data plane

    This is very similar to the separation for 2547 unicast.

    Design Objectives include

    Optimize Bandwidth & Optimize State

    - A given multicast packet should traverse a given link at most once
    - Deliver multicast traffic only to those PE's that have receiver that want the traffic.

    Optimizing State and Bandwidth are conflicting goals.

    MVPN AutoDiscovery uses BGP
    - this eliminates PIM Hello's

    Control traffic does not have to use the tunnels used by the multicast data.

    In the data plane

    - ingress replication to egress
    - a separate tree for every C-(S,G)

    going one way increases state and decreases bandwidth, going the other way does the reverse.

    Can do aggregate state, with a separate state for "Inclusive mapping"

    or "Selective Mapping" - a separate tree per set of C-(S,G)

    The tree is built using PIM-SM BiDir, SSM, whatever.

    The spec does not limit to a specific tree building protocol.

    <audience member> - ask questions now, or at the end ?
    Ross - at the end

    Eric Rosen

    In order to converge the document, tried to see how the proposals differ.

    - What sort of multicast service can be provided
    - methods of implementing multicast service
    - multicast routing information propagation

    One size does not fit all, so tried to clarify multicast service and routing information exchange.

    Provider-Network Multicast Service Interface - PMSI

    - service is scoped to one MVPN
    - three types

    MI-PMSI - multipoint inclusive, all to all
    YU-PMSI - unidirectional
    S-PMSI - selective

    PMSI's are instantiated by tunnels. Types of these

    PIM-created trees
    Point to MultiPoint LSP's

    Unicast tunnels

    PMMSI may require sets of tunnels (e.g., SSM)

    Single tunnel may instantiate more than one PMSI

    - the encapsulation is a function of the tunnel, not the service

    Old terminology -

    Default MDT -> MI-PMSI, instantiated by PIM shared tree or a set of PIM Source Trees

    Data MDT = S-PMSI

    New terminology helps to separate out the service and data issues.

    What sort of tunnels ?

    MPLS vs GRE vs MPLS in GRE vs ...

    Source initiated or receiver initiated creation of tunnels
    TE : Source
    Multicast : Receiver

    Options for creating
    and destroying the tunnels

    As part of discovery
    As a separate phase after discovery
    As needed (this complicates the protocol options)

    How do we ensure interoperability - force a common tunnel choice ?

    The discovery phase - make sure that everyone gets all of the multicast information that they require.

    What PMSI's are going to be used ?
    Will MVPN routing be propagated by unicast or multicast

    What sort of tunnels ? What information is needed to create and destroy them.

    What encapsulation is to be used ? What amount of aggregation.

    For routing information, they considered only PIM and BGP.

    For PIM, C-Join / Prune messages are sent by either multicast or unicast (PE to PE).

    Note : Unicast is different from MI-PMSI over unicast tunnels.

    With PIM, you can minimize overhead by eliminating periodic messages

    - refresh reduction (being worked on in PIM group)
    - hello suppression (provided by BGP in L3VPN)

    This creates a lightweight adjacency which is, however, not interoperable with full adjacencies.

    Can always find the RPF, even if there isn't always a route back to the source.

    Control Messages : Multicast or Unicast

    Allows asserts, join suppression, standard "PIM on a LAN"

    Unicast : No join suppression, no asserts

    OR, you can do it with BGP

    BGP MVPN Routing information update (new SAFI)
    <RD, C-S, C-G, ORIGINATOR PE, Upstream PE - PE2, RT>

    I-PMSI Instantiation -
    Can be uni or multi directional

    Current spec limits trees to PIM-SM, SSM, BiDir, RSVP-TE P2MP LSP's

    Trees can be source based or shared trees.

    Source tree's are set up by the PE
    Shared trees are set up by a RP

    **** except that they say with
    **** SSM

    Each PE uses BGP to advertise whether or not it is capable of MPLS ingress replication, and also downstream MPLS Label

    Joins are sent upstream using BGP or Unicast PIM
    [as there is no full mesh tunnel. Wonder if they have thought about MSDP ?]

    Aggregation allows one P-Multicast Tree to be shared across _multiple_VPNs'.

    Requires a MPLS label to demultiplex a particular VPN - BGP to the RR.

    A PE decides to set up an aggregated tree :

    S-PMSI instantiation

    Set up a separate tree for a set of <C-S, C-G>s that may belong to different VPN's

    This also allows a datagram (UDP) based protocol that may already be deployed.

    For inter-AS - two models

    Tunnel Span's multiple AS's


    Each AS can have its own tunneling mechanism

    The draft talks about deployment models.

    - Anycast RP based on (*,G) advertisements

    When you unicast PIM messages, how do you know which VPN they belong to ?

    Authors request to make it a wg doc.
    Also, they invite the authors of draft-yasukawa to join for the next draft

    Seisho Yasukawa (NTT)

    BGP/MPLS IP Multicast

    Basic ideas

    1. Extend BGP to exchange multicast routing information
    2. Adopt a proxy RP
    3. Use P2MP TE LSP to forward multicast traffic over provider core

    There mechanism is applicable to PIM SM and SSM

    They want to merge the drafts into a single MVPN solution

    Question :
    Marshall Eubanks : How do you plan to do anycast RP ? Currently it is done with MSPD

    A : Using a new SAFI in BGP

    Question :
    Yiqun Cai : How do does the customer do BiDir ?

    A. BiDir is not supported.

    Ross : It is my impression that in both authors have expressed a desire to merge the two documents. What is the consensus of the working group ? Should these be merged ?

    Rahul Aggarwal : Just to make it clear, our draft tried to incorporate as much as possible of the other draft already.

    Yakov Rekhter : So we don't have to wait for the next IETF.

    Ross: we have limited time here for discussion. Shall we ask the authors to merge proposals?
    Shall we accept it now as wg doc once it is merged? Or wait until we see it?
    Many more hands for accepting it now.
    A: Let's get the merged doc on the mailing list and proceed from there.

    Michael Behringer

    RFC2547 environment

    If a PE misconfiguration a CE onto a tunnel, this could be a security problem, and there is no easy way to detect it.

    There is routing authentication

    Proposal - Do away with PE to PE authentication, do authentication across the entire tunnel.

    There is another draft, the Bonica draft. There was a push to merge them, but he thinks now that this does not make too much sense.

    Draft: Beh Bon
    CE Does not need to participate No Yes
    Allows route verification by site No Yes
    Work with route reflectors YES YES
    Requires routing PE-CE YES (Yes, or a new functionality to do this)

    Q (McDysan): as an SP, he likes this. Doesn't want to rely on
    customers to detect problems.

    Q (..., cisco): What prevents using same md5 key for more than 1 CE?
    A: nothing; that's tough luck

    Ron Bonica

    CE Based Membership verification

    We are worried about honest mistakes from the Service provider

    Status Quo : L3 VPN relies on the proper configuration of the Service provider network. Breaches are generally silent.

    The proposed mechanism alerts the customer when the VPN has been breached.

    A VPN site sends a token to the PE, which sends it to every other site.

    This does not protect against malicious behavior on the part of the SSP, intended to protect against accidental exposure.

    This draft and the Behringer draft actually solve rather different problems. One partially prevents configuration errors, the other alerts the customer when it happens.

    [could you concatenate your token with a MPLS label or some other unique ID]

    Ross : Who thinks that these are a bad idea ?

    Rick Wilder : I think that each author should make it clearer what authentication problem it is solving, and also have pointers to the other draft.

    [Audience member] Each one solves a piece of the problem. Putting them together implies that we solve the entire problem, which we probably do not have the bandwidth for. So, keep them separate, but keep them bound together, though.

    Q (Rosen): is this really solving a different problem
    A: yes, because ...

    Ross: who has read both drafts?
    only 9 hands
    most of those 9 think both should be progressed
    Ross: anyone who thinks either idea is a bad thing to progress? None.

    Rick Wilder: we need to make it more clear in draft each how they relate to each other.

    Townsley: Keeping them separate allows more flexibility to advance them (or not).


    Two cases

    Both backbone and sites are v4 and v6 hybrids

    Case 2 : IPv4 backbone with IPv4 / v6

    Method 1 Case 1 : Carry IPv4 and IPv6

    map v4 address to 96+MASK if necessary.

    Packet forwarding between PE-sites

    Method 2 for Case 1

    multi-hop MP-EBGP set up based on IPv4

    Case 2

    PE assigns private IPv4 addresses for IPv6 site, and supports a NAT-PT for these sites

    Add an extra attribute for these sites, IF-V6-Site,

    Wants this to become a WG draft.

    Since the draft is not currently available on the IETF server, it was agreed that the author would get the draft re-issued, and we would then discuss it on the mailing list.


    Uses a mechanism that is a hybrid of 2547
    chapter 10 option a and b

    Advantages : Routes are associated to VPNs and
    IP packets are accessible.
    Very granular TE is possible.

    One "Con" is that it needs to keep VPN routers in ASBR routers, which may lead to state issues if it is widely used.

    Q (Rahul): Isn't it just an implementation difference from option B?
    A: no because ...


    Status of L3 PPVPN Working Group Documents
    Requirements for Multicast Multicast in L3 PPVPNs
    Multicast in BGP/MPLS VPNs
    MPLS VPN Import/Export Verification
    CE Based Membership Verification for L3VPN
    BGP-MPLS VPN extension for IPv4/IPv6 Hybrid Network