2.3.12 Layer 2 Virtual Private Networks (l2vpn)

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-01-25


Rick Wilder <rick@rhwilder.net>
Vach Kompella <vkompella@timetra.com>
Loa Andersson <loa@pi.se>

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):

Russell Housley <housley@vigilsec.com>
Alex Zinin <zinin@psg.com>

Mailing Lists:

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

Description of Working Group:

Alex Zinin is the routing advisor.
Russ Housley is the security advisor.

This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
layer-2 virtual private networks (L2VPNs).

The WG is responsible for standardization of the following solutions:

1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
  across an IP and an MPLS-enabled IP network, allowing standard
  Ethernet devices communicate with each other as if they were
  connected to a common LAN segment.
2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
  point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
  point-to-point Ethernet) across an IP and an MPLS-enabled IP

3. IP-only VPNs -- An L2 service across an IP and MPLS-enabled IP
  network, allowing standard IP devices to communicate with each
  other as if they were connected to a common LAN or with some mesh
  of point-to-point circuits (not necessarily fully meshed).  The WG
  will address both of the following cases:
  - the customer attachment uses the same L2 protocol at all
    attachment points in the L2VPN.

  - the customer attachment uses different L2 protocols at the
    attachment points in the L2VPN. This case is intended to address
    the needs of service providers who may start out with a single L2
    protocol at attachment points, but wish to incrementally upgrade
    individual attachment points over time to newer technologies. This
    is a restricted form of "interworking" that is limited to
    providing the facilities necessary to carry IP over the L2VPN;
    general L2 interworking is not in scope.

The WG will address intra-AS scenarios only at this point (other
scenarios will be considered for inclusion in the updated charter when
the current one is completed.)
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.
As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG.
L2VPN WG will review proposed protocol extensions for L2VPNs before
they are recommended to appropriate protocol-specific WGs.

The WG will work on the following items. Adding new work items will
require rechartering.

1. Discovery of PEs participating in L2 service, and topology of
  required connectivity

2. Signaling of l2vpn related information for the purpose of
  setup and maintenance of l2vpn circuits. As much as possible
  PWE3 signaling procedures should be used

