2.3.12 Layer 3 Virtual Private Networks (l3vpn)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-02


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)
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-ce-based-02.txt
  • draft-ietf-l3vpn-bgp-ipv6-06.txt
  • draft-ietf-l3vpn-mpls-vpn-mib-07.txt
  • draft-ietf-l3vpn-rfc2547bis-03.txt
  • draft-ietf-l3vpn-ipsec-2547-04.txt
  • draft-ietf-l3vpn-ospf-2547-04.txt
  • draft-ietf-l3vpn-gre-ip-2547-04.txt
  • draft-ietf-l3vpn-bgpvpn-auto-06.txt
  • draft-ietf-l3vpn-vpn-vr-02.txt
  • draft-ietf-l3vpn-vr-mib-03.txt
  • draft-ietf-l3vpn-tc-mib-06.txt
  • draft-ietf-l3vpn-as2547-07.txt
  • draft-ietf-l3vpn-as-vr-01.txt
  • draft-ietf-l3vpn-mgt-fwk-08.txt
  • draft-ietf-l3vpn-l3vpn-auth-01.txt
  • draft-declercq-l3vpn-ce-based-as-00.txt
  • draft-ietf-l3vpn-rt-constrain-02.txt
  • draft-ietf-l3vpn-ppvpn-mcast-reqts-01.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)

    Current Meeting Report

    Layer 3 Virtual Private Networks (Internet Area)

    Monday, August 1 at 16:30-18:00

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

    Document Status Review - Ross Callon

    Ross presented the document status review.

    - Made good progress. Ross mentioned the new RFCs published (3809 published a while ago, 4026 published about the same time as last IETF, 4031, 4110, 4111 published since last IETF).

    - The BGP/MPLS IP VPN specification has been waiting for the BGP extended communities draft being done in the idr wg. Recently this was approved to progress and bgp/mpls vpn can progress now. This also frees up other related drafts to progress, including the associated applicability statement, the Framework for L3VPN O&M, Textual conventions for VPNs, and the MIB for BGP/MPLS IP VPNs.

    - pe-pe gre or ip in bgp/mpls has been updated based on IESG review, the revised document is currently in wg last call.

    - ospf for PE-CE protocol has recently been updated (in may) and is waiting for iesg review.

    - bgp auto-discovery revised given the feedback received, back to AD.

    - Waiting for write-up:

    - Constrained VPN route distrib updated, waiting on chairs to send a description to the IESG.

    - BGP-MPLS IP VPN for IPv6 updated, writeup has been very recently provided to IESG.

    - Revised id needed:

    Virtual Router Architecture and its associated applicability statement. Comments have been sent to authors.

    - Under AD evaluation:

    An architecture for PP CE-based VPNs using IPsec and associated AS needs review and update (the chairs need to work on this).

    - Architecture for PE-PE IPSec tunnel for bgp/mpls ip vpns has been recently updated based on last call comments. We need to update its status in the IETF Internet Drafts Status Tracker.

    - Current work:

    o Requirements for multicast
    o Multicast solution in bgp ip vpn
    Both of the above are very active (presentations to follow)

    o CE-CE member verification
    o l3vpn import export verification (

    The 2 above documents have not had recent activity.

    Multicast VPN Requirements - Thomas Morin

    Thomas Morin presented the draft-id.

    - A new update posted 2 weeks ago.
    - in this presentation will go through the changes, the multicast vpn survey, and we talk about next work.
    - On the changes 2 new sections in the draft have been added.
    o Carrier's carrier requirements and
    o New section on QoS (ability to offer different QoS level to different customers.

    - Updated sections: QoS (5.1.3) maintain join and leave delay requirement (refer to RFC2432)and minimum MTU.
    - Tunneling technologies need to mention P2MP LSP as much possible.
    - Compatibility and migration issues solution should state a migration policy.
    - Trouble shooting provide the operator with means LSP ping
    - inter-as section (should provide inter-as mechanism requiring least....
    - Big changes on section 4 (Uses cases) illustrated deployment requirements.
    - describe use cases scenarios
    - provide order of magnitude for scalability requirement,
    - waiting for survey.
    - finally some edits changes...

    - For multicast vpn survey (proposed at last ietf)
    - survey overview (to be answered mainly by ISPs)
    - focus on future expected deployments.
    - typical questions Quantitative and qualitative (type of multicast deployed, etc).
    - Survey launched last week posted on different WG lists please answer it and send completed survey to Daniel King Dan (dnni.com)
    - answers expected by Sept 15 05.

    Tom described the Next items for the draft such as:
    o complete section 4 with the help of the survey and
    o refine the requirements (PE-Ce protocols, inter-AS, carrier's carrier, extranet tunneling protocols, etc)
    o Address some open questions relevance of MTU-related sections.

    - Conclusion: requirement is mostly mature except section 4. Tom asked the audience to provide comments on the draft on the mailing list and answer and disseminate the survey.

    - Questions on the draft: no questions.

    Multicast VPN Solution - Rahul Aggarwal

    Rahul presented the draft:

    This is an update on multicast draft, this is a WG document. Rahul shows the co-authors/contributors, fully committed to move this work forward,

    This presentation for discussion open options. Reduce options if possible, outline the issues and specify required and optional procedures, looking at MVPN routing information exchange service provider technologies

    - need to look at scalability of entire network.
    consider rate of churn C-joins/Prunes number of protocol sessions require frequent periodic changes

    - how does it fit with 2547 operational model unicast

    Rahul shows a table for MVPN routing exchange not exhaustive list. Periodic refresh, session per PE UI-PMSI,. etc. for BGP, PIM UNicast, PIM multicast...

    - Do we really need PIM-SM with GRE? Discovery can be done using BGP, shared trees can be built with PIM-SSM.


    Goal to address these issues and produce 01 version.

    Ross: is you proposal is to propose this options to the WG list. Make WG aware of the options:

    - Ross Callon: is your proposal to ask these questions on the WG mailing list?

    Rahul: Yes. Want to capture these questions in the minutes. Then send email on the list and initiate the discussion.

    - Question on BGP encoding to be published. There are already published encodings for BGP to carry MVPN information

    Rahul: Existing proposal may or may not be used.

    - Question (unidentified person from Cisco): Wants backward compatibility with what has been deployed for years and the Rosen draft.

    Rahul: Certain options have been deployed, some not. Point well taken. Need WG input.

    - Question (Venu Hemige): Deprecate PIM-SM? Some providers already use it.

    Rahul: Point taken. OK.

    - Question: need periodic refreshment. There is are WG items that try to reduce periodic refreshes. Need to consider these approaches other that may reduce the overhead.

    - Albert, Redback: PIM needs periodic refresh? There's some work in PIM WG to reduce periodic refreshes. Need to consider these approaches.

    Rahul: Yes, need to look at pragmatic options, point taken.

    - Question (unidentified person from Cisco): What is a service? The only difference to the MVPN service is whether using SSM or ASM. The protocol you use to implement it should be a separate issue.

    Rahul: draft should talk about applicability of protocols. Draft has told about tunneling technologies

    Yakov Rekhter: I disagree. Need to specify which protocol for interoperability reasons.
    Toerless: same with IS-IS and OSPF.
    Yakov: yes.
    Toerless: what does rfc2547 say about IS-IS?
    Dan Alvarez: At least why do we think BGP is suitable. For example there is no information on dynamic building of OSPF trees etc.

    Comment (Person): this is the wrong level of detail. Why this need to be specified.

    Yakov: I disagree because of interoperability reasons need to specify which protocol to use.

    Question (Albert from Cisco): last comment: how well bgp is suitable for multicast. BGP is not used for intra multicast operation, why BGP is suitable. No information on dynamic multicast tree and how it related to scalability. Why use BGP as replacement for all existing multicast protocols...

    Rahul: Not talking of building trees with BGP, just transporting with BGP. one item for consideration

    Venu Hemige: The one thing for BGP helps is to provide a reliable transport.

    Rahul: Note that BGP does have filtering mechanism...and is applicable in this case.

    Ross: Some of this discussion can go to the text...

    Multicast VPN MIB - Tom Nadeau

    Tom presented the draft.

    Propose this document to manage rosen-multicast doc. interacts well with MPLS MIBS.
    draft need to use the combined approach will be published soon after meeting.

    - Ross: Have you got the input that you need to update the draft?
    - Tom: Yes. It will be updated and published soon.
    - Tom: Can we publish it directly as WG doc.
    - Ross: The MIB manages the combined working group draft. When the
    MIB has been updated to reflect combined drafts then we have two choices:
    either submit as individual contribution and request WG to comment; or just make it wg doc. (note that it doesn't have to be perfect to be published as a WG document, as there is still opportunity for the WG to comment)

    Ross: My personal option if the authors of both sides agree this is the agreed way forward then I don't see objections to adopt it as WG doc.

    Ross: Assuming that the authors of the existing working group multicast document and the authors of the MIB agree that the MIB document is ready to be a working group document, and is a reasonable draft towards a MIB for the WG multicast document, does anybody has any objection to publishing the document as a working group document?

    No objection from audience...

    Virtual Router Multicast Solution - Hong-Ke Zhang

    Presenter: Spencer Dawkins. Spencer gave the presentation because the person who was originally intending to present was unable to attend. He gave credit for the document to its four authors, and very quickly introduces Hong-Ke Zhang who was also present.

    There were some scalability questions on the mailing list such as the number of trees in SP core will not exceed the number of VRs, and does all multicast traffic in a VR share the same tree, answer yes.

    Does this approach require PIM-DM mode answer no, next version will say this more clearly.


    Thomas Morin:
    - suggests solutions draft that clearly states which requirements they meet and which they don't
    - points out that section 6 states that the solution "improves scalability", but is not precise about what we are supposed to compare it to.
    - points out that the draft seems to imply that it would support P2MP
    - MPLS RSVP-TE tunnels, but nothing in the draft tells how, and the solution seems to only work for leaf initiated trees (which P2MP RSVP-TE trees are not)

    - Ross: Who has read the draft: (about ten hands went up)

    - Ross: There were a few hands for those who read the document. Of those who have read the draft, would there be any objection for this to become a WG document. No objection. Given that not all that many people have read the draft, we should repeat this question on the working group email list.

    - Ross: If anybody is interested in deploying multicast for Virtual Routers then please mention this to the mailing list.


    Multicast in BGP/MPLS VPNs
    Requirements for Multicast in L3 PPVPNs
    Multicast in Virtual Router-based IP VPNs