From exim@www1.ietf.org Fri Aug 1 14:00:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02490 for ; Fri, 1 Aug 2003 14:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieCD-0005Lf-A6 for l2vpn-archive@odin.ietf.org; Fri, 01 Aug 2003 14:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71I05WZ020553 for l2vpn-archive@odin.ietf.org; Fri, 1 Aug 2003 14:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieCD-0005LQ-3x for l2vpn-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 14:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02442 for ; Fri, 1 Aug 2003 13:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ieCA-0004oL-00 for l2vpn-web-archive@ietf.org; Fri, 01 Aug 2003 14:00:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ieCA-0004oH-00 for l2vpn-web-archive@ietf.org; Fri, 01 Aug 2003 14:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieC9-0005JZ-MO; Fri, 01 Aug 2003 14:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieBG-0005GB-GP for l2vpn@optimus.ietf.org; Fri, 01 Aug 2003 13:59:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02309 for ; Fri, 1 Aug 2003 13:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ieBE-0004mM-00 for l2vpn@ietf.org; Fri, 01 Aug 2003 13:59:04 -0400 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 19ieBC-0004mA-00 for l2vpn@ietf.org; Fri, 01 Aug 2003 13:59:03 -0400 Received: from vkompella ([64.47.48.10] RDNS failed) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Aug 2003 10:58:01 -0700 Reply-To: From: "Vach Kompella" To: "L2vpn" Subject: Minutes and action items from IETF 57 Date: Fri, 1 Aug 2003 10:59:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B3_01C3581C.0B117D50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 01 Aug 2003 17:58:01.0377 (UTC) FILETIME=[72D92110:01C35856] Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01C3581C.0B117D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I finally got the minutes merged. Thanks to Dinesh and Sunil for taking notes. Raw notes files attached. I'll send another email with the presentations. Action items (I will send out separate emails on each item as needed): - Discussion on mailing list on both WG VPLS solutions - issue 1: do we move forward with two solutions? - issue 2: do they solve different problems, and if so, need applicability stmt for each one - Discussion on mailing list - IPLS: draft-shah - pretty good response from the room - need to verify on mailing list - address issues (Cheng-Yin's) - note to iesg for interworking - what is in scope and what is out - comments from WG on draft-shah interworking - is draft-sajassi in scope? - draft-sodder - need to get better refs for mac-in-mac, along with some indication that IEEE is in support - draft-vpls-ldp - change of vc type + opt parameter for signaling split horizon - change of id from vcid to pwe3 generalized id with some modifications - draft-radoaca - need mailing list response if ready for WG - does it need more clarification or is it just broken? - requirements - 4 week last call issue - framework - thought it was ready for last call - recent comments on mailing list may require some changes - draft-rosen - need to move it along - CE-based VPLS - why is it in scope? Cheng-Yin to address ======================================================== L2VPN minutes from IETF57 Minute takers: Sunil Khandekar, Dinesh Mohan Agenda bashing: Russ is the technical advisor for security ppvpn is no longer existent start using l2vpn mailing list common stuff on l3vpn web page with the charter already up tried as much as could from ppvpn that is relevant three types of vpns - vpws, vpls, and ipls ce-based solutions in the charter or not? one solution out there which is vpls from customer and vpws from provider Cheng Yee - it is not vpls since it is not full mesh Not in charter - inter-area l2vpn and multicast 4 working group documents - l2 framework -03, - vpls-bgp-00.txt new draft, discussion needed on mailing list - vpls-ldp-00.txt new draft, discussion needed on mailing list - l2vpn-requirements-00.txt this is up for last call after meeting Loa: Issue: IESG is interested in a single solution Bilel - how do you define single solution Yakov - do not understand why single solution Loa - as a operater, not as a chair, is interest in single solution for a single problem, no need to have two solutions for one problem, if two solutions, then must be two problems Alex - why are we here, work on a standard for each problem, therefore two solutions for the same problem is not useful Yakov - why this was not applicable to l3vpn yesterday, ietf should not be in business of deciding how many Alex - each one of us has personal opinion, why people are here in the room, lets not have this discussion here since not in agenda, but needs to be discussed since IESG needs Vach - can we hear other people what their opinion is, after we hear it on mike, lets take it to mailing list Bruce Davies - good to have one standard, but IETF has seen multiple standards in past, lets try to come something that wg can reach standards Hamid - way the solutions are decomposed is not correct, ldp/bgp since in ldp bgp may be used for auto-discovery - if functional decomposition done then we do not get into this discussion, e.g. l3 may want to use l3 as much as possible Kireeti - if we can do two Ross - working in standards for long time, never seen standards body being choosy between solutions Ali - show of hands Vach - before we do show of hands, how many have read each one show of hands to see one or multiple solutions - it is tie - we will go with multiple solutions for now - discussion on mailing list Loa - Candidate L2VPN drafts - shah-ipls - sodder-ppvpn-vhls-02 Vach - is this in scope? questionable - to be asked on the mailing list - verify with ADs - radoaca (GVPLS) - carugi-ppvpn-solution-doc-guidelines-01 Loa - we may want to keep this draft, do we need to make it rfc?] - lee-ppvpn-hybrid-vpls-01 - stokes-vkompella-ppvpn-hvpls-oam-02 - shah-ppvpn-arp-mediation - sajassi-interworking - lee-ce-based - any missing? Marco - targets of carugi-ppvpn-solution-doc-guidelines-01, to push solution proposals to document how they satisfy requirements, to begin applicability analysis and to promote convergence in the solution space. Vach - can ADs confirm whether the sodder-draft falls in the l2vpn charter? Loa - draft-shah-arp-mediation is out of scope draft-sajassi-l2vpn-interworking is out of scope draft-ce-based is out of scope, for now Ali - Disparate attachements ckts is a real problem so where will we address this. Vach - Per the charter this is out of scope. We have to decide whether members feel whether we need to address this here. Hamid - Commenting on charter; It says IP VPN and I read that as any particular attachment circuit and hence it should be in charter Alex - The inter-working part was part of the charter when it went to IESG. IESG was concerned that we might be stepping on other bodies toes and hence it was taken out. Lets gauge the consensus in the room and then take up with issue again with the IESG. Arvind - draft-sodder fits in this WG. Vach - Need normative ref for MAC-in-MAC encap Arvind - I will take up the encap We need a normative reference for the encap. Vach - AFAIK, None was given in the draft. If you can find a ref that is a standard or standards track Dinesh - Normative as something that is a std or a work-in-progress docs? Vach - Std is preferred or work-in-progress on its way to become a std is acceptable. Dinesh - Before the last call, I understand the requirement but initially it is ok to refer to some other work in progress. Tom Narten: This is a well known process you should give as much info as possible on reference to a work Loa - Missing components - applicablility statement per solution - security framework - to be worked with Luyuan Fang - mib modules - need volunteers starting to draft what mibs would look like Tom Nadeau - we have pwe3 mibs that kept services like this in mind Loa - would you volunteer to write a doc to describe scope Tom - yes Loa - Organizing ourselves - When you submit a draft to this WG the naming convention should be draft-name-l2vpn-xxx-yyy-00.txt - Once it become a WG doc the name changes to: draft-ietf-l2vpn-xxx-yyy-00.txt. - If you do presentations please follow the a format that has the page numbers on the slide, the issues ISOCORE - Interoperability test from March IETF - presented by Bill Jensen - does not support any particular company - no pictures of Loa this time! - scope of interworking - mpls rsvp-te/ldp signaling ldp over rsvp tumnels mpls based services p2p l2vpn - fr, ehternet/ethernet VLAN, VC tunnel scaling scenarios l3vpns multicast vpns - vpls specific issues - updates from march - clear definition of VPLS encapsulation actions - fixed - ambiguity in the lsr-id - ... - summary ISOCORE leveraged the N+I demo at Las Vegas .... - Upcoming MPLS/GMPLS testing - isocore code testing Aug 4th-Aug 14th .... Danny - Is the methodology and ... available Bill - Yes methodology is available, but some things are under non-disclosure Danny - can you elaborate multicast vpls? - (didn't catch answer) Hamid - p2p l2vpn - did you mean the work in pwe3? logically the only layer that belongs here is martini Bill - maybe should not try to speculate here Bijan - Isocore - the point was that we wanted to test compatibility between draft-martini and VPLS Himanshu Shah - Cienna IPLS draft-shah-ppvpn-IPLS-01.txt - predominantly the traffic is IP so IPLS is adequate, supports IP devices only, subset of VPLS service - adv: no MAC learning at the data plane, no aging, no BPDUs, GVRPs, easier to support PE routers etc.. - when is VPLS needed - when world needs Cheng yin - There are lot of issues that I have raised. Are you going to address this? Himanshu - Yes those will be addressed. Vach - you cannot do the comments here, lets get the comments in mailing list Ali - should address qiq interoperability, partial mesh failure - so having end-points as IP does not remove this problem Bruce Davis - Show of hands in support Vach - pretty good support Dinesh - ieee partial mesh issue is actually applicable to all VPLS solutions Arvind - should also ask support for WG Vach - Show of hands to make it WG 15-20, not to make it WG - 1 Vach - should be also asked on the mailing list if this is ready to become a WG document Vach Kompella draft-ietf-ppvpn-vpls-ldp-00.txt Vach - VC-type changed from 0xb to 0x5 - Handful of hands in favor of adding an optional parameter to indicate the VPLS type. - Have a VPN-id TLV that allows indicating the type of VPN-id that is being used. Ali - Hamid - Use the PW signaling. That signaling contains the generalized signaling field. Why not use that? Vach - I am just asking for the AGI field to be changed to TLV Hamid - There is already some discussion going on in PWE3 to change that. Vach - That is what I am proposing Hamid - OK Luca - why is 32 bits not enough? Vach - 32 bits is not enough for inter-galatic VPLS (really not sufficient for inter-region and inter-AS VPLS) Luca - lets do it in 1000 years then Vach - This takes care when the VPLS spans multiple area. Even though that is out of scope right now, when we do move there I don't want to restrict ourselves. Luca - just introduce a TLV and call it "name" Vach - that is what I am doing Luca - Please propose this on the PWE3 mailing list. Vach - will do. Hamid - It is just not a question of why 32 bits is not enough, it is because we need a way to identify a set of pseudo-wires. Hamid - 32 bit is not enough since it needs to be globally unique Kireeti - use route targets (48 bits) and then you will get discovery too. Vasile Radoaca draft-radoaca-ppvpn-gvpls-02.txt Peter - Lucent - If you look at the disctributed model, you have end to end LDP, do not understand incremental solutions Vasile - distrubution model is distribution of functional elements, in VPLS MAC learnning is impo functional model, therefore access technology is not made specific Peter: Why tie separate pseudo-wire together rather than treat it end to end Vasile: Model is to decompose the access and core and the access can be any type Ali: I think the question was about splicing and the reasons for that is to allow reduction in the number of LDP sessions. Ali: You are still using separate pseudo-wire for unicast and multicast. Is it still true? Vasile: Yes but this allows it to scale better. Ali: The BPDUs of the customer can take a different path from unicast pseudo wire and if there is an issue the end customers will not be able to detect this. This will be a problem. Loa: Please take this on the mailing list. Are you proposing to make WG doc? Vasile - yes, make it WG document Loa: How many would like this to be a WG doc and how many would not? More people were against the draft then for. Go back to mailing list for more feedback. Tom Narten - clearly no consensus here - so do we need to see what needs to change to get more support, or is it fundamentally a broken idea? Ali - we agree that there are merits and some issues in the draft. We need to ensure that we address the issues without wiping out the merits. Himanshu - ARP Mediation Vach - how many people have read, support Vach - is it in scope or out of scope Alex - this is out of scope - WG would like to proceed with this and ball is now in IESG court Loa - is WG requesting the IESG Andy - Inverse ARP is IETF RFC, Inverse ARP for ATM is IETF RFC, this is just trying to mediate between the two, what is the issue Alex - how is IS-IS supported in this case Himanshu - IS IS is not supported Ali - My draft supports IS-IS and I would like Alex to take my draft up with the IESG as well to make it in scope. Ali - bridge encap in is addressed in draft-sajassi interworking, Yetik - Requirements - some of the requirements may be out of scope because of charter change between L2VPN and PPVPN, should we keep them in requirements or take them out Hamid - which of these requirements would be out of scope Yetik - For e.g. inter-AS Loa - 4 weeks for the WG last call Final remarks Vach - Cheng Yin to bring the issues of CE-based on mailing list Ali - HVPLS OAM is on agenda? Vach - HVPLS OAM is not on the agenda Ali - the OAM mechanism that we come up should be transport agnostics. -Vach ------=_NextPart_000_00B3_01C3581C.0B117D50 Content-Type: text/plain; name="l2vpn-minutes-dinesh-mohan.txt" Content-Disposition: attachment; filename="l2vpn-minutes-dinesh-mohan.txt" Content-Transfer-Encoding: quoted-printable Loa -=20 Introductions Note takers - Sunil, Dinesh Agenda bashing=20 Russ is the technical advisor for securuty ppvpn is no longer existent, start using l2vpn mailing list, common = stuff on l3vpn webpage up with the charter already up, tried as much as could from = ppvpn that is relevant three types of vpns - vpws, vpls, and ipls ce-based solutions in the charter or not? one solution out there = which is vpls from customer and=20 vpws from provider cheng yee - it is not vpls since it is not full mesh Not in charter - inter-area l2vpn and multicast 4 working group documents - l2 framework -03,=20 -vpls-bgp-00.txt new draft, discussion = needed -vpls-ldp-00.txt new draft, discussion = needed - l2vpn-requirements-00.txt this is up = for last call after meeting loa: interested in a single solution bilel: how do you define single solution yakov: do not understand why single solution loa: as a operater, not as a chair, is interest in single = solution for a single problem alex: why are we here, work in IETF standards for problems, = therefore two solutions for the=20 same problem are not feasible, if consensus - if we do = not need one standard=20 yakov - why this was not applicable to l3vpn yesterday, ietf = should not be in business of=20 deciding how many alex - each one of us has personal opinion, why people are = here in the room, lets not have this discussion here since not in agenda, but needs to = be discussed since IESG needs =20 vach - can we hear other people what their opinion is, after = we hear it on mike, lets take=20 it to mailing list bruce davis - good to have one standard, but IETF has seen = multiple standards in past, lets try to come something that wg can reach standards hamid - way the solutions are decomposed is not correct, = ldp/bgp since in ldp - bgp may be used for auto-discovery, if functional decomposition = done then we do not get into this discussion, e.g. l3 may want to use l3 as much as = possible keeterti - if we can do two,=20 ross - working in standards for long time, never seen = solutions being choosy between solutions ali - show of hands vach - before we do show of hands, how many have read each = one show of hands to see one or multiple solutions - it is tie - = we will go with multiple solutions and see where the consensus is reached Candidate l2vpn documents - shah-ipls - sodder-ppvpn-vhls-02 [this is in scope? questionable - to be = asked on the mailing list] - radoaca - carugi-ppvpn-solution-doc-guidelines-01 [we may want to keep = this draft, do we need to make it rfc?] - lee-ppvpn-hybrid-vpls-01 - stokes-vkompella-ppvpn-hvpls-oam-02 - shah-ppvpn-arp-mediation - sajassi-interworking - lee-ce-based -- - ... - ... =20 Marco - targets of carugi-ppvpn-solution-doc-guidelines-01, to = push solution proposals to document how they satisfy requirements, to begin = applicability analysis and=20 to promote convergence in the solution space. Missing components - applicablility statement per solution - security framework - to be worked with leuyen - mib modules - need volunteers starting to draft what mibs would = look like Vach - not to have multiple mibs, one common set of mibs Tom - we have mibs that meet the vpls Loa - would you volunteer Tom - yes Ali Sajassi - interworking is out of scope in current charter? = People need disparate attachments. Vach - we need to understand the meaning of interworking, we should = not be steeping on others toes have some comments on interworking draft, to be expressed later Hamid - interworking is wrong choice word, ip only l2vpn, building = l2vpns with=20 Alex - interworking part was part of charter when it went to IESG, = there were concerns so removed to make progress on other aspects, make progress and then bring = it to IESG One document - vpls-requirements-01.txt this does keep coming up, = have tried to kill it When you try to submit a draft draft-name-l2vpn-xxx-yyy-00.txt When the document becomes the WG - name replaced with ietf drawack that all documents would start from 00 version Prefered slide layout shown=20 Arvind - Enterasys - will convey the sentiment Vach - we need normative reference Dinesh - we need to have a normative reference when we go to last = call, may not be complete applicable for ids, since ids make reference to ids/work in = progress all the time ??? - make reference as close to as possible for work in progress = that a sense can be made out of it ISOCORE - Interoperability test from March IETF - ?? behalf of Rajiv = Papneja - does not support any particular company - no pictures of Loa this = time! - scope of interworking - mpls rsvp-te/ldp signaling ldp over rsvp tumnels mpls based services p2p l2vpn - fr, ehternet/ethernet VLAN, VC tunnel scaling = scenarios l3vpns multicast vpns - vpls sepecific issues - updates from march - clear definition of VPLS encapsulation actions - fixed - ambiguity in the lsr-id - ... - summary=20 ISOCORE leveraged the N+I demo at Las Vegas .... - Upcoming MPLS/GVPLS testing=20 - isocore code testing Aug 4th-Aug 14th ..... [??] Is the methodology and ... available Yes methodology is available, but some things are under non-disclosure [???] - can you elaborate multicast vpls? - early tunnels Hamid - p2p l2vpn - did you mean the work in pwe3? logically the only layer that belongs here is martini...maybe should = not try to speculate here [Dijan?? - Isocore] the point was that we wanted to test backward = compatibility... Himanshu Shah - Cienna IPLS - predominantly the traffic is IP so IPLS is adequate, supports IP = devices only, subset of VPLS=20 service - adv: no MAC learning at the data plane, no aging, no BPDUs, GVRPs, = easier to support PE=20 routers etc.. - when is VPLS needed - when world needs=20 Vach - you cannot do the comments and WG status here, lets get the = comments in mailing list Ali - should address qiq interoperability, partial mesh failure - so = having end-points as IP does not remove this problem Bruce Davis - Show of hands in support - reasonably well =20 Dinesh - ieee partial mesh issue is actually applicable to all VPLS = solutions Arvind - should also ask support for WG Show of hands to make it WG 15-20, not to make it WG - 1=20 Vach - should be also asked on the mailing list if this is ready to = become a WG document Vach Kompella - VPLS - Issues that need to be addressed - VC type 0xb to be replaced with appropriate VC tpye from PWE3 IANA = draft - recommending an optional parameter at the time of PW VPLS ask for show of hands 3-4, needs to be taken on mailing list - Name of VPLS - VCID is not adequate use of generalized PWID looks like TLV OR VPN ID TLV Vach is trying to get a sense of room and is not binding Hamid - use of PWE3 signaling since based on LDP, Generalized PWID = should be supported Vach - mentioned that is actually requesting a TYPE in addition Hamid - Use of term VPNID is not ok since there is a draft already = out there that defined VPNId Vach - ... Luca - can you tell me why 32 bits is not enough,=20 Vach - when we come to inter-AS it would become an issue Luca - just introduce a TLV and call it "name" Vach - that is what I am doing Luca - you are asking the PWE3 to revisit the structure, can you ask = it on PWE3 Vach - yes Hamid - 32 bit is not enough since it needs to be globally unique Keereti - use route targets, there is 48 bits Vach - I have raised this issue on the mailing list, will post these = questions on the mailing list again Vasile - GVPLS - good support on the mailing list during the solutions discussion from = SP and others - also received feedback from WG and SP to make few changes=20 - This version is an update based on the feedback received Peter - Lucent - If you look at the disctributed model, you have end to = end LDP, do not=20 understand incremental solutions Vasile - distrubution model is distribution of functional elements, in = VPLS MAC learnning is impo functional model, therefore access technology is not made specific=20 Ali - why we need splicing instead of end-to-end PW is for scaling Vasile - number of LDP sessions is n-square otherwise Ali - still using PW for unicast is different from multicast? Is this = true. Different issue - this is VPLS and IPLS so end devices are bridges - if we had two different PW = for unicast and multicast, then BPDUs could take a different path Loa - take these issues to the mailing list, what are your proposal? Vasile - make it WG document Loa - show of hands for support/opposition - slightly more towards = opposed than support, needs to=20 be taken to the mailing list for further feedback. [??] clearly no consensus here - so do we need to see what needs to = change to get more support Ali - we agree that there are merits and some issues in the draft. We = need to ensure that we address the issues without wiping out the merits. Yetik - Requirements=20 - some of the requirements may be out of scope, should we keep them in = requirements or take them out - Loa - 4 weeks for the WG last call Hamid - which of these requirements would be out of scope Himanshu - ARP Mediation Vach - how many people have read, support Vach - is it in scope or out of scope Alex - this is out of scope, WG would like to proceed with this and = ball is now in IESG court Loa - is WG requesting the IESG Andy - Inverse ARP is IETF RFC, Inverse ARP for ATM is IETF RFC, this = is just trying to mediate=20 between the two Alex - how is IS-IS supported in this case Himanshu - IS IS is not supported Ali - bridge encap in Ali Sajassi is addressed, question to Alex is = when requesting the IESG Vach - We are out of time, Cheng Yin to bring the issues of CE-based on = mailing list Ali - HVPLS is on agenda? Vach - HVPLS OAM is not on the agenda ------=_NextPart_000_00B3_01C3581C.0B117D50 Content-Type: text/plain; name="l2vpn-minutes-sunil.txt" Content-Disposition: attachment; filename="l2vpn-minutes-sunil.txt" Content-Transfer-Encoding: 7bit From: Sunil Khandekar [sunil@timetra.com] Sent: Tuesday, July 22, 2003 12:10 PM To: vkompella@timetra.com; 'Loa Andersson' Subject: RE: Minutes Here you go.... I tried to capture as much as I could but lot of it got lost. You should go thru this and add/edit per your recollection. Hopefully Dinesh took better notes than I did. Sunil -------------- Agenda bashing 5 min -------------- Loa: Introduced Russ. Russ is the technical advisor for security. Russ will ensure that all drafts meet the security requirements. Vach: PPVPN is split into L2 and L3 so members should use. Common issues will be discussed in the L3 group. Charter of the L2 posted. The primary goal is to cover VPWS, VPLS and IPLS only. Should CE-based solution be in the charter. One draft address Cheng Yin: It is not a VPLS solution since it does not use a full mesh. Vach: lets discuss towards the end of the meeting. Vach: Not in charter is inter-area l2vpn and multicast. Lets get done with what we have right now, progress them to IESG and then take on more work. Loa: Framework ready for WG last call. The ldp and bgp based VPLS draft have just become WG doc. I would like to see some convergence . The requirements draft Bilel: can you define what you mean by single solution? Loa: If there are two problems than I can see two solutions. Yakov: I don't understand why we need a single solution. If WG decides on more than one solution that's the way it will be. Loa (personal opinion): As operator would like to see a single solution. Yakov: Will you follow the WG consensus if they come up with two solutions Loa(PO) I cannot force one solution Alex: If we are here to work out a IETF std for one solution. I don't see a need for two solution and I would like to see how the WG members feel Yakov: Yesterday in L3VPN Alex: L3VPN wg standardizes three major solutions. If there is a one clearly scoped solution then I don't see a need to have more than one solution. Yakov: IETF should not dictate that one solution but deployment will drive one or more solution. Alex: When you bring two specs to IESG that solve the same problem Yakov: Alex Vach: Bruce Davie: Its better to have one solution. IETF has history with coming up with two solutions in the past. Lets leave it to working group. Hamid: The solutions are not decomposed (named) appropriately. For e.g LDP draft may use BGP for auto-discovery. Vach: lets not look at the name and decide lets decide based on what each draft represents. Hamid: There are building blocks in each Who says csco and jnpr do not interoperate. We should let the market decide and not mandate a single. Let the market decide. Ross: Having two Ali: can we do a show of hands on what Vach: how may prefer single solution and how many prefer multiple Vach: it's a tie so lets continue with both for now and lets also continue the discussion on the mailing list. Vach: can some one confirm whether the sodder-draft falls in the l2vpn charter. Loa: the draft-carugi-guidline may be useful to keep it around but it may Carugi: the idea of the draft was to try to converge multiple drafts and clarify how each solution tries to address the problem. Loa: draft-shah-arp-mediation is out of scope and draft-sajassi-l2vpn-interwokring is out of scope as well. Draft-ce-based is out of scope. We would like to start progress on draft ..... Ali: Disparate attachements ckts is a real problem so where will we address this. Vach: Per the charter this is out of scope. We have to decide whether members feel whether we need to address this here. Hamid: Commenting on charter; It says IP VPN and I read that as any particular attachment circuit and hence it Alex: The inter-working part was part of the charter when it went to IESG. IESG was concerned that we might be stepping on other bodies toes and hence it was taken out. Lets guage the concensus in the room and then take up with issue again with the IESG. The missing docs: Need applicability statements. Security framework will be covered in the generic security framework draft by Luyuan. We need MIBs. Vach: We don't want multiple mibs. Tom Nadeu: The PWE mibs are designed to work with these solutions. Loa: Can you write a doc explaining the scope Loa: the vpls-requiments will be taken away. When you submit a draft to this WG the naming convention should be Draft-name-l2vpn-xxx-yyy-00.txt Once it become a WG doc the name changes to: Draft-ietf-l2vpn-xxx-yyy-00.txt. If you do presentations please follow the a format that has the page numbers on the slide, the issues Arvind: Draft-sodder fits in this WG. I will take up the encap We need a normative reference for the encap. None was given in the draft. If you can find a ref that Dinesh: Normative as something that is a std or a work-in-progress docs ? Vach: Std is preferred or work-in-progress on its way to become a std is acceptable. Dinesh: Before the last call, I understand the requirement but initially it is ok to refer to some other work in progress. Tom Narten: This is a well known process you should give as much info as possible on reference to a work Arvind: Do Discussion of L2VPN charter 15 min Bijan Jabbari - report on vpls testing 10 min Bil Jensen: Gave an update on VPLS testing done at Isocore in March 03 where several vendors participated. There were some issues discovered that have been resolved in the latest rev of the vpls-ldp draft. Upcoming Testing: MPLS/GMPLS 2003 in Oct Danny: Is the methodology and test results available? Bill: Methodology is available but not test results; they are available for the members. Danny: that's my concern that the results are available only to members. Bill: Unfortunately that's the Jeff: ...missed the question on multicast testing. Bill: Multicast VPN ..... Hamid: You mentioned pt-to-pt VPNS did you mean the martini pseudo-wires. Bill: I guess Bijan: We wanted to show that there was compatibility between the VPLS and pt-to-pt pseudo wires. Himanshu Shah 15-20 min - draft-shah-ppvpn-IPLS-01.txt Ali: I like the draft to be expanded to include how VPLS and IPLS would interoperate. If there are no plans than that should be specified explicity. Also how will you How will you interoperate when the access is L2 only and core is MPLS Himanshu: We will add the section on how access L2 and core MPLS will work. Ali: Even though the end points are IP, the issue are common with VPLS and hence they need to be addressed. Bruce: can we get a sense of the room on the interest in progressing this. Arvind: Can we still go ahead and ask for the draft to be a WG doc? Cheng yin: There are lot of issues that I have raised. Are you going to address this? Himanshu: Yes those will be addressed. Vach: asked how many were in favor of this to be a WG doc? About 15-20 raised their hands. How many are against: no one raised there hands. Vach: we will ask this also on the mailing list. Vach Kompella draft-ietf-ppvpn-vpls-ldp-00.txt 10 min Vach: VC-type changed from 0xb to Handful of hands in favor of adding an optional parameter to indicate the VPLS type. Have a VPN-id TLV that allows indicating the type of VPN-id that is being used. Ali: Hamid: Use the PW signaling. That signaling contents the generalized signaling field. Why not use them Vach: I am just asking for the AGI field to be changed to TLV Hamid: There is already some discussion going on in PWE3 to change that. Vach: That is what I am proposing Hamid: OK Luca: why is 32 bits not enough? Vach: 32 bits is not enough for inter-galatic Luca: lets do it in 1000 years then Vach: This takes care when the VPLS spans multiple area. Even though that is out of scope right now, when we do move there I don't want to restrict ourselves. Luca: Please propose this on the PWE3 mailing list. Vach: will do. Hamid: It is just not a question of why 32 bits is not enough, it is because we need a way to identify a set of pseudo-wires. Kireeti: use route targets and then you will get discovery too. Vasile Radoaca 5 min draft-radoaca-ppvpn-gvpls-02.txt Peter: Why tie separate pseudo-wire together rather than treat it end to end Vasile: Model is to decompose the access and core and the access can be any type Ali: I think the question was about splicing and the reasons for that is to allow reduction in the number of LDP sessions. Ali: You are still using separate pseudo-wire for unicast and multicast. Is it still true? Vasile: Yes but this allows it to scale better. Ali: The BPDUs of the customer can take a different path from unicast pseudo wire and if there is an issue the end customers will not be able to detect this. This will be a problem. Loa: Please take this on the mailing list. Loa: How many would like this to be a WG doc and how many would not? More people were against the draft then for. s Himanshu: Draft-arp-mediation Vach: asked how many would like this to make this a WG doc: No one against making this a WG doc. Vach: Is this in scope or out of scope Alex: out of scope Vach: should we make it part of the scope. Alex: We need to talk to the ADs Andy: In Arp of ATM is already an IETF doc Alex: How do you deal when IS-IS is used on the CE. Himanshu: Currently not a workable and is mentioned in the draft Ali: My draft supports IS-IS and I would like Alex to take my draft up with the IESG as well to make it in scope. Ali: Are we going to discuss VPLS on agenda? Vach: Not on the agenda today. Ali: the OAM mechanism that we come up should be transport agnostics. Loa Andersson 5 min Status on L2 requirements Yetik Serbest 5 min Status on L2 framework Yetik: I have not received any comments so I think the doc is ready for WG last call. There might be few things that we may have to take out. Hamid: what specifically. Yetik: For e.g. inter-AS Other issues (milestones, other drafts) if time permits >-----Original Message----- >From: Vach Kompella [mailto:vkompella@timetra.com] >Sent: Tuesday, July 22, 2003 10:46 AM >To: Sunil Khandekar; Loa Andersson >Subject: Minutes > >Sunil, > >Can you forward Loa and me the minutes from L2VPN? Thanks. > >Vach Kompella >Alcatel >vach.kompella@alcatel.com >650-237-5152 > ------=_NextPart_000_00B3_01C3581C.0B117D50-- From exim@www1.ietf.org Mon Aug 4 10:02:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26148 for ; Mon, 4 Aug 2003 10:02:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfua-0007W4-AZ for l2vpn-archive@odin.ietf.org; Mon, 04 Aug 2003 10:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74E28l4028886 for l2vpn-archive@odin.ietf.org; Mon, 4 Aug 2003 10:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfua-0007Vp-5a for l2vpn-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 10:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26143 for ; Mon, 4 Aug 2003 10:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfuY-0001Pq-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 10:02:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jfuX-0001Pm-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 10:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfuT-0007VN-Ui; Mon, 04 Aug 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfto-0007UW-55 for l2vpn@optimus.ietf.org; Mon, 04 Aug 2003 10:01:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26131 for ; Mon, 4 Aug 2003 10:01:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jftm-0001Pe-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 10:01:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19jftl-0001PR-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 10:01:17 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2003 07:00:47 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h74E0ixc000046; Mon, 4 Aug 2003 10:00:44 -0400 (EDT) Message-Id: <200308041400.h74E0ixc000046@rtp-core-2.cisco.com> To: vach.kompella@alcatel.com cc: "L2vpn" Subject: Identifiers (was Re: Minutes and action items from IETF 57) In-reply-to: Your message of Fri, 01 Aug 2003 10:59:56 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 04 Aug 2003 10:00:44 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Luca - why is 32 bits not enough? > Vach - 32 bits is not enough for inter-galatic VPLS (really not > sufficient for inter-region and inter-AS VPLS) > Luca - lets do it in 1000 years then I thought this was well understood, but I guess not. If a single PW can have its endpoints in different SP networks, then the naming space needs to be structured so that the SPs can each administer a piece of the naming space without fear of naming conflicts. I don't think it will be 1000 years before there is an inter-provider pw. There are also other reasons for adding structure to the name, as indicated in the various signaling and auto-discovery documents. > Luca - just introduce a TLV and call it "name" The problem with this is that (a) it doesn't provide the necessary structure and (b) will cause interoperability problems. From exim@www1.ietf.org Mon Aug 4 10:46:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00432 for ; Mon, 4 Aug 2003 10:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgb5-0000ht-OI for l2vpn-archive@odin.ietf.org; Mon, 04 Aug 2003 10:46:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Ek3Gk002713 for l2vpn-archive@odin.ietf.org; Mon, 4 Aug 2003 10:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgb5-0000hg-KX for l2vpn-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 10:46:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00426 for ; Mon, 4 Aug 2003 10:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jgb3-0002XU-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 10:46:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jgb2-0002XR-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 10:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgb3-0000hE-J6; Mon, 04 Aug 2003 10:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jgaj-0000gj-Q6 for l2vpn@optimus.ietf.org; Mon, 04 Aug 2003 10:45:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00413 for ; Mon, 4 Aug 2003 10:45:35 -0400 (EDT) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jgah-0002X1-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 10:45:39 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt08.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19jgag-0002Wo-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 10:45:38 -0400 Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Mon, 4 Aug 2003 15:45:04 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6BC8@i2km07-ukbr.domain1.systemhost.net> To: erosen@cisco.com, vach.kompella@alcatel.com Cc: l2vpn@ietf.org Subject: RE: Identifiers (was Re: Minutes and action items from IETF 57) Date: Mon, 4 Aug 2003 15:44:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric Rosen wrote 04 August 2003 15:01 > > Luca - why is 32 bits not enough? > > > Vach - 32 bits is not enough for inter-galatic VPLS (really not > > sufficient for inter-region and inter-AS VPLS) > > > Luca - lets do it in 1000 years then > > I thought this was well understood, but I guess not. > > If a single PW can have its endpoints in different SP > networks, then the > naming space needs to be structured so that the SPs can > each administer a > piece of the naming space without fear of naming conflicts. > I don't think > it will be 1000 years before there is an inter-provider pw. > > There are also other reasons for adding structure to the > name, as indicated > in the various signaling and auto-discovery documents. > > > Luca - just introduce a TLV and call it "name" > > The problem with this is that (a) it doesn't provide the > necessary structure > and (b) will cause interoperability problems. NH=> I agree. But there is a deeper issue here than 'naming' ....and its also a much more generic/fundamantal issue than any specific VPN/service instance. Put simply the problem is that it is the LSPs themselves (not the artifical PW client/server adaptation instances) that require access point *addresses*. Unfortunately, this clearly exposes the fact that MPLS must become a layer network in its own right whose addressing is decoupled from any specific client....including IP. It can use the IP (v4 or v6) address structure, but the actual address space belongs to the MPLS layer network not the IP (or any other) layer network. I and many colleagues have been aware of the need to face up to this for several years now. In fact, when I drafted the original version of Y.1711 I pre-empted the need for MPLS layer addressing in the CV packet, based on v6 format (which can also take a v4 structure if required). However, and as we all know only too well, some have a 'desire' to keep MPLS too tightly bound to IP, and this is not doing it any favours architecturally.....and in turn this is not doing me any favours as an operator seeing/knowing problems like this exist when they really need properly sorting out if MPLS is to achieve its potential. regards, Neil From exim@www1.ietf.org Mon Aug 4 14:24:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06799 for ; Mon, 4 Aug 2003 14:24:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jk09-0000Mu-He for l2vpn-archive@odin.ietf.org; Mon, 04 Aug 2003 14:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74IO9RT001375 for l2vpn-archive@odin.ietf.org; Mon, 4 Aug 2003 14:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jk07-0000M6-0B for l2vpn-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06788 for ; Mon, 4 Aug 2003 14:24:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jk04-0004ei-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 14:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jk04-0004ef-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 14:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jk00-0000Ld-RE; Mon, 04 Aug 2003 14:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjzo-0000Ke-RN for l2vpn@optimus.ietf.org; Mon, 04 Aug 2003 14:23:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06782 for ; Mon, 4 Aug 2003 14:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjzc-0004ea-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 14:23:36 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19jjza-0004e0-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 14:23:34 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h74IN2tp020372; Mon, 4 Aug 2003 11:23:02 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-70.cisco.com [128.107.166.70]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJY68651; Mon, 4 Aug 2003 11:16:58 -0700 (PDT) Message-ID: <3F2EA473.79B6D5C8@cisco.com> Date: Mon, 04 Aug 2003 11:22:43 -0700 From: Wei Luo X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: erosen@cisco.com CC: vach.kompella@alcatel.com, L2vpn Subject: Re: Identifiers (was Re: Minutes and action items from IETF 57) References: <200308041400.h74E0ixc000046@rtp-core-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Rosen wrote: > > > Luca - why is 32 bits not enough? > > > Vach - 32 bits is not enough for inter-galatic VPLS (really not > > sufficient for inter-region and inter-AS VPLS) > > > Luca - lets do it in 1000 years then > > I thought this was well understood, but I guess not. > > If a single PW can have its endpoints in different SP networks, then the > naming space needs to be structured so that the SPs can each administer a > piece of the naming space without fear of naming conflicts. I don't think > it will be 1000 years before there is an inter-provider pw. > > There are also other reasons for adding structure to the name, as indicated > in the various signaling and auto-discovery documents. I have to agree that it's not that we need more VPLS than 32 bits can offer, it has to do with the ability of assigning an identifier without consulting everyone in the world first or some sort of univeral central database. In the L2TP L2VPN signaling draft, the identifier is variable length (we still have yet to come up with a common structural encoding for both signaling drafts). > > > Luca - just introduce a TLV and call it "name" > > The problem with this is that (a) it doesn't provide the necessary structure > and (b) will cause interoperability problems. For LDP based signaling, we can either have it in the current L2FEC or a new TLV, but not both. There has to be a single authoritive identifier field to avoid interoperability problems. ---Wei From exim@www1.ietf.org Mon Aug 4 16:14:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10872 for ; Mon, 4 Aug 2003 16:14:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlia-0003vr-BZ for l2vpn-archive@odin.ietf.org; Mon, 04 Aug 2003 16:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74KE8BP015111 for l2vpn-archive@odin.ietf.org; Mon, 4 Aug 2003 16:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jliV-0003uw-Va for l2vpn-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 16:14:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10867 for ; Mon, 4 Aug 2003 16:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jliU-0005NW-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 16:14:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jliT-0005NT-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 16:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jliT-0003uO-Ar; Mon, 04 Aug 2003 16:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jlhn-0003u2-ST for l2vpn@optimus.ietf.org; Mon, 04 Aug 2003 16:13:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10858 for ; Mon, 4 Aug 2003 16:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jlhm-0005NE-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 16:13:18 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19jlhk-0005N9-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 16:13:16 -0400 Received: from sajassi-w2k1.cisco.com (dhcp-171-68-147-60.cisco.com [171.68.147.60]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h74KChLI028493; Mon, 4 Aug 2003 13:12:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20030804104150.022629d8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Aug 2003 13:12:43 -0700 To: "Shah, Himanshu" , "'erosen@cisco.com'" From: Ali Sajassi Subject: RE: On VPLS and Routing Protocols Cc: Alex Zinin , l2vpn@ietf.org In-Reply-To: <8162DD929D7AD24CAD3FC5317CE41FB001061F@w2kmaexg02.ciena.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I am catching up with my emails on this thread and after going over them, I have the following input/comment. The discussion so far has been focused on the fault recovery and either a) how to fix a partial-mesh in case of a node/link or PW failure or b) how to make the end-points accommodate such failures (via NBMA). However, another important piece in here is the fault detection mechanism and this detection & recovery need to happen within the time constraint set forth by IEEE 802.1 for proper operation of emulated LAN segment with the existing IEEE bridges. Given that the failure can be either hard or soft/silent failure, the detection mechanism needs to cover both cases. Also given that a VPLS service instance can span across different network types (e.g., QinQ access network with MPLS/IP core network), the fault detection mechanism needs to operate over different network types. Within the MPLS/IP core network, where a full-mesh with split horizon is run, then one of the following factors can result in a partial mesh connectivity: - link failure - node failure - PW failure due to soft/silent failure The failure that can affect a large number of customers / VPLS instances need to be quickly detected and appropriate action to be taken; whereas, the failure that only affects a single VPLS instance may not have the same urgency. Therefore, one can use TE tunnels between the PEs to ensure that all the PWs between a pair of PEs take the same path and have a rapid failure detection mechanism that operate at the tunnel level and upon detection of a failure an alternate tunnel using FRR can be exercised. Using TE PtP tunnels in the MPLS/IP core, can help with rapid fault detection and recovery mechanism in the core network to take care of failure such as link and node failures (both PE and P). Another advantage of using TE tunnel is that it will take care of ECMP problem for provider's BPDUs packets that need to travel the same path as the VLANs that they protect for an intra-island (and not inter-islannd) scenario. The use of TE tunnels can bring about the scalability concern; however, the use of hierarchical topology (e.g., HVPLS) would/should alleviate such concern since the TE tunnels are among n-PEs (and not u-PEs). Also for the failures that only affect the PW(s) of a given VPLS instance, then the Ethernet OAM mechanisms that are being discussed in IEEE and ITU, can help with fault detection, verification, notification, and isolation at the service instance level. -Ali From exim@www1.ietf.org Mon Aug 4 17:29:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12520 for ; Mon, 4 Aug 2003 17:29:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmtF-00065C-IR for l2vpn-archive@odin.ietf.org; Mon, 04 Aug 2003 17:29:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74LTDaf023383 for l2vpn-archive@odin.ietf.org; Mon, 4 Aug 2003 17:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmtF-000654-9D for l2vpn-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 17:29:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12512 for ; Mon, 4 Aug 2003 17:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmtC-0005lC-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 17:29:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jmtC-0005l9-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 17:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmt3-000642-Nq; Mon, 04 Aug 2003 17:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmsC-00062o-UX for l2vpn@optimus.ietf.org; Mon, 04 Aug 2003 17:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12438 for ; Mon, 4 Aug 2003 17:28:02 -0400 (EDT) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmgx-0005gJ-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 17:16:31 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19jmgw-0005g9-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 17:16:30 -0400 Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Mon, 4 Aug 2003 22:16:13 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6BD2@i2km07-ukbr.domain1.systemhost.net> To: sajassi@cisco.com, hshah@ciena.com, erosen@cisco.com Cc: zinin@psg.com, l2vpn@ietf.org Subject: RE: On VPLS and Routing Protocols Date: Mon, 4 Aug 2003 22:15:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ali, Really nice to meet you (and Stewart B) at SG13 last week and good comments here. However, I have few concerns: Tunnels. I really think its time we stopped playing footloose with these architectural terms and introducered some hard G.805/809 funnctional modelling descriptions. MPLS uses LSPs which are a *server* layer below whatever client we are considering. IP tunnels, say L2TPv3 or GRE on the other hand, are *client* layers to IP, ie IP is the server layer here. So, in a layered architecture sense IP tunnels are in fact just the opposite (ie 'bridges' in a litteral sense) whereas MPLS LSPs are truly *below* (ie server) to whatever client they serve. The key point here, if not blindingly obvious by now, is that we *cannot* equate XoverIP and XoverMPLS.....they are simply *not* the same. And hence my basic problem as I explained to you/Stewart at SG13 with the PWE3 stuff....IP is a cnls mode and MPLS is a co-ps mode. This should be embraced with rejoicing (ie it is *useful*) and not deprecated as some 'mistakenly' see this. Did you see my earlier posting, to Eric R, on the need for MPLS LSPs to have their own access points addressing? This is part of the same issue as I tried to explain to you/Stewart at SG13. We can be so much smarter/useful in what we are doing here.....however, is there the political/commercial will (in IETF) to eventually state IP and MPLS are different networking modes and cannot be subject to the same misguided PWE3 treatment to date? I hope so, but I am also realistic to recognise this may not happen anytime soon. regards, Neil > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: 04 August 2003 21:13 > To: Shah, Himanshu; 'erosen@cisco.com' > Cc: Alex Zinin; l2vpn@ietf.org > Subject: RE: On VPLS and Routing Protocols > > > > I am catching up with my emails on this thread and after > going over them, I > have the following input/comment. > > The discussion so far has been focused on the fault recovery > and either a) > how to fix a partial-mesh in case of a node/link or PW > failure or b) how to > make the end-points accommodate such failures (via NBMA). > However, another > important piece in here is the fault detection mechanism and > this detection > & recovery need to happen within the time constraint set > forth by IEEE > 802.1 for proper operation of emulated LAN segment with the > existing IEEE > bridges. > > Given that the failure can be either hard or soft/silent failure, the > detection mechanism needs to cover both cases. Also given that a VPLS > service instance can span across different network types > (e.g., QinQ access > network with MPLS/IP core network), the fault detection > mechanism needs to > operate over different network types. > > Within the MPLS/IP core network, where a full-mesh with split > horizon is > run, then one of the following factors can result in a partial mesh > connectivity: > - link failure > - node failure > - PW failure due to soft/silent failure > > The failure that can affect a large number of customers / > VPLS instances > need to be quickly detected and appropriate action to be > taken; whereas, > the failure that only affects a single VPLS instance may not > have the same > urgency. Therefore, one can use TE tunnels between the PEs to > ensure that > all the PWs between a pair of PEs take the same path and have a rapid > failure detection mechanism that operate at the tunnel level and upon > detection of a failure an alternate tunnel using FRR can be exercised. > > Using TE PtP tunnels in the MPLS/IP core, can help with rapid fault > detection and recovery mechanism in the core network to take care of > failure such as link and node failures (both PE and P). > > Another advantage of using TE tunnel is that it will take > care of ECMP > problem for provider's BPDUs packets that need to travel the > same path as > the VLANs that they protect for an intra-island (and not > inter-islannd) > scenario. > > The use of TE tunnels can bring about the scalability > concern; however, the > use of hierarchical topology (e.g., HVPLS) would/should > alleviate such > concern since the TE tunnels are among n-PEs (and not u-PEs). > > Also for the failures that only affect the PW(s) of a given > VPLS instance, > then the Ethernet OAM mechanisms that are being discussed in > IEEE and ITU, > can help with fault detection, verification, notification, > and isolation at > the service instance level. > > > -Ali > > > > > From exim@www1.ietf.org Mon Aug 4 18:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14785 for ; Mon, 4 Aug 2003 18:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jo2h-00089l-Ig for l2vpn-archive@odin.ietf.org; Mon, 04 Aug 2003 18:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Mh3hk031349 for l2vpn-archive@odin.ietf.org; Mon, 4 Aug 2003 18:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jo2h-00089Y-Dz for l2vpn-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 18:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14781 for ; Mon, 4 Aug 2003 18:42:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jo2e-000686-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 18:43:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jo2d-000683-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 18:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jo2f-000895-9E; Mon, 04 Aug 2003 18:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jo2N-00088s-DG for l2vpn@optimus.ietf.org; Mon, 04 Aug 2003 18:42:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14778 for ; Mon, 4 Aug 2003 18:42:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jo2K-00067q-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 18:42:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19jo2I-00067f-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 18:42:38 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2003 15:42:09 -0700 Received: from sajassi-w2k1.cisco.com (dhcp-171-68-147-60.cisco.com [171.68.147.60]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h74Mg47G017827; Mon, 4 Aug 2003 15:42:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20030804143657.021e0028@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Aug 2003 15:42:04 -0700 To: neil.2.harrison@bt.com, sajassi@cisco.com, hshah@ciena.com, erosen@cisco.com From: Ali Sajassi Subject: RE: On VPLS and Routing Protocols Cc: zinin@psg.com, l2vpn@ietf.org In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6BD2@i2km07-ukbr.domai n1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 10:15 PM 8/4/2003 +0100, neil.2.harrison@bt.com wrote: >Ali, > >Really nice to meet you (and Stewart B) at SG13 last week and good comments >here. However, I have few concerns: It was also very nice meeting you during SG13 meetings and I enjoyed our conversation and discussions. >Tunnels. I really think its time we stopped playing footloose with these >architectural terms and introducered some hard G.805/809 funnctional >modelling descriptions. MPLS uses LSPs which are a *server* layer below >whatever client we are considering. IP tunnels, say L2TPv3 or GRE on the >other hand, are *client* layers to IP, ie IP is the server layer here. So, >in a layered architecture sense IP tunnels are in fact just the opposite (ie >'bridges' in a litteral sense) whereas MPLS LSPs are truly *below* (ie >server) to whatever client they serve. The key point here, if not >blindingly obvious by now, is that we *cannot* equate XoverIP and >XoverMPLS.....they are simply *not* the same. And hence my basic problem as >I explained to you/Stewart at SG13 with the PWE3 stuff....IP is a cnls mode >and MPLS is a co-ps mode. This should be embraced with rejoicing (ie it is >*useful*) and not deprecated as some 'mistakenly' see this. When I talked about tunnel and PW, I was referring to PSN tunnel (inside which one or more PW is carried) as described in the PWE3 arch document. Although sometimes, some people use the term tunnel and PW interchangeably in the context of L2TP which can be the source of confusion. Also, I think we all agree that an MPLS TE tunnel is a co-ps mode but again not all MPLS applications are TE tunnels :-) I hope, the terms PSN tunnels and PWs as defined in PW arch. document are clear enough to everyone and whenever I use these terms, I use them in context of PWE3. >Did you see my earlier posting, to Eric R, on the need for MPLS LSPs to have >their own access points addressing? This is part of the same issue as I >tried to explain to you/Stewart at SG13. No, but I will go over it when I get a chance. >We can be so much smarter/useful in what we are doing here.....however, is >there the political/commercial will (in IETF) to eventually state IP and >MPLS are different networking modes and cannot be subject to the same >misguided PWE3 treatment to date? I hope so, but I am also realistic to >recognise this may not happen anytime soon. I guess if we recognize that MPLS has two modes of operation (one as clns-ps and the other one as co-ps), then we can appreciate the commonality and differences between IP and MPLS. Regards, Ali >regards, Neil > > > > -----Original Message----- > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > Sent: 04 August 2003 21:13 > > To: Shah, Himanshu; 'erosen@cisco.com' > > Cc: Alex Zinin; l2vpn@ietf.org > > Subject: RE: On VPLS and Routing Protocols > > > > > > > > I am catching up with my emails on this thread and after > > going over them, I > > have the following input/comment. > > > > The discussion so far has been focused on the fault recovery > > and either a) > > how to fix a partial-mesh in case of a node/link or PW > > failure or b) how to > > make the end-points accommodate such failures (via NBMA). > > However, another > > important piece in here is the fault detection mechanism and > > this detection > > & recovery need to happen within the time constraint set > > forth by IEEE > > 802.1 for proper operation of emulated LAN segment with the > > existing IEEE > > bridges. > > > > Given that the failure can be either hard or soft/silent failure, the > > detection mechanism needs to cover both cases. Also given that a VPLS > > service instance can span across different network types > > (e.g., QinQ access > > network with MPLS/IP core network), the fault detection > > mechanism needs to > > operate over different network types. > > > > Within the MPLS/IP core network, where a full-mesh with split > > horizon is > > run, then one of the following factors can result in a partial mesh > > connectivity: > > - link failure > > - node failure > > - PW failure due to soft/silent failure > > > > The failure that can affect a large number of customers / > > VPLS instances > > need to be quickly detected and appropriate action to be > > taken; whereas, > > the failure that only affects a single VPLS instance may not > > have the same > > urgency. Therefore, one can use TE tunnels between the PEs to > > ensure that > > all the PWs between a pair of PEs take the same path and have a rapid > > failure detection mechanism that operate at the tunnel level and upon > > detection of a failure an alternate tunnel using FRR can be exercised. > > > > Using TE PtP tunnels in the MPLS/IP core, can help with rapid fault > > detection and recovery mechanism in the core network to take care of > > failure such as link and node failures (both PE and P). > > > > Another advantage of using TE tunnel is that it will take > > care of ECMP > > problem for provider's BPDUs packets that need to travel the > > same path as > > the VLANs that they protect for an intra-island (and not > > inter-islannd) > > scenario. > > > > The use of TE tunnels can bring about the scalability > > concern; however, the > > use of hierarchical topology (e.g., HVPLS) would/should > > alleviate such > > concern since the TE tunnels are among n-PEs (and not u-PEs). > > > > Also for the failures that only affect the PW(s) of a given > > VPLS instance, > > then the Ethernet OAM mechanisms that are being discussed in > > IEEE and ITU, > > can help with fault detection, verification, notification, > > and isolation at > > the service instance level. > > > > > > -Ali > > > > > > > > > > From exim@www1.ietf.org Mon Aug 4 20:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16305 for ; Mon, 4 Aug 2003 20:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpeN-0001uV-2d for l2vpn-archive@odin.ietf.org; Mon, 04 Aug 2003 20:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h750Q35H007342 for l2vpn-archive@odin.ietf.org; Mon, 4 Aug 2003 20:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpeM-0001uL-UU for l2vpn-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 20:26:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16300 for ; Mon, 4 Aug 2003 20:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpeK-0006TH-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 20:26:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jpeK-0006TE-00 for l2vpn-web-archive@ietf.org; Mon, 04 Aug 2003 20:26:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpeK-0001tt-Vu; Mon, 04 Aug 2003 20:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpdU-0001tU-Jp for l2vpn@optimus.ietf.org; Mon, 04 Aug 2003 20:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16278 for ; Mon, 4 Aug 2003 20:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpdS-0006TA-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 20:25:06 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19jpdR-0006Sw-00 for l2vpn@ietf.org; Mon, 04 Aug 2003 20:25:05 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h750OX722916 for ; Mon, 4 Aug 2003 19:24:33 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Mon, 4 Aug 2003 20:24:32 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'erosen@cisco.com'" Cc: "'l2vpn@ietf.org'" Subject: RE: Truly Generalized VPLS (!) Date: Mon, 4 Aug 2003 20:24:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Given your sample topology: > > U-SRC-PE---N-SRC-PE--------N-DST-PE---U-DST-PE > Eric> In LDP, when you receive a Eric> particular TLV on one session, you forward the corresponding TLV on the Eric> other. That doesn't seem like much of an issue, though the proper behavior Eric> would need to be specified. (Note that in an "ordinary" MPLS LSP, there is Eric> an independent LDP connection between every adjacent pair of LSRs. The Eric> notion of passing attributes along the path, by passing them through the Eric> sequence of LDP connections, is well understood; see the "path vector" and Eric> the "MTU" attributes.) I agree. The consequence is that N-SRC-PE should wait for a Label Mapping Message from U-SRC-PE before it can send a Label Mapping Message to N-DST-PE. In return, N-DST-PE cannot send a Label Mapping Message to N-SRC-PE until it has received a Label Mapping Message from U-DST-PE. In other words, there is a definite sequence to the actions along the path. When this sequence of actions is clearly understood, then I agree that this method is equivalent to sending an RSVP-TE message along the path. However, I still believe that there is a subtle difference with "standard" LDP. In standard LDP with downstream unsolicited mode, N-SRC-PE would send Label Mapping Messages to all its peers. In the GVPLS approach, it sends Label Mapping Messages to those peers that are on the path to U-PEs that support the same VPLS. It uses information from the Label Mapping Message (i.e. the Generalized FEC) and knowledge of the topology, that it has somehow acquired, to determine which of it peers it has to send Label Mapping Messages to (and not just one message, but possibly more than one, depending on the number of U-PEs that are hidden behind that N-PE). I would still argue that we are defining a new protocol, but I don't have a vested interest in RSVP-TE and I think we can make this form of LDP work, if we define it unambiguously. > Peter> In a previous email I asked how an N-PE discovers the "local list" > Peter> and "remote list" that you mention in section 5.5.1 of > Peter> draft-rosen-l2-signaling. From your answer I got the impression that > Peter> you envisioned that those lists would be manually provisioned by the > Peter> Service Provider. > Eric> No, the information can be distributed by whatever Eric> auto-discovery procedure we are using. > I don't think so. Speaking in the context of L2 VPNs, the autodiscovery procedures tell us which U-PEs support a given VPLS. They don't tell us where the intermediate switches are and how they are connected to each other. There are autodiscovery protocols that enable network elements to learn the network topology they have to deal with. They are called routing protocols. I maintain that if you want to do GVPLS right you have to run a combination of BGP and/or your favorite IGP to find out where the PW Label Switching Nodes are and how they are connected to each other and to U-PEs. I think this email thread is coming to an end. In closure I would like to summarize my original point: to find the right solution for GVPLS, you have to generalize the concept of a PW: abolish the notion of a PW being a direct connection between two peer nodes and accept the notion that a PW is an LSP that is routed through multiple intermediate LSRs that switch based on the PW label. In a certain sense it is a matter of perspective. There is a tendency to look "outward". I.e. given a VPLS, try to define what to build around it to generalize it. Instead, one should look "inward". Given a VPLS, try to define how you can add intermediate nodes that aggregate and switch traffic between the PEs. It seems that looking outward is more in line with the natural evolution of networks, but that is just an optical illusion. From exim@www1.ietf.org Wed Aug 6 09:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15632 for ; Wed, 6 Aug 2003 09:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOIp-0004wb-Lh for l2vpn-archive@odin.ietf.org; Wed, 06 Aug 2003 09:26:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76DQ7YU019001 for l2vpn-archive@odin.ietf.org; Wed, 6 Aug 2003 09:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOIp-0004wO-II for l2vpn-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 09:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15626 for ; Wed, 6 Aug 2003 09:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOIn-0002lp-00 for l2vpn-web-archive@ietf.org; Wed, 06 Aug 2003 09:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kOIn-0002ll-00 for l2vpn-web-archive@ietf.org; Wed, 06 Aug 2003 09:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOIi-0004vr-UM; Wed, 06 Aug 2003 09:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOHy-0004tW-15 for l2vpn@optimus.ietf.org; Wed, 06 Aug 2003 09:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15602 for ; Wed, 6 Aug 2003 09:25:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOHw-0002lT-00 for l2vpn@ietf.org; Wed, 06 Aug 2003 09:25:12 -0400 Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx with esmtp (Exim 4.12) id 19kOHv-0002lO-00 for l2vpn@ietf.org; Wed, 06 Aug 2003 09:25:11 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.1/8.12.1) with ESMTP id h76DN26i012789 for ; Wed, 6 Aug 2003 16:23:02 +0300 (IDT) Received: from exrad2.ad.rad.co.il ([192.114.24.112]) by antivir1.rad.co.il (8.12.1/8.12.1) with ESMTP id h76DN2ka012786 for ; Wed, 6 Aug 2003 16:23:02 +0300 (IDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C1E.12B7D0D3" Subject: LDP, LSP PING and VPLS OAM questions Date: Wed, 6 Aug 2003 16:24:32 +0300 Message-ID: <27A0F290348F8E45AEF79889DDE65A52881512@exrad2.ad.rad.co.il> Thread-Topic: LDP, LSP PING and VPLS OAM questions Thread-Index: AcNcHhHVtRxVptwfSKmfbjwF8Pewgw== From: "Yifat Migdal-Steinberg" To: Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35C1E.12B7D0D3 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hello, I have the following questions regarding VPLS (H-VPLS) based on the = lassere-vkompella draft: Control plane versus Data plane: would it be true to say that : 1. data plane is responsible for encapsulation, de-encapsulation=20 and forwarding of packets. All packets arriving to the data plane are encapsulated with a VC label = and one or more LSP labels. 2. Control plane is responsible for setting up the VC and LSP tunnels. = It would usually be LDP for VC tunnels, and might be RSVP-TE for LSP tunnels in the core.=20 The signaling messages (IP/UDP or IP/TCP frames MAY be encapsulated) (The main question is whether LDP packets are NEVER encapsulated, or MAY = be encapsulated). If they are encapsulated, is there a special encapsulation for signaling = (like special label value) ? LSP ping and VPLS OAM (Ping+Traceroute): Error codes: When sending an echo reply of a VPLS ping/traceroute, in = case of error, what would the return code in the echo reply message be - is it always 0, and an error = TLV is included with the appropriate VPLS OAM return code (1-7...) OR, the return value is one of the LSP ping error codes, and 0 + error = TLV is a private state. If only an H. L2 TLV (type=3D10) is included in the request message, is = the LSP checked as well, based on the label of the encapsulated packet, and an error code returned, or is it checked = ONLY if the appropriate TLV is included in the TLV stack. In case of error in the LSP - what = would the return codes be? In case of error in the VC - what would the return code be? Generally - if an hierarchy of LSPs are tested, and a TLVs stack is = included,=20 in case of error, what would be the return code in the reply message - does it refer only to the bottom TLV/LSP or other? (The question rises since the return code is one, while the TLVs may be = stackable) Yifat Mrs. Yifat Migdal-Steinberg RAD Data communications Ltd. 24 Raoul Vallenberg St. Tel-Aviv Tel:03-7657035 Fax:03-6455305 ------_=_NextPart_001_01C35C1E.12B7D0D3 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable LDP, LSP PING and VPLS OAM questions

