2.3.6 Layer 2 Virtual Private Networks (l2vpn)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-30

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.wasserman@nokia.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: https://www1.ietf.org/mail-archive/working-groups/l2vpn/current/maillist.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 L2 VPNs--L2 service across an IP and an MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN segment or a point- to-point circuit.

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
Oct 03  Submit L2 framework to IESG for publication as Informational RFC
Done  Identify VPLS and VPWS solutions for the WG
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-vpls-requirements-00.txt
  • - draft-ietf-l2vpn-l2-framework-03.txt
  • - draft-ietf-l2vpn-requirements-00.txt
  • - draft-ietf-l2vpn-vpls-bgp-00.txt
  • - draft-ietf-l2vpn-vpls-ldp-01.txt
  • - draft-ietf-l2vpn-signaling-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes L2VPN WG November 12, 1530-1730
    Scribe: Kenneth Sundell 
    Scribe: Alia Atlas <aatlas@avici.com>
    L2VPN wg agenda IETF58 - Minneapolis
    1. Agenda bashing
    Loa: There is a custom in the IETF not to use two chairs from same 
    company Rick to stay until next meeting (Rick and Vach at the same 
    No objections.
    Loa went through the agenda
    No changes to agenda
    2. WG Status, Vach Kompella
    At risk:
    Aug 03  Submit an I-D describing MIB for VPLS 
    Aug 03  Submit an I-D describing MIB for VPWS 
    Vach: Submit Enterprise MIBs as jump start
    Aug 03  Submit an I-D on OAM for VPLS 
    Aug 03  Submit an I-D on OAM for VPWS 
    Need to follow the OaM development happening in the MPLS WG closely 
    before persuing the work Need more participation
    Oct 03 Submit L2 requirements to IESG for publication as 
    Informational RFC Into last call soon (some security 
    considerations issues)
    Oct 03  Submit L2 framework to IESG for publication as 
    Informational RFC
    Ready to go too
    Completed or threreabouts
    Done    Identify VPLS and VPWS solutions for the WG 
    Dec 03  Submit VPLS solution documents to IESG 
    Dec 03  Submit VPWS solution documents to IESG 
    A last call warning is issued to find traction. 
    Andy Malis: Send it to the list
    Looking good:
    Jan 04  Submit IP-only L2VPN solution documents to IESG 
    Seems Achievable
    Feb 04  Submit MIB for VPLS to IESG 
    Feb 04  Submit MIB for VPWS to IESG 
    Working group documents
       a: draft-ietf-l2vpn-signaling-00.txt  To be presented.
       b: draft-ietf-l2vpn-requirements-00.txt Waiting for Russ Housley's 
    comments (sec advisor) otherwise ready to go
       c: draft-ietf-l2vpn-l2-framework-03.txt  Eric Rosen
       d: draft-ietf-l2vpn-vpls-bgp-00.txt  Kireeti Kompella
       e: draft-ietf-ppvpn-vpls-ldp-01.txt  Need to rename draft from 
    *ppvpn* to *l2vpn*
       f: draft-shah-ppvpn-ipls-02.txt Will be published as a wg doc
    draft-heinanen-radius-l2tp-vpls-00.txt (will be published as a wg doc) Mark 
    Townsley picked up the work after Juha Heinanen, the document was 
    already approved as a working group document (not issued as that this 
          Mark Townsley: Will resend the document with wg status, but 
    solicits comments on the list before doing do.
    draft-heinanen-radius-pe-discovery-04.txt (will be published as a wg doc) 
    Should have wg status. Greg Weber wasn't present, but Mark said that the 
    same procedure will be applied for this work as well.
    3. Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS
       Eric Rosen
    Assuming that full mesh of PW's is present, if assuption fails, 
    blackholes can occur.
    Failure modes:
      - data plane connectivity
      - PW state at edge
      - auto-discovery failure or configuration mismatch
    Bad ideas for detecting failures
      - local information (detection only)
        - mismatch between operational PWs and discovered endpoints
        - PW operational status changes
      - global information (resilience)
        - PWs as overlay network, Spanning tree
        - PWs as overlay network, run routing
        - but don't really want to run a routing protocol or spanning tree
        - overhead costs
    Not so quite bad idea
      - global information (detection only)
        - each edge tells every other edge "here are the PW endpoints i can
          talk to"
        - get global info, from each edge, set of other edges that can be
        - any edge not universally seen is removed from the mesh
    What is the reaction after constructing this information?
      - log the failure
      - or fix the failure through re-routing
      - most important is to get the detection part
    Is this worth pursuing?
    Yakov: Does it need to be new protocol to existing ones or done by nms 
    Vach: The approach is to detect, fixing things is another question
    Eric: By NMS do you mean some mgmt station or from each PE
    Yakov: From mgmt station
    Vach: Not necessarily need protocol, but we don't want SNMP gets between PEs
    Eric: In practice, using NMS to detect dynamic problems hasn't 
    historically worked well.
    Yakov: Have traps when PW goes up and when goes down, so can check 
    Vach: If just wanting to detect, then MIB could be enough.  If more than 
    Eric: Be careful.  One could build a tool to look at the MIB info to 
    determine this.  How happy are people with depending on NMS yet?
    Yakov: If all the protocol is to do is detection, then need operator 
    action using nms to fix problem
    Vach: we haven't determined the scope of the problem yet, so maybe 
    detection is sufficient
    Liam Casey: The detection time has to be fast, comparable to control 
    plane. Agree to pursuing the work. Propose to do it in the control plane as 
    opposed to the management plane for default border repair.  Suggest that 
    failure mode is "if one router can't be reached by another, then no 
    router should be allowed to reach."
    Jack Lukaski/Lewkowski: Do not reinvent the weel. use existing 
    protocols done elsewhere in this domain (SONET, ATM F4/F5 AIS).  
    Separate in-band from out-of-band.
    Vach: Asking the WG if this is an important problem to solve?
    Yes: a fair number of hands
    Opposed: None
    Vach: The consensus to be verified on the list
    Eric: Had already raised on mailing list, said wasn't important and was 
    beaten up.  But dead silence now.
    4. The "generalized FEC ID" in the PWE3 control messages, as discussed in
    draft-ietf-l2vpn-signaling-00.txt Eric Rosen
    PWE3 control protocol draft (in lc) define it
    Superset of signaling paradigm in VPLS-LDP spec (L2VPN WG draft)
    Eric: Can we all agree to use it?  It has been sparsely discussed on the 
    mailing list by a few persons.  There do not seem to be any 
    substantive technical issues with it
    Vach: Think we can close on this but want to hear others opinions. Naming of a 
    VPLS is going to change substantially.  Not many are involved in the 
    discussion (even if people seem to go off and implement it) Have a couple of 
    issues: most important is to drop the distributed VPLS part, since nobody is 
    doing that.
    Eric: Some people in WG are interested in distributed VPLS.
    Inter-provider case may need it.  Friends from Nortel should jump up.
    (Aside from Vach: Hamid did come to chairs and ask that it should be 
    Rick: Input from VPLS implementers?
    No response
    Eric: We got so tired doing the framework and requirements that at this 
    point nobody cares..?
    Loa: Hmmm no responses.  This is how we handle it, three weeks on the 
    mailing list, no comments and we go with the solution.
    End of session


    VPLS/IPLS Full Mesh Failures
    Generalized FEC Id