Last Modified: 2004-02-04
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
|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|
L2VPN 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 resubmitted. 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 interworking. Need: 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 deployments. base draft specifies signalling and bridging rules. applicability describes the applicability of the base draft to meet the requirements in the requirements draft. Content: 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 management 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 limiting). 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 inserted/terminated 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 scenarios. 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 service. 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 scope. 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 requirements. 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 groups. 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 framework. 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 work. 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 scope. 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 OSPF. 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 encaps. 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 ATM/Frame/Ethernet. Comment on mail-list about terminology. Circuit consists of <AC, PW, AC>. 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 heterogenous). 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 interface. 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 homogeous. Rahul - defining scope of interworking and OAM will help move this forward. 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 message. Merit: 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 general. 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 Server. - 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 signalling). 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 required/useful? 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