Hello,

I have the following = questions regarding VPLS (H-VPLS) based on the lassere-vkompella = draft:

Control plane versus Data = plane:

would it be true to say that = :

1. data plane is responsible = for encapsulation, de-encapsulation

and forwarding  of = packets.

All packets arriving to the = data plane are encapsulated with a VC label and one or more LSP = labels.

2. Control plane is = responsible for setting up the VC and LSP tunnels. It would usually be = LDP for VC tunnels,

and might be RSVP-TE for LSP = tunnels in the core.

The signaling messages = (IP/UDP or IP/TCP frames MAY be encapsulated)

(The main question is = whether LDP packets are NEVER encapsulated, = or MAY be encapsulated).

If they are encapsulated, is = there a special encapsulation for signaling (like special label value) = ?

LSP ping and VPLS OAM = (Ping+Traceroute):

Error codes: When sending an = echo reply of a VPLS ping/traceroute, in case of error, what would = the

return code in the echo = reply message be - is it always 0, and an error TLV is included with the = appropriate VPLS OAM return code (1-7...)

OR, the return value is one = of the LSP ping error codes, and 0 + error TLV is a private = state.

If only an H. L2 TLV = (type=3D10) is included in the request message, is the LSP checked as = well, based on the label

of the encapsulated packet, = and an error code returned, or is it checked ONLY if the = appropriate

TLV is included in the TLV = stack. In case of error in the LSP  - what would the return codes = be?

In case of error in the VC - = what would the return code be?

Generally - if an hierarchy = of LSPs are tested, and a TLVs stack is included,

in case of error, what would = be the return code in the reply message -

does it refer only to the = bottom TLV/LSP or other?

(The question rises since = the return code is one, while the TLVs may be stackable)

Yifat

Mrs. Yifat Migdal-Steinberg

RAD Data communications Ltd.

24 Raoul Vallenberg St.

Tel-Aviv

Tel:03-7657035

Fax:03-6455305

