2.3.5 Layer 2 Virtual Private Networks (l2vpn)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-04

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

    Current Meeting Report

    WG status - Vach
    big trouble with MIBs.  Need volunteers.  Vach had no time to do straw men.  
    After meeting can anyone who is willing to work on VPWS/VPLS MIBs please get 
    together with Vach.
    draft on OAM for VPLS expired as not resubmitted.  Will get it 
    draft being presented on OAM for VPWS by Dinesh Mohan.
    L2 requirements ready for submit to IESG.  Will do WG last call 
    immediately after IETF.
    L2 framework in good shape.  Eric Rosen has some nits to fix which he'll do 
    once fixes some nits in other drafts.
    Kireeti ready to last call BGP VPLS soln.  Vach has work to do on LDP VPLS 
    soln.  Asked at last IETF for comments on the change of FEC.  Only 3 
    comments.  This time will just go ahead and do it.  Should be ready to 
    submit for last call by the week after IETF.
    VPWS solutions need to check with authors if they are ready.
    Need to talk more about IP-only L2VPN docs.  These are 
    Work on MIBs
    VPLS/VPWS OAM work
    applicability statements for VPWS and VPLS
    	Marc will present on VPLS-LDP
    	Can Kireeti take a crack at VPLS-BGP?
    Kireeti - OK, will do applicability for VPLS-BGP
    Discussing BGP with Routing Area directors.  Docs that propose changes to 
    routing area protocols need to be addressed.  Not in agreement with ADs.  We 
    think there is need to have full standard in one doc and take the BGP 
    related parts to IDR for last call/WG approval.  Not clear how we'll do it - 
    will sort out this week.
    Kireeti - have a couple of Qs on applicability for BGP.  Does this 
    process of reviewing BGP part of VPLS apply only to VPLS-BGP, or do we take 
    VPLS-LDP to MPLS, and do we take 2547 to IDR?
    Vach - this is a general direction for everything we do here.  For VPLS 
    will piggyback on PWE3.
    Kireeti - does that mean we take Martini to MPLS also?
    Vach - do we take a section and present it at the other group, or 
    present the whole thing.  Doesn't make sense to extract BGP related 
    stuff.   Trying to figure out what the ADs want us to do.  LDP should be 
    vetted in MPLS and BGP in IDR.
    Kireeti - as a precedent when we did TE we didn't pull stuff out.  The 
    reason we pulled out routing in GMPLS was that there was two ways of doing 
    it.  Had there been one way we'd have had one doc.
    Vach - what does Alex want?
    Alex - the default mode should be that all changes to protocols happen in 
    protocol specific WGs.  Probably should look at specific docs and see if it 
    makes sense to pull out the protocol specific stuff.  Either way docs that 
    propose changes should go to protocol specific WG and check that we have 
    consensus that this is the right way (rather than just no 
    objection).  Goal is not to stall the work, but to ensure that the expert 
    group has a chance to comment on the work and agree that it's the right way 
    to do it.
    Kireeti - is this just for BGP?
    Alex - should look at all docs.
    Kireeti - 2547?
    Alex - 2547 has been there too long.
    Loa - we can cut discussion off here.  We've got a feel for the scope.  Got a 
    problem and we need to do something about it.
    Alex - will be sorted within a couple of weeks.
    Sasha V. - have we had a decision on whether ARP mediation is in scope?
    Vach - that's why I'm going to present on why ARP 
    mediation/interworking of a particular type is in scope.
    Yakov - question on VPLS LDP.  Must specify at least one default mode for 
    auto-discovery to have interoperable implementations.
    Giles - manual config?
    Yakov - spell it out in spec?
    Vach - OK.
    Marc - what discovery we use (manual vs provisioned vs 
    autodiscovery) is implicit in VPLS draft
    VPLS Applicability - Marc Lasserre
    mix of the work in the VPLS draft and practical experience with 
    base draft specifies signalling and bridging rules.
    applicability describes the applicability of the base draft to meet the 
    requirements in the requirements draft.
    1) Overview of solution operation and alternative approaches (and 
    migration from the latter to the former)
    2) scalability
    3) deployment aspects
    (2) and (3) may be combined in future as overlap.
    for scalability have same old L2 issues:
    1) full mesh - and use of H-VPLS to break mesh
    2) MAc address scaling (can't summarise them so need mechanisms to cope 
    with large numbers).  One solution is to say interconnect model is to use 
    routers and limit to one per site, but in the case of a bridge we have 
    other mechanisms - e.g. MAC limiting per port/VLAN per VPLS etc.
    3) broadcast - need to protect SPs resources by limiting amount of 
    broadcast per customer or per VPLS instance
    4) replication - need to look at how efficient it can be in L2 domain.  
    Need to be wirespeed.  Look at how hierarchy can help.  Also enhance 
    multicast replication by using IGMP snooping.
    for deployment we have:
    provisioning/management has various requirements:
    	1) How do we do PE discovery.  Various competing approaches for 
    auto-discovery, plus management based solution (OSS).
    	2) traffic conditioning at ingress - limit amount of traffic a 
    customer can send per VPLS (to meet specific customer SLAs, and to 
    protect core SP resource).
    	3) how to do TE on PSN tunnels for VPLS
    	4) will have a couple of drafts presented on fault and performance 
    migration aspects - how to go from Q or QinQ to VPLS and how to use VPLS to 
    interconnect QinQ islands etc.
    multihoming aspects.  When MTUs are multihomed then how do we cope.  Could 
    use STP or could use primary/secondary links.  So could be handled in 
    customer network (using STPs - means PEs are transparent and backdoors are 
    allowed).  Primary/secondary is similar - up to customer to dictate how it 
    works.  SP doesn't interact much with customer network.  However still need 
    for SP to guarantee loop-free topology.
    packet reordering issues (in presence of ECMP etc.)
    QoS Mappings
    multi-domain connectivity - using H-VPLS spoke to interconnect domains (one 
    spoke per domain).  How do we interwork with BGP VPN.
    interworking with FR/aTM/PP attachments:
    	- data plane is bridged encaps
    	- need to specify how to map service profiles, OAM, circuit 
    management.  Draft today on OAM.  rest still to be done - no draft yet.
    Security - use of per VPLS FIB, but also DoS mitigation.
    This is first rev.  Future revs need to describe capacity scaling etc 
    (hard to pick numbers as are implementation dependent).  Also how to 
    prevent unauthorised CEs attaching.
    Sense of room vis a vis WG doc?
    Yakov - mentioned need for TE in an earlier slide?  Question is this just 
    for unicast, or for unicast and multicast.
    Marc - good question.  TE today is primarily for unicast today, as is FRR.  
    Multicast gets carried over P2P PWs in VPLS so if each P2P circuit is TE 
    then OK on the protection side.  for QoS is more at ingress (rate 
    Yakov - not answered my Q.
    Marc - not required.
    Yakov - useful to clarify in this doc.
    Dinesh Mohan - in draft on OAM section you have taken some of my work into 
    consideration, along with the expired VPLS OAM draft.  Two points:
    1) some aspects in the refs you quote to IEEE.  Not .1ad.  In march will 
    have new ref.
    2) with regards to capability for MPLS-based network and PWs the 
    inter-working aspects you've mentioned will still be possible.
    Sense of room for WG doc.  Not a representative IETF - will ask the 
    question.  First time people have seen this so more a sense of whether Marc 
    should continue the work.  A few in favour.  Nobody opposed.
    VPLS Fault and Performance Management - Dinesh Mohan
    these drafts are in charter.  Trying to focus on 
    fault/performance aspects and maintain alignment with work in other 
    standards bodies.
    OAM typically has two elements:
    1) Interface between NMS and EMS
    2) Interface between EMS and nodes
    we are focussing on the 2nd.
    VPLS is an Ethernet service.  May have Ethernet or MPLS access, and an MPLS 
    core.  From customer POV OAM is CE to CE.  From provider POV it is U-PE to 
    U-PE.  From operator POV it is U-PE to N-PE or N-PE to N-PE 
    (therefore multiple operator domains for one service).  Admin 
    boundaries are important as when different bus 
    models/deployment scenarios are applied there will be different 
    responsibilities.  Will need filtering of OAM flows so they don't flow into 
    the wrong domain.
    Maintenance Points - nodes where OAM flows are 
    Intermediate Points - nodes beteen MPs which are responsible for 
    processing OAMs
    Interesting that in Ethernet domain there are IPs, but in MPLS domain 
    there aren't.
    Need to look at PW/MPLS OAM.
    This is a generic mechanism that can be applied to MPLS layer and to 
    Ethernet layer.  Is possible to have I/W between layers.  Can also be 
    applied to BGP based mechanisms.
    Location of IPs is driven by business relations and deployment 
    Some of the layerings are:
    1) Service layer = VPLS Service.  => needs service OAM.
    2) Network layer => needs network OAM
    3) Transport Links => each link has OAM
    trying to manage various entities.  An association of MPs.  May not want to 
    have all maintenance entities enabled - is a question of which entities the 
    SP is interested in managing.
    Fault Management:
    Need to detect faults, verify them, once verified isolate location, 
    notify maintenance entities, and where possible restore the fault.
    This draft focusses on detect/verify/isolate.
    OAM messages may be sent across various entities depending on reqs. for 
    For detection may take precedents from ATM etc.  Continuity Check used to 
    send periodic heartbeats.  No response expected - rather expect to 
    receive messages and declare a fault if don't get message in time.
    For verify may send a unicast loopback which is non-intrusive and 
    doesn't impact data path.  Can be used to verify if fault detected.
    Traceroute may be used to isolate fault location.  Interesting for 
    Ethernet as notion of MAC address ageout where MACs are aged if no 
    activity seen from pair of MAcs - typically 5 minute ageing.  If want to do 
    isolation have additional requirement (3 options in draft) to sort this.  In 
    IP routing tables aren't flushed so is different.
    Various information elements might be needed.  Want to discuss further in 
    this WG to find out what subset are required for VPLS.  Want OAM to 
    indicate that it is OAM.  Might need a version.  Needs an OPcode to say 
    what function it is.  Need to indicate if is customer to customer or SP to 
    SP.  Also notion of service ID and a transaction ID if that is felt 
    necessary.  Intent is to discuss requirements and more specifically the 
    information elements required.  Exact frame formats are expected to be done 
    in IEEE.
    Performance Management:
    Typically need to measure performance parms across MEs (need to know what 
    they are).  Need a collection mechanism and then 
    measure/calculate stats.  Need then to determine if SLAs at service or 
    network level were met.
    Focus of this draft is on frame loss/delay/DV measurements and on 
    availability.  Diff techs have different terms (e.g. latency and jitter 
    rather than delay and DV).  Draft has some other parameters.
    When methods are considered is possible to measure in different ways.  Need 
    to consider level of accuracy required, and cost associated with that.  
    Draft looks at 3 methods considered:
    Statistical - not accurate as OAM may differ from data plane due to 
    transients or due to forwarding.  Not very accurate.
    Data Plane Managed Objects in management plane - apply data path 
    counters to management plane.  Can be done in software. Only 
    limitation (which can be addressed) is delay between time the OAM frame is 
    inserted and time the counters can be accessed.  So results may be 
    inaccurate (but can sample to fix this).
    Data Plane Managed Objects in data plane - typically requires h/w assist but 
    is most accurate.
    Recommendation is Data Plane Managed Objects in management plane.  
    Recommendation is to use a generic method.  Typically CC is 
    unsolicited (and can be extended for perf).  Loopback is unsolicited (and 
    ditto can be extended).
    Draft also discusses how frame loss and frame delay can be measured.
    Need for further discussion in this group to identify reqs. for VPLS OAM.
    Need to co-ordinate with IETF WGs for L2VPN reqs (L2VPN) and 
    management framework for OAM (L3VPN - but has L2 components in).  Also need 
    to co-ordinate with other standards bodies (802.1, ITU-T Q.3/13, MEF).
    Rahul - need to scope out what is the meaning of VPLS OAM as far as this WG 
    is concerned.  To me traceroute would seem to be out of scope.
    Dinesh - not sure why you think Traceroute is out of scope.  It's 
    required.  VPLS is ethernet-based service and fact it's realised over MPLS or 
    IP PSN introduces layering.  Each layer may have OAM, but need 
    capability at service layer.
    Rahul - WG needs to scope whether traceroute is in or out of scope.
    Vach (WG chair hat off) - this is good work but doesn't belong here.  It's an 
    OAM for an Ethernet service, part of which includes VPLS.  VPLS is done 
    here in IETF.  But may be used in addition with Q and QinQ.  End to end 
    service OAM includes VPLSes, but isn't specific to VPLS - so doesn't 
    belong to IETF.  Ethernet header/MAC layer stuff belongs elsewhere.  If you 
    can point out what IETF-defined VPLS needs to do so your OAM works then we 
    can address that.  While VPLS has MAC layer the MAC layer is outside VPLS 
    Dinesh - in OAM layering slide was trying to address why we need this work 
    here, and why is aligned with work in other groups.  If you consider this 
    outside WG scope then need to consider that we have work on MAC 
    scaling.  We're not transparent to that.
    Vach - but you are talking about work done at MAC layer.  Ought to be in 
    IEEE or ITU.  What does IETF need to do to support that work?  This work can 
    be fully done in IEEE.
    Dinesh - still feel that part of this work belongs to this WG as much as to 
    other bodies.  When considering VPLS as a service there is a component of 
    VPLS OAM.  When we have hierarchy then we can understand service aspects and 
    service OAM for VPLS.  IETF has expertise and should provide 
    Monique - having been involved in the discussions I want to support this 
    work. Not a trivial issue to say this is out of scope.  For Ethernet 
    period need to be very careful.  Customers are asking what we're doing 
    about Ethernet OAM.  Need to address scope of what can be done in IETF wrt 
    VPLS OAM.  But can't afford to ignore work going on in other standards 
    Kireeti - need to discuss what VPLS OAM is.  Ethernet OAM doesn't belong 
    here.  Not to say we should ignore work and work blindly without being 
    aware of it.  If it's specific to VPLS then it's in-scope.  If it's for 
    Ethernet and can be applied to VPLS then it isn't.  When talking about 
    scoping you are guilty unless proven innocent (assume is out of scope 
    unless can prove is in-scope).  Liason is a good way of staying in synch.  
    Not saying that whenever work needs IETF attention that it needs to be done 
    in IETF.
    Dinesh - there are aspects that we require in terms of 
    capabilities.  Not up to L2VPN to determine specifics of frame formats, but 
    is up to us to figure out information elements.
    Kireeti - FRF did LMI.  Defined their info elements.  What PWE3 did was to 
    say what LMI meant in PWE3.
    Dinesh - next step I've identified is to indicate other groups we need to 
    work with.  Need to define what this group needs to define in terms of VPLS 
    OAM.  No intent to duplicate work in other bodies.
    Marc - applicability for having framework doc for OAM.  VPLS is an 
    Ethernet service as far as a customer is concerned.  This group is 
    concerned with management of VPLS as a provider provisioned VPN.  So 
    subset of your draft is relevant to this group.
    Dinesh - there are aspects we haven't addressed in this WG - e.g. 
    layers.  That is an area we need to extend and augment in terms of the 
    Vach (WG chair hat on) - need to end discussion here.  Will make 
    statement on mailing list wrt scope.  Still don't see why you think this 
    belongs here.  If is informational then liason is way to go.  If you have 
    specific requirements then let us know about those in particular - 
    otherwise rest can be done through liason.
    Loa - not really clear to me whether we need to do anything.  May be that we 
    need to add information element to signalling, or might have to come up 
    with requirements for others to do their work, or might see a VPLS OAM 
    framework as useful for others to refer to.  Let's continue that 
    discussion on the WG list.  Dinesh should initiate.
    Dinesh - I concur.
    L2 IP Interworking - Vach
    Problem statement: 
    providers are trying to move to bigger/faster technologies but can't do it in 
    one hit.  Would like a VPWS where they can move one end from FR to GigE, but 
    leave the other end.
    In IETF we're concerned with IP.  so if L2VPN carries IP we have a way of 
    transferring IP packets from FR to Ethernet.  Need to work this out 
    between L2VPN and PWE3.
    Can have an IP-only PW.  Then need to address address resolution.  How do CE 
    nodes figure out who the far end is.
    We need to develop NSP function to take ARP from PE-CE AC at one end, turn 
    into canonical form, and hand to other side - who can make 
    appropriate mods to proxy etc.
    So interworking of address resolution protocols.  When people say "let's do 
    somewhere else" is saying "tell someone else to do ARP to Inverse ARP" etc.  
    That's a job for IETF.  Once have figured this out we can make this I/W PW 
    Issues around IGP impact (e.g. can't use broadcast links on a PW).  Need to 
    determine limitations.  Are ADs happy with this work in L2VPN, given this 
    Thomas Narten - ARP mediation draft has a question mark on IS-IS.  Need to 
    understand implications of that.  For OSPF can work-around by 
    configuring as P2P link.  Do we have same option for IS-IS?
    Vach - IS-IS issue can be handled in two ways.  (1) P2P mode.  (2) Not many 
    customer locations actually use IS-IS so may be non-problem even though it is 
    a problem.
    Thomas - I'm fairly comfortable but need to take it to IESG.  Question is 
    how much complexity does this add.  Can't speak for IESG.  Will need to 
    tweak charter.
    Naiming - have a draft on P2P over LAN for IGP.  Works fine for ISIS and 
    Giles - problem with ISIS is that ISIS isn't IP.
    Vach - issue is encaps.  Do we want to carry L2 headers.  Draft has two 
    modes.  If we get go from ADs would like to discuss that - and pursue ONE 
    OAM for VPWS - Mustapha
    Two types of PW:
    1) Homogenous - ACs are of same type
    2) Heterogenous - ACs may be different types:
    	IP only
    	Frame to ATM SIW (FRF 12)
    	Ethernet Interworking (bridged mode)
    Frame/ATM and Ethernet aren't discussed in charter, but is OK as PW and AC 
    are standard.  Interworking is done outside PW.  Procedures for IP 
    interworking apply to these also.
    For homogenous VPWS this is covered by draft-nadul (presented Monday in 
    PWE3).  Nadul was focussed on mapping VCCV to Frame/ATM/etc.  Scope was 
    increased to be a more generic VPWS OAM.  Common people on both drafts, and 
    turns out that drafts have converged in many aspects.  Homogenous stuff 
    will be in draft-nadul and presented in PWE3 and L2VPN.
    Not defining protocols - all describes how native OAM works with PW OAM to 
    get end-to-end OAM working (e.g. how does segment OAM from ATM to PW to 
    Ethernet work).
    Need to look into types of defect and define procedures for handling them.  
    Using PWE3 protocols, and those defined in other bodies for 
    Comment on mail-list about terminology.  Circuit consists of <AC, PW, 
    Homogenous = <AC, PW, AC> are all same type.
    Heterogeous = any two segments are different type.
    Homogenous VPWS - key is that link layer is not terminated at the PE.  L2 
    protocol runs end-to-end.  So if native service has an OAM we should use it 
    as much as possible.  Need to test end to end and segments.  That way SP can 
    troubleshoot any segment.  So PW OAM is a segment of the end-to-end 
    native service OAM.  Exception is that FR has LMI (end to end OAM is 
    FRF.19 but hasn't been deployed much).  For FR can't really extend native 
    service OAM so will use heterogeous model.  Ethernet has link 
    management/OAM progressing in other bodies, but no deployed inband 
    Ethernet OAM so again use heterogeous model.
    Good example of heterogeous is IP.  Send IP over MPLS using PW.  Once you 
    terminate link layer you can't extend it.  So you have boundaries for your 
    OAM (one at each PE).  3 segments for OAM (native on each AC, and PW in the 
    middle).  No choice but to use PW-specific OAM.  So use PW control draft.  
    Exception is Frame-ATM with an ATM PW (as can extend ATM PW as if was 
    In terms of detecting if PW is down reiterate that for FR not much 
    FRF.19.  For ATM have OAM.  For Ethernet today only have physical 
    OAM for homogenous is very simple - tunnel native OAM through PW.
    OAM for heterogenous have no tunnelling over PW.  So if detect problem in, 
    e.g. ATM attachment, then PE generates RDI back to CE and sends status 
    message to remote PE - which will send AIS to the remote CE (which will 
    send RDI back).
    Issues of flooding of alarms on ACs resulting in large amounts of PW 
    status signalling.  Issue for discussion.
    drafts have converged on many aspects so will work together for full 
    alignment and present back to PWE3 and to L2VPN (draft-nadul = 
    homogenous).  Suggest we progress heterogenous here (main focus on IP for 
    now).  One important point is that this work (heterogenous) is fully 
    aligned with service interworking work in MPLS and FR alliance.  Also need to 
    discuss heterogeous in PWE3 - is it just L2VPN specific.
    Rahul - couple of points.  Need to clarify scope of interworking and where it 
    lives in IETF.   Also need to define what is VPWS OAM.  Have 
    homogenous, IP only, any to any interworking.  Need to address any to any 
    first as IP is subset of that.
    Mustapha - in terms of what we mean by VPWS OAM we mean how to use the 
    native service OAM and PW-specific OAM to ensure VPWS service has 
    end-to-end OAM.  Not about defining protocols (PW-specific done in PWE3 and 
    native services elsewhere).  Defining rather procedures and saying what is 
    done at boundaries.
    Rahul - homogenous is covered in nadul draft.
    Mustapha - need to refer to nadul once we've aligned (so just have a 
    pointer here).  Need to cover heterogeous (currently IP only) and 
    explain the procedures - explain why heterogenous is different to 
    Rahul - defining scope of interworking and OAM will help move this 
    Vach - we'll take that to mailing list.
    Vach - if we talk about Ethernet to Ethernet as using heterogenous model as 
    Ethernet has no OAM today.  Let's keep it as that.  When IEEE does OAM for 
    Ethernet we'll use that and not terminate OAM and go to PW OAM.  So keep 
    things simple and clean.
    Mustapha - I agree with that.  This is an exception as don't have 
    deployed Ethernet OAM.  Once we have inband OAM for Ethernet we'll have to 
    support it.
    Monique - fully support that.  Let's be pragmatic - carriers want us to 
    solve this.
    Craig White - we need PWE to come up with a generic link encaps and use 
    L2VPN for the one to many case.  So if you just want P2P link PWE can 
    cover it fine.  One to many is much better covered here.
    vach - NSP is our mediation between AC OAM and PW OAM
    Craig - I'd propose that PWE is best group for P2P.  This group builds VPNs 
    out of PWs.  So PWE3 should define new PW type for interworking.
    Vach - IP PW should be defined in PWE3.  And PWE3 should define 
    heterogenous OAM.
    Craig - have come up with subset that could go in a CW to have base 
    functionality of OAM for the generic.
    Vach - let's continue on mailing list.
    Signalling for Access Service Network using LDP - Tetsushi
    Access Service Network is broadband access.  Uses authentication (NAI). 
    Typically PPPoE etc. today.
    Aim is to allow subscriber to use IEEE 802.1X to connect to ISP as a 
    special case of VPLS.
    Special type of VPLS as:
    1) don't forward broadcast/multicast between subscribers.  Bridge only 
    exists on network server.
    LDP signalling used to set up PW from Network Access Concentrator to 
    Network Server.
    Use single sided signalling (but not AGI).
    QoS info can be specified - RADIUS Access-Accept and in LDP mapping 
    1) less encaps overhead than L2TP.
    2) QoS.
    Vach - two comments.  NAC to bridge element is H-VPLS spoke.  If QoS is 
    important then take that to PWE3 (not here).  That way can be used for PW in 
    Tetsushi - not H-VPLS because of forwarding plane
    Giles - is H-VPLS but tie all PWs into the same mesh group at the hub end.  
    Good as it ensures even known MACs from NAC to NAC go via Network 
    - Loa Andersson: too early for this to become a working group document
      and want to see the discussion on the mailing list
    BGP Autodiscovery for LDP/L2TP VPWS/VPLS - Paul Unbehagen
    can do auto-discovery and auto-establish of PWs.
    Use RTs
    PE can use AFI/SAFI to encode VPWS/VPLS etc.
    AFI needs to be assigned by IANA
    SAFI is a bit pattern.
    NLRI based on AFI/SAFI.  Encode AGI and AII (single sided 
    AGI needs to match from BGP to LDP.  AII becomes a Target AII.
    Transparent mode - PE1 and PE2 build PW directly (ASBRs unaware of 
    L2VPNs).  Need reachability to PE devices in each AS.
    Proxy mode - ASBRs need to be VPN aware.  Stitch 3 PWs together to 
    provide service (PE-ASBR, ASBR-ASBR, ASBR-PE).  Can use SNAP in MP-BGP to 
    allow operator to see actual path of PW on remote PE through ASes.
    Question - do we need to support PW-id as well as GID?
    Move to WG?
    Yakov - SAFI is bitmask so can carry VPLS and VPWS in one message.  Is that 
    Paul - Yes.
    Yakov - same as unicast/multicast in IP routers.
    Sue Hares - we thought there would be a lot of both eventually.  but might 
    not be much VPLS at first.
    Paul - allows you to communicate PE-PE if we do both, or one or other.  In 
    future might want to split the two.
    Yakov - which WG is this a WG doc for?  It uses BGP.  So should it be 
    reviewed by IDR?
    Paul - needs to go in front of IDR.
    Vach - need to go to IDR and have IDR say is no problem.  Need to wait for 
    their response.
    Yakov - what is question to IDR?  We need to be very specific.
    Vach - does this break/affect BGP in some way?  The BGP experts are over 
    there and can tell us if is good.  Not asking them if it is a good idea.
    Kireeti - please make clear what questions are asked of IDR wrt the 
    auto-disc and BGP VPLS drafts
    Kireeti - should there not be similar soul-searching in the MPLS WG 
    regarding LDP VPLS?
    Ross Callon - do we want one or multiple documents?  Do people taking care 
    about BGP care about what's done here in the L2VPN working group?  How do we 
    make these people aware of these activities -> discuss these documents that 
    uses BGP and have last call there to ensure common acceptance.
    Loa Andersson - there is a group working on how to resolve this issue


    VPLS Applicability Draft
    VPLS Fault and Performance Management
    OAM Procedures for VPWS Interworking
    Signaling Protocol for Access Service Network using LDP
    BGP-based Auto-Discovery for L2VPNs