2.3.11 Layer 2 Virtual Private Networks (l2vpn)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-27


Shane Amante <Shane.Amante@Level3.com>
Vach Kompella <vach.kompella@alcatel.com>

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

Russ 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 2003  Submit an I-D describing MIB for VPLS
Aug 2003  Submit an I-D describing MIB for VPWS
Aug 2003  Submit an I-D on OAM for VPLS
Aug 2003  Submit an I-D on OAM for VPWS
Oct 2003  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 2003  Submit VPLS solution documents to IESG
Dec 2003  Submit VPWS solution documents to IESG
Jan 2004  Submit IP-only L2VPN solution documents to IESG
Feb 2004  Submit MIB for VPLS to IESG
Feb 2004  Submit MIB for VPWS to IESG
Mar 2004  Submit OAM for VPWS to IESG
Mar 2004  Submit OAM for VPLS to IESG
Apr 2004  Submit OAM for IP L2VPN to IESG


  • draft-ietf-l2vpn-l2-framework-05.txt
  • draft-ietf-l2vpn-requirements-05.txt
  • draft-ietf-l2vpn-vpls-bgp-05.txt
  • draft-ietf-l2vpn-vpls-ldp-07.txt
  • draft-ietf-l2vpn-signaling-06.txt
  • draft-ietf-l2vpn-ipls-05.txt
  • draft-ietf-l2vpn-radius-pe-discovery-02.txt
  • draft-ietf-l2vpn-oam-req-frmk-04.txt
  • draft-ietf-l2vpn-arp-mediation-04.txt
  • draft-ietf-l2vpn-vpws-iw-oam-00.txt
  • draft-ietf-l2vpn-vpls-mcast-reqts-00.txt

    No Request For Comments

    Current Meeting Report

    IETF 64: Layer 2 Virtual Private Network WG (l2vpn) Meeting Minutes
    Monday, November 7, 1300-1500
    I) Administrivia
    II) WG Document Status (Vach)
       WG Doc Status:
       + draft-ietf-l2vpn-requirements-05
         - Only minor changes to fix id-nits, in IESG Queue
       + draft-ietf-l2vpn-l2-framework-05
         - RFC-Editor: Blocked on reqmt's
       + draft-ietf-l2vpn-vpls-bgp
         - GenArt review asked for some changes, to align with VPLS-LDP.
           Changes agreed upon; should be done shortly after IETF 64.
       + draft-ietf-l2vpn-vpls-ldp
         - GenArt review asked for some minor changes; changes agreed upon,
           should be sent out soon.
       + draft-ietf-l2vpn-ipls-05
         - WG Last Call after IETF 64
       + draft-ietf-l2vpn-arp-mediation-04
         - WG Last Call after IETF 64
       + draft-ietf-l2vpn-signaling-06
         - WG Last Call completed, WG chair analysis done, sent to Mark;
           Mark to proccess & shepherd through IESG.
       + draft-ietf-l2vpn-radius-pe-discovery
         - Needs more work, esp. views from SP's.
       + draft-ietf-l2vpn-oam-req-frmk
         - Dinesh to present changes -03 -> -04 at this meeting
       3 New WG Docs:
       + draft-ietf-l2vpn-vpws-iw-oam-00
         - Been around a long time; probably ready for WG Last Call.
       + draft-ietf-l2vpn-vpls-mcast-reqts-00
         - Fairly new WG draft, but borrows from mcast work in L3VPN with
           mods to work in L2VPN, so quite mature already.  Good response on
           it, lots of SP work also.  Should be going to WG Last Call
           fairly soon.
       + draft-raggarwa-l2vpn-vpls-mcast-01
         - After IETF 64, will be republished as WG Draft.  ID is about
           methods/procedures to create mcast trees in L2VPN.  Discusses
           encapsulation, signaling protocols, general architecture of
           VPLS multicast.
         - Separate drafts on PIM snooping & LDP for L2VPN mcast, (both
           presented at this meeting).
    III) VPLS Interoperability with CE Bridges
       Ali Sajassi
       - Overview of ID History: 
         + At IETF 63 asked to partition draft into mandatory and optional
         + This new version accomodated those suggestions.   
       - Objectives
         + Identify issues associated with IEEE bridges as CE devices
         + Demonstrate how to use PE models from L2VPN-FR to address
           majority of interop issues.
       - Re-categorization
         + Mandatory Issues: service mapping of AC, CE bridge protocol
           handling, partial mesh of PW, multicast.
         + Optional Issues: customer network topo changes, redundancy
           and dual-homing, MAC address scalability, ease of interop
           with Provider Bridges.
       - VPLS PE Model as defined in L2VPN Framework
         +  What if multipoint Ethernet service spans multiple networks
            (MPLS, 802.1ad, etc.)  Service is end to end, but VPLS is just
            in an MPLS domain.  VPN framework models a PE as a bridging
            component facing the customer ACs and a LAN emulation model
            facing the core (consisting of VPLS forwarders).
       - VPLS PE Model as defined in L2VPN Framework
         +  Bridge module can be split into C-VLAN and S-VLAN are per 
            802.1ad.  Once you use that model it becomes clear how you can
            interop with customer bridges/CE protocols and support
            different mappings into VPLS.
       - VPLS as (V)LAN Emulation
         + For a given VPLS instance LAN emulation is done by VPLS forwarders
           with full mesh of PWs, and mapping into bridge module.
       - Questions: Any section needs clarification?  Authors prefer to hear 
         it on the list to clear it up.
       - Given that this is based on L2VPN framework model and elaborated
         upon it to get L2VPN working then is consistent with work here in
         L2VPN, so therefore can we move to WG status?
    Q&A at the Mic:
    * Himanshu Shah - how is topology change notification from customer STP 
      sent to VPLS so you can do MAC withdraw?
    * Ali - draft documents two ways.  (1) customer TCN can be mapped to IEEE 
      provider bridge TCN - message generated per customer with a special MAC 
      address that when it goes to specific nodes tells them to flush the 
      MACs for that VLAN.  (2) use LDP MAC withdraw message.  If you do that 
      then you need to interop with provider bridges.  => first way has no 
      interop issues, second way does.
    * Florin Balus - looking at picture.  Should each forwarder be modelled 
      as a port in the bridge (rather than muxing to the bridging module)?
    * Ali - discussed on mailing list.  VPLS forwarder does MAC learning per
      PW.  That whole set of PWs can map to a virtual interface in the 
      bridging module - where each VPLS maps to a VLAN.
    * Florin - so each forwarder is a bridge?
    * Ali - IEEE bridge is data plane plus control plane.  With this model 
      the VPLS forwarder is a MAC filtering database.  Doesn't mean that you 
      can't *implement* it in one filtering database.
    * Shane - will send out mail after meeting to check consensus on moving 
      to WG status.  Please look out for that.
    * Ali - final note, would like to recommend reading of the L2VPN 
      framework so you can get an idea of how this solution maps to that 
    IV) Requirements for Multicast Support in Virtual Private LAN Services
       Yuji Kamite
       - Draft covers problem statement and shows specific functional reqs
         for solutions.  Initially published in June, but incorporates a lot 
         of info from L3VPN.  Major issues resolved in Sep 2005 issue.  Now
         a WG doc.
       - Major changes:
         1) "Traffic Tax".  What is the weight of the two issues of (a) 
            replication to non-member sites (b) multiple copies on one shared 
            physical path.  Solution - SHOULD try to solve both issues, but 
            MUST identify which issues it tries to solve and SHOULD provide a
            basis for evaluating how well it solves the issues (if it's 
         2) IGMP snooping.  IGMPv2 vs v3.  Refers to MAGMA-SNOOP.
         3) L2 Processing - Corrected statement of L2 processing; no reason
            to rule out L2 techniques, (CGMP, GMRP, etc.)
         4) IPv6 issue raised at last IETF - conclusion was no changes needed 
            as MLD snooping was already mentioned and NDP will also work,
            (see comment on list: Aug 19 2005).
       - Editorial changes etc.
       - Next Steps
         1) Need to clarify remaining issues, (e.g. application 
            considerations, how to flood L2 control frames (BPDU), what 
            protocols to snoop (PE-CE), protection/restoration wrt PIM hello 
         2) Need more feedback on the OAM section (6.5) from implementors and 
            operators.  Please send comments to list.
    Q&A at the Mic:
    * Ijsbrand Wijnands (?) - this doc covers IP and L2 (control plane) 
      multicast.  Why include L2 packets - they're already broadcast?  If we 
      limit scope to L3 then solution will be easier.
    * Yuji - Main idea is to optimise L3 multicast over VPLS, but it must 
      also consider how to deal with L2 frames which use multicast MACs.  
      Required that solution has an optimization for L3 data but also carries 
      L2 control frames in a way that doesn't cause operational (or other) 
      issues.  So trying to show what the potential issues are.
    * Yakov Rekhter - Agreed to previous comment.  It's best to document IP 
      multicast over VPLS and *then* document L2 or whatever else is left.  
      Much more benefit to addressing former than addressing latter.
    V) PIM Snooping over VPLS
       Venu Hemige
       - At last IETF, consensus of WG was to split VPLS multicast into
         4 components:
         1) How to build mcast trees, (Rahul's draft)
         2) IGMP snooping (in magma)
         3) PIM snooping in VPLS, (this draft)
         4) PE-PE mcast state distribution (LDP or BGP) -- to prevent 
            snooping on PWs
       - Therefore, draft-serbest split into two drafts: this one and
         the LDP one.
       - PIM Snooping in VPLS: In VPLS multicast traffic is flooded to all
         ports, (whether they want to receive it or not). PIM snooping 
         prevents unwanted traffic going to ports that don't want it, (Issue 
         A of Reqmt's Draft). PIM snooping on ACs.  Forwarding rules for when 
         IGMP and PIM are both active. Requires PIM join supression to be 
         disabled, (to keep it clean).  Can use either PIM snooping on PWs or 
         LDP to distribute state info.
    * Ali - Question on PIM snooping vs. LDP.  Venu - Either/or can be used.
       - Changes from draft-serbest. Removed IGMP snooping; updates on PIM
         snooping procedures; requires CE's to disable PIM Join suppression;
         PIM join/prune are flooded in VPLS; LDP procedures to 
         draft-qiu-serbest-mcast-ldp; modified procedures for duplicate
         traffic -- new procedures use control plane, scales better, no
         data plane requirement.
       - PIM snooping basic example: Joins directed to RPF neighbor, but
         flooded so seen by other PE's and CE's.  Only PE's on the path to
         the RPF neighbor build state. New procedures in control plane to 
         prevent duplicates, (scales solution better).
       - Assert mechanism to prevent duplicate traffic. VPLS split horizon 
         rules dictate that traffic ingress on PW should not egress on 
         it. But want to allow traffic on any port to reach a router that 
         forwards traffic onto a VPLS instance, result in assert between
         rtrs. New rules: (1) add incoming port to outgoing port list; and,
         (2) when an upstream PE sees a join it adds PW towards RPF neighbor
         to the outgoing port list. This allows the assert to happen and to 
         avoid duplicates.
       - PIM snooping is needed to make VPLS multicast work. Lots of 
         interest in solving this issue. Can it be WG?
    Q&A at the Mic:
    * Dino Farinacci - In PIM, join supression was there to enable scaling 
      over Ethernet.  Why would disabling it globally help you scale?
    * Venu - Part of the problem is that if you don't disable join supression 
      then VPLS won't work.
    * Dino - I know why you did it, and I know you want it to make things 
      work. But it won't work if you disable it either.
    * Yakov - this is about tradeoffs.  Not black-and-white.  If you want to 
      restrict traffic to PEs that want it then you have more joins. But if 
      you don't then you flood.  So it's a tradeoff.  A solution should allow 
      for the tradeoff and identify them.
    * Ijsbrand - You can make it work without disabling join supression.
    * Venu - Yes, that was presented in earlier draft at last IETF, but it 
      was deemed that those were 'hacks'.
    * Ijsbrand - just an issue of how you define PIM snooping.  If you want 
      this to interoperate you need to decide whether to allow/disallow 
      supression.  I'd rather prefer Join suppression and let the PE router, 
      (i.e. the entity that does PIM snooping), do the right thing.  Maybe
      the draft should not explicitly require disabling Join suppression on 
      the CE routers, so we don't have to change their behavior.
    * Ali - have you discussed getting feedback from PIM or MPLS WG as to 
      using LDP for passing PIM messages?
    * Venu - No.
    * Ali - Would be good to get it.
    * Venu - We will do that.
    * Suresh - Is disabling join supression an option or a requirement?
    * Ijsbrand - If the CE wants to disable join supression then go ahead, 
      but the requirement here shouldn't require it. The draft assumes that 
      PIM snooping is both edge/core functionality. Not necessarily the right 
      thing to include the core - as there are other ways of building the 
      trees. Should core/edge be separated into two drafts?
    * Venu - Rahul's draft addresses how to build trees in core. When we
      talk about LDP we're talking about VPLS join information.
    * Suresh - Some history/perspective of Join-Suppression Issue. When
      this draft was presented last time we didn't want to disable join
      supression, but it requires the PE's to participate more than just
      snooping. By requiring Join Suppression, PEs just snoop - no packets
      have to be modified. Without Join Suppression, the PE would
      become an active element in the network, (not just a snooping device).
    * Tom Morin - About Join Suppression issue on PE's. Would it work also
      if you use different tunnelling for multicast, (e.g. P2MP tunnels)?
    * Venu - Yes. We have talked to Rahul to make sure we're on the same 
      page. Please point out any discrepancies.
    * Tom Morin - Some parts of draft are repeats of reqmt's doc. It maybe
      best to strip them out.
    * Venu - OK, will talk to you about that...
    * Venu - Asked if this could become a WG document?
    * Shane (Chair) - We will take it to the list, to iron out whether we
      want or don't want Join Suppression in the ID.
    VI) Using LDP for VPLS Multicast
       Ray Qiu
       - LDP already used to establish PWs and we don't want new protocol; 
         Good to use LDP as runs over TCP -- no state refresh, so it scales; 
         No need to send state to all PE routers (if PE has no listeners?); 
         therefore, LDP is good.
       - Only snoop on ACs, so it scales well. C-multicast control packets
         are forwarded "as is," based on destination MAC address. Therefore, 
         we don't modify packets.
       - New LDP Mulcast Capability TLV, carried in LDP initialisation 
         message to do capability discovery. Another TLV in notification 
         message with various sub-TLVs. Will modify PIM Hello sub-TLV in
         next revision of draft, (MAC address isn't needed -- had thought it
         was required in corner cases).
       - PE floods Joins upstream, but also sends LDP messages, to build
         PIM neighbor states. LDP also used to build Join/Prune state.
       - Next steps: Questions?  WG document?
    Q&A at the Mic:
    * Dino - You need explicit tracking in LDP to make this work, LDP doesn't 
      have that concept today. When you send Join's from multiple receiver 
      PE's, you need to keep track of them so you know when to Prune.
    * Ray - encoding here is aligned with PIM state. State machine is in the 
      PIM snooping spec. Don't think anything needed for LDP.
    * Suresh - PE downstream that has CE receivers is the one which 
      accumulates Joins.
    * Dino - Fanout from the ingress PE requires you to know when each one 
      has stopped listening.
    * Suresh - It's a per-peer thing. 2 diff PEs on 2 diff sessions.
    * Dino - that's explicit tracking.
    * Venu - no need for explicit tracking in LDP. It's needed in the 
      snooping component. PIM keeps state as to where it receives the Join.  
      don't need to change anything in LDP.
    * Dino - Absolutely right. Now we have explicit tracking in 3 protocols.
    * Venu - You need some entity to gather info/state. There's no protocol 
      involved.  PE's snoop - they don't run PIM...
    * Ali - before we consider this as WG doc, we should take this to the PIM 
      and MPLS WGs before we overload LDP.
    * Albert Tian - This is using LDP to carry multicast routing info. People 
      know that PIM refresh reduction is being worked on in the PIM group. 
      TCP as a reliable transport makes PIM work quite similarly to this, it
      could be a viable solution to this.
    * Yakov - 2 comments: 1) Overloading is a red herring. We've done it with 
      BGP & LDP.  LDP was designed for unicast labels, then it was extended
      from IP FECs to PWs and nobody complained. Why now?  2) Putting PIM 
      over TCP. If it happens we can evaluate it. Until then this is our
      only option.
    * Shane - Check on how many in favour/against/have even read the draft.
      3 in favour. More against. 12 or so read it. Take to list and iron out 
      the issues. 
    VII) L2VPN OAM Requirements and Framework
      Dinesh Mohan
      - L2VPN OAM. Draft introduces a framework so we can address how OAM is
        applied in different parts of the network. Points out the native 
        mechanisms that can be applied and also what impact this has on the
        PSN layer, (specifically the OAM mechanisms across that). Service
        layer to make use of native technology OAM. Underlying PSN layers
        make use of PW/LSP OAM.
      - Draft-04 Editorial Updates: Addt'l authors, contributors added 
        (mainly SP's). Section 1.1 (Terminology) added. Section 4
        reorganized and other sections added for better readability,
        specifically: distinguishing VPLS and VPWS OAM. VPWS aspects 
        consolidated into this draft.
      - Technical Updates: Section 3.2, on OAM domains, clarified -- needed 
        to draw distinction between hierarchical and adjacent domains. At 
        least in PWE3 there is now MS-PW. Section 5 added to discuss VPWS 
        framework, based on draft-delord-pwe3-oam. Added section 9, OAM
        operational scenarios, to provide info on what mechanisms can be
        used for different OAM layers, but not prescriptive.
      - Two models in which VPWS services can be managed:
        1) CE owned by customer. Access network is physical interface from
        CE-PE, so not much OAM to be done on AC, and monitoring is shared 
        between SP and customer. SP monitors the PW.
        2) CE managed by SP. SP has end-to-end manageability, therefore runs
        end-to-end OAM. Two sub-models, depending on whether PE's are client 
        service aware. If AC is an access network the SP needs to monitor 
        that, and again there will be an underlying tunnel layer that 
        provides the AC PW.
      - Technical Updates:
        + Added an Appendix on alternate management models, specifically 
          around scenarios where the PE can't do the native service OAM.
        + IPLS OAM Sections removed, no interest or contributions.
      - Alernate Mgmt Models: 
        1) Minimal OAM. Model where provider does end-to-end OAM. Operators
           monitor segments, eg.: Access Tunnels & PSN Tunnels. Issue is that 
           it's hard to localise a fault if the service is down.
        2) Segment OAM with I/W. Interworking is required on PE, which may
           be simple or complex, depending on homogeneous or heterogenous
           VPWS. Issue is that it isn't true end-to-end OAM. Lots of 
           variations of the Interworking Function need to be realised.   
       - Next Steps:
         1) Need to add the VPWS OAM, (based on the delord draft). Will add
            a section after this meeting.
         2) Need to update some refs.
         3) Targetting Last Call by the next meeting, (would have done it 
            this meeting if the above 2 issues were addressed in time).
         4) Initiate some solution drafts. May amount to just highlighting 
            how existing mechanisms in PWE3 and L2VPN can be used in 
            conjunction with the native service OAM.
         5) Also can initiate draft on interim reqmt's, (minimal OAM
            solutions), but would need volunteers to author this.
    Q&A at the Mic:
    * Vach - I am confused as to what direction you're taking. One sense is 
      we do native OAM based on AC, (e.g.: ATM PW). Are you suggesting that
      native OAM is not sufficient? Is the draft suggesting that IW is not
      required at all?
    * Dinesh - Draft provides framework on how end-to-end service monitoring 
      can be exercised. One option is to apply native OAM for end-to-end 
      service OAM.  If end-to-end service monitoring is not sufficient with
      native mechanisms, then we can do some sort of interworking. How this
      is used in terms of a solution is that each solution can discuss which 
      model it is using and what requirements it meets.
    * Himanshu - Just to be clear, are you proposing that for Ethernet OAM 
      (where IEEE are working on OAM) that a VPLS PE should do something 
      specific on the PW?
    * Dinesh - the point is that you can monitor at service layer
      (e.g. Ethernet OAM) depending on whether the PE has the capability to
      do it or not. This draft only gives an overview of the full picture.  
      The solution drafts, in the future, can show how it works.
    * Chair - Does anybody have any other comments on this draft?
    * Himanshu - Want to go back to multicast. Would like to know if 
      multicast pruning is required or not. Is that the issue or is LDP
      not required?
    * Ali - can you take to mailing list?  Going back to L2VPN framework.
      Since it now has hierarchical and peer models it is very inclusive so
      think it is ready for Last Call. Please read and make comments on the
      mailing list.
    * Shane - when will you have a final draft?
    * Ali - January?  Have thanksgiving then vacation etc.
    * Dinesh - would second that.
    * Shane - be prepared to read this in Jan so it can be ready to Last Call
      (perhaps) by next IETF.
    * No more comments, meeting adjourned.
    VIII) Meeting Closes


    WG Document Status
    VPLS Interoperability with CE Bridges
    Reqmt's for Multicast Support in Virtual Private LAN Services
    PIM Snooping over VPLS
    Using LDP for VPLS Multicast
    L2VPN OAM Requirements and Framework