------_=_NextPart_001_01C35C1E.12B7D0D3-- From exim@www1.ietf.org Wed Aug 6 15:04:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29832 for ; Wed, 6 Aug 2003 15:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTZt-0004Z2-6K for l2vpn-archive@odin.ietf.org; Wed, 06 Aug 2003 15:04:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76J45hs017545 for l2vpn-archive@odin.ietf.org; Wed, 6 Aug 2003 15:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTZs-0004Yu-Hv for l2vpn-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 15:04:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29777 for ; Wed, 6 Aug 2003 15:03:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTZp-0005vL-00 for l2vpn-web-archive@ietf.org; Wed, 06 Aug 2003 15:04:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kTZp-0005vI-00 for l2vpn-web-archive@ietf.org; Wed, 06 Aug 2003 15:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTZp-0004YN-NA; Wed, 06 Aug 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTZ3-0004Tx-UA for l2vpn@optimus.ietf.org; Wed, 06 Aug 2003 15:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29694 for ; Wed, 6 Aug 2003 15:03:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTZ0-0005ui-00 for l2vpn@ietf.org; Wed, 06 Aug 2003 15:03:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19kTZ0-0005uD-00 for l2vpn@ietf.org; Wed, 06 Aug 2003 15:03:10 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2003 12:07:24 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h76J2cxc016059; Wed, 6 Aug 2003 15:02:38 -0400 (EDT) Message-Id: <200308061902.h76J2cxc016059@rtp-core-2.cisco.com> To: l2vpn@ietf.org Subject: Failures of the full mesh Reply-to: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Wed_Aug__6_15:02:38_2003-1" Date: Wed, 06 Aug 2003 15:02:38 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Multipart_Wed_Aug__6_15:02:38_2003-1 Content-Type: text/plain; charset=US-ASCII I've posted the following draft to sketch out a proposal for detecting and reacting to failures of the full mesh in VPLS and IPLS. --Multipart_Wed_Aug__6_15:02:38_2003-1 Content-Type: message/rfc822 Return-Path: Message-Id: <200308061440.KAA18867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-l2vpn-mesh-failure-00.txt Date: Wed, 06 Aug 2003 10:40:03 -0400 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS Author(s) : E. Rosen Filename : draft-rosen-l2vpn-mesh-failure-00.txt Pages : 0 Date : 2003-8-6 Certain L2VPN architectures [IPLS, VPLS] rely on there being a full mesh of pseudowires [PWE3-ARCH] among a set of entities. This mesh is used to provide a 'LAN-like' service among the entities. If one or more of these pseudowires is absent, so that there is not really a full mesh, various higher layers (from routing to bridge control protocols) that expect a LAN-like service may fail to work as expected. Therefore it is desirable to have procedures that enable the pseudowire endpoints to determine automatically whether there is really a full mesh or not. It is also desirable to have procedures that cause the L2VPNs to adapt to pseudowire failures. This document proposes a set of procedures to meet these goals. Detailed protocol encodings are not present, but will be added in future versions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-l2vpn-mesh-failure-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-l2vpn-mesh-failure-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosen-l2vpn-mesh-failure-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-6095823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-l2vpn-mesh-failure-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-l2vpn-mesh-failure-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6095823.I-D@ietf.org> --OtherAccess-- --NextPart-- --Multipart_Wed_Aug__6_15:02:38_2003-1-- From exim@www1.ietf.org Wed Aug 6 19:35:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10174 for ; Wed, 6 Aug 2003 19:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXo7-0007lI-Ub for l2vpn-archive@odin.ietf.org; Wed, 06 Aug 2003 19:35:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76NZ3QL029832 for l2vpn-archive@odin.ietf.org; Wed, 6 Aug 2003 19:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXo7-0007l5-Qy for l2vpn-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 19:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10171 for ; Wed, 6 Aug 2003 19:34:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kXo6-0000S5-00 for l2vpn-web-archive@ietf.org; Wed, 06 Aug 2003 19:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kXo5-0000S2-00 for l2vpn-web-archive@ietf.org; Wed, 06 Aug 2003 19:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXo5-0007kQ-AP; Wed, 06 Aug 2003 19:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kXnf-0007jm-3r for l2vpn@optimus.ietf.org; Wed, 06 Aug 2003 19:34:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10159 for ; Wed, 6 Aug 2003 19:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kXnd-0000Rh-00 for l2vpn@ietf.org; Wed, 06 Aug 2003 19:34:33 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kXnc-0000Re-00 for l2vpn@ietf.org; Wed, 06 Aug 2003 19:34:32 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kXnd-000Is3-29 for l2vpn@ietf.org; Wed, 06 Aug 2003 23:34:33 +0000 Date: Wed, 6 Aug 2003 16:34:25 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <40206481174.20030806163425@psg.com> To: l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-Reply-To: <200307301834.h6UIYVxc022222@rtp-core-2.cisco.com> References: <200307301834.h6UIYVxc022222@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the delay. Eric: > But this doesn't handle the case where A and Z, for some reason, either (a) > never find out about each other, or (b) never succeed in setting up PWs to > each other in the first place. Also, if node Z happens to go down, doesn't > this make all the PWs go down? > I really don't think this can be done based on local knowledge. You're right. Looks like without the PW status from others we can't tell the cases where a PW corresponds to a node failure that we don't need to worry about (because 2-way connectivity is disrupted for all other nodes and VPN routing reconverges correctly) and a real PW failure where we might need to either do a repair or ensure consistent 2-way connectivity by bringing some other PWs logically down. Kireeti: > This might be simpler, but it is a hack. It is cleaner for A and/or Z > to withdraw their labels so that B..Y all know that their connections > to A and/or Z are down. Per above, agreed that node-local decision wouldn't work. However, if we go the route of degrading connectivity to the level of a node failure in a PW failure scenario, then withdrawing the labels may not be the way, as we may end up with catch-22, where I am trying to decide if I should bring a PW up based on the state of other PWs, and other PWs are not brought up, because other nodes are waiting on me. I think we need logical status for a PW that the nodes would control locally in addition to the actual PW status that they would exchange with each other. Cheng-Yin: > Mick Seaman proposed a solution on IEEE 802.1 > (or PPVPN?) mailing list prior to this. My understanding of the proposal > is - the VPLS entity shall disable the MAC port presented to the 802.1ad > bridge if a PW fails. I think Himanshu has described a similar approach > ("blocking" VPLS port) in this thread. Doesn't this suffer from the same problem Eric pointed out--the whole VPLS falling apart when a single node goes down and brings PWs with all other PEs down too? Alex From exim@www1.ietf.org Thu Aug 7 05:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05803 for ; Thu, 7 Aug 2003 05:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khSE-0005TW-Ea for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 05:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h779r6ZC021042 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 05:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khSE-0005TJ-8U for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 05:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05790 for ; Thu, 7 Aug 2003 05:52:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khSA-0004My-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 05:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19khSA-0004Mv-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 05:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khS9-0005Sj-1M; Thu, 07 Aug 2003 05:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khRq-0005SC-6i for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 05:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05780 for ; Thu, 7 Aug 2003 05:52:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khRm-0004Ml-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 05:52:38 -0400 Received: from maila.telia.com ([194.22.194.231]) by ietf-mx with esmtp (Exim 4.12) id 19khRl-0004Mi-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 05:52:37 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.9/8.12.9) with ESMTP id h779qWnS021874; Thu, 7 Aug 2003 11:52:32 +0200 (CEST) X-Original-Recipient: l2vpn@ietf.org Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h779qVc05593; Thu, 7 Aug 2003 11:52:31 +0200 (CEST) Message-ID: <3F321F97.5080709@pi.se> Date: Thu, 07 Aug 2003 11:44:55 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson CC: l2vpn , Rick Wilder , Vach Kompella , Thomas Narten , Alex Zinin , Scott Bradner Subject: Re: opinion on number of vpls soluions - polling operators in the l2vpn wg References: <3F1810DF.6040109@pi.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, a few weeks ago I sent this mail soliticing the opinions of operators on the number of VPLS solutions that the l2vpn wg shall produce, from operators. I guess that the response has not been overwhelming. just a handfull (6), of which one was clearly not from an operator. If you an operator and want to respond please do so. Of the opertor respeonses 1 was addresed to the chairs/ADs, 2 came through Scott and 2 directly to me. I guess that the conclusions are: - that oerators want a vpls solution (rather quickly) - that operators are as diverging in opinions as the the rest of the working group on the technical solution - that the operators would expect a standards organization to come with one single compatible standard - that there are supporters for ldp and bgp based solutions among the operators Hardly, decisiveand leaves us more or less where we were when we left the Vienna meeting. We will try to solve this through the normal wg process. /Loa Loa Andersson wrote: > Working Group, > > we would like to solicit the input of operators represented in the > l2vpn working group on the discusion on the number of vpls solutions > to be progressed and standardized by the IETF. > > This have been discussed on the mailing list and ws discussed over again > at the l2vpn wg meeting in Vienna. > > We know that operators some times, e.g. for competitive reason, don't > want to speak up in public, therefore it is possible to send a mail > to Scott Bradner > > sob@harvard.edu > > He will make sure that the response will be kept annonymous, and only > the content made known to the wg chairs. The rest of you can send mail > directly to the wg-chairs, with a copy to the wg mailing list as you > see fit. > > What we would like to is: > > - do you prefer one single solution for the vpls space > - do you prefer multiple solutions vpls space > - do care if there is any solution at all for the vpls space > - do you care about the number of solutions at all, as long as > your prefered solution is represented. > > We don't plan to make the "votes" public, just tell the working > group the sense of the operator community. > > We appreciate your support in this. > > Rick, Vach and Loa > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From exim@www1.ietf.org Thu Aug 7 07:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08707 for ; Thu, 7 Aug 2003 07:47:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjEW-0000yd-N8 for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 07:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Bl4iR003749 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 07:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjEW-0000yO-Hs for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 07:47:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08693 for ; Thu, 7 Aug 2003 07:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjEV-0005Er-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 07:47:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kjEV-0005Eo-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 07:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjET-0000xv-Lv; Thu, 07 Aug 2003 07:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjE4-0000xd-Gt for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 07:46:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08689 for ; Thu, 7 Aug 2003 07:46:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjE3-0005El-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 07:46:35 -0400 Received: from frlnparexcha03.lambdanet.fr ([217.71.101.91]) by ietf-mx with esmtp (Exim 4.12) id 19kjE2-0005Eb-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 07:46:34 -0400 Received: by frlnparexcha03.lambdanet.fr with Internet Mail Service (5.5.2655.55) id ; Thu, 7 Aug 2003 13:46:24 +0200 Message-ID: <8D91FF5277472A45A0A8F9654A14649701494B81@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'Loa Andersson'" Cc: l2vpn Subject: RE: opinion on number of vpls soluions - polling operators in the l2vpn wg Date: Thu, 7 Aug 2003 13:46:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35CD9.8687A100" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35CD9.8687A100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Loa, If something is wrong under a VPLS solution, then the group must reject = it but if nothing is technically wrong... why not live with both,standardising them and make them (co)existing properly? Operators are able to choose between 2 solutions according to the = necessary efforts (or not) to make cohabit VPLS with other services.=20 I am convinced that to impose a unique solution will only delay the deployment of VPLS. This is my personnal point of view. Mourad -----Message d'origine----- De : Loa Andersson [mailto:loa@pi.se] Envoy=E9 : jeudi 7 ao=FBt 2003 11:45 =C0 : Loa Andersson Cc : l2vpn; Rick Wilder; Vach Kompella; Thomas Narten; Alex Zinin; = Scott Bradner Objet : Re: opinion on number of vpls soluions - polling operators in the l2vpn wg All, a few weeks ago I sent this mail soliticing the opinions of operators on the number of VPLS solutions that the l2vpn wg shall produce, from operators. I guess that the response has not been overwhelming. just a handfull (6), of which one was clearly not from an operator. If you an operator and want to respond please do so. Of the opertor respeonses 1 was addresed to the chairs/ADs, 2 came through Scott and 2 directly to me. I guess that the conclusions are: - that oerators want a vpls solution (rather quickly) - that operators are as diverging in opinions as the the rest of the working group on the technical solution - that the operators would expect a standards organization to come with one single compatible standard - that there are supporters for ldp and bgp based solutions among the operators Hardly, decisiveand leaves us more or less where we were when we left the Vienna meeting. We will try to solve this through the normal wg process. /Loa Loa Andersson wrote: > Working Group, >=20 > we would like to solicit the input of operators represented in the > l2vpn working group on the discusion on the number of vpls solutions > to be progressed and standardized by the IETF. >=20 > This have been discussed on the mailing list and ws discussed over = again > at the l2vpn wg meeting in Vienna. >=20 > We know that operators some times, e.g. for competitive reason, don't > want to speak up in public, therefore it is possible to send a mail > to Scott Bradner >=20 > sob@harvard.edu >=20 > He will make sure that the response will be kept annonymous, and only > the content made known to the wg chairs. The rest of you can send = mail > directly to the wg-chairs, with a copy to the wg mailing list as you > see fit. >=20 > What we would like to is: >=20 > - do you prefer one single solution for the vpls space > - do you prefer multiple solutions vpls space > - do care if there is any solution at all for the vpls space > - do you care about the number of solutions at all, as long as > your prefered solution is represented. >=20 > We don't plan to make the "votes" public, just tell the working > group the sense of the operator community. >=20 > We appreciate your support in this. >=20 > Rick, Vach and Loa >=20 >=20 --=20 /Loa mobile + 46 739 81 21 64 email: loa@pi.se ------_=_NextPart_001_01C35CD9.8687A100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: opinion on number of vpls soluions - polling operators in = the l2vpn wg

Hi Loa,

If something is wrong under a VPLS solution, then the = group must reject it but if nothing is technically wrong...
why not live with both,standardising them and make = them (co)existing properly?

Operators are able to choose between 2 solutions = according to the necessary efforts (or not) to make cohabit VPLS with = other services.

I am convinced that to impose a unique solution will = only delay the deployment of VPLS.

This is my personnal point of view.

Mourad


-----Message d'origine-----
De : Loa Andersson [mailto:loa@pi.se]
Envoy=E9 : jeudi 7 ao=FBt 2003 11:45
=C0 : Loa Andersson
Cc : l2vpn; Rick Wilder; Vach Kompella; Thomas = Narten; Alex Zinin; Scott
Bradner
Objet : Re: opinion on number of vpls soluions - = polling operators in
the l2vpn wg


All,

a few weeks ago I sent this mail soliticing the = opinions of operators
on the number of VPLS solutions that the l2vpn wg = shall produce, from
operators. I guess that the response has not  = been overwhelming. just
a handfull (6), of which one was clearly not from an = operator. If you
an operator and want to respond please do so.
Of the opertor respeonses 1 was addresed to the = chairs/ADs, 2 came
through Scott and 2 directly to me.

I guess that the conclusions are:

- that oerators want a vpls solution (rather = quickly)
- that operators are as diverging in opinions as the = the rest of
   the working group on the technical = solution
- that the operators would expect a standards = organization to come
   with one single compatible = standard
- that there are supporters for ldp and bgp based = solutions among the
   operators

Hardly, decisiveand leaves us more or less where we = were when we left
the Vienna meeting. We will try to solve this = through the normal wg
process.

/Loa

Loa Andersson wrote:
> Working Group,
>
> we would like to solicit the input of operators = represented in the
> l2vpn working group on the discusion on the = number of vpls solutions
> to be progressed and standardized by the = IETF.
>
> This have been discussed on the mailing list = and ws discussed over again
> at the l2vpn wg meeting in Vienna.
>
> We know that operators some times, e.g. for = competitive reason, don't
> want to speak up in public, therefore it is = possible to send a mail
> to Scott Bradner
>
> sob@harvard.edu
>
> He will make sure that the response will be = kept annonymous, and only
> the content made known to the wg chairs. The = rest of you can send mail
> directly to the wg-chairs, with a copy to the = wg mailing list as you
> see fit.
>
> What we would like to is:
>
> - do you prefer one single solution for the = vpls space
> - do you prefer multiple solutions vpls = space
> - do care if there is any solution at all for = the vpls space
> - do you care about the number of solutions at = all, as long as
>   your prefered solution is = represented.
>
> We don't plan to make the "votes" = public, just tell the working
> group the sense of the operator = community.
>
> We appreciate your support in this.
>
> Rick, Vach and Loa
>
>


--
/Loa

mobile + 46 739 81 21 64
email: loa@pi.se

------_=_NextPart_001_01C35CD9.8687A100-- From exim@www1.ietf.org Thu Aug 7 09:43:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12058 for ; Thu, 7 Aug 2003 09:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kl2m-0005XU-T1 for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 09:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Dh4fj021286 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 09:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kl2m-0005XE-1q for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 09:43:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12036 for ; Thu, 7 Aug 2003 09:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kl2k-00064c-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 09:43:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kl2j-00064Y-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 09:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kl2i-0005Wd-Uv; Thu, 07 Aug 2003 09:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kl24-0005TL-TF for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 09:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12007 for ; Thu, 7 Aug 2003 09:42:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kl23-00063z-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 09:42:19 -0400 Received: from sc-f100-01.extremenetworks.com ([63.251.106.30] helo=extrgate1.extremenetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19kl22-00063U-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 09:42:18 -0400 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Thu, 7 Aug 2003 06:41:29 -0700 Message-ID: <82F679A6A377F84B8F665D8F90D12B8DD8F527@sc-msexch-05.extremenetworks.com> From: Olen Stokes To: "'Yifat Migdal-Steinberg'" , l2vpn@ietf.org Subject: RE: LDP, LSP PING and VPLS OAM questions Date: Thu, 7 Aug 2003 06:37:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35CE9.0BD57620" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35CE9.0BD57620 Content-Type: text/plain; charset="windows-1255" Please see comments in line... -----Original Message----- From: Yifat Migdal-Steinberg [mailto:yifat_ms@rad.com] Sent: Wednesday, August 06, 2003 9:25 AM To: l2vpn@ietf.org Subject: LDP, LSP PING and VPLS OAM questions Hello, I have the following questions regarding VPLS (H-VPLS) based on the lassere-vkompella draft: Control plane versus Data plane: would it be true to say that : 1. data plane is responsible for encapsulation, de-encapsulation and forwarding of packets. All packets arriving to the data plane are encapsulated with a VC label and one or more LSP labels. [OLS]: in cases where PHP is used, there may not be a "LSP label." 2. Control plane is responsible for setting up the VC and LSP tunnels. It would usually be LDP for VC tunnels, and might be RSVP-TE for LSP tunnels in the core. The signaling messages (IP/UDP or IP/TCP frames MAY be encapsulated) (The main question is whether LDP packets are NEVER encapsulated, or MAY be encapsulated). [OLS]: Packets for the targeted LDP session may be sent using the underlying LSP. If they are encapsulated, is there a special encapsulation for signaling (like special label value) ? LSP ping and VPLS OAM (Ping+Traceroute): Error codes: When sending an echo reply of a VPLS ping/traceroute, in case of error, what would the return code in the echo reply message be - is it always 0, and an error TLV is included with the appropriate VPLS OAM return code (1-7...) OR, the return value is one of the LSP ping error codes, and 0 + error TLV is a private state. [OLS]: The following LSP ping error codes should be used when responding to a HVPLS ping/traceroute: 1 Malformed echo request received 2 One or more of the TLVs was not understand For other codes, an error TLV is used. If only an H. L2 TLV (type=10) is included in the request message, is the LSP checked as well, based on the label of the encapsulated packet, and an error code returned, or is it checked ONLY if the appropriate TLV is included in the TLV stack. [OLS] : If only an H. L2 TLV is included in the request, the label for the underlying LSP cannot be checked since the packet may have gone through intermediate MPLS nodes. The label is included in the label stack of the downstream mapping so that an operator can see which of multiple equal cost underlying LSPs was chosen at the previous HVPLS node. In case of error in the LSP - what would the return codes be? In case of error in the VC - what would the return code be? Generally - if an hierarchy of LSPs are tested, and a TLVs stack is included, in case of error, what would be the return code in the reply message - does it refer only to the bottom TLV/LSP or other? (The question rises since the return code is one, while the TLVs may be stackable) [OLS]: If a request is received that has, for example, a stack of three TLVs, then my opinion would be: 1) the first TLV is checked. If this node is not the egress, then this TLV would be included in the reply and the appropriate return code set. If this node is the egress, then this TLV would be included in the reply and checking would move to the second TLV. 2) if this node is not the egress for the second TLV, then this TLV would be included in the reply and the return code set based on this TLV. If this node is the egress, then this TLV would be included in the reply and checking would move to the third TLV. 3) if this node is not the egress for the third TLV, then this TLV would be included in the reply and the return code set based on this TLV. If this node is the egress, then this TLV would be included in the reply and a return code of egress set. So, the reply would contain TLVs from the stack of TLVs in the request, up to where the replying node is not the egress. The return code would be set based on the last TLV in the stack in the reply. A return code of egress is assumed for the other TLVs in the stack. Again, this is my opinion. The authors of the LSP ping draft may have something else in mind. Yifat Mrs. Yifat Migdal-Steinberg RAD Data communications Ltd. 24 Raoul Vallenberg St. Tel-Aviv Tel:03-7657035 Fax:03-6455305 ------_=_NextPart_001_01C35CE9.0BD57620 Content-Type: text/html; charset="windows-1255" LDP, LSP PING and VPLS OAM questions
Please see comments in line...
-----Original Message-----
From: Yifat Migdal-Steinberg [mailto:yifat_ms@rad.com]
Sent: Wednesday, August 06, 2003 9:25 AM
To: l2vpn@ietf.org
Subject: LDP, LSP PING and VPLS OAM questions


Hello,

I have the following questions regarding VPLS (H-VPLS) based on the lassere-vkompella draft:

Control plane versus Data plane:

would it be true to say that :

1. data plane is responsible for encapsulation, de-encapsulation

and forwarding  of packets.

All packets arriving to the data plane are encapsulated with a VC label and one or more LSP labels.

[OLS]: in cases where PHP is used, there may not be a "LSP label."

2. Control plane is responsible for setting up the VC and LSP tunnels. It would usually be LDP for VC tunnels,

and might be RSVP-TE for LSP tunnels in the core.

The signaling messages (IP/UDP or IP/TCP frames MAY be encapsulated)

(The main question is whether LDP packets are NEVER encapsulated, or MAY be encapsulated).

[OLS]: Packets for the targeted LDP session may be sent using the underlying LSP.

If they are encapsulated, is there a special encapsulation for signaling (like special label value) ?

LSP ping and VPLS OAM (Ping+Traceroute):

Error codes: When sending an echo reply of a VPLS ping/traceroute, in case of error, what would the

return code in the echo reply message be - is it always 0, and an error TLV is included with the appropriate VPLS OAM return code (1-7...)

OR, the return value is one of the LSP ping error codes, and 0 + error TLV is a private state.
 
[OLS]: The following LSP ping error codes should be used when responding to a HVPLS ping/traceroute:

1    Malformed echo request received

2    One or more of the TLVs was not understand

For other codes, an error TLV is used.

 

If only an H. L2 TLV (type=10) is included in the request message, is the LSP checked as well, based on the label

of the encapsulated packet, and an error code returned, or is it checked ONLY if the appropriate

TLV is included in the TLV stack.

[OLS] : If only an H. L2 TLV is included in the request, the label for the underlying LSP cannot be checked since the packet may have gone through intermediate MPLS nodes.  The label is included in the label stack of the downstream mapping so that an operator can see which of multiple equal cost underlying LSPs was chosen at the previous HVPLS node.

 

 In case of error in the LSP  - what would the return codes be?

In case of error in the VC - what would the return code be?

Generally - if an hierarchy of LSPs are tested, and a TLVs stack is included,

in case of error, what would be the return code in the reply message -

does it refer only to the bottom TLV/LSP or other?

(The question rises since the return code is one, while the TLVs may be stackable)

[OLS]: If a request is received that has, for example, a stack of three TLVs, then my opinion would be:

1) the first TLV is checked.  If this node is not the egress, then this TLV would be included in the reply and the appropriate return code set.  If this node is the egress, then this TLV would be included in the reply and checking would move to the second TLV.

2) if this node is not the egress for the second TLV, then this TLV would be included in the reply and the return code set based on this TLV.  If this node is the egress, then this TLV would be included in the reply and checking would move to the third TLV.

3) if this node is not the egress for the third TLV, then this TLV would be included in the reply and the return code set based on this TLV.  If this node is the egress, then this TLV would be included in the reply and a return code of egress set.

So, the reply would contain TLVs from the stack of TLVs in the request, up to where the replying node is not the egress.  The return code would be set based on the last TLV in the stack in the reply.  A return code of egress is assumed for the other TLVs in the stack.

 Again, this is my opinion.  The authors of the LSP ping draft may have something else in mind.

Yifat

Mrs. Yifat Migdal-Steinberg

RAD Data communications Ltd.

24 Raoul Vallenberg St.

Tel-Aviv

Tel:03-7657035

Fax:03-6455305

------_=_NextPart_001_01C35CE9.0BD57620-- From exim@www1.ietf.org Thu Aug 7 15:08:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27844 for ; Thu, 7 Aug 2003 15:08:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq7H-0000aM-Hc for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 15:08:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77J836R002244 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 15:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq7H-0000a7-Bg for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 15:08:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27783 for ; Thu, 7 Aug 2003 15:07:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kq7E-0001vf-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 15:08:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kq7D-0001vc-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 15:07:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq7E-0000Za-I6; Thu, 07 Aug 2003 15:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq6w-0000VX-1Q for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 15:07:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27731 for ; Thu, 7 Aug 2003 15:07:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kq6t-0001v1-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:07:39 -0400 Received: from mailf.telia.com ([194.22.194.25]) by ietf-mx with esmtp (Exim 4.12) id 19kq6s-0001uw-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:07:38 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailf.telia.com (8.12.9/8.12.9) with ESMTP id h77J7WPl001476; Thu, 7 Aug 2003 21:07:32 +0200 (CEST) X-Original-Recipient: l2vpn@ietf.org Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h77J7Wc11002; Thu, 7 Aug 2003 21:07:32 +0200 (CEST) Message-ID: <3F32A378.6080101@pi.se> Date: Thu, 07 Aug 2003 21:07:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org CC: Eric Rosen , Vach Kompella , Rick Wilder Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, we have a request to make draft-rosen-ppvpn-l2-signaling-03.txt a working group document. Please comment on this to the mailing list. at this stage we want don't want to count abstention as support - so please speak up if you want this as a wg draft. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Thu Aug 7 15:25:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29192 for ; Thu, 7 Aug 2003 15:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqNj-00019r-8u for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 15:25:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77JP3jm004445 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 15:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqNj-00019c-2O for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 15:25:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29159 for ; Thu, 7 Aug 2003 15:24:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqNh-00026b-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 15:25:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kqNh-00026Y-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 15:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqNh-000198-G8; Thu, 07 Aug 2003 15:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqNC-00018s-A9 for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 15:24:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29155 for ; Thu, 7 Aug 2003 15:24:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqNB-00026P-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:24:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19kqNA-00026C-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:24:28 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 07 Aug 2003 12:28:58 -0700 Received: from pentagon (pentagon.cisco.com [64.100.238.39]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h77JNsXw008971; Thu, 7 Aug 2003 15:23:55 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-20.cisco.com [10.86.240.20]) by pentagon (8.10.2+Sun/CISCO.WS.1.2) with ESMTP id h77JNs824540; Thu, 7 Aug 2003 15:23:54 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Loa Andersson'" , Cc: "'Eric Rosen'" , "'Vach Kompella'" , "'Rick Wilder'" Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Thu, 7 Aug 2003 15:23:45 -0400 Organization: Cisco Systems Message-ID: <00ea01c35d19$6e9bb690$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F32A378.6080101@pi.se> Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I support. --Tom > All, > > we have a request to make > draft-rosen-ppvpn-l2-signaling-03.txt > a working group document. Please comment on this to the > mailing list. at this stage we want don't want to count > abstention as support - so please speak up if you want this > as a wg draft. > > /Loa > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > > From exim@www1.ietf.org Thu Aug 7 15:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29866 for ; Thu, 7 Aug 2003 15:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqi5-000269-KG for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 15:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Jk5UN008059 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 15:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqi5-00025u-Cn for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 15:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29862 for ; Thu, 7 Aug 2003 15:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqi4-0002FX-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 15:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kqi3-0002FU-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 15:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqi1-00025M-62; Thu, 07 Aug 2003 15:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqha-00024j-9E for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 15:45:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29853 for ; Thu, 7 Aug 2003 15:45:28 -0400 (EDT) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqhY-0002FK-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:45:32 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt08.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19kqhY-0002F3-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:45:32 -0400 Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 7 Aug 2003 20:45:04 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6BF7@i2km07-ukbr.domain1.systemhost.net> To: loa@pi.se Cc: l2vpn@ietf.org, rick_h_wilder@yahoo.com, vkompella@timetra.com, narten@us.ibm.com, zinin@psg.com, sob@harvard.edu Subject: RE: opinion on number of vpls soluions - polling operators in the l2vpn wg Date: Thu, 7 Aug 2003 20:44:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Loa....I am intrigued. Given a lukewarm (I am being (very) generous) response, how can you say: " - that operators want a vpls solution (rather quickly)". regards, Neil > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: 07 August 2003 10:45 > To: Loa Andersson > Cc: l2vpn; Rick Wilder; Vach Kompella; Thomas Narten; Alex > Zinin; Scott > Bradner > Subject: Re: opinion on number of vpls soluions - polling operators in > the l2vpn wg > > > All, > > a few weeks ago I sent this mail soliticing the opinions of operators > on the number of VPLS solutions that the l2vpn wg shall produce, from > operators. I guess that the response has not been overwhelming. just > a handfull (6), of which one was clearly not from an operator. If you > an operator and want to respond please do so. > Of the opertor respeonses 1 was addresed to the chairs/ADs, 2 came > through Scott and 2 directly to me. > > I guess that the conclusions are: > > - that oerators want a vpls solution (rather quickly) > - that operators are as diverging in opinions as the the rest of > the working group on the technical solution > - that the operators would expect a standards organization to come > with one single compatible standard > - that there are supporters for ldp and bgp based solutions among the > operators > > Hardly, decisiveand leaves us more or less where we were when we left > the Vienna meeting. We will try to solve this through the normal wg > process. > > /Loa > > Loa Andersson wrote: > > Working Group, > > > > we would like to solicit the input of operators represented in the > > l2vpn working group on the discusion on the number of vpls solutions > > to be progressed and standardized by the IETF. > > > > This have been discussed on the mailing list and ws > discussed over again > > at the l2vpn wg meeting in Vienna. > > > > We know that operators some times, e.g. for competitive > reason, don't > > want to speak up in public, therefore it is possible to send a mail > > to Scott Bradner > > > > sob@harvard.edu > > > > He will make sure that the response will be kept > annonymous, and only > > the content made known to the wg chairs. The rest of you > can send mail > > directly to the wg-chairs, with a copy to the wg mailing list as you > > see fit. > > > > What we would like to is: > > > > - do you prefer one single solution for the vpls space > > - do you prefer multiple solutions vpls space > > - do care if there is any solution at all for the vpls space > > - do you care about the number of solutions at all, as long as > > your prefered solution is represented. > > > > We don't plan to make the "votes" public, just tell the working > > group the sense of the operator community. > > > > We appreciate your support in this. > > > > Rick, Vach and Loa > > > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > > > From exim@www1.ietf.org Thu Aug 7 16:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00306 for ; Thu, 7 Aug 2003 16:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqvb-0002Ur-3M for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 16:00:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77K03jk009591 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 16:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqva-0002Uc-RH for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 16:00:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00285 for ; Thu, 7 Aug 2003 15:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqvZ-0002LA-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 16:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kqvY-0002L7-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 16:00:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqvZ-0002UA-2o; Thu, 07 Aug 2003 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kquh-0002Pk-Bc for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 15:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00276 for ; Thu, 7 Aug 2003 15:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kquf-0002Kw-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:59:05 -0400 Received: from lightwave.chromisys.com ([63.102.55.206]) by ietf-mx with esmtp (Exim 4.12) id 19kquf-0002Kc-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 15:59:05 -0400 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 12:58:21 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048B31@nimbus> From: John Drake To: "'Loa Andersson'" , l2vpn@ietf.org Cc: Eric Rosen , Vach Kompella , Rick Wilder Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Thu, 7 Aug 2003 12:58:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , absolutely > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Thursday, August 07, 2003 12:08 PM > To: l2vpn@ietf.org > Cc: Eric Rosen; Vach Kompella; Rick Wilder > Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? > > > All, > > we have a request to make > draft-rosen-ppvpn-l2-signaling-03.txt > a working group document. Please comment on this to the > mailing list. at this stage we want don't want to count > abstention as support - so please speak up if you want > this as a wg draft. > > /Loa > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > > From exim@www1.ietf.org Thu Aug 7 16:12:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00767 for ; Thu, 7 Aug 2003 16:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kr7D-0003Fb-BF for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 16:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77KC38I012489 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 16:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kr7D-0003FM-4M for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 16:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00745 for ; Thu, 7 Aug 2003 16:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kr7B-0002R9-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 16:12:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kr7B-0002R6-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 16:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kr7B-0003Eo-5x; Thu, 07 Aug 2003 16:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kr6K-0003Ae-Pq for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 16:11:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00655 for ; Thu, 7 Aug 2003 16:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kr6I-0002QH-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 16:11:07 -0400 Received: from maild.telia.com ([194.22.190.101]) by ietf-mx with esmtp (Exim 4.12) id 19kr6H-0002Pj-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 16:11:05 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maild.telia.com (8.12.9/8.12.9) with ESMTP id h77K9mNw009955; Thu, 7 Aug 2003 22:09:48 +0200 (CEST) X-Original-Recipient: l2vpn@ietf.org Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h77K9mc01683; Thu, 7 Aug 2003 22:09:48 +0200 (CEST) Message-ID: <3F32B210.9070108@pi.se> Date: Thu, 07 Aug 2003 22:09:52 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: l2vpn@ietf.org, rick_h_wilder@yahoo.com, vkompella@timetra.com, narten@us.ibm.com, zinin@psg.com, sob@harvard.edu Subject: Re: opinion on number of vpls soluions - polling operators in the l2vpn wg References: <0536FC9B908BEC4597EE721BE6A35389025D6BF7@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6BF7@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Neil, your correct - should have been - all the respondees want a vpls solution (rather quickly) btw the count is now up to 7 /Loa neil.2.harrison@bt.com wrote: > Loa....I am intrigued. Given a lukewarm (I am being (very) generous) > response, how can you say: > " - that operators want a vpls solution (rather quickly)". > > regards, Neil > > >>-----Original Message----- >>From: Loa Andersson [mailto:loa@pi.se] >>Sent: 07 August 2003 10:45 >>To: Loa Andersson >>Cc: l2vpn; Rick Wilder; Vach Kompella; Thomas Narten; Alex >>Zinin; Scott >>Bradner >>Subject: Re: opinion on number of vpls soluions - polling operators in >>the l2vpn wg >> >> >>All, >> >>a few weeks ago I sent this mail soliticing the opinions of operators >>on the number of VPLS solutions that the l2vpn wg shall produce, from >>operators. I guess that the response has not been overwhelming. just >>a handfull (6), of which one was clearly not from an operator. If you >>an operator and want to respond please do so. >>Of the opertor respeonses 1 was addresed to the chairs/ADs, 2 came >>through Scott and 2 directly to me. >> >>I guess that the conclusions are: >> >>- that oerators want a vpls solution (rather quickly) >>- that operators are as diverging in opinions as the the rest of >> the working group on the technical solution >>- that the operators would expect a standards organization to come >> with one single compatible standard >>- that there are supporters for ldp and bgp based solutions among the >> operators >> >>Hardly, decisiveand leaves us more or less where we were when we left >>the Vienna meeting. We will try to solve this through the normal wg >>process. >> >>/Loa >> >>Loa Andersson wrote: >> >>>Working Group, >>> >>>we would like to solicit the input of operators represented in the >>>l2vpn working group on the discusion on the number of vpls solutions >>>to be progressed and standardized by the IETF. >>> >>>This have been discussed on the mailing list and ws >> >>discussed over again >> >>>at the l2vpn wg meeting in Vienna. >>> >>>We know that operators some times, e.g. for competitive >> >>reason, don't >> >>>want to speak up in public, therefore it is possible to send a mail >>>to Scott Bradner >>> >>>sob@harvard.edu >>> >>>He will make sure that the response will be kept >> >>annonymous, and only >> >>>the content made known to the wg chairs. The rest of you >> >>can send mail >> >>>directly to the wg-chairs, with a copy to the wg mailing list as you >>>see fit. >>> >>>What we would like to is: >>> >>>- do you prefer one single solution for the vpls space >>>- do you prefer multiple solutions vpls space >>>- do care if there is any solution at all for the vpls space >>>- do you care about the number of solutions at all, as long as >>> your prefered solution is represented. >>> >>>We don't plan to make the "votes" public, just tell the working >>>group the sense of the operator community. >>> >>>We appreciate your support in this. >>> >>>Rick, Vach and Loa >>> >>> >> >> >>-- >>/Loa >> >>mobile + 46 739 81 21 64 >>email: loa@pi.se >> >> >> > > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Thu Aug 7 17:37:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04285 for ; Thu, 7 Aug 2003 17:37:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksRw-000769-TD for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 17:37:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77LbWGX027279 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 17:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksRw-00075m-Nr for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 17:37:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04255 for ; Thu, 7 Aug 2003 17:37:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksRR-0006rf-4S; Thu, 07 Aug 2003 17:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksRL-0006r9-Sf for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 17:36:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04243 for ; Thu, 7 Aug 2003 17:36:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ksRJ-00033f-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 17:36:53 -0400 Received: from vmmrnat.verisignmail.com ([216.168.230.187] helo=vmmr8.verisignmail.com) by ietf-mx with esmtp (Exim 4.12) id 19ksRI-00033c-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 17:36:52 -0400 Received: from ms7.verisignmail.com (ms7.verisignmail.com [216.168.230.174] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AOX08940; Thu, 7 Aug 2003 17:36:51 -0400 (EDT) Received: from khumbu ([65.211.67.100]) by ms7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ALW26732; Thu, 7 Aug 2003 17:36:50 -0400 (EDT) From: "Eric W Gray" To: "'Loa Andersson'" Cc: Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Thu, 7 Aug 2003 17:36:48 -0400 Message-ID: <024b01c35d2c$04f89510$6901a8c0@khumbu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F32A378.6080101@pi.se> Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Loa, Yes, this should be a WG document. -----Original Message----- From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, August 07, 2003 3:08 PM To: l2vpn@ietf.org Cc: Eric Rosen; Vach Kompella; Rick Wilder Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? All, we have a request to make draft-rosen-ppvpn-l2-signaling-03.txt a working group document. Please comment on this to the mailing list. at this stage we want don't want to count abstention as support - so please speak up if you want this as a wg draft. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Thu Aug 7 17:44:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04467 for ; Thu, 7 Aug 2003 17:44:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksYh-0007Mi-FL for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 17:44:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77LiVgL028307 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 17:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksYh-0007MU-At for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 17:44:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04457 for ; Thu, 7 Aug 2003 17:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksYC-0007Jl-FW; Thu, 07 Aug 2003 17:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksXe-0007JU-4a for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 17:43:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04447 for ; Thu, 7 Aug 2003 17:43:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ksXb-00035V-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 17:43:23 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19ksXb-00035S-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 17:43:23 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h77LfqU05002; Thu, 7 Aug 2003 17:41:52 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <3ZF0Q430>; Thu, 7 Aug 2003 17:41:51 -0400 Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6DD8@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Eric W Gray'" , "'Loa Andersson'" Cc: l2vpn@ietf.org Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Thu, 7 Aug 2003 17:41:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35D2C.61107AC0" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35D2C.61107AC0 Content-Type: text/plain Loa, I support to be a WG document. Vasile -----Original Message----- From: Eric W Gray [mailto:egray@westridgenetworks.com] Sent: Thursday, August 07, 2003 5:37 PM To: 'Loa Andersson' Cc: l2vpn@ietf.org Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Loa, Yes, this should be a WG document. -----Original Message----- From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, August 07, 2003 3:08 PM To: l2vpn@ietf.org Cc: Eric Rosen; Vach Kompella; Rick Wilder Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? All, we have a request to make draft-rosen-ppvpn-l2-signaling-03.txt a working group document. Please comment on this to the mailing list. at this stage we want don't want to count abstention as support - so please speak up if you want this as a wg draft. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se ------_=_NextPart_001_01C35D2C.61107AC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc?