3. Solution documents (providing the framework for a specific
  solution, should include info on how discovery, signaling,
  and encaps work together, include security, AS as a separate

4. MIBs
5. L2VPN-specific OAM extensions--extensions to existing OAM
  solutions for VPLS, VPWS, and IP-only L2VPNs.

Where necessary, the WG will coordinate its activities with IEEE 802.1

Goals and Milestones:

Aug 03  Submit an I-D describing MIB for VPLS
Aug 03  Submit an I-D describing MIB for VPWS
Aug 03  Submit an I-D on OAM for VPLS
Aug 03  Submit an I-D on OAM for VPWS
Oct 03  Submit L2 requirements to IESG for publication as Informational RFC
Done  Identify VPLS and VPWS solutions for the WG
Done  Submit L2 framework to IESG for publication as Informational RFC
Dec 03  Submit VPLS solution documents to IESG
Dec 03  Submit VPWS solution documents to IESG
Jan 04  Submit IP-only L2VPN solution documents to IESG
Feb 04  Submit MIB for VPLS to IESG
Feb 04  Submit MIB for VPWS to IESG
Mar 04  Submit OAM for VPWS to IESG
Mar 04  Submit OAM for VPLS to IESG
Apr 04  Submit OAM for IP L2VPN to IESG


  • draft-ietf-l2vpn-l2-framework-05.txt
  • draft-ietf-l2vpn-requirements-04.txt
  • draft-ietf-l2vpn-vpls-bgp-04.txt
  • draft-ietf-l2vpn-vpls-ldp-06.txt
  • draft-ietf-l2vpn-signaling-03.txt
  • draft-ietf-l2vpn-ipls-01.txt
  • draft-ietf-l2vpn-radius-pe-discovery-01.txt
  • draft-ietf-l2vpn-oam-req-frmk-02.txt
  • draft-ietf-l2vpn-arp-mediation-00.txt
  • draft-ietf-l2vpn-vpls-ldp-applic-00.txt

    No Request For Comments

    Current Meeting Report

    March 8, 2005, 1:00 pm: Layer 2 Virtual Private Network WG Meeting Minutes
    Co-Chairs: Rick Wilder, Vach Kompella, Loa Andersson

    Rick Wilder opened the meeting. No change on agenda.

    Loa Andersson announced that he will step down as Layer 2 chair, as he is becoming an IAB member. Mark Townsley is the new AD for the Internet Area.

    Agenda bashing: The last item, Cheng-Yin Lee’s presentation is cancelled.

    Status update on documents in progress:
    Framework document is in RFC queue.
    Requirement doc is in IESG review.
    Vpls-bgp and vpls-ldp are on standards track, under review.

    Himanshu on ARP mediation draft – see presentation slides: no discussions on mailing list, no draft update since last WG meeting. Some ID nits on IANA allocation and security section. IPLS draft is in same state. Both ready for last call after final updates to become IETF draft.

    Thomas Narten – Stepping down as AD. Wants to ensure there are at least one or two implementations for VPLS, otherwise it can prevent a document from moving forward.

    Loa: requests clarification on whether implementations are a definite requirement for progression of documents in the Internet area.

    L2VPN provisioning and signaling (authors Eric Rosen, Bruce Davie and Vasile Radioca) – presented by Bruce Davie of Cisco
    Draft now covers provisioning, discovery and signaling. New change addresses inter-AS issues. This builds on Luca Martini’s draft on pseudo-wire switching. Clarifying text on BGP autodiscovery. Same options in multi-AS as for RFC2547-bis. Bruce presented a picture similar to Option C. Possible drawback – advert PE loopback address, no control on inter-AS signaling. Presented next picture similar to 2547-bis option B. Signaling sessions are not PE-PE any more but in segments.
    Slide on BGP autodiscovery. AFI, SAFI piece needs to get nailed down so that there is single AFI for all L2VPN solutions, and different SAFI for l2vpn-ldp and l2vpn-bgp.
    Next slide describes signaling previously defined didn’t work for inter-AS VPN case. Talking to Hamid Ouldbrahim to keep everything in-synch with BGP autodiscovery draft. Also have to finalize IANA section. Requested last call.

    Yakov Rekhter: What is the relationship between VPN ID in L2VPN and Route Target for L3VPN. If AGI and route targets are the same we should not have two terms for the same thing.

    Bruce Davie: AGI is defined in requirements for L2VPN.

    Eric Rosen: AGI can be VPN ID for non-BGP and Route Target for BGP.

    Vach Kompella: Significant changes requested, so postpone Last Call until after next draft version.

    L2VPN OAM requirements and framework:
    Dinesh Mohan, Nortel

    Framework propose OAM layering across entities – L2VPN service layer, pseudo-wire layer, PSN layer – also includes customer, SP, Network Operator roles.
    Requirements: Focus on Service Layer, Pseudo-wire layer

    General status update provided from last IETF meeting – Editorial updates to VPWS and IPLS sections added. VPWS is TBD and IPLS – for future study. OAM framework updated – VPLS can be a service, network or emulation. Dinesh read from next slide. ECMP implications and priority considered. Periodicity of OAM depending on protection considered. VPWS and IPLS OAM requirements to be added. Drafts on these have been introduced, and will be included as applicable.
    See presentation slides for next steps.

    Vach: Spirited discussion in last IETF as unclear where it was going. Comment: presentation is more informative than draft, so need to edit text to make it more relevant to IETF work.

    Rick: summary of last meeting is scope of work, and that’s still not in document.

    Dinesh: some work in PWE3 is following the layers constructs that have been introduced in this draft.

    Alex Sajassi, Cisco: VPLS as service, network and LAN/VLAN was discussed in last mtg, and that has been put in the doc.

    Dinesh introduced a backup slide on how different layers come together – Services (Service OAM), Network (Network OAM) and Transport Links/PWE3 (Ethernet Link OAM, PW/MPLS OAM, EoSONET OAM or Other OAM)

    Vach Kompella (not as Chair): Service may traverse Ethernet bridge network or VPLS. Need to be clear what we are working on here. The service model should be clearly in the context of VPLS.

    Dinesh: We are not following IEEE which is focusing on Ethernet bridge, but on PWE3/PSN.

    Using RADIUS for PE-based VPN discovery: Greg Weber
    Mark Townsley, Wei Luo, Skip Booth, Greg Weber, Juha Heihanen

    Now version 01 is WG draft. This doc specifies RADIUS specific mapping for protocol independent model.
    L2VPN authorization steps: New text in this draft, to ensure that terminology is in line with signaling draft, generalized to cover VPLS, VPWS.
    RADIUS transactions and examples.
    To do: A lot left to do: Address accounting, authorization changes, presenting this draft to RADIUS extension (RADEXT) WG to get ideas/feedback.

    Vach: We agreed in last meeting that this is a direction should be taken, and we are seeing a better picture of what Mark T was talking about, but little discussion on mailing list. Would like to see lot more participation to ensure that we are headed in the right direction.

    Ron from Resolute: Is the problem being solved for authentication or for provisioning?

    Greg: more provisioning, RADIUS server is already being used for this type of role in deployments. The servers could also be used in dial-up scenarios.

    Mark: Discovery using RADIUS for specifically centralized server based discovery and provisioning. The opinion has been that RADIUS is preferred over LDAP and DNS for auto-discovery with a centralized server.

    Supporting IP Multicast over VPLS: Venu Hemige

    Problem: Multicast traffic being sent to all PE’s, goal to not send traffic to sites without receivers.
    PIM snooping of PW’s can overwhelm PEs, PIM-refresh reduction and snooping CE-PE link helps overcome burden of PIM snooping in the core, and address reliability of join-prune PDU.
    Defined LDP TLV defined to flush snooping state.

    Eric Rosen, Cisco: PIM Refresh-reduction has to be friendly – but PIM WG is not likely to take this as a serious requirement in defining refresh-reduction. This is a hack, and will be fragile. Many providers take it as a serious requirement to pass on all that is put on the link and this violates that.

    Vach: So should we take to PIM group? Let’s work on this draft in this WG till it matures enough and has enough consensus to send to PIM WG

    Yakov Rekhter: Is packet retransmission being proposed to solution to unreliability of PIM control messages?

    Venu: yes

    Yakov Rekhter: In unreliable situation, retransmit message is not part of PIM and is not sufficient. Use something in the way of PIM refresh reduction.

    Kireeti Kompella: As IGMP snooping and PIM snooping are hacks that have already been implemented, why *document* them now?

    Further discussion required on the mailing list.

    Multicast in VPLS: Rahul Agarwal
    Yuji Kamite, NTT, and Luyuan Fang, ATT

    Update: VPLS mechanisms are in separate drafts and both have limitations for multicast.
    Slide on limitations. Replication of traffic on ingress is possible, and optimizes state in P routers, but not bandwidth.
    Optimizing bandwidth and state are conflicting goals.
    VPLS multicast architecture control plane – use existing auto-discovery mechanisms, allow flooding elimination – PE-CE snooping in draft-serbest-l2vpn-vpl-mcast: PE does not maintain L2 adjacency with CE.
    PIM snooping – and how there is a scalability problem
    Use reliable exchange of multicast control messages between PE’s to avoid PIM snooping on PWs.
    Design goals include using as little state as possible beyond VPLS unicast, and elimination of flooding
    Aggregate P-multicast trees, to allow one P-multicast tree to be shared across multiple VPLS’s. Next slide described inclusive mapping.
    Request to move forward.

    Ali Sajassi: Suggesting solutions without having requirements in framework and requirements draft. Terminology doesn’t match. Issue is IGMP and PIM snooping’s applicability in SP network is questionable, maybe in Enterprise network. Also it is limited to IP traffic of user. What about VPLS.

    Rahul: 2 SP’s on draft – so requirements being addressed. Snooping mentioned for PE-CE link only.

    Alex: Offering diff services over same UNI is solved, why have new mechanism
    Rahul: Specific solution for VPLS multicast.

    ??: Rather than use of IP addresses, the solution use MAC addresses – that covers Layer 2 mutlicast better. Can we make this more generic?

    Rahul: Open if there is interest

    Vach Kompella: This has requirements support – but need to formalize the requirements to cover mutlicast. Comment on using BGP to distribute state from PIM’s soft state to BGP hard state.

    Yakov Rekhter: Looking at history, PIM’s refresh reduction makes it more hard state.

    Vach: If PIM refresh reduction is done, why not snoop at that point.

    Yakov: questioned if CE’s will implement refresh reduction. In this, multicast use in service provider is addressed in text.

    Loa: Cut discussion here, as running short of time. Ask AD’s about document structure, and refer further discussion to mailing list.

    Soft PVC ATM-MPLS interworking for PW
    George Swallow
    Eric Gray
    Not much change in draft presented in PWE3 group. Currently taken this to MPLS and Frame Relay Alliance, and probably is a better place to discuss this draft. This draft is probably going to get reduced to code points.

    OAM procedures for VPWS interworking
    Mustapha Aissaoui

    See presentation slides for scope of draft and changes from last revision.
    Ask WG to progress document to WG status. All or nearly all people who said they have read this draft agreed to make this a WG doc.

    Mutli-hop PW Service
    Dave McDysan, MCI and Florin Balus.

    See presentation slides for MH PW challenges and solutions and for Use Cases on Inter-provider and Metro Access Interconnection.
    Solutions addressed in 2 drafts: draft-martini-pwe3-switching, draft-balus-mh-pw-control
    Further work to include: signaling, admission control, resiliency, explicit routing
    Operational Consistency – Service Management, refer to draft-ietf-pwe3-control-protocol and balus draft
    LDP extensions defined including MH PW TLV in LDP label mapping message
    Operational walkthrough highlighting steps specific to MH PW
    Slide on next steps: Does this work belong to PWE3 or L2VPN
    Connections belong to PWE3, but discovery belongs to L2VPN
    Bruce’s draft is for cases where BGP exists at stitching points, but that is not assumed here.

    Bruce Davie: You can add discovery to the other draft. Very similar to martini-pwe3 draft. So, why need to introduce this in PW signaling instead of using FEC 129.
    Keep signaling separate from routing.

    Vach: Take discussion to mailing list as it is first time this draft discussed. We are out of time.


    ARP-Mediation and IPLS Status Update
    L2VPN Provisioning & Signaling
    L2VPN OAM Requirements & Framework
    L2VPN RADIUS Auto-discovery and provisioning
    Supporting IP Multicast over VPLS
    Multicast in VPLS
    OAM Procedures for VPWS Interworking
    Multi-hop Pseudowire Setup and Maintenance using LDP