2.3.10 Layer 2 Virtual Private Networks (l2vpn)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-29

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 network.

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

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-01.txt
  • - draft-ietf-l2vpn-vpls-bgp-02.txt
  • - draft-ietf-l2vpn-vpls-ldp-03.txt
  • - draft-ietf-l2vpn-signaling-01.txt
  • - draft-ietf-l2vpn-radius-pe-discovery-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF 60

    L2 VPN meeting notes

    8/3/2004 San Diego

    Chairs: Vach Kompella, Loa Andersson, Rick Wilder



    1. V. Kompella summarized updates to the L2VPN charter. These changes allow the WG to undertake work supporting connection between different L2 technologies in order to carry IP packets.
    2. L. Andersson presented the status of WG documents:


      1. Framework-05.txt: authors believe that this version addressed comments from iesg, This needs to be verified.
      2. Requirements-01.txt, should have been sent to wg last call
      3. Solution drafts:

                                                                   i.      VPLS-BGP-01.txt: requested the idr WG to review but they havenít yet come back to us

                                                                 ii.      VPLS-LDP-01.txt: WG last call on hold, authors will get back with an updated version ďend of the weekĒ.

    †† Kireeti: Will this be reviewed by MPLS WG or is the VPLS-BGP a special case in needing review by IDR WG?Loa: its special treatment for anything that touches BGP.

                                                                iii.      Signaling-00.txt: Rosen unchanged.Loa: Author may ask for WG last call via the email list.

    1. Mark Townsley, radius/L2TPbased VPLS
      1. Didnít ask for a slot, no change to the draft. Thomas Narten requests that the document be brought to the attention of the Radius Extensions WG.
    2. ARP mediation, Himanshu Shah, Ciena
      1. Historic summary: first presented 2 years ago, initial feedback is IETF doesnít want to get involved.After some discussion it is included in the charter now.
      2. Motivation:
      3. Problem: 2 attachment circuits are of different types, one side asks for IP address of the other end
      4. Recent updates:

                                                                   i.      clarified address learning procedures for PE that is connected to Ethernet

                                                                 ii.      Clarified IPCP participation procedure

      1. Request: accept as a WG document
      2. Chairs asked for show of support in the room for the document. Strong support indicated by show of hands. Support to be confirmed on the email list prior to final decision on making the draft a WG document.
    1. Marc L., Riverstone, VPLS-LDP-applicability
      1. Updated it to align with the requirements in requirements-draft
      2. Changes:

                                                                   i.      organization to improve idea flow

                                                                 ii.      references to the L2VPN Requirements document.

      1. Vach: is there enough experience to write a AS draft
      2. Marc: yes, the draft talked about deployment experices
      3. Ali: take it to the mailing it
      4. Vach: Will ask the question on the mailing list and see if there is consensus to make this a WG document. The Chairs specifically request input from service providers with deployment experience.
    1. Matthew Bocci, ďATM signaling interworking
      1. Background: tunneling ATM signaling & routing over vpws
      2. Problem statement: pnni is being deployed on wide scale in ATM multi-service networks, want to maintain signle e2e control plane across pnni/psn tunnel signaling
      3. Architecture: psn tunnel is a single-hop pnni link, one PE support both Pnni/tunnel signaling. PSN is transparent to PNNI, no changes needed to pwe3 or L2VPN protocols
      4. Next step: multiple interoperable implementations, ATM forum spec was approved last year, progress as informational RFC as an individual contribution not as a WG contribution.
      5. Kireeti: How does this relate to work in the MPLS/Frame Relay Alliance (MFA)and do we have a liaison with them?
      6. Andy: yes there is a liaison, MFA work is behind the ATM forum work but will be more general.


    1. Swallow, Cisco, L2VPN spvc service spanning ATM & PSN, opposite to Matthewís work
      1. Problem statement: some sites of a customer on ATM network some on MPLS network
      2. Requirement:

                                                                   i.      Automatic:

                                                                 ii.      Recovery no per VC/vp config at ATM/psn boundary

                                                                iii.      Minimal to no change to ATM software

      1. Solution

                                                                   i.      Addressing is key

                                                                 ii.      PWE identifiers: 2 identifiers for circuit: SAI & TAI, structure of SAI, TAI: AGI & AII

                                                                iii.      Mismatched identifiers: ATM vs pwe3

                                                               iv.      Described NSAP format

                                                                 v.      Described how to map identifiers

                                                               vi.      MPLS/ATM interface: outside scope, but FYI.Interface between ATM and MPLS could be pnni or other

                                                              vii.      ATM setup; PAE to ME (ATM to MPLS) direction, ME terminates PNNI and initiate MPLS signaling as needed

                                                            viii.      MPLS setup: MPE to ME:

      1. Conclusions: protocol additions are minor, can be added to L2VPN signaling draft
      2. Vach: what do you want from this WG?
      3. George: TBD, discussion and input from the mailing list would be useful
      4. M. Aissaoui: Is the intent to request that an AGI type be dedicated to this application and be assigned by IANA?
      5. George: intent is that both PEs use the same method and this should be added to the L2VPN signaling draft.
      6. Hamid: this work is being explored in the mfa as well, described a case and said that auto-discovery cannot be done
      7. George: not trying to solve that problem.Can solve a majority of the problems and attack others as we move along
      8. Vach: tell us what you want and we will see if we can honor that
    1. Peter Busschbach, Lucent, using BGP NLRI to signal ATM information
      1. ATM over an MPLS core, the general model doesnít scale
      2. Explained why BGP can be used to improve scaling
      3. BGP path selection and ATM route selection: a PE (pe3) will have both BGP and pnni, define a new afi / safi for ATM addresses, defined new extended community attributes: ATM admin weight (new), RT (route target)
      4. Request to become a WG document
      5. Loa: all works that touch IDR should be done by IDR WG.Since this doesnít touch L2VPN signaling.So this needs to go back IDR
      6. Sue: clarification:. the work needs L2VPN wg bless before IDR will take it.
      7. Vach: find out whether mfa want it and if yes, make a request to the IDR WG
      8. Peter: mfa wants the IETF to bless it before moving ahead.
      9. Kireeti: L2VPN is the closest wg to take it.Currently not in L2VPN charter.Need to change the charter. If the charter is changed, decide whether to bless it or not, and then inform IDR.
      10. Alex Z.: let the mfa send a liason statement to IDR
      11. Kireeti: if the MFA did so, is it enough for the IDR to move forward
      12. Rosen: how many address needed
      13. Peter: 1000s to 10000s
      14. Rosen: address it in the document
      15. Peter: OK
    2. Dinesh Mohan, Nortel: VPLS OAM requirements and framework
      1. Discussion following the presentation in Seoul concluded that L2VPN WG should work on VPLS-specific OAM mechanisms and requirements but should not replicate work in other standards bodies.
      2. This document describes requirements areas: discovery, connectivity, frame loss/delay/jitter, data path execution etc
      3. Described notions of different domains, maintenance points and intermediate points.
      4. How different layers come together: service OAM on top of network OAM on top of transport link OAM
      5. Whatís next: accept as WG document, continue coordination with other bodies, extend this document as an overall L2VPN requirements and frame work document. Moderately strong support for this becoming a WG document was shown in the room.
      6. Vach: need some more discussion in the mailing list
    3. Vasile, Nortel et alBFD extensions for PW Exchange of Fault Notifications
      1. Background: current LDP satus tlv mechanism is useful and viewed as minimal default implementation for interoperability, but it loads the control plane
      2. Approach

                                                                   i.      If you have BFD, use BFD ÖÖÖ..

      1. This document differs from draft-aissaoui-l2vpn-vpws-iw-oam-01 in that it presents an inband alternative to PW status signaling.
      2. Though LSP-Ping could notify remote PE of the AC defect, that involves more processing by the control plane.
      3. Discussion to continue on the email list.
    1. Mustapha Aissaoui, OAM procedures for VPWS interworking ,
      1. Open issues:

                                                                   i.      Discussion of defect loop emulation model

                                                                 ii.      Action over an ATM AC as a result of a PE receiving a PW defect indication for a defect in the PW transmit direction

                                                                iii.      Check L2TPv3

      1. Next steps:

                                                                   i.      Address open issues

                                                                 ii.      Get more feedback on email list

                                                                iii.      See is this can become a WG document.

      1. Chairs request show of support in the room. No strong consensus shown. Discussion to continue via email.
    1. Vach Kompella: LDP-based discovery server
      1. Step 1: PE registers at the discovery server
      2. Step2: learn membership: server relay membership information to other relevant PEs
      3. Step3: when some PE leaves, de-register, and server will inform other PEs.
      4. Ali: a different server for L2TP v3?
      5. Sasha: whatís the difference from the radius approach?
      6. Ali: auto-discovery should be separate and independent from signaling so that it can be re-used
      7. Hamid: radius is to avoid BGP, why another way to avoid BGP?
      8. Vach: there are SPs that donít want to use BGP-based or Radius-based approach
      9. George: need recovery procedure
      10. Luca: there was a stokes-draft, LDP-based, no need for discovery server
      11. Rosen: not enough attention to single point of failure etc
      12. Yakov: just add whatever BGP has to LDP and LDP will work.
      13. V. Kompella and L. Martini may develop draft to present to the WG
    2. Giles, Tellabs,VPLS auto-discovery
      1. LDP-based,

                                                                   i.      requirements

    1.      Node discovery

    2.      Service discovery

    3.      Service signaling

    4.      Tunnel signaling

                                                                 ii.      Meta issues

    1.      Should node/service discovery be combined

    2.      Want to minimize number of issues

      1. OSPF-lsa based

                                                                   i.      Issues: scope of type 10 lsas

                                                                 ii.      Require another draft for IS-IS

                                                                iii.      Canít work across areas

      1. LDP-based, stokes-draft

                                                                   i.      Some SPs donít use hop-by-hop LDP and may be resistant of using LDP

      1. LDP discovery Server

                                                                   i.      Issues

    1.      involve major changes to LDP

    2.      signaling via proxy may not improve scaling relative to LDP

      1. BGP-based

                                                                   i.      Some SPs donít want to use BGP

      1. Radius

                                                                   i.      Adds an additional protocol

                                                                 ii.      Doesnít inform PEs when PEs are added/deleted

      1. See presentation slides for summary of pros and cons for each approach



    Signalling Interworking for ATM VPWS
    VPLS OAM Requirements & Framework
    BFD Extensions for PW Exchange of Fault Notifications
    OAM Procedures for VPWS Interworking