Loa,

  I support to be a WG document.

Vasile

-----Original Message-----
From: Eric W Gray [mailto:egray@westridgenetwor= ks.com]
Sent: Thursday, August 07, 2003 5:37 PM
To: 'Loa Andersson'
Cc: l2vpn@ietf.org
Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - = for wg doc?


Loa,

        Yes, this = should be a WG document.

-----Original Message-----
From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] = On Behalf Of Loa Andersson
Sent: Thursday, August 07, 2003 3:08 PM
To: l2vpn@ietf.org
Cc: Eric Rosen; Vach Kompella; Rick Wilder
Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for = wg doc?

All,

we have a request to make
draft-rosen-ppvpn-l2-signaling-03.txt
a working group document. Please comment on this to = the
mailing list. at this stage we want don't want to = count abstention as support - so please speak up if you want this as a = wg draft.

/Loa

--
Loa Andersson

Mobile          = +46 739 81 21 64
Email         &nbs= p; loa@pi.se






------_=_NextPart_001_01C35D2C.61107AC0-- From exim@www1.ietf.org Thu Aug 7 22:57:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13345 for ; Thu, 7 Aug 2003 22:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kxRD-0001Px-RZ for l2vpn-archive@odin.ietf.org; Thu, 07 Aug 2003 22:57:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h782v7L2005445 for l2vpn-archive@odin.ietf.org; Thu, 7 Aug 2003 22:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kxRD-0001Pk-Lm for l2vpn-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 22:57:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13342 for ; Thu, 7 Aug 2003 22:57:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kxR7-0004rt-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 22:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kxR6-0004rq-00 for l2vpn-web-archive@ietf.org; Thu, 07 Aug 2003 22:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kxR7-0001PI-Eo; Thu, 07 Aug 2003 22:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kxQN-0001P6-Ml for l2vpn@optimus.ietf.org; Thu, 07 Aug 2003 22:56:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13331 for ; Thu, 7 Aug 2003 22:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kxQK-0004rg-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 22:56:12 -0400 Received: from tomts21.bellnexxia.net ([209.226.175.183] helo=tomts21-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19kxQJ-0004rd-00 for l2vpn@ietf.org; Thu, 07 Aug 2003 22:56:11 -0400 Received: from alcatel.com ([64.230.126.198]) by tomts21-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030808025610.JDSU19697.tomts21-srv.bellnexxia.net@alcatel.com>; Thu, 7 Aug 2003 22:56:10 -0400 Message-ID: <3F33114A.4010009@alcatel.com> Date: Thu, 07 Aug 2003 22:56:10 -0400 From: cylee User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Alex Zinin CC: l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols References: <200307301834.h6UIYVxc022222@rtp-core-2.cisco.com> <40206481174.20030806163425@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Alex Zinin wrote: >>Mick Seaman proposed a solution on IEEE 802.1 >>(or PPVPN?) mailing list prior to this. My understanding of the proposal >>is - the VPLS entity shall disable the MAC port presented to the 802.1ad >>bridge if a PW fails. I think Himanshu has described a similar approach >>("blocking" VPLS port) in this thread. >> > >Doesn't this suffer from the same problem Eric pointed out--the whole >VPLS falling apart when a single node goes down and brings PWs with >all other PEs down too? > Yes, I think all the proposals (whether the "LAN failure" emulation is transparent to higher layer protocols, e.g. in the above proposals and Vach's proposal, and in proposals which require routing protocols to handle the PW "failure") need to solve a common problem i.e. "... PEs may need to agree on which are the currently participating PEs and ensure all other participating PEs have connectivity to each other, i.e. a protocol among PEs may be needed ..." for each VPLS instance, essentially. This is what I have referred to as a "LAN failure emulation protocol" in past discussions. >>But this doesn't handle the case where A and Z, for some reason, either (a) >>never find out about each other, or (b) never succeed in setting up PWs to >>each other in the first place. Also, if node Z happens to go down, doesn't >>this make all the PWs go down? >> >>I really don't think this can be done based on local knowledge. >> > >You're right. Looks like without the PW status from others we can't >tell the cases where a PW corresponds to a node failure that we don't >need to worry about (because 2-way connectivity is disrupted for all >other nodes and VPN routing reconverges correctly) and a real PW >failure > >>This might be simpler, but it is a hack. It is cleaner for A and/or Z >>to withdraw their labels so that B..Y all know that their connections >>to A and/or Z are down. >> > >Per above, agreed that node-local decision wouldn't work. However, if >we go the route of degrading connectivity to the level of a node >failure in a PW failure scenario, then withdrawing the labels may not >be the way, as we may end up with catch-22, where I am trying to >decide if I should bring a PW up based on the state of other PWs, and >other PWs are not brought up, because other nodes are waiting on me. > Withdrawing labels is an implicit indication, and hence issues like the one you brought up. In my response to Himanshu, "I still think A & Z need to tell (may need to be explicit to prevent ambiguity) other PEs that it is not participating in the VPLS anymore.". Without an explicit PW status of a VPLS instance, I think there will also be similar issues initially when PWs are setup, and subsequent PW re-establishment after PW failure. I think a "LAN failure emulation protocol" can be specified but it is difficult to get it to work. Some concerns I have with a LAN failure emulation protocol are timing (fast enough to be transparent to higher layer protocols but not so fast as to cause unnecessary failure emulation) and race conditions (real or perceived multiple PW failure). Thanks, Cheng-Yin From exim@www1.ietf.org Fri Aug 8 00:34:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15561 for ; Fri, 8 Aug 2003 00:34:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kyx2-0004Dm-AJ for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 00:34:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h784Y47f016220 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 00:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kyx2-0004DX-4W for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 00:34:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15552 for ; Fri, 8 Aug 2003 00:33:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kywz-0005FU-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 00:34:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kywy-0005FR-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 00:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kywz-0004D5-Em; Fri, 08 Aug 2003 00:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kywf-0004Cl-OL for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 00:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15543 for ; Fri, 8 Aug 2003 00:33:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kywd-0005FJ-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 00:33:39 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19kywc-0005FA-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 00:33:38 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 9810020298 for ; Thu, 7 Aug 2003 22:36:06 -0600 (MDT) Date: Thu, 7 Aug 2003 22:33:03 -0600 Subject: Re: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: l2vpn@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <3F32A378.6080101@pi.se> Message-Id: <66140CEC-C959-11D7-BD97-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I support this becoming a WG document as well.. -danny On Thursday, August 7, 2003, at 01:07 PM, Loa Andersson wrote: > All, > > we have a request to make > draft-rosen-ppvpn-l2-signaling-03.txt > a working group document. Please comment on this to the > mailing list. at this stage we want don't want to count > abstention as support - so please speak up if you want > this as a wg draft. > > /Loa > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > > From exim@www1.ietf.org Fri Aug 8 00:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15894 for ; Fri, 8 Aug 2003 00:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz8e-0004tB-1l for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 00:46:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h784k4qo018787 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 00:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz8d-0004sw-S0 for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 00:46:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15889 for ; Fri, 8 Aug 2003 00:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kz8b-0005Kj-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 00:46:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kz8a-0005Kg-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 00:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz8c-0004sI-4K; Fri, 08 Aug 2003 00:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz8F-0004rT-Vr for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 00:45:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15831 for ; Fri, 8 Aug 2003 00:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kz8D-0005Jo-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 00:45:37 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19kz8C-0005Jl-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 00:45:36 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h784jWfF008626 for ; Thu, 7 Aug 2003 21:45:32 -0700 (MST) Received: from zin01exm01.corp.mot.com (zin01exm01.corp.mot.com [217.1.122.3]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h784jS76003794 for ; Thu, 7 Aug 2003 23:45:30 -0500 Received: by zin01exm01.corp.mot.com with Internet Mail Service (5.5.2657.2) id <3JKZ5CA2>; Fri, 8 Aug 2003 10:15:26 +0530 Message-ID: From: Nagarajan Ananth-Q3241C To: Loa Andersson , l2vpn@ietf.org Cc: Eric Rosen , Vach Kompella , Rick Wilder Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Fri, 8 Aug 2003 10:15:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I support the request to make this a WG doc. -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Friday, August 08, 2003 12:38 AM To: l2vpn@ietf.org Cc: Eric Rosen; Vach Kompella; Rick Wilder Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? All, we have a request to make draft-rosen-ppvpn-l2-signaling-03.txt a working group document. Please comment on this to the mailing list. at this stage we want don't want to count abstention as support - so please speak up if you want this as a wg draft. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Fri Aug 8 01:28:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16682 for ; Fri, 8 Aug 2003 01:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kznH-0006J2-OL for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 01:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h785S37h024234 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 01:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kznH-0006In-Hv for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 01:28:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16674 for ; Fri, 8 Aug 2003 01:27:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kznE-0005Vy-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 01:28:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kznE-0005Vv-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 01:28:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kznF-0006IL-4b; Fri, 08 Aug 2003 01:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzmi-0006I2-Ma for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 01:27:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16664 for ; Fri, 8 Aug 2003 01:27:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kzmf-0005Vr-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 01:27:25 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kzme-0005Vl-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 01:27:25 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 07:26:22 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h785OZx5008088; Fri, 8 Aug 2003 07:24:36 +0200 (MET DST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Fri, 8 Aug 2003 07:26:48 +0200 Message-ID: <3C775706078CA347A8653E03E1469106FA993A@xbe-ams-313.cisco.com> Thread-Topic: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Thread-Index: AcNdF0rGXRhSguJWS2iR9IGkwA2HmwAVijQw From: "Monique Morrow (mmorrow)" To: "Loa Andersson" Cc: "Eric Rosen (erosen)" , "Vach Kompella" , "Rick Wilder" , Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I support. /Monique -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: 07 August 2003 21:08 To: l2vpn@ietf.org Cc: Eric Rosen (erosen); Vach Kompella; Rick Wilder Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? All, we have a request to make draft-rosen-ppvpn-l2-signaling-03.txt a working group document. Please comment on this to the mailing list. at this stage we want don't want to count abstention as support - so please speak up if you want this as a wg draft. /Loa --=20 Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Fri Aug 8 03:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02480 for ; Fri, 8 Aug 2003 03:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1wq-0006HO-FT for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 03:46:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h787k4SO024132 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 03:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1wp-0006H9-Mm for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 03:46:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02472 for ; Fri, 8 Aug 2003 03:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l1wn-0006Ut-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 03:46:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l1wm-0006Uq-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 03:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1wm-0006Gf-Vz; Fri, 08 Aug 2003 03:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1wG-0006G6-Lq for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 03:45:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02469 for ; Fri, 8 Aug 2003 03:45:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l1wE-0006Un-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 03:45:26 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l1wD-0006Uf-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 03:45:25 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 09:44:29 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h787ggoA025815; Fri, 8 Aug 2003 09:42:42 +0200 (MET DST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Fri, 8 Aug 2003 09:44:55 +0200 Message-ID: <482B1AF8F350874DAED573526461DE3DEA876C@xbe-ams-313.cisco.com> Thread-Topic: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Thread-Index: AcNdF0rGXRhSguJWS2iR9IGkwA2HmwAVijQwAATEDjA= From: "Matthias Falkner (mfalkner)" To: "Loa Andersson" Cc: "Eric Rosen (erosen)" , "Vach Kompella" , "Rick Wilder" , Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I fully support this Matthias Falkner, Cisco Systems GmbH, 85399 Hallbergmoos Tel.: +49 811 559 5596, GSM: +49 170 575 4265 -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: 07 August 2003 21:08 To: l2vpn@ietf.org Cc: Eric Rosen (erosen); Vach Kompella; Rick Wilder Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? All, we have a request to make draft-rosen-ppvpn-l2-signaling-03.txt a working group document. Please comment on this to the mailing list. at this stage we want don't want to count abstention as support - so please speak up if you want this as a wg draft. /Loa --=20 Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Fri Aug 8 09:35:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10240 for ; Fri, 8 Aug 2003 09:35:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7Oa-0004SA-PC for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 09:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78DZ4N3017113 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 09:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7Oa-0004Rw-Hj for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 09:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10214 for ; Fri, 8 Aug 2003 09:34:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7OY-0000e8-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 09:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l7OY-0000e5-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 09:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7OX-0004RR-D9; Fri, 08 Aug 2003 09:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7Nf-0004Pb-Vb for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 09:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10207 for ; Fri, 8 Aug 2003 09:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7Ne-0000ds-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 09:34:06 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19l7Nd-0000di-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 09:34:05 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h78DXWD29420 for ; Fri, 8 Aug 2003 08:33:32 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 8 Aug 2003 09:33:28 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Loa Andersson'" , l2vpn@ietf.org Cc: Eric Rosen , Vach Kompella , Rick Wilder Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Fri, 8 Aug 2003 09:33:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Agree, Peter > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Thursday, August 07, 2003 3:08 PM > To: l2vpn@ietf.org > Cc: Eric Rosen; Vach Kompella; Rick Wilder > Subject: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? > > > All, > > we have a request to make > draft-rosen-ppvpn-l2-signaling-03.txt > a working group document. Please comment on this to the > mailing list. at this stage we want don't want to count > abstention as support - so please speak up if you want > this as a wg draft. > > /Loa > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > > From exim@www1.ietf.org Fri Aug 8 13:03:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17667 for ; Fri, 8 Aug 2003 13:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAdv-0005l1-GX for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 13:03:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78H37JJ022130 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 13:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAdv-0005kr-Bg for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 13:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17661 for ; Fri, 8 Aug 2003 13:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lAdt-00026N-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 13:03:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lAdt-00026J-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 13:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAdo-0005kN-Ie; Fri, 08 Aug 2003 13:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAd5-0005jl-Gm for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 13:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17647 for ; Fri, 8 Aug 2003 13:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lAd3-000262-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 13:02:13 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19lAd3-00025y-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 13:02:13 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 13:02:04 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001063E@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'Alex Zinin'" , l2vpn@ietf.org Subject: RE: On VPLS and Routing Protocols Date: Fri, 8 Aug 2003 13:02:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35DCE.C9DF5A10" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35DCE.C9DF5A10 Content-Type: text/plain; charset="iso-8859-1" What I mean by VPLS port blocking is this. If a PW from PE A to PE Z fails for VPLS instance x, PE A simply blocks bridge port to VPLS instance x. It does not send PW status to Z or to any other PEs. No traffic for VPLS instance x would be forwarded to/from any PW by PE A. Thus, isolating all the CEs behind PE A of VPLS instance x from the rest. I don't believe this has domino effect because no PE finds out about bridge port blocking on PE A. /himanshu Alex Zinin wrote: ---- stuff deleted --- > > Cheng-Yin: > > > Mick Seaman proposed a solution on IEEE 802.1 > > (or PPVPN?) mailing list prior to this. My understanding of > the proposal > > is - the VPLS entity shall disable the MAC port presented > to the 802.1ad > > bridge if a PW fails. I think Himanshu has described a > similar approach > > ("blocking" VPLS port) in this thread. > > Doesn't this suffer from the same problem Eric pointed out--the whole > VPLS falling apart when a single node goes down and brings PWs with > all other PEs down too? > > Alex > > > ------_=_NextPart_001_01C35DCE.C9DF5A10 Content-Type: text/html; charset="iso-8859-1" RE: On VPLS and Routing Protocols

What I mean by VPLS port blocking is this.

If a PW from PE A to PE Z fails for VPLS instance x,
PE A simply blocks bridge port to VPLS instance x.
It does not send PW status to Z or to any other PEs.
No traffic for VPLS instance x would be forwarded
to/from any PW by PE A. Thus, isolating all the CEs behind
PE A of VPLS instance x from the rest.

I don't believe this has domino effect because no PE
finds out about bridge port blocking on PE A.

/himanshu

Alex Zinin wrote:
---- stuff deleted ---
>
> Cheng-Yin:
>
> > Mick Seaman proposed a solution on IEEE 802.1
> > (or PPVPN?) mailing list prior to this. My understanding of
> the proposal
> > is - the VPLS entity shall disable the MAC port presented
> to the 802.1ad
> > bridge if a PW fails. I think Himanshu has described a
> similar approach
> > ("blocking" VPLS port) in this thread.
>
> Doesn't this suffer from the same problem Eric pointed out--the whole
> VPLS falling apart when a single node goes down and brings PWs with
> all other PEs down too?
>
> Alex
>
>
>

------_=_NextPart_001_01C35DCE.C9DF5A10-- From exim@www1.ietf.org Fri Aug 8 13:14:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18130 for ; Fri, 8 Aug 2003 13:14:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAoV-0006Hm-EI for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 13:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78HE3Ju024156 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 13:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAoV-0006HS-85 for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 13:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18107 for ; Fri, 8 Aug 2003 13:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lAoT-0002D6-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 13:14:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lAoS-0002D3-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 13:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAoT-0006Gm-A3; Fri, 08 Aug 2003 13:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lAnf-0006GM-HF for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 13:13:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18071 for ; Fri, 8 Aug 2003 13:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lAnd-0002CF-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 13:13:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19lAnd-0002Bu-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 13:13:09 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 08 Aug 2003 10:12:38 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h78HCaXw028000; Fri, 8 Aug 2003 13:12:36 -0400 (EDT) Message-Id: <200308081712.h78HCaXw028000@rtp-core-1.cisco.com> To: "Shah, Himanshu" cc: "'Alex Zinin'" , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Fri, 08 Aug 2003 13:02:02 -0400. <8162DD929D7AD24CAD3FC5317CE41FB001063E@w2kmaexg02.ciena.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Aug 2003 13:12:36 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Himanshu> If a PW from PE A to PE Z fails for VPLS instance x, Himanshu> PE A simply blocks bridge port to VPLS instance x. So if the pseudowire data plane fails entirely at PE Z, this means that all other PEs block their Emulated LAN ports for VPLS instance x. I.e., every VPLS instance supported by PE Z is 100% down. From exim@www1.ietf.org Fri Aug 8 14:07:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19487 for ; Fri, 8 Aug 2003 14:07:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBdn-000865-JW for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 14:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78I73WX031111 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 14:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBdn-00085i-D9 for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 14:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19478 for ; Fri, 8 Aug 2003 14:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBdl-0002VP-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 14:07:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lBdk-0002VM-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 14:07:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBdk-00084c-Vc; Fri, 08 Aug 2003 14:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBcq-0007zZ-Ur for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 14:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19467 for ; Fri, 8 Aug 2003 14:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBco-0002VG-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 14:06:02 -0400 Received: from gate1.cal.attcanada.com ([209.82.18.194] helo=ash.allstream.com) by ietf-mx with esmtp (Exim 4.12) id 19lBcn-0002V2-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 14:06:01 -0400 Received: from CALVS002.att-intra.com ([10.1.1.46]) by ash.allstream.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com for ; Fri, 8 Aug 2003 12:05:13 -0600 Received: From CALEX006.att-intra.com ([10.1.1.80]) by CALVS002.att-intra.com (WebShield SMTP v4.5 MR1a); id 1060365862613; Fri, 8 Aug 2003 12:04:22 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: Questions regarding the VPLS Date: Fri, 8 Aug 2003 12:04:17 -0600 Message-ID: Thread-Topic: Questions regarding the VPLS Thread-Index: AcNd13uwlZvIvcXcTfGsZSwKTSpFIA== From: "Christopher, Dunstan" To: Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Any-to-any service requires fully meshed VCs due to the "split horizon = rule" of learning and forwarding across the VPLS leg points.=20 a) What is the reason for Tunnel LSPs to be meshed across the PE-PE ? = Does this not bring back n^2 issue for addition of another PE.=20 b) What are the other technical alternatives to provide VPLS service = based on non PE-PE meshed tunnels when P is introduced? regards, Dunstan Christopher From exim@www1.ietf.org Fri Aug 8 14:32:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20215 for ; Fri, 8 Aug 2003 14:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC1z-0000pi-1V for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 14:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78IW3HA003200 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 14:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC1y-0000pX-Sl for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 14:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20196 for ; Fri, 8 Aug 2003 14:31:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lC1w-0002gm-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 14:32:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lC1v-0002gj-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 14:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC1x-0000p5-8R; Fri, 08 Aug 2003 14:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC1X-0000mR-Jq for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 14:31:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20167 for ; Fri, 8 Aug 2003 14:31:29 -0400 (EDT) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lC1U-0002gK-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 14:31:32 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19lC1U-0002g5-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 14:31:32 -0400 Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 8 Aug 2003 19:31:11 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6C0C@i2km07-ukbr.domain1.systemhost.net> To: Dunstan.Christopher@allstream.com, l2vpn@ietf.org Subject: RE: Questions regarding the VPLS Date: Fri, 8 Aug 2003 19:30:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Christopher, Dunstan wrote 08 August 2003 19:04 > Any-to-any service requires fully meshed VCs due to the > "split horizon rule" of learning and forwarding across the > VPLS leg points. > a) What is the reason for Tunnel LSPs to be meshed across the > PE-PE ? Does this not bring back n^2 issue for addition of > another PE. NH=> This issue is so important I can't let it pass without comment. In a co-ps mode only p2p and p2mp topology constructs are architecturally valid. (I will avoid getting into the discussion of the architecturally wrong mp2p merging case here, except to note that the only way to demerge is to run p2p trails above these *if* their client layer is not cnls). This means that if A wants to talk to B then A has to have (trail) connectivity in the data-plane with B....that is just a fact that cannot be avoided. So you cannot avoid this *ever* with a co-ps mode (or indeed a co-cs mode). You can stack trails (ie put in hierarchy) to improve scaling (something we have been doing in Telecoms since forever it seems). The only way to avoid the so-called N^/2 connectivity problem is not to have any data-plane connections at all, ie use a true cnls mode. All 3 modes (ie cnls, co-ps and co-cs) have different behaviours (which is a good thing) and we need them all. What we don't want is to have them corrupted by inappropriate treatment......not sure everyone has grokked the importance of this yet however. regards, Neil From exim@www1.ietf.org Fri Aug 8 14:37:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20397 for ; Fri, 8 Aug 2003 14:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC6n-00015m-UV for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 14:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Ib1AL004192 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 14:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC6n-00015X-QB for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 14:37:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20374 for ; Fri, 8 Aug 2003 14:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lC6l-0002kG-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 14:36:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lC6k-0002kD-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 14:36:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC6m-00014i-PP; Fri, 08 Aug 2003 14:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lC5w-000146-NR for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 14:36:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20337 for ; Fri, 8 Aug 2003 14:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lC5t-0002jg-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 14:36:05 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19lC5t-0002jb-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 14:36:05 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 14:36:00 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001063F@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'erosen@cisco.com'" Cc: "'Alex Zinin'" , l2vpn@ietf.org Subject: RE: On VPLS and Routing Protocols Date: Fri, 8 Aug 2003 14:35:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35DDB.E999AF10" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35DDB.E999AF10 Content-Type: text/plain; charset="iso-8859-1" Not true. In my example PE A would block emulated LAN port to VPLS instance x. PE Z or for that matter any PE in VPLS instance x would know that PE A has blocked emulated LAN port. Using your example, if PW data plane fails, PE Z would block emulated LAN port for VPLS instance x only.. No other PEs participating in VPLS instance x would know that PE Z has blocked his emulated LAN port for VPLS instance x. And neither would PE Z block emulated LAN port for VPLS instance other than x. Isn't this somewhat similar to what bridges do today? Blocking of a Bridge port is not notified to anybody. It is local decision based on information received from the BPDU. /himanshu > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, August 08, 2003 1:13 PM > To: Shah, Himanshu > Cc: 'Alex Zinin'; l2vpn@ietf.org > Subject: Re: On VPLS and Routing Protocols > > > > Himanshu> If a PW from PE A to PE Z fails for VPLS instance x, > Himanshu> PE A simply blocks bridge port to VPLS instance x. > > So if the pseudowire data plane fails entirely at PE Z, this > means that all > other PEs block their Emulated LAN ports for VPLS instance > x. I.e., every > VPLS instance supported by PE Z is 100% down. > > > ------_=_NextPart_001_01C35DDB.E999AF10 Content-Type: text/html; charset="iso-8859-1" RE: On VPLS and Routing Protocols

Not true.

In my example PE A would block emulated LAN port to
VPLS instance x. PE Z or for that matter any PE in VPLS
instance x would know that PE A has blocked emulated LAN
port.

Using  your example, if PW data plane fails, PE Z would block
emulated LAN port for VPLS instance x only.. No other PEs
participating in VPLS instance x would know that PE Z has
blocked his emulated LAN port for VPLS instance x.  And
neither would PE Z block emulated LAN port for VPLS
instance other than x. 

Isn't this somewhat similar to what bridges do today?
Blocking of a Bridge port is not notified to anybody. It is local
decision based on information received from the BPDU.

/himanshu


> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Friday, August 08, 2003 1:13 PM
> To: Shah, Himanshu
> Cc: 'Alex Zinin'; l2vpn@ietf.org
> Subject: Re: On VPLS and Routing Protocols
>
>
>
> Himanshu> If a PW from PE A to PE Z fails for VPLS instance x,
> Himanshu> PE A simply blocks bridge port to VPLS instance x.
>
> So if the pseudowire data plane fails  entirely at PE Z, this
> means that all
> other PEs block  their Emulated LAN ports for VPLS  instance
> x.  I.e., every
> VPLS instance supported by PE Z is 100% down.
>
>
>

------_=_NextPart_001_01C35DDB.E999AF10-- From exim@www1.ietf.org Fri Aug 8 16:25:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24679 for ; Fri, 8 Aug 2003 16:25:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDn3-0005uj-Lg for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 16:24:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KOjEY022714 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 16:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDn3-0005uG-6y for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:24:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24595 for ; Fri, 8 Aug 2003 16:24:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmT-0005cI-5C; Fri, 08 Aug 2003 16:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDDA-0004Lx-7I for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 15:47:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23761 for ; Fri, 8 Aug 2003 15:47:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDD8-0003PT-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 15:47:38 -0400 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 19lDD8-0003PA-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 15:47:38 -0400 Received: from vkompella ([64.47.48.10] RDNS failed) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Aug 2003 12:47:07 -0700 Reply-To: From: "Vach Kompella" To: "Christopher, Dunstan" , Subject: RE: Questions regarding the VPLS Date: Fri, 8 Aug 2003 12:48:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: X-OriginalArrivalTime: 08 Aug 2003 19:47:07.0650 (UTC) FILETIME=[D99F5E20:01C35DE5] Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit However, the n^2 issue isn't the same as the n^2 issue of ATM VCs. Here, the tunnels carry multiple services. -Vach > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org]On Behalf Of > Christopher, Dunstan > Sent: Friday, August 08, 2003 11:04 AM > To: l2vpn@ietf.org > Subject: Questions regarding the VPLS > > > > Any-to-any service requires fully meshed VCs due to the "split > horizon rule" of learning and forwarding across the VPLS leg points. > a) What is the reason for Tunnel LSPs to be meshed across the PE-PE ? > Does this not bring back n^2 issue for addition of another PE. > b) What are the other technical alternatives to provide VPLS service > based on non PE-PE meshed tunnels when P is introduced? > > > regards, > > Dunstan Christopher > > > From exim@www1.ietf.org Fri Aug 8 16:31:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25012 for ; Fri, 8 Aug 2003 16:31:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDtb-0006jK-Ak for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 16:31:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KVVJt025864 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 16:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDtb-0006j5-6M for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:31:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24994 for ; Fri, 8 Aug 2003 16:31:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDt6-0006fU-HJ; Fri, 08 Aug 2003 16:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDso-0006eu-QV for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 16:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24942 for ; Fri, 8 Aug 2003 16:30:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDsm-0003sP-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 16:30:41 -0400 Received: from gate1.cal.attcanada.com ([209.82.18.194] helo=ash.allstream.com) by ietf-mx with esmtp (Exim 4.12) id 19lDsm-0003rx-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 16:30:40 -0400 Received: from CALVS002.att-intra.com ([10.1.1.46]) by ash.allstream.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com for ; Fri, 8 Aug 2003 14:30:06 -0600 Received: From CALEX006.att-intra.com ([10.1.1.80]) by CALVS002.att-intra.com (WebShield SMTP v4.5 MR1a); id 1060374607463; Fri, 8 Aug 2003 14:30:07 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Questions regarding the VPLS Date: Fri, 8 Aug 2003 14:30:06 -0600 Message-ID: Thread-Topic: Questions regarding the VPLS Thread-Index: AcNd5eUkXt19kMfrScmcH+lnlA2C3gAADmQwAAFaYOA= From: "Christopher, Dunstan" To: Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does the PE-PE tunnels have to be meshed for L2VPNs ? Can we get away with segmenting the tunnel from PE-P, P-P and P-PE?=20 Would P help in L2VPN to alleviate meshed tunnel LSPs ? regards, Dunstan Christopher -----Original Message----- From: Vach Kompella [mailto:vach.kompella@alcatel.com] Sent: August 8, 2003 3:49 PM To: Christopher, Dunstan; l2vpn@ietf.org Subject: RE: Questions regarding the VPLS However, the n^2 issue isn't the same as the n^2 issue of ATM VCs. = Here, the tunnels carry multiple services. -Vach > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org]On Behalf Of > Christopher, Dunstan > Sent: Friday, August 08, 2003 11:04 AM > To: l2vpn@ietf.org > Subject: Questions regarding the VPLS > > > > Any-to-any service requires fully meshed VCs due to the "split > horizon rule" of learning and forwarding across the VPLS leg points. > a) What is the reason for Tunnel LSPs to be meshed across the PE-PE ? > Does this not bring back n^2 issue for addition of another PE. > b) What are the other technical alternatives to provide VPLS service > based on non PE-PE meshed tunnels when P is introduced? > > > regards, > > Dunstan Christopher > > > From exim@www1.ietf.org Fri Aug 8 16:57:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25710 for ; Fri, 8 Aug 2003 16:57:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEIK-0007iG-7M for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 16:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Kv40Q029648 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 16:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEIJ-0007i7-Rr for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25704 for ; Fri, 8 Aug 2003 16:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEIH-00045w-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 16:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lEIH-00045t-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 16:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEIH-0007hf-Ug; Fri, 08 Aug 2003 16:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEHv-0007hL-WA for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 16:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25697 for ; Fri, 8 Aug 2003 16:56:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEHt-00045e-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 16:56:37 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19lEHt-00045Y-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 16:56:37 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 16:56:32 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB0010642@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "Shah, Himanshu" , "'erosen@cisco.com'" Cc: "'Alex Zinin'" , "'l2vpn@ietf.org'" Subject: RE: On VPLS and Routing Protocols Date: Fri, 8 Aug 2003 16:56:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35DEF.8B63B440" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35DEF.8B63B440 Content-Type: text/plain; charset="iso-8859-1" Correction in my earlier response..... >In my example PE A would block emulated LAN port to > VPLS instance x. PE Z or for that matter any PE in VPLS > instance x would know that PE A has blocked emulated LAN > port. This should have read..... >In my example PE A would block emulated LAN port to > VPLS instance x. PE Z or for that matter any PE in VPLS > instance x would NOT know that PE A has blocked emulated LAN port ^^^^^ /himanshu > -----Original Message----- > From: Shah, Himanshu > Sent: Friday, August 08, 2003 2:36 PM > To: 'erosen@cisco.com' > Cc: 'Alex Zinin'; l2vpn@ietf.org > Subject: RE: On VPLS and Routing Protocols > > > Not true. > > > > Using your example, if PW data plane fails, PE Z would block > emulated LAN port for VPLS instance x only.. No other PEs > participating in VPLS instance x would know that PE Z has > blocked his emulated LAN port for VPLS instance x. And > neither would PE Z block emulated LAN port for VPLS > instance other than x. > > Isn't this somewhat similar to what bridges do today? > Blocking of a Bridge port is not notified to anybody. It is local > decision based on information received from the BPDU. > > /himanshu > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Friday, August 08, 2003 1:13 PM > > To: Shah, Himanshu > > Cc: 'Alex Zinin'; l2vpn@ietf.org > > Subject: Re: On VPLS and Routing Protocols > > > > > > > > Himanshu> If a PW from PE A to PE Z fails for VPLS instance x, > > Himanshu> PE A simply blocks bridge port to VPLS instance x. > > > > So if the pseudowire data plane fails entirely at PE Z, this > > means that all > > other PEs block their Emulated LAN ports for VPLS instance > > x. I.e., every > > VPLS instance supported by PE Z is 100% down. > > > > > > > ------_=_NextPart_001_01C35DEF.8B63B440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: On VPLS and Routing Protocols

Correction in my earlier response.....

>In my example PE A would block emulated LAN port = to
> VPLS instance x. PE Z or for that matter any PE = in VPLS
> instance x would know that PE A has blocked = emulated LAN
> port.

This should have read.....

>In my example PE A would block emulated LAN port = to
> VPLS instance x. PE Z or for that matter any PE = in VPLS
> instance x would NOT know that PE A has blocked = emulated LAN port
          &nb= sp;           &nb= sp;           = ^^^^^
/himanshu


> -----Original Message-----
> From: Shah, Himanshu
> Sent: Friday, August 08, 2003 2:36 PM
> To: 'erosen@cisco.com'
> Cc: 'Alex Zinin'; l2vpn@ietf.org
> Subject: RE: On VPLS and Routing Protocols =
>
>
> Not true.
>
>
>
> Using  your example, if PW data plane = fails, PE Z would block
> emulated LAN port for VPLS instance x only.. No = other PEs
> participating in VPLS instance x would know = that PE Z has
> blocked his emulated LAN port for VPLS instance = x.  And
> neither would PE Z block emulated LAN port for = VPLS
> instance other than x. 
>
> Isn't this somewhat similar to what bridges do = today?
> Blocking of a Bridge port is not notified to = anybody. It is local
> decision based on information received from the = BPDU.
>
> /himanshu
>
>
> > -----Original Message-----
> > From: Eric Rosen [mailto:erosen@cisco.com]
> > Sent: Friday, August 08, 2003 1:13 = PM
> > To: Shah, Himanshu
> > Cc: 'Alex Zinin'; l2vpn@ietf.org
> > Subject: Re: On VPLS and Routing Protocols =
> >
> >
> >
> > Himanshu> If a PW from PE A to PE Z = fails for VPLS instance x,
> > Himanshu> PE A simply blocks bridge = port to VPLS instance x.
> >
> > So if the pseudowire data plane = fails  entirely at PE Z, this
> > means that all
> > other PEs block  their Emulated LAN = ports for VPLS  instance
> > x.  I.e., every
> > VPLS instance supported by PE Z is 100% = down.
> >
> >
> >
>

------_=_NextPart_001_01C35DEF.8B63B440-- From exim@www1.ietf.org Fri Aug 8 17:01:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26030 for ; Fri, 8 Aug 2003 17:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEMF-0008Ca-3y for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 17:01:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78L17vS031522 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 17:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEME-0008CL-V9 for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 17:01:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26006 for ; Fri, 8 Aug 2003 17:01:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEMC-0004Bc-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lEMC-0004BZ-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEMD-0008Bp-JB; Fri, 08 Aug 2003 17:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEM5-00086x-P6 for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 17:00:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25982 for ; Fri, 8 Aug 2003 17:00:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEM3-0004B1-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:00:55 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19lEM3-00049u-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:00:55 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 08 Aug 2003 14:00:25 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h78L0MXw007790; Fri, 8 Aug 2003 17:00:22 -0400 (EDT) Message-Id: <200308082100.h78L0MXw007790@rtp-core-1.cisco.com> To: "Shah, Himanshu" cc: "'Alex Zinin'" , l2vpn@ietf.org Subject: Re: On VPLS and Routing Protocols In-reply-to: Your message of Fri, 08 Aug 2003 14:35:59 -0400. <8162DD929D7AD24CAD3FC5317CE41FB001063F@w2kmaexg02.ciena.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Aug 2003 17:00:22 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric> So if the pseudowire data plane fails entirely at PE Z, this means Eric> that all other PEs block their Emulated LAN ports for VPLS instance x. Eric> I.e., every VPLS instance supported by PE Z is 100% down. Himanshu> Using your example, if PW data plane fails, PE Z would block Himanshu> emulated LAN port for VPLS instance x only. No other PEs Himanshu> participating in VPLS instance x would know that PE Z has blocked Himanshu> his emulated LAN port for VPLS instance x. What you say is true, but it does not contradict what I said. Every PE supporting VPLS instance x has a PW to PE Z, so if PE Z fails, every one of those PWs will fail, and every PE supporting VPLS instance x will block its Emulated LAN interface for VPLS instance x. Of course, one PE doesn't know that another PE has done this, nevertheless they all do it. From exim@www1.ietf.org Fri Aug 8 17:03:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26103 for ; Fri, 8 Aug 2003 17:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEO7-0008Hh-3V for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 17:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78L331i031839 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 17:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEO6-0008HS-Um for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 17:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26091 for ; Fri, 8 Aug 2003 17:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEO4-0004CN-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lEO4-0004CK-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEO5-0008GK-H5; Fri, 08 Aug 2003 17:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEN9-0008Fj-Sv for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 17:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26057 for ; Fri, 8 Aug 2003 17:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEN7-0004CE-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:02:01 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx2.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19lEN6-0004C5-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:02:00 -0400 Received: (qmail 12683 invoked from network); 8 Aug 2003 21:02:18 -0000 Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217) by kanmx2.ca.alcatel.com with SMTP; 8 Aug 2003 21:02:17 -0000 Received: from CAOTTM00152 ([138.120.62.4]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with SMTP id HJBJN000.B6J; Fri, 8 Aug 2003 16:59:24 -0400 Message-ID: <000901c35def$eecf8450$043e788a@CAOTTM00152> From: "Cheng-Yin Lee" To: Cc: , , Subject: RE: On VPLS and Routing Protocols Date: Fri, 8 Aug 2003 16:59:17 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C35DCE.675D9BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C35DCE.675D9BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Himanshu, I believe the case Alex is referring to is when a PE node fails.=20 For e.g. if PE Z fails, other PEs with PWs to PE Z will block its VPLS = port for VPLS instance x, i.e. the whole VPLS instance x is down, even = though PE A and other PEs could still participate in the VPLS instance. Regards Cheng-Yin Himanshu Shah wrote: What I mean by VPLS port blocking is this.=20 If a PW from PE A to PE Z fails for VPLS instance x,=20 PE A simply blocks bridge port to VPLS instance x.=20 It does not send PW status to Z or to any other PEs.=20 No traffic for VPLS instance x would be forwarded=20 to/from any PW by PE A. Thus, isolating all the CEs behind=20 PE A of VPLS instance x from the rest.=20 I don't believe this has domino effect because no PE=20 finds out about bridge port blocking on PE A.=20 /himanshu=20 Alex Zinin wrote:=20 ---- stuff deleted ---=20 >=20 > Cheng-Yin:=20 >=20 > > Mick Seaman proposed a solution on IEEE 802.1=20 > > (or PPVPN?) mailing list prior to this. My understanding of=20 > the proposal=20 > > is - the VPLS entity shall disable the MAC port presented=20 > to the 802.1ad=20 > > bridge if a PW fails. I think Himanshu has described a=20 > similar approach=20 > > ("blocking" VPLS port) in this thread.=20 >=20 > Doesn't this suffer from the same problem Eric pointed out--the whole=20 > VPLS falling apart when a single node goes down and brings PWs with=20 > all other PEs down too?=20 >=20 > Alex=20 >=20 >=20 >=20 ------=_NextPart_000_0006_01C35DCE.675D9BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Himanshu,

I believe the case Alex is referring to is when a PE node fails.

For e.g. if PE Z fails, other PEs with PWs to PE Z will block its = VPLS port=20 for VPLS instance x, i.e. the whole VPLS instance x is down, even though = PE A=20 and other PEs could still participate in the VPLS instance.

Regards

Cheng-Yin

 

Himanshu Shah wrote:

What I mean by VPLS port blocking is this.

If a PW from PE A to PE Z fails for VPLS instance = x,=20
PE A simply blocks bridge port to VPLS instance = x.=20
It does not send PW status to Z or to any other = PEs.=20
No traffic for VPLS instance x would be forwarded=20
to/from any PW by PE A. Thus, isolating all = the CEs=20 behind
PE A of VPLS instance x from the = rest.=20

I don't believe this has domino effect because no = PE=20
finds out about bridge port blocking on PE A. =

/himanshu

Alex Zinin wrote:
---- stuff = deleted=20 ---
>
> = Cheng-Yin:=20
>
> > Mick Seaman = proposed a=20 solution on IEEE 802.1
> > (or PPVPN?) = mailing=20 list prior to this. My understanding of
> = the=20 proposal
> > is - the VPLS entity shall = disable=20 the MAC port presented
> to the = 802.1ad=20
> > bridge if a PW fails. I think Himanshu has = described=20 a
> similar approach
>=20 > ("blocking" VPLS port) in this thread.
>=20
> Doesn't this suffer from the same problem = Eric=20 pointed out--the whole
> VPLS falling apart = when a=20 single node goes down and brings PWs with
> = all other=20 PEs down too?
>
>=20 Alex
>
> =
> =


------=_NextPart_000_0006_01C35DCE.675D9BE0-- From exim@www1.ietf.org Fri Aug 8 17:07:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26161 for ; Fri, 8 Aug 2003 17:07:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lERz-0008Rj-3Y for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 17:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78L73Dd032461 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 17:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lERy-0008RM-UF for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 17:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26142 for ; Fri, 8 Aug 2003 17:06:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lERw-0004D9-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:07:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lERw-0004D6-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:07:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lERx-0008Pi-PJ; Fri, 08 Aug 2003 17:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lERd-0008Ov-C3 for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 17:06:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26138 for ; Fri, 8 Aug 2003 17:06:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lERb-0004D3-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:06:39 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19lERa-0004D0-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:06:38 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2003 14:11:24 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h78L66xc006579; Fri, 8 Aug 2003 17:06:06 -0400 (EDT) Message-Id: <200308082106.h78L66xc006579@rtp-core-2.cisco.com> To: "Christopher, Dunstan" cc: l2vpn@ietf.org Subject: Re: Questions regarding the VPLS In-reply-to: Your message of Fri, 08 Aug 2003 12:04:17 -0600. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Aug 2003 17:06:05 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Dunstan> Does this not bring back n^2 issue for addition of another PE. You do end up with n^2 pseudowires, but since the intermediate nodes do not have to hold any per-pseudowire state, there is no n^2 issue. From exim@www1.ietf.org Fri Aug 8 17:12:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24678 for ; Fri, 8 Aug 2003 16:25:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDn3-0005uk-Lr for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 16:24:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KOjmV022721 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 16:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDn3-0005uF-5l for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:24:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24594 for ; Fri, 8 Aug 2003 16:24:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmT-0005cl-PH; Fri, 08 Aug 2003 16:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDOa-0004bx-Ks for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 15:59:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23969 for ; Fri, 8 Aug 2003 15:59:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDOZ-0003WN-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 15:59:27 -0400 Received: from gate1.cal.attcanada.com ([209.82.18.194] helo=ash.allstream.com) by ietf-mx with esmtp (Exim 4.12) id 19lDOY-0003Vj-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 15:59:26 -0400 Received: from CALVS002.att-intra.com ([10.1.1.46]) by ash.allstream.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com for ; Fri, 8 Aug 2003 13:58:46 -0600 Received: From CALEX006.att-intra.com ([10.1.1.80]) by CALVS002.att-intra.com (WebShield SMTP v4.5 MR1a); id 1060372717663; Fri, 8 Aug 2003 13:58:37 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Questions regarding the VPLS Date: Fri, 8 Aug 2003 13:58:36 -0600 Message-ID: Thread-Topic: Questions regarding the VPLS Thread-Index: AcNd5eUkXt19kMfrScmcH+lnlA2C3gAADmQw From: "Christopher, Dunstan" To: , Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Vach Kompella, Does the PE-PE tunnel E-LSP have to be meshed for L2VPN ? Can we get away with creating the segmenting the tunnel from PE-P, P-P = and P-PE?=20 Would P help in L2VPN to alleviate meshed tunnel LSPs ? regards, Dunstan Christopher -----Original Message----- From: Vach Kompella [mailto:vach.kompella@alcatel.com] Sent: August 8, 2003 3:49 PM To: Christopher, Dunstan; l2vpn@ietf.org Subject: RE: Questions regarding the VPLS However, the n^2 issue isn't the same as the n^2 issue of ATM VCs. = Here, the tunnels carry multiple services. -Vach > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org]On Behalf Of > Christopher, Dunstan > Sent: Friday, August 08, 2003 11:04 AM > To: l2vpn@ietf.org > Subject: Questions regarding the VPLS > > > > Any-to-any service requires fully meshed VCs due to the "split > horizon rule" of learning and forwarding across the VPLS leg points. > a) What is the reason for Tunnel LSPs to be meshed across the PE-PE ? > Does this not bring back n^2 issue for addition of another PE. > b) What are the other technical alternatives to provide VPLS service > based on non PE-PE meshed tunnels when P is introduced? > > > regards, > > Dunstan Christopher > > > From exim@www1.ietf.org Fri Aug 8 17:30:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26698 for ; Fri, 8 Aug 2003 17:30:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEoI-00013F-BW for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 17:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78LU66s004035 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 17:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEoI-000130-7H for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 17:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26689 for ; Fri, 8 Aug 2003 17:30:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEoF-0004NB-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:30:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lEoF-0004N8-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEoD-00012W-4c; Fri, 08 Aug 2003 17:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEnI-00011v-B9 for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 17:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26669 for ; Fri, 8 Aug 2003 17:28:58 -0400 (EDT) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEnF-0004Mc-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:29:01 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt03.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19lEnF-0004MZ-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:29:01 -0400 Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 8 Aug 2003 22:28:36 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6C0F@i2km07-ukbr.domain1.systemhost.net> To: erosen@cisco.com, Dunstan.Christopher@allstream.com Cc: l2vpn@ietf.org Subject: RE: Questions regarding the VPLS Date: Fri, 8 Aug 2003 22:28:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Dunstan> Does this not bring back n^2 issue for addition of > another PE. > > Eric> You do end up with n^2 pseudowires, but since the > intermediate nodes do not > have to hold any per-pseudowire state, there is no n^2 issue. NH=> Agreed Eric....but this is hierarchy at work.....the basic n^2 'truth' still holds. regards, Neil From exim@www1.ietf.org Fri Aug 8 17:41:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27148 for ; Fri, 8 Aug 2003 17:41:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEyt-0001aj-T7 for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 17:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Lf3HZ006112 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 17:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEyt-0001aV-Ol for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 17:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27067 for ; Fri, 8 Aug 2003 17:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEyr-0004Qv-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lEyq-0004Qs-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 17:41:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEyr-0001a1-FR; Fri, 08 Aug 2003 17:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEyA-0001ZU-2c for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 17:40:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27024 for ; Fri, 8 Aug 2003 17:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEy1-0004QX-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:40:09 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19lEy1-0004QU-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 17:40:09 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 17:40:09 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB0010644@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: "'Cheng-Yin Lee'" Cc: l2vpn@ietf.org, erosen@cisco.com, zinin@psg.com Subject: RE: On VPLS and Routing Protocols Date: Fri, 8 Aug 2003 17:40:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35DF5.A1DAFD40" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35DF5.A1DAFD40 Content-Type: text/plain; charset="iso-8859-1" Got it. I was referring to the case for PW going down due to transport tunnel carrying the PW going down. Node failure is definitely different case and Alex and Eric are right that this scheme would not work. /himanshu -----Original Message----- From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] Sent: Friday, August 08, 2003 4:59 PM To: Shah, Himanshu Cc: l2vpn@ietf.org; erosen@cisco.com; zinin@psg.com Subject: RE: On VPLS and Routing Protocols Himanshu, I believe the case Alex is referring to is when a PE node fails. For e.g. if PE Z fails, other PEs with PWs to PE Z will block its VPLS port for VPLS instance x, i.e. the whole VPLS instance x is down, even though PE A and other PEs could still participate in the VPLS instance. Regards Cheng-Yin Himanshu Shah wrote: What I mean by VPLS port blocking is this. If a PW from PE A to PE Z fails for VPLS instance x, PE A simply blocks bridge port to VPLS instance x. It does not send PW status to Z or to any other PEs. No traffic for VPLS instance x would be forwarded to/from any PW by PE A. Thus, isolating all the CEs behind PE A of VPLS instance x from the rest. I don't believe this has domino effect because no PE finds out about bridge port blocking on PE A. /himanshu Alex Zinin wrote: ---- stuff deleted --- > > Cheng-Yin: > > > Mick Seaman proposed a solution on IEEE 802.1 > > (or PPVPN?) mailing list prior to this. My understanding of > the proposal > > is - the VPLS entity shall disable the MAC port presented > to the 802.1ad > > bridge if a PW fails. I think Himanshu has described a > similar approach > > ("blocking" VPLS port) in this thread. > > Doesn't this suffer from the same problem Eric pointed out--the whole > VPLS falling apart when a single node goes down and brings PWs with > all other PEs down too? > > Alex > > > ------_=_NextPart_001_01C35DF5.A1DAFD40 Content-Type: text/html; charset="iso-8859-1"
Got it. I was referring to the case for PW going down due to transport
tunnel carrying the PW going down. Node failure is definitely different case
and Alex and Eric are right that this scheme would not work.
 
/himanshu
-----Original Message-----
From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com]
Sent: Friday, August 08, 2003 4:59 PM
To: Shah, Himanshu
Cc: l2vpn@ietf.org; erosen@cisco.com; zinin@psg.com
Subject: RE: On VPLS and Routing Protocols

Himanshu,

I believe the case Alex is referring to is when a PE node fails.

For e.g. if PE Z fails, other PEs with PWs to PE Z will block its VPLS port for VPLS instance x, i.e. the whole VPLS instance x is down, even though PE A and other PEs could still participate in the VPLS instance.

Regards

Cheng-Yin

 

Himanshu Shah wrote:

What I mean by VPLS port blocking is this.

If a PW from PE A to PE Z fails for VPLS instance x,
PE A simply blocks bridge port to VPLS instance x.
It does not send PW status to Z or to any other PEs.
No traffic for VPLS instance x would be forwarded
to/from any PW by PE A. Thus, isolating all the CEs behind
PE A of VPLS instance x from the rest.

I don't believe this has domino effect because no PE
finds out about bridge port blocking on PE A.

/himanshu

Alex Zinin wrote:
---- stuff deleted ---
>
> Cheng-Yin:
>
> > Mick Seaman proposed a solution on IEEE 802.1
> > (or PPVPN?) mailing list prior to this. My understanding of
> the proposal
> > is - the VPLS entity shall disable the MAC port presented
> to the 802.1ad
> > bridge if a PW fails. I think Himanshu has described a
> similar approach
> > ("blocking" VPLS port) in this thread.
>
> Doesn't this suffer from the same problem Eric pointed out--the whole
> VPLS falling apart when a single node goes down and brings PWs with
> all other PEs down too?
>
> Alex
>
>
>


------_=_NextPart_001_01C35DF5.A1DAFD40-- From exim@www1.ietf.org Fri Aug 8 18:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29381 for ; Fri, 8 Aug 2003 18:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFcb-0003K3-8i for l2vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 18:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78MM5i8012768 for l2vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 18:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFcb-0003Jr-4K for l2vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 18:22:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29372 for ; Fri, 8 Aug 2003 18:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lFcY-0004g0-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 18:22:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lFcX-0004fx-00 for l2vpn-web-archive@ietf.org; Fri, 08 Aug 2003 18:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFcX-0003JP-Cv; Fri, 08 Aug 2003 18:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lFbq-0003J7-AM for l2vpn@optimus.ietf.org; Fri, 08 Aug 2003 18:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29367 for ; Fri, 8 Aug 2003 18:21:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lFbn-0004fu-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 18:21:15 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19lFbm-0004fr-00 for l2vpn@ietf.org; Fri, 08 Aug 2003 18:21:14 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h78MKf725151 for ; Fri, 8 Aug 2003 17:20:42 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 8 Aug 2003 18:20:41 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'erosen@cisco.com'" , "Christopher, Dunstan" Cc: l2vpn@ietf.org Subject: RE: Questions regarding the VPLS Date: Fri, 8 Aug 2003 18:20:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric Rosen wrote: > > Dunstan> Does this not bring back n^2 issue for addition of > another PE. > > You do end up with n^2 pseudowires, but since the > intermediate nodes do not > have to hold any per-pseudowire state, there is no n^2 issue. > That is true for the non-distributed model. In a decoupled VPLS solution, the intermediate nodes (i.e. the N-PEs) do hold per-pseudowire state. A few observations: 1) Strictly speaking, there is no n^2 issue. A single VPLS instance needs a full mesh of Pseudo Wires, but the total number of PWs in a network scales linearly with the number of VPLS instances. 2) That said, the total number of PWs could become large. Based on experience with other L2 services, the average number of attachment circuits per VPN is around 20. The number of PWs per VPLS is probably in the low hundreds. 3) The primary solution for dealing with a large number of PWs is tunneling. However, in a non-distributed model that becomes unwieldy. Strictly speaking, it is still not an n^2 problem, since you don't need a full mesh of transport LSPs between all PEs. You only need LSPs between those PEs that support at least one common VPLS instance. But still, the number of transport LSPs becomes large. 4) The next step is a distributed (decoupled) model. Through the use of intermediate aggregation points, the number of transport LSPs decreases significantly, but the price you pay is that the intermediate nodes must hold per-PW state. I agree with Neil Harrison that this is a fundamental truth of connection-oriented services: one way or another you have to deal with a large number of point-to-point connections. 5) Personally, I think that through smart usage of tunneling and decoupling (i.e. intermediate PW switching), it is possible to build infrastructures that can support very large numbers of VPLSs. However, I think that that requires more flexibility than it offered by the current GVPLS proposal which assumes that on any path there will be at most two intermediate aggregation points. Peter From exim@www1.ietf.org Sun Aug 10 04:51:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01582 for ; Sun, 10 Aug 2003 04:51:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lluy-0005uw-1v for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 04:51:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7A8pC4t022746 for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 04:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19llux-0005um-Un for l2vpn-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 04:51:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01562 for ; Sun, 10 Aug 2003 04:51:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lluv-000697-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 04:51:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lluu-000693-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 04:51:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19llun-0005uE-KX; Sun, 10 Aug 2003 04:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lluH-0005sO-GU for l2vpn@optimus.ietf.org; Sun, 10 Aug 2003 04:50:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01547 for ; Sun, 10 Aug 2003 04:50:25 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lluE-00068x-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 04:50:26 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt02.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19lluD-00068p-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 04:50:26 -0400 Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sun, 10 Aug 2003 09:49:57 +0100 Message-ID: To: l2vpn@ietf.org Subject: VPN Identifiers Date: Sun, 10 Aug 2003 09:49:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , There has been some discussion on the mailing list regarding the VPN ID naming space but I do not believe any consensus has been reached. This subject was also discussed recently by a few colleagues within BT, it focussed on 4 main questions: 1. How should the VPN ID be made globally unique? 2. Should the VPN ID be human readable or machine readable? 3. Should the VPN ID be fixed or variable length? 4. How big should the VPN ID be? The discussion concluded that to support inter provider VPNs the VPN ID must be have a globally unique element and a locally administered element, but what should the globally unique element be? One possible solution would be to use MAC OUI's, but what about service providers that don't have these? Another possible solution would be to use AS numbers, but what about service providers that don't have Internet connectivity and just want to provide VPNs? The global element must be controlled by an appropriate authority but we need to be able to re-use existing global IDs. Service providers will not want to have to wait (weeks or even months) for new global IDs to be allocated to provide VPNs. From a management/provisioning perspective it would be useful if VPN IDs were human readable. This would make it intuitively obvious by looking in the RADIUS database or by looking at BGP advertisements which VPNs sites belong to. One possible solution might be to use DNS, but this raises the question whether VPN IDs should be of fixed or variable length? A fixed length would be preferable so that they could be easily parsed and to make it simpler to carry them in a signalling protocol, which leads on to the question how long should they be? We need to get the length right the first time to avoid problems in the future, one suggestion was to make the length 8 bytes. Feedback on the above would be much appreciated. Regards, Richard From exim@www1.ietf.org Sun Aug 10 05:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02017 for ; Sun, 10 Aug 2003 05:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lmOp-0006gX-6B for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 05:22:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7A9M3dX025691 for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 05:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lmOp-0006gI-1B for l2vpn-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 05:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02013 for ; Sun, 10 Aug 2003 05:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lmOl-0006Kv-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 05:21:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lmOl-0006Ks-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 05:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lmOn-0006fp-5w; Sun, 10 Aug 2003 05:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lmOH-0006fe-N0 for l2vpn@optimus.ietf.org; Sun, 10 Aug 2003 05:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02009 for ; Sun, 10 Aug 2003 05:21:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lmOE-0006Kp-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 05:21:26 -0400 Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 19lmOD-0006KT-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 05:21:25 -0400 Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Sun, 10 Aug 2003 12:23:07 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Aug 2003 12:16:24 +0200 Message-ID: From: Sasha Vainshtein To: "'richard.spencer@bt.com'" Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Sun, 10 Aug 2003 12:16:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Richard, I think that "service providers that do not have Internet connectivity but just want to provide VPNs" do not have to worry about global uniqueness of their VPN IDs because they cannot participate in inter-provider VPNs. A single value in the global idenifier namespace (whatever it is) could be allocated to indicate that the VPN ID using this value as its global identifier is actually a private VPN ID of this provider and its uniqueness is limited accordingly. Did I miss something? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Sunday, August 10, 2003 10:50 AM > To: l2vpn@ietf.org > Subject: VPN Identifiers > > > There has been some discussion on the mailing list regarding > the VPN ID > naming space but I do not believe any consensus has been reached. This > subject was also discussed recently by a few colleagues within BT, it > focussed on 4 main questions: > > 1. How should the VPN ID be made globally unique? > 2. Should the VPN ID be human readable or machine readable? > 3. Should the VPN ID be fixed or variable length? > 4. How big should the VPN ID be? > > The discussion concluded that to support inter provider VPNs > the VPN ID must > be have a globally unique element and a locally administered > element, but > what should the globally unique element be? One possible > solution would be > to use MAC OUI's, but what about service providers that don't > have these? > Another possible solution would be to use AS numbers, but > what about service > providers that don't have Internet connectivity and just want > to provide > VPNs? The global element must be controlled by an appropriate > authority but > we need to be able to re-use existing global IDs. Service > providers will not > want to have to wait (weeks or even months) for new global IDs to be > allocated to provide VPNs. > > From a management/provisioning perspective it would be useful > if VPN IDs > were human readable. This would make it intuitively obvious > by looking in > the RADIUS database or by looking at BGP advertisements which > VPNs sites > belong to. One possible solution might be to use DNS, but > this raises the > question whether VPN IDs should be of fixed or variable > length? A fixed > length would be preferable so that they could be easily > parsed and to make > it simpler to carry them in a signalling protocol, which > leads on to the > question how long should they be? We need to get the length > right the first > time to avoid problems in the future, one suggestion was to > make the length > 8 bytes. > > Feedback on the above would be much appreciated. > > Regards, > > Richard > > > > > From exim@www1.ietf.org Sun Aug 10 06:10:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02704 for ; Sun, 10 Aug 2003 06:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ln9J-0007o9-4R for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 06:10:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AAA5BM030009 for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 06:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ln9J-0007nw-0c for l2vpn-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 06:10:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02701 for ; Sun, 10 Aug 2003 06:09:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ln9E-0006XX-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 06:10:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ln9D-0006XU-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 06:09:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ln9F-0007nS-0J; Sun, 10 Aug 2003 06:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ln8u-0007n7-VH for l2vpn@optimus.ietf.org; Sun, 10 Aug 2003 06:09:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02698 for ; Sun, 10 Aug 2003 06:09:35 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ln8r-0006XR-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 06:09:37 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19ln8q-0006XD-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 06:09:36 -0400 Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sun, 10 Aug 2003 11:09:22 +0100 Message-ID: To: Sasha@AXERRA.com Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Sun, 10 Aug 2003 11:09:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sasha, > I think that "service providers that do not have Internet > connectivity but > just want > to provide VPNs" do not have to worry about global uniqueness > of their VPN > IDs > because they cannot participate in inter-provider VPNs. RS> Why can't a provider participate in inter-provider VPNs just because they don't provide Internet connectivity via their VPN network? What if the VPN network is an MPLS network, who says the provider will be using the Internet IPv4 address space for addressing, or that they will even be using IPv4 addresses? Providers already offer inter-provider/transit VPNs where IP doesn't enter into the equation at all, e.g. ATM VPNs where the ATM network has its own separate address space. > A single value in the global idenifier namespace (whatever > it is) could be > allocated > to indicate that the VPN ID using this value as its global > identifier is > actually > a private VPN ID of this provider and its uniqueness is > limited accordingly. RS> Agreed but this doesn't answer any of the original questions, i.e. type of global identifier, VPN ID length, format etc. Richard > > Did I miss something? > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: Sunday, August 10, 2003 10:50 AM > > To: l2vpn@ietf.org > > Subject: VPN Identifiers > > > > > > There has been some discussion on the mailing list regarding > > the VPN ID > > naming space but I do not believe any consensus has been > reached. This > > subject was also discussed recently by a few colleagues > within BT, it > > focussed on 4 main questions: > > > > 1. How should the VPN ID be made globally unique? > > 2. Should the VPN ID be human readable or machine readable? > > 3. Should the VPN ID be fixed or variable length? > > 4. How big should the VPN ID be? > > > > The discussion concluded that to support inter provider VPNs > > the VPN ID must > > be have a globally unique element and a locally administered > > element, but > > what should the globally unique element be? One possible > > solution would be > > to use MAC OUI's, but what about service providers that don't > > have these? > > Another possible solution would be to use AS numbers, but > > what about service > > providers that don't have Internet connectivity and just want > > to provide > > VPNs? The global element must be controlled by an appropriate > > authority but > > we need to be able to re-use existing global IDs. Service > > providers will not > > want to have to wait (weeks or even months) for new global IDs to be > > allocated to provide VPNs. > > > > From a management/provisioning perspective it would be useful > > if VPN IDs > > were human readable. This would make it intuitively obvious > > by looking in > > the RADIUS database or by looking at BGP advertisements which > > VPNs sites > > belong to. One possible solution might be to use DNS, but > > this raises the > > question whether VPN IDs should be of fixed or variable > > length? A fixed > > length would be preferable so that they could be easily > > parsed and to make > > it simpler to carry them in a signalling protocol, which > > leads on to the > > question how long should they be? We need to get the length > > right the first > > time to avoid problems in the future, one suggestion was to > > make the length > > 8 bytes. > > > > Feedback on the above would be much appreciated. > > > > Regards, > > > > Richard > > > > > > > > > > > From exim@www1.ietf.org Sun Aug 10 06:18:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03050 for ; Sun, 10 Aug 2003 06:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnH0-000812-Eu for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 06:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AAI20G030806 for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 06:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnH0-00080n-9u for l2vpn-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 06:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03012 for ; Sun, 10 Aug 2003 06:17:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lnGw-0006bo-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 06:17:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lnGw-0006bl-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 06:17:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnGy-0007ze-QD; Sun, 10 Aug 2003 06:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnGp-0007zT-R3 for l2vpn@optimus.ietf.org; Sun, 10 Aug 2003 06:17:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02993 for ; Sun, 10 Aug 2003 06:17:46 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lnGm-0006bZ-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 06:17:48 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt02.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19lnGl-0006bA-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 06:17:47 -0400 Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sun, 10 Aug 2003 11:17:20 +0100 Message-ID: To: l2vpn@ietf.org Subject: BGP CE Identifier allocation Date: Sun, 10 Aug 2003 11:17:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As discussed on the mailing list, BGP can only broadcast the same information to every peer in the network it has a session with, i.e. it cannot signal information on a point to point basis. As a result of this, the VPLS draft that uses BGP for signalling has to use a label block to signal different labels to each PE participating in a VPN. A different label must be sent to each PE participating in a VPN so that MAC address learning can take place, i.e. the VPN label identifies which VPN the packet belongs to and which PE it was received from in order to populate the MAC forwarding tables. This is not necessary on RFC2547 as it doesn't matter where packets come from, i.e. the VPN label just tells the PE which VPN the packet belongs to. The BGP signalling label block function requires each CE to have a CE ID, which must be unique in the context of a VPN. It is suggested that the CE ID can be used as an index in an algorithm to determine which label is allocated to which CE. This is fine in the intra-provider case as the CE ID can be locally administered, but what about the inter-provider VPN case? One solution would be to make a single provider the CE ID authority for each VPN, i.e. a single provider controls the CE IDs for any given VPN and all other providers must request CE IDs from the relevant provider. Another solution would be to make CE IDs globally unique, IPv6? Thoughts on the above would be appreciated. Thanks, Richard From exim@www1.ietf.org Sun Aug 10 06:24:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03159 for ; Sun, 10 Aug 2003 06:24:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnMo-00089s-7p for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 06:24:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AAO29x031354 for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 06:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnMo-00089d-3j for l2vpn-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 06:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03153 for ; Sun, 10 Aug 2003 06:23:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lnMk-0006eT-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 06:23:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lnMj-0006eQ-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 06:23:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnMm-00088y-Ie; Sun, 10 Aug 2003 06:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lnM4-00088i-RI for l2vpn@optimus.ietf.org; Sun, 10 Aug 2003 06:23:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03135 for ; Sun, 10 Aug 2003 06:23:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lnM0-0006eE-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 06:23:12 -0400 Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 19lnM0-0006e3-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 06:23:12 -0400 Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Sun, 10 Aug 2003 13:25:00 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Aug 2003 13:18:18 +0200 Message-ID: From: Sasha Vainshtein To: "'richard.spencer@bt.com'" Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Sun, 10 Aug 2003 13:18:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Richard, I have not expressed my position accurately enough. What I intended to say is that if a provider communicates with the other providers for whatever reason (e.g., for providing inter-provider VPNs), it probably has AS number(s) assigned to its network. And, vice versa, a provider that does not have any AS numbers assigned probably cannot communicate with the other providers. Whether Internet access is or is not provided as part of the VPN service is not relevant. And, IMO, VPNs provided over networks that do not use IPv4/IPv6 addresses (like ATM networks you have mentioned) are out of scope of this WG. The current WG charter defines its scope as following: 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. As you see, it mentions IP networks (MPLS-enabled or not) as the only type of networks over which the L2 VPN services are provided. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Sunday, August 10, 2003 12:09 PM > To: Sasha Vainshtein > Cc: l2vpn@ietf.org > Subject: RE: VPN Identifiers > > > Sasha, > > > I think that "service providers that do not have Internet > > connectivity but > > just want > > to provide VPNs" do not have to worry about global uniqueness > > of their VPN > > IDs > > because they cannot participate in inter-provider VPNs. > > RS> Why can't a provider participate in inter-provider VPNs > just because > they don't provide Internet connectivity via their VPN > network? What if the > VPN network is an MPLS network, who says the provider will be > using the > Internet IPv4 address space for addressing, or that they will > even be using > IPv4 addresses? Providers already offer > inter-provider/transit VPNs where IP > doesn't enter into the equation at all, e.g. ATM VPNs where > the ATM network > has its own separate address space. > > > A single value in the global idenifier namespace (whatever > > it is) could be > > allocated > > to indicate that the VPN ID using this value as its global > > identifier is > > actually > > a private VPN ID of this provider and its uniqueness is > > limited accordingly. > > RS> Agreed but this doesn't answer any of the original > questions, i.e. type > of global identifier, VPN ID length, format etc. > > Richard > > > > > Did I miss something? > > > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > > Sent: Sunday, August 10, 2003 10:50 AM > > > To: l2vpn@ietf.org > > > Subject: VPN Identifiers > > > > > > > > > There has been some discussion on the mailing list regarding > > > the VPN ID > > > naming space but I do not believe any consensus has been > > reached. This > > > subject was also discussed recently by a few colleagues > > within BT, it > > > focussed on 4 main questions: > > > > > > 1. How should the VPN ID be made globally unique? > > > 2. Should the VPN ID be human readable or machine readable? > > > 3. Should the VPN ID be fixed or variable length? > > > 4. How big should the VPN ID be? > > > > > > The discussion concluded that to support inter provider VPNs > > > the VPN ID must > > > be have a globally unique element and a locally administered > > > element, but > > > what should the globally unique element be? One possible > > > solution would be > > > to use MAC OUI's, but what about service providers that don't > > > have these? > > > Another possible solution would be to use AS numbers, but > > > what about service > > > providers that don't have Internet connectivity and just want > > > to provide > > > VPNs? The global element must be controlled by an appropriate > > > authority but > > > we need to be able to re-use existing global IDs. Service > > > providers will not > > > want to have to wait (weeks or even months) for new > global IDs to be > > > allocated to provide VPNs. > > > > > > From a management/provisioning perspective it would be useful > > > if VPN IDs > > > were human readable. This would make it intuitively obvious > > > by looking in > > > the RADIUS database or by looking at BGP advertisements which > > > VPNs sites > > > belong to. One possible solution might be to use DNS, but > > > this raises the > > > question whether VPN IDs should be of fixed or variable > > > length? A fixed > > > length would be preferable so that they could be easily > > > parsed and to make > > > it simpler to carry them in a signalling protocol, which > > > leads on to the > > > question how long should they be? We need to get the length > > > right the first > > > time to avoid problems in the future, one suggestion was to > > > make the length > > > 8 bytes. > > > > > > Feedback on the above would be much appreciated. > > > > > > Regards, > > > > > > Richard > > > > > > > > > > > > > > > > > > From exim@www1.ietf.org Sun Aug 10 18:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18937 for ; Sun, 10 Aug 2003 18:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lyeV-0000rH-Ny for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 18:27:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AMR3S4003298 for l2vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 18:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lyeV-0000r7-6q for l2vpn-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 18:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18926 for ; Sun, 10 Aug 2003 18:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lyeS-0001dX-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 18:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lyeR-0001dU-00 for l2vpn-web-archive@ietf.org; Sun, 10 Aug 2003 18:26:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lyeS-0000qf-Qh; Sun, 10 Aug 2003 18:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lydv-0000pw-Pc for l2vpn@optimus.ietf.org; Sun, 10 Aug 2003 18:26:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18923 for ; Sun, 10 Aug 2003 18:26:21 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lyds-0001dR-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 18:26:24 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19lyds-0001dK-00 for l2vpn@ietf.org; Sun, 10 Aug 2003 18:26:24 -0400 Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sun, 10 Aug 2003 23:25:54 +0100 Message-ID: To: Sasha@AXERRA.com Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Sun, 10 Aug 2003 23:25:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sasha, Thank you for expressing your position on this subject. I agree that if a provider communicates with other providers today it will have AS numbers assigned to its IP/MPLS network. However, I am approaching this problem from the viewpoint that MPLS networks in the future might not necessarily use the Internets IPv4 address space. I agree that this is currently out of scope as far as this working group is concerned, but I would like to see a VPN ID format defined that could be used regardless of what VPN address space is used. For example, a service provider may choose to use an out-of-band control plane and a centralised routing/signalling mechanisms along with IPv6 addressing for its MPLS VPN network. I am not saying that BT or any other providers consider this to be the best approach, but it is one option and I know of at least one vendor that supports this functionality. However, just because IPv4 addressing might not be used by some providers in the future, this does not mean that AS numbers should not be used as global identifiers, just that this raises the question regarding how easy it will be for VPN providers that do not offer Internet connectivity to obtain AS numbers. This is a minor point and does not even apply to BT which does offer Internet connectivity, I'm just attempting to explore what the global element of the VPN ID should be and what the format/length should be. I am also approaching this problem from the viewpoint that VPN IDs *could be* used across multiple VPN technologies e.g. ATM, SHD/SONET, MPLS, IP, etc. I agree that this too is currently out of scope as far as this working group is concerned, but from a providers perspective it would be *very useful* if the same VPN ID could be used across all VPN technologies. So for example, a provider might use the same auto-discovery mechanism and the same VPN ID format for L1 VPNs across SDH/SONET, L2 VPNs across MPLS, and L3 VPNs across IP. I realise that this approach and thinking is out of scope as far as this working group is concerned, but the VPN ID defined in this working group for IP/MPLS will have to be used (or translated) by any provider that wants to re-use VPN IDs across some or all VPN technologies. As long as the VPN ID format defined within this working group does not impose any scalability restrictions and is globally unique I can't see any reason why it can't be used across different VPN network technologies. Thanks, Richard > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: 10 August 2003 12:18 > To: Spencer,R,Richard,XGH5 R > Cc: l2vpn@ietf.org > Subject: RE: VPN Identifiers > > > Richard, > > I have not expressed my position accurately enough. > > What I intended to say is that if a provider communicates with the > other providers for whatever reason (e.g., for providing > inter-provider > VPNs), it probably has AS number(s) assigned to its network. > And, vice versa, a provider that does not have any AS numbers assigned > probably cannot communicate with the other providers. > > Whether Internet access is or is not provided as part of the VPN > service is not relevant. > > And, IMO, VPNs provided over networks that do not use > IPv4/IPv6 addresses > (like ATM networks you have mentioned) are out of scope of this WG. > The current WG charter defines its scope as following: > > > 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. > > > As you see, it mentions IP networks (MPLS-enabled or not) as > the only type of networks over which the L2 VPN services are > provided. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: Sunday, August 10, 2003 12:09 PM > > To: Sasha Vainshtein > > Cc: l2vpn@ietf.org > > Subject: RE: VPN Identifiers > > > > > > Sasha, > > > > > I think that "service providers that do not have Internet > > > connectivity but > > > just want > > > to provide VPNs" do not have to worry about global uniqueness > > > of their VPN > > > IDs > > > because they cannot participate in inter-provider VPNs. > > > > RS> Why can't a provider participate in inter-provider VPNs > > just because > > they don't provide Internet connectivity via their VPN > > network? What if the > > VPN network is an MPLS network, who says the provider will be > > using the > > Internet IPv4 address space for addressing, or that they will > > even be using > > IPv4 addresses? Providers already offer > > inter-provider/transit VPNs where IP > > doesn't enter into the equation at all, e.g. ATM VPNs where > > the ATM network > > has its own separate address space. > > > > > A single value in the global idenifier namespace (whatever > > > it is) could be > > > allocated > > > to indicate that the VPN ID using this value as its global > > > identifier is > > > actually > > > a private VPN ID of this provider and its uniqueness is > > > limited accordingly. > > > > RS> Agreed but this doesn't answer any of the original > > questions, i.e. type > > of global identifier, VPN ID length, format etc. > > > > Richard > > > > > > > > Did I miss something? > > > > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > > > > > > > > > > > > > -----Original Message----- > > > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > > > Sent: Sunday, August 10, 2003 10:50 AM > > > > To: l2vpn@ietf.org > > > > Subject: VPN Identifiers > > > > > > > > > > > > There has been some discussion on the mailing list regarding > > > > the VPN ID > > > > naming space but I do not believe any consensus has been > > > reached. This > > > > subject was also discussed recently by a few colleagues > > > within BT, it > > > > focussed on 4 main questions: > > > > > > > > 1. How should the VPN ID be made globally unique? > > > > 2. Should the VPN ID be human readable or machine readable? > > > > 3. Should the VPN ID be fixed or variable length? > > > > 4. How big should the VPN ID be? > > > > > > > > The discussion concluded that to support inter provider VPNs > > > > the VPN ID must > > > > be have a globally unique element and a locally administered > > > > element, but > > > > what should the globally unique element be? One possible > > > > solution would be > > > > to use MAC OUI's, but what about service providers that don't > > > > have these? > > > > Another possible solution would be to use AS numbers, but > > > > what about service > > > > providers that don't have Internet connectivity and just want > > > > to provide > > > > VPNs? The global element must be controlled by an appropriate > > > > authority but > > > > we need to be able to re-use existing global IDs. Service > > > > providers will not > > > > want to have to wait (weeks or even months) for new > > global IDs to be > > > > allocated to provide VPNs. > > > > > > > > From a management/provisioning perspective it would be useful > > > > if VPN IDs > > > > were human readable. This would make it intuitively obvious > > > > by looking in > > > > the RADIUS database or by looking at BGP advertisements which > > > > VPNs sites > > > > belong to. One possible solution might be to use DNS, but > > > > this raises the > > > > question whether VPN IDs should be of fixed or variable > > > > length? A fixed > > > > length would be preferable so that they could be easily > > > > parsed and to make > > > > it simpler to carry them in a signalling protocol, which > > > > leads on to the > > > > question how long should they be? We need to get the length > > > > right the first > > > > time to avoid problems in the future, one suggestion was to > > > > make the length > > > > 8 bytes. > > > > > > > > Feedback on the above would be much appreciated. > > > > > > > > Regards, > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > > > From exim@www1.ietf.org Mon Aug 11 08:59:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14726 for ; Mon, 11 Aug 2003 08:59:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCGQ-0001rl-Ho for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 08:59:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BCx65U007167 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 08:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCGQ-0001rW-E8 for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 08:59:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14682 for ; Mon, 11 Aug 2003 08:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCGP-0005cX-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 08:59:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mCGO-0005cT-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 08:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCGL-0001qp-GM; Mon, 11 Aug 2003 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCFZ-0001nA-87 for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 08:58:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14648 for ; Mon, 11 Aug 2003 08:58:07 -0400 (EDT) From: Moshe.Aharon@ecitele.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCFX-0005bk-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 08:58:11 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19mCFW-0005bc-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 08:58:10 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h7BCqm8j002409 for ; Mon, 11 Aug 2003 15:52:48 +0300 (IDT) Subject: Where did the QoS Framework go?... To: l2vpn@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Mon, 11 Aug 2003 15:58:27 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 08/11/2003 03:58:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, Does anyone know to which WG the VPN QoS Framework is related? Thanks, /Moshe From exim@www1.ietf.org Mon Aug 11 11:02:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19583 for ; Mon, 11 Aug 2003 11:02:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEBT-0006yd-5h for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BF272X026813 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEBS-0006yO-Vn for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 11:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19558 for ; Mon, 11 Aug 2003 11:01:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEBQ-0006Vh-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:02:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mEBP-0006Ve-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEBP-0006xv-6C; Mon, 11 Aug 2003 11:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEAu-0006un-8E for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 11:01:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19495 for ; Mon, 11 Aug 2003 11:01:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEAr-0006VL-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:01:29 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19mEAq-0006UK-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:01:28 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7BEmU3H010435 for ; Mon, 11 Aug 2003 10:00:57 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C00185F0E; Mon, 11 Aug 2003 11:00:47 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Mon, 11 Aug 2003 10:00:56 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA011BEBF3@KCCLUST06EVS1.ugd.att.com> Thread-Topic: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Thread-Index: AcNdGcWbbNs66GyFRTGsMEceY9on5QC/y5lg From: "Ash, Gerald R (Jerry), ALABS" To: "Loa Andersson" , Cc: "Ash, Gerald R (Jerry), ALABS" , "Eric Rosen" , "Vach Kompella" , "Rick Wilder" Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Loa, > we have a request to make > draft-rosen-ppvpn-l2-signaling-03.txt > a working group document. Please comment on this to the > mailing list. at this stage we want don't want to count > abstention as support - so please speak up if you want > this as a wg draft. I support. Jerry From exim@www1.ietf.org Mon Aug 11 11:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20516 for ; Mon, 11 Aug 2003 11:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mElE-0008RQ-SK for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:39:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BFd4kO032442 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mElE-0008RB-M2 for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 11:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20502 for ; Mon, 11 Aug 2003 11:38:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mElD-0006hq-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mElD-0006hn-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mElB-0008Qf-Jf; Mon, 11 Aug 2003 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEl7-0008QK-3f for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 11:38:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20486 for ; Mon, 11 Aug 2003 11:38:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEl6-0006hd-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:38:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19mEl5-0006hJ-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:38:55 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BFcKb09443; Mon, 11 Aug 2003 11:38:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 11:38:21 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Loa Andersson , l2vpn@ietf.org Cc: Eric Rosen , Vach Kompella , Rick Wilder Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Mon, 11 Aug 2003 11:38:19 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , [Catching up on my emails]... > > we have a request to make > draft-rosen-ppvpn-l2-signaling-03.txt > a working group document. Please comment on this to the > mailing list. at this stage we want don't want to count > abstention as support - so please speak up if you want > this as a wg draft. > Yes. This should be a WG document. Hamid. From exim@www1.ietf.org Mon Aug 11 11:41:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20586 for ; Mon, 11 Aug 2003 11:41:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEn9-00005Q-E0 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BFf3lZ000326 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEn9-00005B-5l for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 11:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20561 for ; Mon, 11 Aug 2003 11:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEn8-0006is-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mEn7-0006ip-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEn8-0008Vi-0j; Mon, 11 Aug 2003 11:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEmu-0008VF-Re for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 11:40:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20554 for ; Mon, 11 Aug 2003 11:40:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEmt-0006ic-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:40:47 -0400 Received: from mailg.telia.com ([194.22.194.26]) by ietf-mx with esmtp (Exim 4.12) id 19mEms-0006iZ-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:40:46 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.9/8.12.9) with ESMTP id h7BFedhl015378; Mon, 11 Aug 2003 17:40:39 +0200 (CEST) X-Original-Recipient: l2vpn@ietf.org Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h7BFecc14858; Mon, 11 Aug 2003 17:40:38 +0200 (CEST) Message-ID: <3F37B8F6.6080305@pi.se> Date: Mon, 11 Aug 2003 17:40:38 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hamid Ould-Brahim CC: l2vpn@ietf.org, Eric Rosen , Vach Kompella , Rick Wilder Subject: Re: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, I've enough support for this document to make it a working group document. Will do so as soon as I talked to the authors. Thanks! /Loa Hamid Ould-Brahim wrote: > [Catching up on my emails]... > > >>we have a request to make >>draft-rosen-ppvpn-l2-signaling-03.txt >>a working group document. Please comment on this to the >>mailing list. at this stage we want don't want to count >>abstention as support - so please speak up if you want >>this as a wg draft. >> > > > Yes. This should be a WG document. > > Hamid. > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Mon Aug 11 11:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20637 for ; Mon, 11 Aug 2003 11:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEp4-00009i-5i for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:43:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BFh29s000594 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 11:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEp4-00009V-0k for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 11:43:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20628 for ; Mon, 11 Aug 2003 11:42:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEp2-0006jY-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:43:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mEp2-0006jV-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 11:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEp2-00008M-Ne; Mon, 11 Aug 2003 11:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEoA-00007N-N9 for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 11:42:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20617 for ; Mon, 11 Aug 2003 11:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEo9-0006jJ-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:42:05 -0400 Received: from mdmail.ciena.com ([63.118.39.25] helo=w2k07exg01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 19mEo8-0006jG-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 11:42:05 -0400 Received: by w2k07exg01.ciena.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 11:41:58 -0400 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001064A@w2kmaexg02.ciena.com> From: "Shah, Himanshu" To: Loa Andersson , l2vpn@ietf.org Cc: Eric Rosen , Vach Kompella , Rick Wilder Subject: RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc? Date: Mon, 11 Aug 2003 11:41:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3601F.192BA810" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3601F.192BA810 Content-Type: text/plain; charset="iso-8859-1" > we have a request to make > draft-rosen-ppvpn-l2-signaling-03.txt > a working group document. Please comment on this to the > mailing list. at this stage we want don't want to count > abstention as support - so please speak up if you want > this as a wg draft. > > This should be a WG doc. /himanshu ------_=_NextPart_001_01C3601F.192BA810 Content-Type: text/html; charset="iso-8859-1" RE: draft-rosen-ppvpn-l2-signaling-03.txt - for wg doc?

>  we have a request to make
>  draft-rosen-ppvpn-l2-signaling-03.txt
>  a working group document. Please comment on this to the
>  mailing list. at this stage we want don't want to count
>  abstention as support - so please speak up if you want
>  this as a wg draft.
> 
>


This should be a WG doc.

/himanshu

------_=_NextPart_001_01C3601F.192BA810-- From exim@www1.ietf.org Mon Aug 11 13:25:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24754 for ; Mon, 11 Aug 2003 13:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGPp-0004vJ-Kg for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 13:25:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHP5tD018922 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 13:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGPp-0004v7-GO for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:25:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24750 for ; Mon, 11 Aug 2003 13:24:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGPn-0007gw-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 13:25:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGPm-0007gt-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 13:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGPl-0004ud-4F; Mon, 11 Aug 2003 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGOp-0004tz-Cu for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 13:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24729 for ; Mon, 11 Aug 2003 13:23:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGOn-0007gm-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 13:24:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mGOm-0007gY-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 13:24:00 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2003 10:29:27 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7BHNRXw024483; Mon, 11 Aug 2003 13:23:27 -0400 (EDT) Message-Id: <200308111723.h7BHNRXw024483@rtp-core-1.cisco.com> To: "Busschbach, Peter B (Peter)" cc: "Christopher, Dunstan" , l2vpn@ietf.org Subject: Re: Questions regarding the VPLS In-reply-to: Your message of Fri, 08 Aug 2003 18:20:40 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Aug 2003 13:23:27 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Peter> 1) Strictly speaking, there is no n^2 issue. A single VPLS instance Peter> needs a full mesh of Pseudo Wires, but the total number of PWs in Peter> a network scales linearly with the number of VPLS instances. I think in this context n would be the number of PEs, and it is then true that the number of PWs needed in a particular VPLS instance is O(n^2). If we ignore the distributed VPLS for a moment, the point is that there isn't any node whose resources need to scale up at O(n^2). Resources at the PEs scale as O(n), and resources as the intermediate nodes are unaffected by an increase in the number of PEs. It is true that if some node is mediating the signaling between two other sets of nodes (as in distributed VPLS), the node doing the mediating has a scaling problem on the order of the product of the sizes of the two sets. Peter> That said, the total number of PWs could become large. Yes, and that is why L2 scales poorly when compared to L3. If you want the number of PEs to be able to increase in a scalable manner, try L3VPN! If one used spanning tree instead of full mesh with split horizon, a PE's pw-related resources would not need to scale up even at O(n). Of course, there are other scaling limitations that would then arise, due to the sub-optimal routing, the need to explicitly manage the overlay, etc. Peter> the number of transport LSPs becomes large. No problem, use mp2p "transport LSPs" and the state at the intermediate nodes is marginal. From exim@www1.ietf.org Mon Aug 11 13:27:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24814 for ; Mon, 11 Aug 2003 13:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGRj-00054S-1B for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 13:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHR3ux019486 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 13:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGRi-00054D-RW for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24803 for ; Mon, 11 Aug 2003 13:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGRg-0007hL-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 13:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGRg-0007hI-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 13:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGRh-000530-Pe; Mon, 11 Aug 2003 13:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGQw-0004yf-0C for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 13:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24781 for ; Mon, 11 Aug 2003 13:26:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGQt-0007hE-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 13:26:11 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mGQt-0007h1-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 13:26:11 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2003 10:25:40 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7BHPcXw024970; Mon, 11 Aug 2003 13:25:38 -0400 (EDT) Message-Id: <200308111725.h7BHPcXw024970@rtp-core-1.cisco.com> To: richard.spencer@bt.com cc: Sasha@AXERRA.com, l2vpn@ietf.org Subject: Re: VPN Identifiers In-reply-to: Your message of Sun, 10 Aug 2003 23:25:39 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Aug 2003 13:25:38 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We already have an 8-byte VPN-Id format which can be based either on AS numbers or on OUIs, and is extensible to other possibilities as well. Have you looked at draft-ouldbrahim-ppvpn-gid-03.txt? From exim@www1.ietf.org Mon Aug 11 13:59:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26186 for ; Mon, 11 Aug 2003 13:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGwh-0006Kt-Ri for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 13:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHx3Yj024349 for l2vpn-archive@odin.ietf.org; Mon, 11 Aug 2003 13:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGwh-0006Ke-Gr for l2vpn-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26173 for ; Mon, 11 Aug 2003 13:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGwf-00006r-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 13:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGwe-00006o-00 for l2vpn-web-archive@ietf.org; Mon, 11 Aug 2003 13:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGwe-0006JU-Rr; Mon, 11 Aug 2003 13:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGvp-0006Ef-MJ for l2vpn@optimus.ietf.org; Mon, 11 Aug 2003 13:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26143 for ; Mon, 11 Aug 2003 13:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGvn-00006X-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 13:58:07 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19mGvm-00006U-00 for l2vpn@ietf.org; Mon, 11 Aug 2003 13:58:06 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BHvVn12051; Mon, 11 Aug 2003 13:57:31 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 13:57:32 -0400 Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com, richard.spencer@bt.com Cc: Sasha@AXERRA.com, l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Mon, 11 Aug 2003 13:57:31 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric, > > > > We already have an 8-byte VPN-Id format which can be > based either on AS > numbers or on OUIs, and is extensible to other possibilities > as well. Have > you looked at draft-ouldbrahim-ppvpn-gid-03.txt? > > Yes. Actually I was going to suggest to the WG to consider the gid draft as part of the vpn identifiers discussion. It looks to me all what is needed is a format that guarantees uniqueness of the id route target and 2685 formats. It's length is however limited to 8 octets in length. I personally don't see a requirement to support variable length gids at this point in time. Hamid. From exim@www1.ietf.org Tue Aug 12 02:17:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29807 for ; Tue, 12 Aug 2003 02:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mSSy-000530-EF for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 02:17:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C6H84P019393 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 02:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mSSx-00052i-2o for l2vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 02:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29757 for ; Tue, 12 Aug 2003 02:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mSSt-0004jb-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 02:17:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mSSt-0004jY-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 02:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mSSr-000525-DA; Tue, 12 Aug 2003 02:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mSSS-0004zH-0Q for l2vpn@optimus.ietf.org; Tue, 12 Aug 2003 02:16:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29706; Tue, 12 Aug 2003 02:16:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mSSM-0004jQ-00; Tue, 12 Aug 2003 02:16:30 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19mSSK-0004jN-00; Tue, 12 Aug 2003 02:16:29 -0400 Received: from l04955 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HJH00LQOTBZ0S@mta0.huawei.com>; Tue, 12 Aug 2003 14:14:25 +0800 (CST) Date: Tue, 12 Aug 2003 14:14:27 +0800 From: lidefeng Subject: Re: L2vpn digest, Vol 1 #36 - 1 msg To: l2vpn@ietf.org, l2vpn-request@ietf.org Message-id: <001a01c36098$fc423a00$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030806160005.12839.66836.Mailman@www1.ietf.org> Content-Transfer-Encoding: 7BIT Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Where can I find the"l2vpn digest,Vol 1 #1" through "l2vpn digest,Vol 1 #35"? I have only those of after "l2vpn digest,Vol 1 #36". Thank you very much! ----- Original Message ----- From: To: Sent: Thursday, August 07, 2003 12:00 AM Subject: L2vpn digest, Vol 1 #36 - 1 msg > Send L2vpn mailing list submissions to > l2vpn@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/l2vpn > or, via email, send a message with subject or body 'help' to > l2vpn-request@ietf.org > > You can reach the person managing the list at > l2vpn-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of L2vpn digest..." > > > Today's Topics: > > 1. LDP, LSP PING and VPLS OAM questions (Yifat Migdal-Steinberg) > > --__--__-- > > Message: 1 > Subject: LDP, LSP PING and VPLS OAM questions > Date: Wed, 6 Aug 2003 16:24:32 +0300 > From: "Yifat Migdal-Steinberg" > To: > > > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C35C1E.12B7D0D3 > Content-Type: text/plain; > charset="windows-1255" > Content-Transfer-Encoding: quoted-printable > > > Hello, > > I have the following questions regarding VPLS (H-VPLS) based on the = > lassere-vkompella draft: > > Control plane versus Data plane: > > would it be true to say that : > > 1. data plane is responsible for encapsulation, de-encapsulation=20 > and forwarding of packets. > All packets arriving to the data plane are encapsulated with a VC label = > and one or more LSP labels. > > 2. Control plane is responsible for setting up the VC and LSP tunnels. = > It would usually be LDP for VC tunnels, > and might be RSVP-TE for LSP tunnels in the core.=20 > The signaling messages (IP/UDP or IP/TCP frames MAY be encapsulated) > (The main question is whether LDP packets are NEVER encapsulated, or MAY = > be encapsulated). > If they are encapsulated, is there a special encapsulation for signaling = > (like special label value) ? > > LSP ping and VPLS OAM (Ping+Traceroute): > > Error codes: When sending an echo reply of a VPLS ping/traceroute, in = > case of error, what would the > return code in the echo reply message be - is it always 0, and an error = > TLV is included with the appropriate VPLS OAM return code (1-7...) > OR, the return value is one of the LSP ping error codes, and 0 + error = > TLV is a private state. > > If only an H. L2 TLV (type=3D10) is included in the request message, is = > the LSP checked as well, based on the label > of the encapsulated packet, and an error code returned, or is it checked = > ONLY if the appropriate > TLV is included in the TLV stack. In case of error in the LSP - what = > would the return codes be? > In case of error in the VC - what would the return code be? > > Generally - if an hierarchy of LSPs are tested, and a TLVs stack is = > included,=20 > in case of error, what would be the return code in the reply message - > does it refer only to the bottom TLV/LSP or other? > (The question rises since the return code is one, while the TLVs may be = > stackable) > > Yifat > > Mrs. Yifat Migdal-Steinberg > RAD Data communications Ltd. > 24 Raoul Vallenberg St. > Tel-Aviv > Tel:03-7657035 > Fax:03-6455305 > > > ------_=_NextPart_001_01C35C1E.12B7D0D3 > Content-Type: text/html; > charset="windows-1255" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dwindows-1255"> > 6.0.6396.0"> > LDP, LSP PING and VPLS OAM questions > > > >
> >

Hello,

> >

I have the following = > questions regarding VPLS (H-VPLS) based on the lassere-vkompella = > draft:

> >

Control plane versus Data = > plane:

> >

would it be true to say that = > :

> >

1. data plane is responsible = > for encapsulation, de-encapsulation

> >

and forwarding  of = > packets.

> >

All packets arriving to the = > data plane are encapsulated with a VC label and one or more LSP = > labels.

> >

2. Control plane is = > responsible for setting up the VC and LSP tunnels. It would usually be = > LDP for VC tunnels,

> >

and might be RSVP-TE for LSP = > tunnels in the core.

> >

The signaling messages = > (IP/UDP or IP/TCP frames MAY be encapsulated)

> >

(The main question is = > whether LDP packets are Roman">NEVER encapsulated, = > or MAY FACE=3D"Times New Roman"> be encapsulated).

> >

If they are encapsulated, is = > there a special encapsulation for signaling (like special label value) = > ?

> >

LSP ping and VPLS OAM = > (Ping+Traceroute):

> >

Error codes: When sending an = > echo reply of a VPLS ping/traceroute, in case of error, what would = > the

> >

return code in the echo = > reply message be - is it always 0, and an error TLV is included with the = > appropriate VPLS OAM return code (1-7...)

> >

OR, the return value is one = > of the LSP ping error codes, and 0 + error TLV is a private = > state.

> >

If only an H. L2 TLV = > (type=3D10) is included in the request message, is the LSP checked as = > well, based on the label

> >

of the encapsulated packet, = > and an error code returned, or is it checked ONLY if the = > appropriate

> >

TLV is included in the TLV = > stack. In case of error in the LSP  - what would the return codes = > be?

> >

In case of error in the VC - = > what would the return code be?

> >

Generally - if an hierarchy = > of LSPs are tested, and a TLVs stack is included,

> >

in case of error, what would = > be the return code in the reply message -

> >

does it refer only to the = > bottom TLV/LSP or other?

> >

(The question rises since = > the return code is one, while the TLVs may be stackable)

> >

Yifat

> >

FACE=3D"Times New Roman">Mrs. Yifat Migdal-Steinberg

> >

FACE=3D"Times New Roman">RAD Data communications Ltd.

> >

FACE=3D"Times New Roman">24 Raoul Vallenberg St.

> >

FACE=3D"Times New Roman">Tel-Aviv

> >

FACE=3D"Times New Roman">Tel:03-7657035

> >

FACE=3D"Times New Roman">Fax:03-6455305 LANG=3D"he">

> > > > ------_=_NextPart_001_01C35C1E.12B7D0D3-- > > > > --__--__-- > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www1.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest From exim@www1.ietf.org Tue Aug 12 12:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20870 for ; Tue, 12 Aug 2003 12:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc66-0001dw-6R for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 12:34:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGYANm006311 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 12:34:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc66-0001di-2d for l2vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 12:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20845 for ; Tue, 12 Aug 2003 12:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mc64-00026O-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 12:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mc64-00026K-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 12:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc5x-0001cL-AI; Tue, 12 Aug 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc5w-0001c0-5B for l2vpn@optimus.ietf.org; Tue, 12 Aug 2003 12:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20832 for ; Tue, 12 Aug 2003 12:33:54 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mc5u-000268-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 12:33:58 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt02.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19mc5t-00025y-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 12:33:57 -0400 Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 12 Aug 2003 17:33:35 +0100 Message-ID: To: erosen@cisco.com Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Tue, 12 Aug 2003 17:33:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric, The VPN ID needs to be used in provisioning, auto-discovery, signalling and AAA. So whatever VPN ID format is defined will have to be supported by automated provisioning systems, auto-discovery mechanisms, signalling mechanisms and AAA mechanisms. VPN ID format support should not be dependant on the mechanisms used. A provider should be able to select which mechanisms they want to use without having to worry about what VPN ID formats they support. For example, a provider might deploy a VPN network using signalling mechanism X and AAA mechanism B, but later decide to change over to signalling mechanism Y. In this scenario the provider should not have to completely reconfigure its AAA database because signalling mechanism X uses a different VPN ID format to signalling mechanism Y. As described in your signalling draft, RFC2685 VPN IDs could be used in BGP based auto-discovery/signalling as they can be encoded as Route Distinguishers/Targets. However, the draft also states that any other method of assigning a unique identifier to a VPLS and encoding it as an RD will do. The LDP VPLS draft currently uses a VC ID, although the draft states that this will be replaced with a VPN ID TLV. The RADIUS discovery draft currently uses a variable length VPN ID which has the format: vpnY.domainZ.net, although this could be anything and is just used as an example. The point is that currently different mechanisms use different VPN ID formats. If it is decided that draft-ouldbrahim-ppvpn-gid-03.txt is the best VPN ID format to use then that's fine, but for inter-dependency and interoperability reasons it should be used across all VPN mechanisms. Looking at draft-ouldbrahim-ppvpn-gid-03.txt, do we really need 4+ different naming methods for a VPN? I think two options for global identifiers at the most should be sufficient, i.e. AS#, or OUI, although obviously one global ID would be preferable. Richard > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 11 August 2003 18:26 > To: Spencer,R,Richard,XGH5 R > Cc: Sasha@AXERRA.com; l2vpn@ietf.org > Subject: Re: VPN Identifiers > > > > We already have an 8-byte VPN-Id format which can be > based either on AS > numbers or on OUIs, and is extensible to other possibilities > as well. Have > you looked at draft-ouldbrahim-ppvpn-gid-03.txt? > From exim@www1.ietf.org Tue Aug 12 14:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23499 for ; Tue, 12 Aug 2003 14:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdmW-0005GU-4a for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 14:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CIM4bI020232 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 14:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdmV-0005GF-US for l2vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 14:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23484 for ; Tue, 12 Aug 2003 14:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdmT-0002uO-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 14:22:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mdmS-0002uL-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 14:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdmT-0005Fg-Lz; Tue, 12 Aug 2003 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mdmE-0005FJ-Vj for l2vpn@optimus.ietf.org; Tue, 12 Aug 2003 14:21:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23474 for ; Tue, 12 Aug 2003 14:21:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mdmC-0002u2-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 14:21:44 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19mdmB-0002tc-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 14:21:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CIL4018120; Tue, 12 Aug 2003 14:21:04 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 14:21:04 -0400 Message-ID: From: "Hamid Ould-Brahim" To: richard.spencer@bt.com, erosen@cisco.com Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Tue, 12 Aug 2003 14:15:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Richard, [clipped...] > > The point is that currently different mechanisms use different VPN ID > formats. I would say instead "different mechanisms use different global unique identifiers some of them are intended to uniquely identify a VPN." >If it is decided that > draft-ouldbrahim-ppvpn-gid-03.txt is the best > VPN ID format to use then that's fine, but for inter-dependency and > interoperability reasons it should be used across all VPN mechanisms. > Looking at draft-ouldbrahim-ppvpn-gid-03.txt, do we really > need 4+ different > naming methods for a VPN? I think two options for global > identifiers at the > most should be sufficient, i.e. AS#, or OUI, although > obviously one global > ID would be preferable. draft-ouldbrahim-ppvpn-gid-03.txt tries to define formats for supporting global unique identifiers mainly intended for VPN solutions and mostly targeting control planes, and among these formats it supports the route target and RFC2685 formats within an 8 octets length field. These ids are required to be unique only within a given solution and they do not necessarily identify a VPN. A particular solution may decide to assign a gid to uniquely identify a VPN if it wants to, and may want to use gids for other purposes as well. The draft does not solve the problem of defining a unique VPN-ID format intended to be used everywhere across all solutions including management. In my view if one wants to solve this problem and enforce that id on all solutions and on all the components of a given solution then there is already rfc2685 standard which pretty much meets the definition you mentioned below. Whether solutions within l2vpns will be using it everywhere is obviously another thing. Hamid. > > Richard > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: 11 August 2003 18:26 > > To: Spencer,R,Richard,XGH5 R > > Cc: Sasha@AXERRA.com; l2vpn@ietf.org > > Subject: Re: VPN Identifiers > > > > > > > > We already have an 8-byte VPN-Id format which can be > > based either on AS > > numbers or on OUIs, and is extensible to other possibilities > > as well. Have > > you looked at draft-ouldbrahim-ppvpn-gid-03.txt? > > > > From exim@www1.ietf.org Tue Aug 12 14:38:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23844 for ; Tue, 12 Aug 2003 14:38:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me1z-0005pA-G4 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 14:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CIc3La022383 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 14:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me1z-0005ow-BQ for l2vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 14:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23839 for ; Tue, 12 Aug 2003 14:37:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me1w-00030p-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 14:38:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19me1w-00030m-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 14:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me1w-0005oT-Rc; Tue, 12 Aug 2003 14:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me10-0005YK-TF for l2vpn@optimus.ietf.org; Tue, 12 Aug 2003 14:37:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23819 for ; Tue, 12 Aug 2003 14:36:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me0l-0002zz-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 14:36:47 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19me0l-0002zk-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 14:36:47 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CIaG021539 for ; Tue, 12 Aug 2003 14:36:16 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 14:36:16 -0400 Message-ID: From: "Hamid Ould-Brahim" To: vach.kompella@alcatel.com, L2vpn Subject: RE: Minutes and action items from IETF 57 Date: Tue, 12 Aug 2003 14:36:16 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vach, [Catching up on my emails...] Some comments on the minutes... > > Loa - draft-shah-arp-mediation is out of scope > draft-sajassi-l2vpn-interworking is out of scope > draft-ce-based is out of scope, for now > > Ali - Disparate attachements ckts is a real problem so where > will we address this. > > Vach - Per the charter this is out of scope. We have to decide > whether members feel whether we need to address this > here. > > Hamid - Commenting on charter; It says IP VPN and I read that as > any particular attachment circuit and hence it should be > in charter I meant that: "It looks to me that the IP_based L2VPN already in the charter covers as well the ability to interconnect two disparate attachment circuits for IP only traffic." > > Alex - The inter-working part was part of the charter when it > went to IESG. IESG was concerned that we might be > stepping on other bodies toes and hence it was taken out. > Lets gauge the consensus in the room and then take up > with issue again with the IESG. > [clipped]... > > Hamid - p2p l2vpn - did you mean the work in pwe3? > logically the only layer that belongs here is martini Remove the "logically...". [clipped...] > > Vach - I am just asking for the AGI field to be changed to TLV > > Hamid - There is already some discussion going on in PWE3 > to change that. > Not sure I said the above statement ;-). > Vach - That is what I am proposing > > Hamid - OK > > Luca - why is 32 bits not enough? > > Vach - 32 bits is not enough for inter-galatic VPLS (really not > sufficient for inter-region and inter-AS VPLS) > > Luca - lets do it in 1000 years then > > Vach - This takes care when the VPLS spans multiple area. Even > though that is out of scope right now, when we do move > there I don't want to restrict ourselves. > > Luca - just introduce a TLV and call it "name" > > Vach - that is what I am doing > > Luca - Please propose this on the PWE3 mailing list. > > Vach - will do. > > Hamid - It is just not a question of why 32 bits is not enough, it > is because we need a way to identify a set of > pseudo-wires. I think I mentioned that: "It is not just about increasing the number of bits. The ID should be globally unique therefore it requires a format that guarantees its uniqueness. From that aspect, a four octets field will not make it." Thanks. Hamid. From exim@www1.ietf.org Tue Aug 12 14:40:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23945 for ; Tue, 12 Aug 2003 14:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me3u-0005z6-Tb for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 14:40:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CIe2fk022998 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 14:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me3u-0005yr-Mr for l2vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 14:40:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23938 for ; Tue, 12 Aug 2003 14:39:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me3s-00031p-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 14:40:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19me3r-00031m-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 14:39:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me3t-0005xl-KX; Tue, 12 Aug 2003 14:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19me3O-0005wZ-Ix for l2vpn@optimus.ietf.org; Tue, 12 Aug 2003 14:39:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23914 for ; Tue, 12 Aug 2003 14:39:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19me3L-00031c-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 14:39:27 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19me3L-00031G-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 14:39:27 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2003 11:45:08 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7CIcsxc029096; Tue, 12 Aug 2003 14:38:55 -0400 (EDT) Message-Id: <200308121838.h7CIcsxc029096@rtp-core-2.cisco.com> To: richard.spencer@bt.com cc: l2vpn@ietf.org Subject: Re: VPN Identifiers In-reply-to: Your message of Tue, 12 Aug 2003 17:33:09 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 Aug 2003 14:38:54 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Richard> If it is decided that draft-ouldbrahim-ppvpn-gid-03.txt is the best Richard> VPN ID format to use then that's fine, but for inter-dependency and Richard> interoperability reasons it should be used across all VPN Richard> mechanisms. I have no problem with this, but if there is anyone who still wants to be able to use domain names as VPN-ids, I don't imagine they will go along with this ;-) Richard> Looking at draft-ouldbrahim-ppvpn-gid-03.txt, do we really need 4+ Richard> different naming methods for a VPN? I think two options for global Richard> identifiers at the most should be sufficient, i.e. AS#, or OUI, Richard> although obviously one global ID would be preferable. With regard to the requirements you've stated, I don't think it matters how many different methods there are for producing VPN-ids, as long as there is no ambiguity introduced into the encodings. From exim@www1.ietf.org Tue Aug 12 16:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29022 for ; Tue, 12 Aug 2003 16:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mg8e-0002xk-Il for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 16:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CKr4xP011382 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 16:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mg8d-0002xV-V6 for l2vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 16:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29012 for ; Tue, 12 Aug 2003 16:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mg8b-0003xl-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 16:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mg8b-0003xi-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 16:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mg8a-0002x3-Pu; Tue, 12 Aug 2003 16:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mg7h-0002wT-W6 for l2vpn@optimus.ietf.org; Tue, 12 Aug 2003 16:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28978 for ; Tue, 12 Aug 2003 16:52:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mg7f-0003xA-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 16:52:03 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19mg7f-0003x2-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 16:52:03 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CKpU316210; Tue, 12 Aug 2003 16:51:30 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 16:51:31 -0400 Message-ID: From: "Hamid Ould-Brahim" To: vach.kompella@alcatel.com, "Christopher, Dunstan" , l2vpn@ietf.org Subject: RE: Questions regarding the VPLS Date: Tue, 12 Aug 2003 16:51:30 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vach, > > > However, the n^2 issue isn't the same as the n^2 issue of ATM > VCs. Here, the > tunnels carry multiple services. > > True. In addition to that the n^2 PE-PE tunnels is a bit different from the n^2 layer-2 services running across these tunnels. The complexity of the former depends on the number of PEs and the engineering of the provider network and impacts only the provider network while the complexity of the latter depends on the number of l2vpns and the number of sites for each VPN that requires connectivity to all the other sites, and the impact can be on both provider and customer networks (if we assume that routing needs to be configured on top of these VCs). Hamid. From exim@www1.ietf.org Wed Aug 13 02:24:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04507 for ; Wed, 13 Aug 2003 02:24:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp3J-00006v-LW for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 02:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D6O98Z000424 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 02:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp3J-00006l-As for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 02:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03935 for ; Wed, 13 Aug 2003 02:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mp3C-00071f-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 02:24:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mp3B-00071b-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 02:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp3C-00005N-Iy; Wed, 13 Aug 2003 02:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp2F-0008Ux-6P for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 02:23:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02876 for ; Wed, 13 Aug 2003 02:22:58 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mp2B-00071H-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 02:22:59 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt08.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19mp2A-00070z-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 02:22:58 -0400 Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 13 Aug 2003 07:22:49 +0100 Message-ID: To: hbrahim@nortelnetworks.com, erosen@cisco.com Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Wed, 13 Aug 2003 07:22:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hamid, I understand that your GID draft is not intended to solve the problem of defining a unique VPN-ID format and I agree that RFC2685 meets the requirements for a VPN-ID. If there is consensus that this is the best VPN ID to use then I would like to see all the drafts support its use. Richard > -----Original Message----- > From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] > Sent: 12 August 2003 19:16 > To: Spencer,R,Richard,XGH5 R; erosen@cisco.com > Cc: l2vpn@ietf.org > Subject: RE: VPN Identifiers > > > Richard, > > [clipped...] > > > > > The point is that currently different mechanisms use > different VPN ID > > formats. > > I would say instead "different mechanisms use different global unique > identifiers some of them are intended to uniquely identify a VPN." > > >If it is decided that > > draft-ouldbrahim-ppvpn-gid-03.txt is the best > > VPN ID format to use then that's fine, but for inter-dependency and > > interoperability reasons it should be used across all VPN > mechanisms. > > Looking at draft-ouldbrahim-ppvpn-gid-03.txt, do we really > > need 4+ different > > naming methods for a VPN? I think two options for global > > identifiers at the > > most should be sufficient, i.e. AS#, or OUI, although > > obviously one global > > ID would be preferable. > > draft-ouldbrahim-ppvpn-gid-03.txt tries to define formats for > supporting global unique identifiers mainly intended for VPN > solutions and mostly targeting control planes, and among these > formats it supports the route target and RFC2685 formats within > an 8 octets length field. These ids are required to be unique > only within a given solution and they do not necessarily identify > a VPN. A particular solution may decide to assign a gid to uniquely > identify a VPN if it wants to, and may want to use gids for other > purposes as well. > > The draft does not solve the problem of defining a unique VPN-ID > format intended to be used everywhere across all solutions including > management. In my view if one wants to solve this problem and enforce > that id on all solutions and on all the components of a given solution > then there is already rfc2685 standard which pretty > much meets the definition you mentioned below. Whether solutions > within l2vpns will be using it everywhere is obviously > another thing. > > Hamid. > > > > > Richard > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: 11 August 2003 18:26 > > > To: Spencer,R,Richard,XGH5 R > > > Cc: Sasha@AXERRA.com; l2vpn@ietf.org > > > Subject: Re: VPN Identifiers > > > > > > > > > > > > We already have an 8-byte VPN-Id format which can be > > > based either on AS > > > numbers or on OUIs, and is extensible to other possibilities > > > as well. Have > > > you looked at draft-ouldbrahim-ppvpn-gid-03.txt? > > > > > > > > From exim@www1.ietf.org Wed Aug 13 02:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08629 for ; Wed, 13 Aug 2003 02:30:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp94-0000Q9-4L for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 02:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D6U5mC001610 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 02:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp92-0000Pt-4v for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 02:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08186 for ; Wed, 13 Aug 2003 02:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mp8y-00072p-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 02:30:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mp8x-00072m-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 02:29:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp90-0000Of-4A; Wed, 13 Aug 2003 02:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mp8a-0000NY-4g for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 02:29:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06698 for ; Wed, 13 Aug 2003 02:27:55 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mp6y-00072O-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 02:27:56 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt02.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19mp6y-00072J-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 02:27:56 -0400 Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 13 Aug 2003 07:27:40 +0100 Message-ID: To: erosen@cisco.com Cc: l2vpn@ietf.org Subject: DNS VPN ID Format (Was: VPN Identifiers) Date: Wed, 13 Aug 2003 07:27:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Eric: > I have no problem with this, but if there is anyone who > still wants to be able to use domain names as VPN-ids, > I don't imagine they will go along with this ;-) OK so lets ask the question, is there anyone that wants to use domain names to identify VPNs? DNS is ideal for domain name addresses and email addresses because the email/domain names need to be used/understood/remembered in everyday life by end users that potentially have very little knowledge of computing. VPN IDs on the other hand only need to be used/understood/remembered by network operations staff or network systems/protocols. Operations staff are used to using machine readable parameters such as IP addresses/VLAN IDs/DLCIs/etc and obviously systems/protocols don't care what the format of a parameter is as long as its well defined. Although the fact that DNS names are human readable is useful, IMO the downsides (i.e. variable length and parsing problems) mean that this option should be discarded. Thanks, Richard From exim@www1.ietf.org Wed Aug 13 02:52:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10725 for ; Wed, 13 Aug 2003 02:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mpUN-0001VE-O4 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 02:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D6q7A6005771 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 02:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mpUK-0001UK-TY for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 02:52:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10722 for ; Wed, 13 Aug 2003 02:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mpUH-0007D0-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 02:52:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mpUG-0007Cx-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 02:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mpUH-0001Tp-SX; Wed, 13 Aug 2003 02:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mpTb-0001T5-Fy for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 02:51:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10717 for ; Wed, 13 Aug 2003 02:51:14 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mpTX-0007Cr-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 02:51:15 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt02.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19mpTX-0007Co-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 02:51:15 -0400 Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 13 Aug 2003 07:50:59 +0100 Message-ID: To: erosen@cisco.com Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Wed, 13 Aug 2003 07:50:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Eric: > With regard to the requirements you've stated, I don't think > it matters how many different methods there are for producing > VPN-ids, as long as there is no ambiguity introduced into the > encodings. I agree, but only if the same encodings are supported by all the VPN drafts. For example, lets say a network operator decides that they want to deploy a VPLS service today using BGP auto-discovery along with LDP signalling. BGP auto-discovery has an 8 byte field that can be used to encode an RFC2685 VPN ID, but the LDP signalling draft currently uses has a 4 byte VC ID to identify a VPN. So what VPN ID format should the operator use? The alternatives seem to be i) use 4 byte VPN ID in both, or ii) use two different VPN IDs and map/translate between the two. Option i) has scalability/global uniqueness issues and option ii) requires multiple VPN IDs to be provisioned/managed. If there are operators that have deployed VPLS using a combination of these two mechanisms or there are alternative options then I would be interested in hearing about them. Looking at things from a vendors perspective specifying a single VPN ID format would make implementation simpler/cheaper. Looking at things from an operators perspective as long as ALL the VPN ID formats are supported by ALL the VPN protocols/systems that need to use VPN IDs then there is no issue. The provider can just select whichever VPN ID meets their requirements without having to worry about which mechanisms support which VPN ID format. The issues arises when the operator has to manage multiple VPN IDs or perform VPN ID translation because the mechanisms/systems the operator wants to implement use different VPN ID formats. Richard From exim@www1.ietf.org Wed Aug 13 07:41:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16147 for ; Wed, 13 Aug 2003 07:41:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mu01-0003M9-3F for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 07:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DBf5Fk012898 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 07:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mu00-0003Lx-Rs for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 07:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16142 for ; Wed, 13 Aug 2003 07:41:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mu00-0000XU-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 07:41:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mtzz-0000XR-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 07:41:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mtzy-0003LU-7t; Wed, 13 Aug 2003 07:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mtzO-0003L4-K2 for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 07:40:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16132 for ; Wed, 13 Aug 2003 07:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mtzN-0000XN-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 07:40:25 -0400 Received: from [212.113.11.114] (helo=rincewind.office.packetexchange.net ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19mtzN-0000XK-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 07:40:25 -0400 Received: from [213.208.123.104] (helo=gizpad) by rincewind.office.packetexchange.net with esmtp (Exim 3.35 #1 (Debian)) id 19mtym-0003kJ-00; Wed, 13 Aug 2003 12:39:48 +0100 Subject: RE: VPN Identifiers From: Giles Heron To: richard.spencer@bt.com Cc: hbrahim@nortelnetworks.com, erosen@cisco.com, l2vpn@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Aug 2003 12:35:39 +0000 Message-Id: <1060778139.2096.14.camel@gizpad> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not sure I'd go with that consensus. OUIs aren't exactly cheap, are they? Giles On Wed, 2003-08-13 at 06:22, richard.spencer@bt.com wrote: > Hamid, > > I understand that your GID draft is not intended to solve the problem of > defining a unique VPN-ID format and I agree that RFC2685 meets the > requirements for a VPN-ID. If there is consensus that this is the best VPN > ID to use then I would like to see all the drafts support its use. > > Richard > > > -----Original Message----- > > From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] > > Sent: 12 August 2003 19:16 > > To: Spencer,R,Richard,XGH5 R; erosen@cisco.com > > Cc: l2vpn@ietf.org > > Subject: RE: VPN Identifiers > > > > > > Richard, > > > > [clipped...] > > > > > > > > The point is that currently different mechanisms use > > different VPN ID > > > formats. > > > > I would say instead "different mechanisms use different global unique > > identifiers some of them are intended to uniquely identify a VPN." > > > > >If it is decided that > > > draft-ouldbrahim-ppvpn-gid-03.txt is the best > > > VPN ID format to use then that's fine, but for inter-dependency and > > > interoperability reasons it should be used across all VPN > > mechanisms. > > > Looking at draft-ouldbrahim-ppvpn-gid-03.txt, do we really > > > need 4+ different > > > naming methods for a VPN? I think two options for global > > > identifiers at the > > > most should be sufficient, i.e. AS#, or OUI, although > > > obviously one global > > > ID would be preferable. > > > > draft-ouldbrahim-ppvpn-gid-03.txt tries to define formats for > > supporting global unique identifiers mainly intended for VPN > > solutions and mostly targeting control planes, and among these > > formats it supports the route target and RFC2685 formats within > > an 8 octets length field. These ids are required to be unique > > only within a given solution and they do not necessarily identify > > a VPN. A particular solution may decide to assign a gid to uniquely > > identify a VPN if it wants to, and may want to use gids for other > > purposes as well. > > > > The draft does not solve the problem of defining a unique VPN-ID > > format intended to be used everywhere across all solutions including > > management. In my view if one wants to solve this problem and enforce > > that id on all solutions and on all the components of a given solution > > then there is already rfc2685 standard which pretty > > much meets the definition you mentioned below. Whether solutions > > within l2vpns will be using it everywhere is obviously > > another thing. > > > > Hamid. > > > > > > > > Richard > > > > > > > -----Original Message----- > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > Sent: 11 August 2003 18:26 > > > > To: Spencer,R,Richard,XGH5 R > > > > Cc: Sasha@AXERRA.com; l2vpn@ietf.org > > > > Subject: Re: VPN Identifiers > > > > > > > > > > > > > > > > We already have an 8-byte VPN-Id format which can be > > > > based either on AS > > > > numbers or on OUIs, and is extensible to other possibilities > > > > as well. Have > > > > you looked at draft-ouldbrahim-ppvpn-gid-03.txt? > > > > > > > > > > > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From exim@www1.ietf.org Wed Aug 13 08:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17938 for ; Wed, 13 Aug 2003 08:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mv2p-0005mS-Kb for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 08:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DCm3dW022215 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 08:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mv2p-0005mE-Gr for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 08:48:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17912 for ; Wed, 13 Aug 2003 08:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mv2o-00012K-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 08:48:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mv2n-00012H-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 08:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mv2n-0005ld-AO; Wed, 13 Aug 2003 08:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mv20-0005ku-AL for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 08:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17850 for ; Wed, 13 Aug 2003 08:47:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mv1y-00010i-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 08:47:11 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19mv1y-0000zy-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 08:47:10 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 13 Aug 2003 14:46:05 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7DCiNUp011837; Wed, 13 Aug 2003 14:44:24 +0200 (MET DST) Received: from cisco.com (dhcp-par-ilm-vl14-64-103-30-53.cisco.com [64.103.30.53]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA11366; Wed, 13 Aug 2003 14:46:37 +0200 (MET DST) Message-ID: <3F3A332D.8000101@cisco.com> Date: Wed, 13 Aug 2003 14:46:37 +0200 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.spencer@bt.com CC: erosen@cisco.com, l2vpn@ietf.org Subject: Re: VPN Identifiers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit richard.spencer@bt.com wrote: >>Eric: >>With regard to the requirements you've stated, I don't think >>it matters how many different methods there are for producing >>VPN-ids, as long as there is no ambiguity introduced into the >>encodings. > > > I agree, but only if the same encodings are supported by all the VPN drafts. > For example, lets say a network operator decides that they want to deploy a > VPLS service today using BGP auto-discovery along with LDP signalling. BGP > auto-discovery has an 8 byte field that can be used to encode an RFC2685 VPN > ID, but the LDP signalling draft currently uses has a 4 byte VC ID to > identify a VPN. So what VPN ID format should the operator use? The > alternatives seem to be i) use 4 byte VPN ID in both, or ii) use two > different VPN IDs and map/translate between the two. Option i) has > scalability/global uniqueness issues and option ii) requires multiple VPN > IDs to be provisioned/managed. If there are operators that have deployed > VPLS using a combination of these two mechanisms or there are alternative > options then I would be interested in hearing about them. > > Looking at things from a vendors perspective specifying a single VPN ID > format would make implementation simpler/cheaper. Looking at things from an > operators perspective as long as ALL the VPN ID formats are supported by ALL > the VPN protocols/systems that need to use VPN IDs then there is no issue. > The provider can just select whichever VPN ID meets their requirements > without having to worry about which mechanisms support which VPN ID format. > The issues arises when the operator has to manage multiple VPN IDs or > perform VPN ID translation because the mechanisms/systems the operator wants > to implement use different VPN ID formats. > > Richard Ambiguity between VPN ID formats or not, isn't the real point that you can't turn 8 octets into 4 without losing a significant amount of information? The showstopper I see here is with the unacceptably low common denominator introduced by the 4 octet VCID used by LDP signaling today more than anything else. draft-rosen-ppvpn-l2-signaling-03.txt addresses the current LDP limitation, and L2TPv3 has used a variable length endpoint identifier since day one. Perhaps the 4-octet IDs should be banished to manual setup only, and the 8+ octet format(s) used for pseudowires setup via auto-discovery. - Mark > > > > From exim@www1.ietf.org Wed Aug 13 09:18:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18482 for ; Wed, 13 Aug 2003 09:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mvVs-0006jg-4p for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 09:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DDI4O1025891 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 09:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mvVr-0006jW-V3 for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 09:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18479 for ; Wed, 13 Aug 2003 09:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mvVq-0001KY-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 09:18:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mvVp-0001KV-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 09:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mvVo-0006j4-K1; Wed, 13 Aug 2003 09:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mvUy-0006gg-RM for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 09:17:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18475 for ; Wed, 13 Aug 2003 09:17:03 -0400 (EDT) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mvUx-0001K3-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 09:17:07 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19mvUw-0001Jr-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 09:17:06 -0400 Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 13 Aug 2003 14:16:32 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6C4A@i2km07-ukbr.domain1.systemhost.net> To: townsley@cisco.com, richard.spencer@bt.com Cc: erosen@cisco.com, l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Wed, 13 Aug 2003 14:16:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mark, I agree with you. But I also want to emphasis another point Richard made in an earlier mail.....that is, we should decouple identifiers (by they names, as here, or addresses) from other functional components, like specific instances of routing or signalling protocols. In the case of named entities these are either abstract 'group' objects (like a VPN-ID) or an external (to the network, but may bind to a network access point address) 'single' objects. Further, addresses belong to network access points in the data-plane and quite clearly ought to be able to be used with any signalling (or routing) protocol.....including case of 'none'. regards, Neil > -----Original Message----- > From: W. Mark Townsley [mailto:townsley@cisco.com] > Sent: 13 August 2003 13:47 > To: Spencer,R,Richard,XGH5 R > Cc: erosen@cisco.com; l2vpn@ietf.org > Subject: Re: VPN Identifiers > > > > > richard.spencer@bt.com wrote: > >>Eric: > >>With regard to the requirements you've stated, I don't think > >>it matters how many different methods there are for producing > >>VPN-ids, as long as there is no ambiguity introduced into the > >>encodings. > > > > > > I agree, but only if the same encodings are supported by > all the VPN drafts. > > For example, lets say a network operator decides that they > want to deploy a > > VPLS service today using BGP auto-discovery along with LDP > signalling. BGP > > auto-discovery has an 8 byte field that can be used to > encode an RFC2685 VPN > > ID, but the LDP signalling draft currently uses has a 4 > byte VC ID to > > identify a VPN. So what VPN ID format should the operator use? The > > alternatives seem to be i) use 4 byte VPN ID in both, or ii) use two > > different VPN IDs and map/translate between the two. Option i) has > > scalability/global uniqueness issues and option ii) > requires multiple VPN > > IDs to be provisioned/managed. If there are operators that > have deployed > > VPLS using a combination of these two mechanisms or there > are alternative > > options then I would be interested in hearing about them. > > > > Looking at things from a vendors perspective specifying a > single VPN ID > > format would make implementation simpler/cheaper. Looking > at things from an > > operators perspective as long as ALL the VPN ID formats are > supported by ALL > > the VPN protocols/systems that need to use VPN IDs then > there is no issue. > > The provider can just select whichever VPN ID meets their > requirements > > without having to worry about which mechanisms support > which VPN ID format. > > The issues arises when the operator has to manage multiple > VPN IDs or > > perform VPN ID translation because the mechanisms/systems > the operator wants > > to implement use different VPN ID formats. > > > > Richard > > Ambiguity between VPN ID formats or not, isn't the real point > that you can't > turn 8 octets into 4 without losing a significant amount of > information? The > showstopper I see here is with the unacceptably low common > denominator > introduced by the 4 octet VCID used by LDP signaling today > more than anything else. > > draft-rosen-ppvpn-l2-signaling-03.txt addresses the current > LDP limitation, and > L2TPv3 has used a variable length endpoint identifier since > day one. Perhaps the > 4-octet IDs should be banished to manual setup only, and the > 8+ octet format(s) > used for pseudowires setup via auto-discovery. > > - Mark > > > > > > > > > > > > > From exim@www1.ietf.org Wed Aug 13 10:01:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19494 for ; Wed, 13 Aug 2003 10:01:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwBU-000851-4V for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 10:01:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DE14YD031053 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 10:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwBT-00084i-U2 for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 10:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19454 for ; Wed, 13 Aug 2003 10:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwBR-0001e3-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 10:01:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mwBR-0001e0-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 10:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwBS-000847-92; Wed, 13 Aug 2003 10:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwBI-00083W-At for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 10:00:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19443 for ; Wed, 13 Aug 2003 10:00:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwBG-0001ds-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 10:00:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mwBF-0001do-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 10:00:49 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2003 07:06:43 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7DE0Exc007130; Wed, 13 Aug 2003 10:00:14 -0400 (EDT) Message-Id: <200308131400.h7DE0Exc007130@rtp-core-2.cisco.com> To: richard.spencer@bt.com cc: hbrahim@nortelnetworks.com, l2vpn@ietf.org Subject: Re: VPN Identifiers In-reply-to: Your message of Wed, 13 Aug 2003 07:22:23 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Aug 2003 10:00:16 -0400 From: Eric Rosen Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Richard> If there is consensus that this is the best VPN ID to use then I Richard> would like to see all the drafts support its use. Not much chance of that. No one has presented a requirement for a single kind of VPN id. From exim@www1.ietf.org Wed Aug 13 12:14:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24673 for ; Wed, 13 Aug 2003 12:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myGC-0006zX-Py for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 12:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DGE4v6026863 for l2vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 12:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myGC-0006xm-Dk for l2vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 12:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24661 for ; Wed, 13 Aug 2003 12:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myGB-0002sb-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 12:14:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19myGA-0002sY-00 for l2vpn-web-archive@ietf.org; Wed, 13 Aug 2003 12:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myG9-0006xB-Oc; Wed, 13 Aug 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myFF-0006wI-3x for l2vpn@optimus.ietf.org; Wed, 13 Aug 2003 12:13:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24649 for ; Wed, 13 Aug 2003 12:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myFD-0002sG-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 12:13:03 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19myFC-0002s4-00 for l2vpn@ietf.org; Wed, 13 Aug 2003 12:13:03 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7DGCOQ20962 for ; Wed, 13 Aug 2003 12:12:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 12:12:24 -0400 Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com, richard.spencer@bt.com Cc: l2vpn@ietf.org Subject: RE: VPN Identifiers Date: Wed, 13 Aug 2003 12:12:22 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Eric, > > > > Richard> If there is consensus that this is the best VPN ID > to use then I > Richard> would like to see all the drafts support its use. > > Not much chance of that. > > No one has presented a requirement for a single kind of VPN id. > Yes. That is why I think the simplest approach is to use GIDs and each solution can equate gid to vpn-id in all its components if it wants to including management, and the operator picks the format it prefers supported within a given solution. Looks to me a pragmatic proposal. Hamid. From exim@www1.ietf.org Thu Aug 14 18:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29675 for ; Thu, 14 Aug 2003 18:21:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nQSt-0003Rk-Bj for l2vpn-archive@odin.ietf.org; Thu, 14 Aug 2003 18:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EML3HN013242 for l2vpn-archive@odin.ietf.org; Thu, 14 Aug 2003 18:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nQSt-0003RV-5x for l2vpn-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 18:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29646 for ; Thu, 14 Aug 2003 18:20:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nQSq-0006MR-00 for l2vpn-web-archive@ietf.org; Thu, 14 Aug 2003 18:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nQSp-0006MN-00 for l2vpn-web-archive@ietf.org; Thu, 14 Aug 2003 18:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nQSq-0003R4-Bm; Thu, 14 Aug 2003 18:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nQRu-0003GX-Kg for l2vpn@optimus.ietf.org; Thu, 14 Aug 2003 18:20:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29621 for ; Thu, 14 Aug 2003 18:19:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nQRr-0006MJ-00 for l2vpn@ietf.org; Thu, 14 Aug 2003 18:19:59 -0400 Received: from maila.telia.com ([194.22.194.231]) by ietf-mx with esmtp (Exim 4.12) id 19nQRq-0006MF-00 for l2vpn@ietf.org; Thu, 14 Aug 2003 18:19:59 -0400 Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.9/8.12.9) with ESMTP id h7EMJsHD014203; Fri, 15 Aug 2003 00:19:55 +0200 (CEST) X-Original-Recipient: l2vpn@ietf.org Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h7EMJsc13680; Fri, 15 Aug 2003 00:19:54 +0200 (CEST) Message-ID: <3F3C0AF0.2090305@pi.se> Date: Fri, 15 Aug 2003 00:19:28 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org CC: "Vach Kompella" , Rick Wilder Subject: draft-shah-ppvpn-IPLS-02.txt for working group doc? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Working Group, we have a request to make the "IP-Only LAN Service (IPLS)" a working group document. This work is within the working group charter, and we would like to have your view, pros or cons, whether this document is what we should base the IPLS solution on. Again a case where you need to speak up, silence won't be interpreted one why or the other. Please send your response to the list. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Fri Aug 15 11:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00813 for ; Fri, 15 Aug 2003 11:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngdT-0008EB-5z for l2vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 11:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFb3OV031621 for l2vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 11:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngdS-0008Dw-NP for l2vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 11:37:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00805 for ; Fri, 15 Aug 2003 11:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngdR-0003Ev-00 for l2vpn-web-archive@ietf.org; Fri, 15 Aug 2003 11:37:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ngdQ-0003Er-00 for l2vpn-web-archive@ietf.org; Fri, 15 Aug 2003 11:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngdQ-0008CX-II; Fri, 15 Aug 2003 11:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngcT-00089y-NP for l2vpn@optimus.ietf.org; Fri, 15 Aug 2003 11:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00790 for ; Fri, 15 Aug 2003 11:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngcS-0003EP-00 for l2vpn@ietf.org; Fri, 15 Aug 2003 11:36:00 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19ngcR-0003EG-00 for l2vpn@ietf.org; Fri, 15 Aug 2003 11:36:00 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7FFZQA29214 for ; Fri, 15 Aug 2003 10:35:27 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 15 Aug 2003 11:35:26 -0400 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Loa Andersson'" , l2vpn@ietf.org Cc: Vach Kompella , Rick Wilder Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc? Date: Fri, 15 Aug 2003 11:35:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Loa, I am not sure to what extent IPLS will be deployed, but I think it is an elegant solution that should be pursued further. I support that the document becomes a WG draft. Peter > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Thursday, August 14, 2003 6:19 PM > To: l2vpn@ietf.org > Cc: Vach Kompella; Rick Wilder > Subject: draft-shah-ppvpn-IPLS-02.txt for working group doc? > > > Working Group, > > we have a request to make the "IP-Only LAN Service (IPLS)" > a working group document. > > This work is within the working group charter, and we > would like to have your view, pros or cons, whether this > document is what we should base the IPLS solution on. > > Again a case where you need to speak up, silence won't > be interpreted one why or the other. > > Please send your response to the list. > > /Loa > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > From exim@www1.ietf.org Fri Aug 15 13:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05335 for ; Fri, 15 Aug 2003 13:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niBJ-00069h-0K for l2vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:16:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHG4Wh023649 for l2vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niBI-00069A-Jy for l2vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:16:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05301 for ; Fri, 15 Aug 2003 13:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niBG-0004NH-00 for l2vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:16:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19niBG-0004NE-00 for l2vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niBF-00068K-GC; Fri, 15 Aug 2003 13:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhJJ-0003Se-0s for l2vpn@optimus.ietf.org; Fri, 15 Aug 2003 12:20:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02235 for ; Fri, 15 Aug 2003 12:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhJH-0003dB-00 for l2vpn@ietf.org; Fri, 15 Aug 2003 12:20:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nhJF-0003d7-00 for l2vpn@ietf.org; Fri, 15 Aug 2003 12:20:15 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2003 09:26:40 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7FGJWuG012117; Fri, 15 Aug 2003 09:19:41 -0700 (PDT) Received: from rtp-stealthvpn-421.cisco.com (rtp-stealthvpn-421.cisco.com [10.81.3.166]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id ABO47184; Fri, 15 Aug 2003 12:19:30 -0400 (EDT) Date: Fri, 15 Aug 2003 12:19:29 -0400 From: Bruce Davie To: Loa Andersson , l2vpn@ietf.org cc: Vach Kompella , Rick Wilder Subject: Re: draft-shah-ppvpn-IPLS-02.txt for working group doc? Message-ID: <183970535.1060949969@[10.86.162.253]> In-Reply-To: <3F3C0AF0.2090305@pi.se> References: <3F3C0AF0.2090305@pi.se> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Loa, The document is a good start at addressing the problem space of IPLS, and I'm glad to see the problem being tackled by the WG. So yes, please adopt it as a WG doc. Bruce --On Friday, August 15, 2003 12:19 AM +0200 Loa Andersson wrote: > Working Group, > > we have a request to make the "IP-Only LAN Service (IPLS)" > a working group document. > > This work is within the working group charter, and we > would like to have your view, pros or cons, whether this > document is what we should base the IPLS solution on. > > Again a case where you need to speak up, silence won't > be interpreted one why or the other. > > Please send your response to the list. > > /Loa > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > From exim@www1.ietf.org Mon Aug 18 00:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28211 for ; Mon, 18 Aug 2003 00:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oc0v-0006FE-Uk for l2vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 00:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7I4r5k4023998 for l2vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 00:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oc0v-0006Ez-LD for l2vpn-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 00:53:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28169 for ; Mon, 18 Aug 2003 00:52:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oc0t-0004gV-00 for l2vpn-web-archive@ietf.org; Mon, 18 Aug 2003 00:53:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oc0s-0004gR-00 for l2vpn-web-archive@ietf.org; Mon, 18 Aug 2003 00:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oc0r-0006EP-97; Mon, 18 Aug 2003 00:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oc0M-0006Cl-Fx for l2vpn@optimus.ietf.org; Mon, 18 Aug 2003 00:52:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28147 for ; Mon, 18 Aug 2003 00:52:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oc0J-0004fy-00 for l2vpn@ietf.org; Mon, 18 Aug 2003 00:52:27 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19oc0I-0004fu-00 for l2vpn@ietf.org; Mon, 18 Aug 2003 00:52:27 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7I4qRVD022822 for ; Sun, 17 Aug 2003 21:52:27 -0700 (MST) Received: from zin01exm01.corp.mot.com (zin01exm01.corp.mot.com [217.1.122.3]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h7I4qA01025626 for ; Sun, 17 Aug 2003 23:52:12 -0500 Received: by zin01exm01.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Mon, 18 Aug 2003 10:22:22 +0530 Message-ID: From: Nagarajan Ananth-Q3241C To: Loa Andersson , l2vpn@ietf.org Cc: Vach Kompella , Rick Wilder Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc? Date: Mon, 18 Aug 2003 10:22:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This document is a good start. I support it being made a WG doc. -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Friday, August 15, 2003 3:49 AM To: l2vpn@ietf.org Cc: Vach Kompella; Rick Wilder Subject: draft-shah-ppvpn-IPLS-02.txt for working group doc? Working Group, we have a request to make the "IP-Only LAN Service (IPLS)" a working group document. This work is within the working group charter, and we would like to have your view, pros or cons, whether this document is what we should base the IPLS solution on. Again a case where you need to speak up, silence won't be interpreted one why or the other. Please send your response to the list. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Mon Aug 18 06:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15028 for ; Mon, 18 Aug 2003 06:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohE8-0000KA-BA for l2vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 06:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IAR4KK001242 for l2vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 06:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohE8-0000Jx-2j for l2vpn-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 06:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15003 for ; Mon, 18 Aug 2003 06:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ohE4-0006Fz-00 for l2vpn-web-archive@ietf.org; Mon, 18 Aug 2003 06:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ohE3-0006Fw-00 for l2vpn-web-archive@ietf.org; Mon, 18 Aug 2003 06:26:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohE4-0000JM-Tl; Mon, 18 Aug 2003 06:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohDM-0000I2-9s for l2vpn@optimus.ietf.org; Mon, 18 Aug 2003 06:26:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14994 for ; Mon, 18 Aug 2003 06:26:10 -0400 (EDT) From: jeremy.de_clercq@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ohDI-0006Fn-00 for l2vpn@ietf.org; Mon, 18 Aug 2003 06:26:12 -0400 Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19ohDH-0006FZ-00 for l2vpn@ietf.org; Mon, 18 Aug 2003 06:26:11 -0400 Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h7IAl90N012027; Mon, 18 Aug 2003 12:47:09 +0200 Received: from alcatel.be ([138.203.67.106]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003081812252814:2715 ; Mon, 18 Aug 2003 12:25:28 +0200 Message-ID: <3F40A997.756EE2E2@alcatel.be> Date: Mon, 18 Aug 2003 12:25:27 +0200 Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Moshe.Aharon@ecitele.com CC: l2vpn@ietf.org Subject: Re: Where did the QoS Framework go?... References: X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/18/2003 12:25:28, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/18/2003 12:25:29, Serialize complete at 08/18/2003 12:25:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Moshe, as VPN QoS is currently not in any of the VPN WG charters, it is not related to any WG right now.. When the WGs will have finished their ongoing tasks, we hope that a re-chartering will include QoS issues. It will then most probably be related to both the L2VPN and L3VPN WG. Jeremy. Moshe.Aharon@ecitele.com wrote: > > Hi, > > Does anyone know to which WG the VPN QoS Framework is related? > > Thanks, > /Moshe -- +===========================================================+ | Jeremy De Clercq | | Alcatel | | Francis Wellesplein 1 phone: +32 (0)3 240 4752 | | B-2018 Antwerpen fax: +32 (0)3 240 4886 | | Belgium jeremy.de_clercq@alcatel.be | +===========================================================+ From exim@www1.ietf.org Wed Aug 20 10:23:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11208 for ; Wed, 20 Aug 2003 10:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pTre-0006jd-OE for l2vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 10:23:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KEN6fS025883 for l2vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 10:23:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pTre-0006jO-IJ for l2vpn-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 10:23:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11205 for ; Wed, 20 Aug 2003 10:22:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pTrc-0001Ik-00 for l2vpn-web-archive@ietf.org; Wed, 20 Aug 2003 10:23:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pTrb-0001Ig-00 for l2vpn-web-archive@ietf.org; Wed, 20 Aug 2003 10:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pTrY-0006iq-U0; Wed, 20 Aug 2003 10:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pTrL-0006ib-RY for l2vpn@optimus.ietf.org; Wed, 20 Aug 2003 10:22:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11197 for ; Wed, 20 Aug 2003 10:22:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pTrJ-0001IS-00 for l2vpn@ietf.org; Wed, 20 Aug 2003 10:22:45 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19pTrI-0001IF-00 for l2vpn@ietf.org; Wed, 20 Aug 2003 10:22:45 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7KEM4a22235; Wed, 20 Aug 2003 10:22:04 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Aug 2003 10:22:05 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Loa Andersson , l2vpn@ietf.org Cc: Vach Kompella , Rick Wilder Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc? Date: Wed, 20 Aug 2003 10:22:04 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Loa, Looks to me the document is a good starting point for IPLS work. It should be a working group document. Hamid. > > > Working Group, > > we have a request to make the "IP-Only LAN Service (IPLS)" > a working group document. > > This work is within the working group charter, and we > would like to have your view, pros or cons, whether this > document is what we should base the IPLS solution on. > > Again a case where you need to speak up, silence won't > be interpreted one why or the other. > > Please send your response to the list. > > /Loa > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > > > From exim@www1.ietf.org Wed Aug 20 11:29:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14310 for ; Wed, 20 Aug 2003 11:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUtT-0001N5-W5 for l2vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 11:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFT30W005265 for l2vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 11:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUtT-0001Mq-NG for l2vpn-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:29:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14263 for ; Wed, 20 Aug 2003 11:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUtS-00023z-00 for l2vpn-web-archive@ietf.org; Wed, 20 Aug 2003 11:29:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pUtR-00023u-00 for l2vpn-web-archive@ietf.org; Wed, 20 Aug 2003 11:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUtQ-0001Lr-IS; Wed, 20 Aug 2003 11:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUtM-0001LD-Hp for l2vpn@optimus.ietf.org; Wed, 20 Aug 2003 11:28:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14248 for ; Wed, 20 Aug 2003 11:28:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUtL-00023a-00 for l2vpn@ietf.org; Wed, 20 Aug 2003 11:28:55 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19pUtK-000231-00 for l2vpn@ietf.org; Wed, 20 Aug 2003 11:28:54 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7KFPls8007079; Wed, 20 Aug 2003 17:26:04 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Aug 2003 17:28:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc? Date: Wed, 20 Aug 2003 16:28:19 +0100 Message-ID: Thread-Topic: draft-shah-ppvpn-IPLS-02.txt for working group doc? Thread-Index: AcNisoVQsHo8fok+Rsyp0ZXw2xDtNQEecEeg From: "Francois Le Faucheur (flefauch)" To: "Loa Andersson" , Cc: "Vach Kompella" , "Rick Wilder" , "Francois Le Faucheur (flefauch)" X-OriginalArrivalTime: 20 Aug 2003 15:28:20.0024 (UTC) FILETIME=[AF64AB80:01C3672F] Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Loa, I support this document becoming a WG document. Francois =20 >> Again a case where you need to speak up, silence won't >> be interpreted one why or the other. This is in case the above applies also to co-authors of the document. From exim@www1.ietf.org Wed Aug 20 12:04:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17200 for ; Wed, 20 Aug 2003 12:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVRN-0004Vm-23 for l2vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 12:04:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KG45PF017342 for l2vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 12:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVRM-0004Vd-Ru for l2vpn-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 12:04:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17181 for ; Wed, 20 Aug 2003 12:03:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVRL-0002uQ-00 for l2vpn-web-archive@ietf.org; Wed, 20 Aug 2003 12:04:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pVRL-0002uN-00 for l2vpn-web-archive@ietf.org; Wed, 20 Aug 2003 12:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVRJ-0004Us-OD; Wed, 20 Aug 2003 12:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVR5-0004U1-Ly for l2vpn@optimus.ietf.org; Wed, 20 Aug 2003 12:03:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17164 for ; Wed, 20 Aug 2003 12:03:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVR4-0002tn-00 for l2vpn@ietf.org; Wed, 20 Aug 2003 12:03:46 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19pVQz-0002su-00 for l2vpn@ietf.org; Wed, 20 Aug 2003 12:03:41 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7KFhga01803; Wed, 20 Aug 2003 11:43:42 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Aug 2003 11:43:41 -0400 Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6E09@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Francois Le Faucheur (flefauch)'" , Loa Andersson , l2vpn@ietf.org Cc: Vach Kompella , Rick Wilder Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc? Date: Wed, 20 Aug 2003 11:43:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36731.C51D9BBA" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36731.C51D9BBA Content-Type: text/plain Loa, I support this document to be a WG document. Vasile -----Original Message----- From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: Wednesday, August 20, 2003 11:28 AM To: Loa Andersson; l2vpn@ietf.org Cc: Vach Kompella; Rick Wilder; Francois Le Faucheur (flefauch) Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc? Hello Loa, I support this document becoming a WG document. Francois >> Again a case where you need to speak up, silence won't >> be interpreted one why or the other. This is in case the above applies also to co-authors of the document. ------_=_NextPart_001_01C36731.C51D9BBA Content-Type: text/html RE: draft-shah-ppvpn-IPLS-02.txt for working group doc?

Loa,

  I support this document to be a WG document.

Vasile

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
Sent: Wednesday, August 20, 2003 11:28 AM
To: Loa Andersson; l2vpn@ietf.org
Cc: Vach Kompella; Rick Wilder; Francois Le Faucheur (flefauch)
Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc?


Hello Loa,

I support this document becoming a WG document.

Francois
 

>> Again a case where you need to speak up, silence won't
>> be interpreted one why or the other.

This is in case the above applies also to co-authors of the document.

------_=_NextPart_001_01C36731.C51D9BBA-- From exim@www1.ietf.org Sun Aug 24 02:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24086 for ; Sun, 24 Aug 2003 02:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qoKI-00043y-FM for l2vpn-archive@odin.ietf.org; Sun, 24 Aug 2003 02:26:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7O6QA8J015612 for l2vpn-archive@odin.ietf.org; Sun, 24 Aug 2003 02:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qoKH-00043j-My for l2vpn-web-archive@optimus.ietf.org; Sun, 24 Aug 2003 02:26:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24065 for ; Sun, 24 Aug 2003 02:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qoKE-0002g1-00 for l2vpn-web-archive@ietf.org; Sun, 24 Aug 2003 02:26:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qoKD-0002fx-00 for l2vpn-web-archive@ietf.org; Sun, 24 Aug 2003 02:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qoKA-000432-Ti; Sun, 24 Aug 2003 02:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qoJh-00041S-Us for l2vpn@optimus.ietf.org; Sun, 24 Aug 2003 02:25:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24051 for ; Sun, 24 Aug 2003 02:25:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qoJe-0002fm-00 for l2vpn@ietf.org; Sun, 24 Aug 2003 02:25:30 -0400 Received: from law12-oe65.law12.hotmail.com ([64.4.18.200] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19qoJd-0002fg-00 for l2vpn@ietf.org; Sun, 24 Aug 2003 02:25:29 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Aug 2003 23:25:00 -0700 Received: from 218.244.36.158 by law12-oe65.adinternal.hotmail.com with DAV; Sun, 24 Aug 2003 06:24:59 +0000 X-Originating-IP: [218.244.36.158] X-Originating-Email: [zhangle23@hotmail.com] From: "zhangle" To: "Luca Martini" , Cc: Subject: questions of L2VPN Date: Sun, 24 Aug 2003 14:22:33 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C36A4B.28C20040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 24 Aug 2003 06:25:00.0018 (UTC) FILETIME=[71ED8520:01C36A08] Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C36A4B.28C20040 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 DQpJIGhhdmUgZ290IHRoZSBmb2xsb3dpbmcgZHJhZnRzOg0KICAgIGRyYWZ0LWlldGYtcHdlMy1j b250cm9sLXByb3RvY29sLTAzLnR4dCwgICAgZHJhZnQtaWV0Zi1wd2UzLWV0aGVybmV0LWVuY2Fw LTAzLnR4dA0KYW5kIGRyYWZ0LW1hcnRpbmktbDJjaXJjdWl0LXRyYW5zLW1wbHMtMTEudHh0LCAg ZHJhZnQtbWFydGluaS1sMmNpcmN1aXQtZW5jYXAtbXBscy0wNS50eHQNCg0KYnV0IHRoZSBkcmFm dHMgc2VlbXMgdG8gYmUgY29uZmxpY3RlZC4NCg0Kd2hlbiBJIGNyZWF0ZSBhIEwyVlBOIHVzaW5n IExEUCwgTWF5IEkgY2hhbmdlIHRoZSBMMiBmcmFtZSBoZWFkZXIgb24gdGhlIGluZ3Jlc3M/DQp0 aGVyZSBpcyBzb21lIGRlc2NyaWJ0aW9uIGJlbG93Og0KDQppbiBkcmFmdC1tYXJ0aW5pLWwyY2ly Y3VpdC10cmFucy1tcGxzLTExLnR4dCx3cm90ZToNCg0KMy4gVHVubmVsIExhYmVscyBhbmQgVkMg TGFiZWxzIA0KICAgLi4uVGhlIHRyYW5zcG9ydGVkIGZyYW1lIE1BWSBiZSBtb2RpZmllZCB3aGVu IGl0IHJlYWNoZXMgdGhlIGVncmVzcyByb3V0ZXIuDQogICBJZiB0aGUgaGVhZGVyIG9mIHRoZSB0 cmFuc3BvcnRlZCBsYXllciAyIGZyYW1lIGlzIG1vZGlmaWVkLCB0aGlzIE1VU1QNCiAgIGJlIGRv bmUgYXQgdGhlIGVncmVzcyBMU1Igb25seS4NCg0KYnV0IGluIGRyYWZ0LWlldGYtcHdlMy1jb250 cm9sLXByb3RvY29sLTAzLnR4dDoNCjUuNC4gSW50ZXJmYWNlIFBhcmFtZXRlcnMgRmllbGQNCi4u Lg0KLSBSZXF1ZXN0ZWQgVkxBTiBJRC4NCg0KICAgICAgIEFuIE9wdGlvbmFsIDE2IGJpdCB2YWx1 ZSBpbmRpY2F0aW5nIHRoZSByZXF1ZXN0ZWQgVkxBTiBJRC4gVGhpcw0KICAgICAgIHBhcmFtZXRl ciBNQVkgYmUgdXNlZCBieSBhbiBQRSB0aGF0IGlzIGluY2FwYWJsZSBvZiByZXdyaXRpbmcgdGhl DQogICAgICAgODAyLjFRIGV0aGVybmV0IFZMQU4gdGFnIG9uIG91dHB1dC4gSWYgdGhlIGluZ3Jl c3MgUEUgcmVjZWl2ZXMNCiAgICAgICB0aGlzIHJlcXVlc3QgaXQgTUFZIHJld3JpdGUgdGhlIFZM QU4gSUQgdGFnIGluIGlucHV0IHRvIG1hdGNoIHRoZQ0KICAgICAgIHJlcXVlc3RlZCBWTEFOIElE LiBJZiB0aGlzIGlzIG5vdCBwb3NzaWJsZSwgYW5kIHRoZSBWTEFOIElEIGRvZXMNCiAgICAgICBu b3QgYWxyZWFkeSBtYXRjaCBjb25maWd1cmVkIGluZ3Jlc3MgVkxBTiBJRCB0aGUgUFcgc2hvdWxk IG5vdCBiZQ0KICAgICAgIGVuYWJsZWQuVGhpcyBwYXJhbWV0ZXIgaXMgYXBwbGljYWJsZSBvbmx5 IHRvIFBXIHR5cGUgNC4NCg0KYW5kIGluIGRyYWZ0LWlldGYtcHdlMy1ldGhlcm5ldC1lbmNhcC0w My50eHQ6DQozLjEuMi4gUmF3IE1vZGUgdnMuIFRhZ2dlZCBNb2RlDQouLi4NCklmIGFuIGV0aGVy bmV0IFBXIGlzIG9wZXJhdGluZyBpbiByYXcgbW9kZSwgc2VydmljZS1kZWxpbWl0aW5nIHRhZ3MN CiAgIGFyZSBORVZFUiBzZW50IG92ZXIgdGhlIFBXLiAgSWYgYSBzZXJ2aWNlLWRlbGltaXRpbmcg dGFnIGlzIHByZXNlbnQNCiAgIHdoZW4gdGhlIGZyYW1lIGlzIHJlY2VpdmVkIGZyb20gdGhlIENF IGJ5IHRoZSBQRSwgaXQgTVVTVCBiZSBzdHJpcHBlZA0KICAgKGJ5IHRoZSBOU1ApIGZyb20gdGhl IGZyYW1lIGJlZm9yZSB0aGUgZnJhbWUgaXMgc2VudCB0byB0aGUgUFcuDQoNCiAgIElmIGFuIGV0 aGVybmV0IFBXIGlzIG9wZXJhdGluZyBpbiB0YWdnZWQgbW9kZSwgZXZlcnkgZnJhbWUgc2VudCBv bg0KICAgdGhlIFBXIE1VU1QgaGF2ZSBhIHNlcnZpY2UtZGVsaW1pdGluZyBWTEFOIHRhZy4gIElm IHRoZSBmcmFtZSBhcw0KICAgcmVjZWl2ZWQgYnkgdGhlIFBFIGZyb20gdGhlIENFIGRvZXMgbm90 IGhhdmUgYSBzZXJ2aWNlLWRlbGltaXRpbmcNCiAgIFZMQU4gdGFnLCB0aGUgUEUgbXVzdCBwcmVw ZW5kIHRoZSBmcmFtZSB3aXRoIGEgZHVtbXkgVkxBTiB0YWcgYmVmb3JlDQogICBzZW5kaW5nIHRo ZSBmcmFtZSBvbiB0aGUgUFcuDQogICANCg0K ------=_NextPart_000_001B_01C36A4B.28C20040 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdp bmRvd3MtMTI1MiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNS4wMC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+SSBoYXZlIGdvdCB0aGUgZm9sbG93aW5nIGRyYWZ0czo8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KZHJhZnQtaWV0Zi1wd2UzLWNvbnRyb2wtcHJvdG9jb2wtMDMudHh0LCZuYnNwOyZu YnNwOyZuYnNwOyANCmRyYWZ0LWlldGYtcHdlMy1ldGhlcm5ldC1lbmNhcC0wMy50eHQ8QlI+YW5k IA0KZHJhZnQtbWFydGluaS1sMmNpcmN1aXQtdHJhbnMtbXBscy0xMS50eHQsJm5ic3A7IA0KZHJh ZnQtbWFydGluaS1sMmNpcmN1aXQtZW5jYXAtbXBscy0wNS50eHQ8QlI+PEJSPmJ1dCB0aGUgZHJh ZnRzIHNlZW1zIHRvIGJlIA0KY29uZmxpY3RlZC48QlI+PEJSPndoZW4gSSBjcmVhdGUgYSBMMlZQ TiB1c2luZyBMRFAsIE1heSBJIGNoYW5nZSB0aGUgTDIgZnJhbWUgDQpoZWFkZXIgb24gdGhlIGlu Z3Jlc3M/PEJSPnRoZXJlIGlzIHNvbWUgZGVzY3JpYnRpb24gYmVsb3c6PEJSPjxCUj5pbiANCmRy YWZ0LW1hcnRpbmktbDJjaXJjdWl0LXRyYW5zLW1wbHMtMTEudHh0LHdyb3RlOjxCUj48QlI+My4g VHVubmVsIExhYmVscyBhbmQgVkMgDQpMYWJlbHMgPEJSPiZuYnNwOyZuYnNwOyAuLi5UaGUgdHJh bnNwb3J0ZWQgZnJhbWUgTUFZIGJlIG1vZGlmaWVkIHdoZW4gaXQgcmVhY2hlcyANCnRoZSBlZ3Jl c3Mgcm91dGVyLjxCUj4mbmJzcDsmbmJzcDsgSWYgdGhlIGhlYWRlciBvZiB0aGUgdHJhbnNwb3J0 ZWQgbGF5ZXIgMiANCmZyYW1lIGlzIG1vZGlmaWVkLCB0aGlzIE1VU1Q8QlI+Jm5ic3A7Jm5ic3A7 IGJlIGRvbmUgYXQgdGhlIGVncmVzcyBMU1IgDQpvbmx5LjxCUj48QlI+YnV0IGluIGRyYWZ0LWll dGYtcHdlMy1jb250cm9sLXByb3RvY29sLTAzLnR4dDo8QlI+NS40LiBJbnRlcmZhY2UgDQpQYXJh bWV0ZXJzIEZpZWxkPEJSPi4uLjxCUj4tIFJlcXVlc3RlZCBWTEFOIA0KSUQuPEJSPjxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW4gT3B0aW9uYWwgMTYgYml0IHZhbHVl IA0KaW5kaWNhdGluZyB0aGUgcmVxdWVzdGVkIFZMQU4gSUQuIFRoaXM8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGFyYW1ldGVyIE1BWSBiZSB1c2VkIGJ5IGFuIFBF IHRoYXQgaXMgaW5jYXBhYmxlIG9mIHJld3JpdGluZyANCnRoZTxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgODAyLjFRIGV0aGVybmV0IFZMQU4gdGFnIG9uIG91dHB1dC4g DQpJZiB0aGUgaW5ncmVzcyBQRSByZWNlaXZlczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhpcyByZXF1ZXN0IA0KaXQgTUFZIHJld3JpdGUgdGhlIFZMQU4gSUQgdGFn IGluIGlucHV0IHRvIG1hdGNoIA0KdGhlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyByZXF1ZXN0ZWQgVkxBTiBJRC4gSWYgdGhpcyBpcyBub3QgDQpwb3NzaWJsZSwgYW5k IHRoZSBWTEFOIElEIGRvZXM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5vdCANCmFscmVhZHkgbWF0Y2ggY29uZmlndXJlZCBpbmdyZXNzIFZMQU4gSUQgdGhlIFBXIHNo b3VsZCBub3QgDQpiZTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5h YmxlZC5UaGlzIHBhcmFtZXRlciBpcyBhcHBsaWNhYmxlIA0Kb25seSB0byBQVyB0eXBlIDQuPEJS PjxCUj5hbmQgaW4gDQpkcmFmdC1pZXRmLXB3ZTMtZXRoZXJuZXQtZW5jYXAtMDMudHh0OjxCUj4z LjEuMi4gUmF3IE1vZGUgdnMuIFRhZ2dlZCANCk1vZGU8QlI+Li4uPEJSPklmIGFuIGV0aGVybmV0 IFBXIGlzIG9wZXJhdGluZyBpbiByYXcgbW9kZSwgc2VydmljZS1kZWxpbWl0aW5nIA0KdGFnczxC Uj4mbmJzcDsmbmJzcDsgYXJlIE5FVkVSIHNlbnQgb3ZlciB0aGUgUFcuJm5ic3A7IElmIGEgc2Vy dmljZS1kZWxpbWl0aW5nIA0KdGFnIGlzIHByZXNlbnQ8QlI+Jm5ic3A7Jm5ic3A7IHdoZW4gdGhl IGZyYW1lIGlzIHJlY2VpdmVkIGZyb20gdGhlIENFIGJ5IHRoZSBQRSwgDQppdCBNVVNUIGJlIHN0 cmlwcGVkPEJSPiZuYnNwOyZuYnNwOyAoYnkgdGhlIE5TUCkgZnJvbSB0aGUgZnJhbWUgYmVmb3Jl IHRoZSBmcmFtZSANCmlzIHNlbnQgdG8gdGhlIFBXLjxCUj48QlI+Jm5ic3A7Jm5ic3A7IElmIGFu IGV0aGVybmV0IFBXIGlzIG9wZXJhdGluZyBpbiB0YWdnZWQgDQptb2RlLCBldmVyeSBmcmFtZSBz ZW50IG9uPEJSPiZuYnNwOyZuYnNwOyB0aGUgUFcgTVVTVCBoYXZlIGEgc2VydmljZS1kZWxpbWl0 aW5nIA0KVkxBTiB0YWcuJm5ic3A7IElmIHRoZSBmcmFtZSBhczxCUj4mbmJzcDsmbmJzcDsgcmVj ZWl2ZWQgYnkgdGhlIFBFIGZyb20gdGhlIENFIA0KZG9lcyBub3QgaGF2ZSBhIHNlcnZpY2UtZGVs aW1pdGluZzxCUj4mbmJzcDsmbmJzcDsgVkxBTiB0YWcsIHRoZSBQRSBtdXN0IHByZXBlbmQgDQp0 aGUgZnJhbWUgd2l0aCBhIGR1bW15IFZMQU4gdGFnIGJlZm9yZTxCUj4mbmJzcDsmbmJzcDsgc2Vu ZGluZyB0aGUgZnJhbWUgb24gdGhlIA0KUFcuPEJSPiZuYnNwOyZuYnNwOyA8QlI+PC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_001B_01C36A4B.28C20040-- From exim@www1.ietf.org Wed Aug 27 04:01:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03827 for ; Wed, 27 Aug 2003 04:01:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rthY-0002ny-78 for l2vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 02:22:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6McBh010748 for l2vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 02:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rruD-0003Rr-AK for l2vpn-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 00:27:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18349 for ; Wed, 27 Aug 2003 00:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rruA-0003uP-00 for l2vpn-web-archive@ietf.org; Wed, 27 Aug 2003 00:27:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rruA-0003uL-00 for l2vpn-web-archive@ietf.org; Wed, 27 Aug 2003 00:27:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmfh-0004il-3k; Tue, 26 Aug 2003 18:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rai7-00060k-PG for l2vpn@optimus.ietf.org; Tue, 26 Aug 2003 06:06:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26237 for ; Tue, 26 Aug 2003 06:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rai4-0006lP-00 for l2vpn@ietf.org; Tue, 26 Aug 2003 06:05:56 -0400 Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 19rai2-0006l7-00 for l2vpn@ietf.org; Tue, 26 Aug 2003 06:05:55 -0400 Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Tue, 26 Aug 2003 13:07:10 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 12:59:47 +0200 Message-ID: From: Sasha Vainshtein To: "'Loa Andersson'" Cc: Vach Kompella , Rick Wilder , l2vpn@ietf.org Subject: RE: draft-shah-ppvpn-IPLS-02.txt for working group doc? Date: Tue, 26 Aug 2003 12:59:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Loa and all, Sorry for a late response. I support this draft to become a WG document. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Friday, August 15, 2003 12:19 AM > To: l2vpn@ietf.org > Cc: Vach Kompella; Rick Wilder > Subject: draft-shah-ppvpn-IPLS-02.txt for working group doc? > > > Working Group, > > we have a request to make the "IP-Only LAN Service (IPLS)" > a working group document. > > This work is within the working group charter, and we > would like to have your view, pros or cons, whether this > document is what we should base the IPLS solution on. > > Again a case where you need to speak up, silence won't > be interpreted one why or the other. > > Please send your response to the list. > > /Loa > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > >