From mailnull@www1.ietf.org Fri May 23 23:06:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05251 for ; Fri, 23 May 2003 23:06:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4O366m22842 for l2vpn-archive@odin.ietf.org; Fri, 23 May 2003 23:06:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O364B22838 for ; Fri, 23 May 2003 23: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 XAA05247 for ; Fri, 23 May 2003 23:05:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JPKf-00053I-00 for l2vpn-web-archive@ietf.org; Fri, 23 May 2003 23:04:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JPKf-00053E-00 for l2vpn-web-archive@ietf.org; Fri, 23 May 2003 23:04:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O363B22834; Fri, 23 May 2003 23:06:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O35CB22809 for ; Fri, 23 May 2003 23:05: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 XAA05188 for ; Fri, 23 May 2003 23:05:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JPJp-00051m-00 for l2vpn@ietf.org; Fri, 23 May 2003 23:03:37 -0400 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 19JPJo-00051i-00 for l2vpn@ietf.org; Fri, 23 May 2003 23:03:36 -0400 Received: from adsl-63-201-33-143.dsl.snfc21.pacbell.net (HELO laptopmark) (m?seery@63.201.33.143 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 May 2003 03:05:02 -0000 From: "Mark Seery" To: "Alex Zinin" Cc: , Subject: RE: Draft charter for L2VPN: Perfect LAN emulation Date: Fri, 23 May 2003 20:04:40 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1561049532698.20030523162312@psg.com> Importance: Normal 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, Perhaps not emulation, but I think a definition of "LAN" might be useful. i.e. a broadcast/multicast segment, the interconnection of emulated bridges, a single virtual bridge, etc. Or if that granularity of description is not desired by the group, then a statement to that effect. As to perfect, or imperfect I have not strong opinion, as long as people are comfortable that standars compliant Ethernet devices are able to attach to the service and use it. Mark -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Friday, May 23, 2003 4:23 PM To: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN: Perfect LAN emulation Reading the discussion between Matt, Eric, et al, it seems that we have two main questions at hand: 1. Should the charter define the level of transparency of the L2 VPN mechanisms to the higher-layer protocols, and if so, what should the required level be? 2. Should the charter say that the WG will work with IEEE 802.1 to ensure proper interworking. My reading of the discussion on the first item is that we don't have a strong case for spelling out that a perfect emulation is required. If anyone disagrees, please speak up. I didn't see a discussion on the second issue, but it seems like a reasonable proposal to me. Alex From mailnull@www1.ietf.org Tue May 27 08:44:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10197 for ; Tue, 27 May 2003 08:44:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RCi3c15571 for l2vpn-archive@odin.ietf.org; Tue, 27 May 2003 08:44:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RCi3B15568 for ; Tue, 27 May 2003 08:44: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 IAA10188 for ; Tue, 27 May 2003 08:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kdmc-0003xa-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 08:42:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Kdmc-0003xW-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 08:42:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RCi2B15554; Tue, 27 May 2003 08:44:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RCg5B15480 for ; Tue, 27 May 2003 08:42: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 IAA10142 for ; Tue, 27 May 2003 08:42:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kdki-0003wd-00 for l2vpn@ietf.org; Tue, 27 May 2003 08:40:29 -0400 Received: from mailg.telia.com ([194.22.194.26]) by ietf-mx with esmtp (Exim 4.12) id 19Kdkh-0003wZ-00 for l2vpn@ietf.org; Tue, 27 May 2003 08:40:28 -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 h4RCg0x3000343; Tue, 27 May 2003 14:42:00 +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 h4RCg0c17278; Tue, 27 May 2003 14:42:00 +0200 (CEST) Message-ID: <3ED35C24.3010707@pi.se> Date: Tue, 27 May 2003 14:37:56 +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: l2vpn@ietf.org CC: ppvpn@nortelnetworks.com Subject: Re: Single vs many solution(s) References: <200305201548.h4KFmlu16485@merlot.juniper.net> <1931049485390.20030523162225@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 All, since became co-chair of the ppvpn more or less over one single night, I still have some reading to do to get up to speed on the ppvpn side. However, I do have some opinions on e.g. "single vs. many" and where we should try to go. Some of them are "programatic", the type of position a wg chair will always need to take - until provoen wrong. Others are specific and realting to the discussion on the number of solutions for l2vpns in ietf. Programatic: 1. as a working group or as a standards organization it is our goal/task/duty to come up with one single standard per problem. 2. we need to recognize that there are several problems, and sometimes they look very similar, and that they may require very different solutions 3. not being able to agree on a single solution is not a failure, the standards organization don't make market decisions, at best it can be supportive. If we don't agree the market will decide. Specific: 1. so far I've seen multiple solutions aiming to solve the same problen, e.g. the vkompella vs. kkompella discussion 2. the thread so far has been interesting, e.g. Ross' dsicussion on situations where "we" have taken decisions to forward more than one solutions. Though I don't think Ross would like to go as far as to say that we should aim for multiple solutions and let the market decide 3. if it is true that we are trying to solve one single problem - and given that this problem needs to be more precisely stated - then I will as wg chair work for one singel standard coming out of the wg 4. if on the other hand it is possible to show that there are two separate problem that requires separate solutions I will try to promote solutions that addresses the problems 5. the discussion on this thread so far is a bit of disappointment, since it very much goes along the lines "my solution is better than yours", rather than "I think the solution should be differnet from what you propose, because ..." or "yes you have a solution that will work in the situation you describe, but there are further problems that needs to be address by differnt solutions" So until someone proven that that e.g. the kkompella and vkompella addresses different problems I will try to make the wg adopt only one. But I won't cry if we can't, we just send both of them "experimental" and revisit the question in a couple of years and promote one of them to PS (market decide). If we can clearly desccribe the two problems we are trying to solve, and it can be show that two solutions solves those two pa*roblems, then I'm fully prepared send multiple solutions to IESG and request they are made PS. Any volunteer to try describe the problem space(s)? I guess they same goes for the different discovery approaches. /Loa BTW - I suggest tht we start dropping copies to the ppvpn-list for anything that is not vpn generic. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From mailnull@www1.ietf.org Tue May 27 10:36:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14428 for ; Tue, 27 May 2003 10:36:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4REZic24023 for l2vpn-archive@odin.ietf.org; Tue, 27 May 2003 10:35:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4REZhB24020 for ; Tue, 27 May 2003 10:35:43 -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 KAA14408 for ; Tue, 27 May 2003 10:35:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KfWi-0004mA-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 10:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KfWh-0004m6-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 10:34:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4REZ4B23999; Tue, 27 May 2003 10:35:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4REYsB23970 for ; Tue, 27 May 2003 10:34:54 -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 KAA14360 for ; Tue, 27 May 2003 10:34:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KfVu-0004lw-00 for l2vpn@ietf.org; Tue, 27 May 2003 10:33:18 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19KfVt-0004lg-00 for l2vpn@ietf.org; Tue, 27 May 2003 10:33:17 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4REYKu15636; Tue, 27 May 2003 07:34:20 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200305271434.h4REYKu15636@merlot.juniper.net> To: l2vpn@ietf.org, ppvpn@nortelnetworks.com Subject: Re: Single vs many solution(s) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63283.1054046060.1@juniper.net> Date: Tue, 27 May 2003 07:34:20 -0700 From: Yakov Rekhter 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: , Folks, I think that the following message is quite relevant to the discussion. Yakov. ----------------------------------------------------------------- Date: Fri, 23 May 2003 10:04:39 EDT To: problem-statement@alvestrand.no From: Frank Kastenholz Subject: The One True Path To Nirvana Folks, I hate to inject a bit of reality into this but whether the IETF decides to bless one-and-only-one way to do FOO with the high-honor of "Standards Track RFC" or allows multiple ways is only marginally important. Vendors, being interested in making money, try to differentiate their products. The Offical IETF Mantra in this regard is that vendor differentiation arises out of things like quality. While true, it is not the complete truth. Vendors will also have with their own protocols as alternative ways to do FOO. The vendor's marketing people will then tout their proprietary FOO Protocol as "better" than the standard in various ways. The proprietary FOO Protocol might even be what the vendor tried to get made a standard but failed (and now there might be an installed base...) Second, customers (bless their checkbooks and capex budgets) sometimes what something that's not the standard. It could have been something that was a candidate for standardizing but didn't make it. It could be something that the customer came up with. It could be some set of requirements that the customer has (or thinks they have) that are not met with the standard, requiring some non-standard-FOO. Having multiple levels of standard really doesn't have any effect on what vendors do or what customers want. If the deltas from one level to the next are "just bugfixes" then that's how they are treated by vendors. If there are substantive changes in function (function-x is available in proposed std, but not in draft, or vice versa) then the implementation becomes the union of all standard-levels, with config switches and the like. In other words, the propose/draft/full hierarchy is little more than feel-good self-gratification on the part of The Process Experts. Btw, before I get roasted for heresy a) There are always exceptions where things happen differently. When the right things happen, it's like winning the lottery. Enjoy it, but don't count on it b) This is not a state of affairs that I find particularly desireable. It is a state of affairs that does exist, however, and pretending that it does not exist is foolish. So, the short answer is that multiple-competing-FOOs is a fact of life. We live with it. We deal with it. Whatever the IETF does, it will not go away. That said, what the IETF _can_ do is to make the problem easier to deal with by - getting the technical quality of things as high as we can as early as we can. That means -00 of the draft, if possible (yes, I know it won't happen, but the sooner, the better) - getting drafts and changes and RFCs through the system faster (without sacrificing quality). Ideally, -00 of the ID comes out 1 week after the first BOF and there are no changes made to it, ever. Frank Kastenholz This is all my personal opinion and does not have anything to do with what my employer says, thinks, does, etc. From mailnull@www1.ietf.org Tue May 27 11:17:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16359 for ; Tue, 27 May 2003 11:17:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RFH6U27700 for l2vpn-archive@odin.ietf.org; Tue, 27 May 2003 11:17:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFH5B27697 for ; Tue, 27 May 2003 11:17: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 LAA16319 for ; Tue, 27 May 2003 11:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgAk-0005Ir-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 11:15:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KgAk-0005Io-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 11:15:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFH4B27693; Tue, 27 May 2003 11:17:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFGDB27664 for ; Tue, 27 May 2003 11:16: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 LAA16279 for ; Tue, 27 May 2003 11:16:10 -0400 (EDT) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kg9u-0005IK-00 for l2vpn@ietf.org; Tue, 27 May 2003 11:14:38 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19Kg9t-0005Hl-00 for l2vpn@ietf.org; Tue, 27 May 2003 11:14:37 -0400 Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 27 May 2003 16:15:16 +0100 Message-ID: To: yakov@juniper.net, l2vpn@ietf.org, ppvpn@nortelnetworks.com Subject: RE: Single vs many solution(s) Date: Tue, 27 May 2003 16:15:01 +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: , Yakov I think the phrase "Vendors, being interested in making money" from the message below sums it up nicely;-) Perhaps standardisation and interoperability may only be "marginally important" to some large vendors that have the luxury of a large installed customer base, or to some providers where a non-standard feature is the only fix to a unique requirement. However, I would suggest that for large operators looking at the *possibility* of using MPLS as their next co pkt-sw core, standardisation and interoperability would be extremely important. The L2 MPLS VPN solutions are not just quick 'value add features' (which I think some people seem to perceive them to be, due to the fact that they can be deployed using existing networks and protocols with minimal changes). L2 MPLS VPNs offer operators the *potential* to migrate existing co pkt-sw services (i.e. ATM, Frame Relay) onto a single platform that one might expect to be around for another 20 years or so to justify its investment. I would suggest that proper standardisation (especially at the architectural level) is a prerequisite for protecting this investment. Richard > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: 27 May 2003 15:34 > To: l2vpn@ietf.org; ppvpn@nortelnetworks.com > Subject: Re: Single vs many solution(s) > > > Folks, > > I think that the following message is quite relevant to the > discussion. > > Yakov. > ----------------------------------------------------------------- > Date: Fri, 23 May 2003 10:04:39 EDT > To: problem-statement@alvestrand.no > From: Frank Kastenholz > Subject: The One True Path To Nirvana > > Folks, > I hate to inject a bit of reality into this but > whether the IETF decides to bless one-and-only-one > way to do FOO with the high-honor of "Standards Track > RFC" or allows multiple ways is only marginally > important. > > Vendors, being interested in making money, try to > differentiate their products. The Offical IETF > Mantra in this regard is that vendor differentiation > arises out of things like quality. While true, it is not > the complete truth. Vendors will also have with their > own protocols as alternative ways to do FOO. The vendor's > marketing people will then tout their proprietary FOO > Protocol as "better" than the standard in various ways. > The proprietary FOO Protocol might even be what the > vendor tried to get made a standard but failed (and > now there might be an installed base...) > > Second, customers (bless their checkbooks and capex budgets) > sometimes what something that's not the standard. It could > have been something that was a candidate for standardizing > but didn't make it. It could be something that the customer > came up with. It could be some set of requirements that > the customer has (or thinks they have) that are not met > with the standard, requiring some non-standard-FOO. > > Having multiple levels of standard really doesn't have > any effect on what vendors do or what customers want. > If the deltas from one level to the next are "just > bugfixes" then that's how they are treated by vendors. > If there are substantive changes in function (function-x > is available in proposed std, but not in draft, or vice > versa) then the implementation becomes the union of all > standard-levels, with config switches and the like. In other > words, the propose/draft/full hierarchy is little more than > feel-good self-gratification on the part of The Process Experts. > > Btw, before I get roasted for heresy > a) There are always exceptions where things happen > differently. When the right things happen, it's > like winning the lottery. Enjoy it, but don't count > on it > b) This is not a state of affairs that I find particularly > desireable. It is a state of affairs that does exist, > however, and pretending that it does not exist is foolish. > > So, the short answer is that multiple-competing-FOOs is > a fact of life. We live with it. We deal with it. Whatever > the IETF does, it will not go away. > > That said, what the IETF _can_ do is to make the problem > easier to deal with by > - getting the technical quality of things as high as we > can as early as we can. That means -00 of the draft, > if possible (yes, I know it won't happen, but the sooner, > the better) > - getting drafts and changes and RFCs through the system > faster (without sacrificing quality). > Ideally, -00 of the ID comes out 1 week after the first BOF > and there are no changes made to it, ever. > > > > Frank Kastenholz > > This is all my personal opinion and does not have anything to do > with what my employer says, thinks, does, etc. > > From mailnull@www1.ietf.org Tue May 27 11:24:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16665 for ; Tue, 27 May 2003 11:24:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RFO2m28002 for l2vpn-archive@odin.ietf.org; Tue, 27 May 2003 11:24:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFO2B27999 for ; Tue, 27 May 2003 11: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 LAA16643 for ; Tue, 27 May 2003 11:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgHS-0005O9-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 11:22:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KgHS-0005O6-00 for l2vpn-web-archive@ietf.org; Tue, 27 May 2003 11:22:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFO0B27987; Tue, 27 May 2003 11:24:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFNAB27940 for ; Tue, 27 May 2003 11:23: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 LAA16590 for ; Tue, 27 May 2003 11:23:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgGd-0005NB-00 for l2vpn@ietf.org; Tue, 27 May 2003 11:21:35 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19KgGc-0005Mx-00 for l2vpn@ietf.org; Tue, 27 May 2003 11:21:34 -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 h4RFMZG08174; Tue, 27 May 2003 11:22:35 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 May 2003 11:22:36 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Loa Andersson , l2vpn@ietf.org Cc: ppvpn@nortelnetworks.com Subject: RE: Single vs many solution(s) Date: Tue, 27 May 2003 11:22:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32463.CC184C14" 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_01C32463.CC184C14 Content-Type: text/plain; charset="iso-8859-1" Loa, > > 1. so far I've seen multiple solutions aiming to solve the same > problen, e.g. the vkompella vs. kkompella discussion > ... > > So until someone proven that that e.g. the kkompella and vkompella > addresses different problems I will try to make the wg adopt only one. .... > > Any volunteer to try describe the problem space(s)? > I think since vkompella vs kkompella discussions (or more precisely kkompella discussions) we have been moving from one issue/topic to another not related to the drafts themselves and if I summarize the item we can list: a) Are there strong *technical* issues with kkompella proposal? There was a debate, the draft is now WG document so I assume the chairs and ADs concluded that there are no major technical issues stopping the WG to work on the proposal. So let's move on from that item. b) Should the WG work on more than one distinct solution for the same problem (problem == l2vpn service)? Given a) and adopting other drafts the answer is yes. In fact we also indirectly debated that since IPLS and VPLS provide the same "service", then a potential question is "Should the wg consider IPLS and VPLS as solving the same problem or different problems?" If it is the same problem should the wg focus only on VPLS (as a superset service)? or should the WG treat l2vpn services for IP host/routers-based CEs as different l2vpn services? c) Should the solutions all progress as PS or experimental? It looks to me it is premature to debate that item at this point in time. d) Do we need multiple mechanisms for the same problem? (e.g., Radius and BGP discovery)? In my view this question should be contrasted to the approach taken in solving the l2vpn problem and the requirements addressed in the solution. There are problems that are services and there are those that are mechanisms. Since we are working on a per-solution style, it is logical that protocol choices made in one solution may not be acceptable to others or will not meet the requirements for other solution. In that respect having multiple mechanisms (using multiple protocols) to be used in one or more solutions is a consequence of both the approach taken and the reality of ppvpn problem space -as being 'provider-centric technology/services' instead of being only 'protocol-centric' problem. Therefore I don't see the value of addressing this item (nothing wrong discussing the technical aspects though). e) Concerns on the use of BGP (routing protocol) for implementing VPN functions. Using BGP for implementing VPN functions is a valid approach and so far since l3vpns we know about the applicability of BGP-based mechanisms in the field more than any other mechanism. It looks to me Yakov's request to put clearly on the table the IESG concerns (if any) for this item is a reasonable request. That will allow the WG to debate the items that are really of concerns or need to be addressed and highlighted..and that will just improve the quality of wg outputs. > BTW - I suggest tht we start dropping copies to the ppvpn-list for > anything that is not vpn generic. > If I am not mistaken, I think the debate on l2vpn mailing list is on the charter only. Hamid. ------_=_NextPart_001_01C32463.CC184C14 Content-Type: text/html; charset="iso-8859-1" RE: Single vs many solution(s)

Loa,

>
> 1. so far I've seen multiple solutions aiming to solve the same
>     problen, e.g. the vkompella vs. kkompella discussion
>
<snip>...

>
> So until someone proven that that e.g. the kkompella and vkompella
> addresses different problems I will try to make the wg adopt only one.

<snip>....

>
> Any volunteer to try describe the problem space(s)?
>

I think since vkompella vs kkompella discussions (or more precisely
kkompella discussions) we have been moving from
one issue/topic to another not related to the drafts themselves and
if I summarize the item we can list:

a) Are there strong *technical* issues with kkompella proposal?

  There was a debate, the draft is now WG document so I assume
  the chairs and ADs concluded that there are no major technical issues
  stopping the WG to work on the proposal. So let's move on from
  that item.
 
b) Should the WG work on more than one distinct solution
   for the same problem (problem == l2vpn service)?

   Given a) and adopting other drafts the answer is yes.
   In fact we also indirectly debated that since IPLS and VPLS provide
   the same "service", then a potential question is

   "Should the wg consider IPLS and VPLS
   as solving the same problem or different problems?"

   If it is the same problem should the wg focus only on VPLS (as a
   superset service)? or should the WG treat l2vpn services
   for IP host/routers-based CEs as different l2vpn services?
 
c) Should the solutions all progress as PS or experimental?
  
   It looks to me it is premature to debate that item at this
   point in time.

d) Do we need multiple mechanisms for the same problem?
   (e.g., Radius and BGP discovery)?

   In my view this question should be contrasted to the approach taken
   in solving the l2vpn problem and the requirements
   addressed in the solution. There are problems that
   are services and there are those that are mechanisms.

   Since we are working on a per-solution style, it is logical that
   protocol choices made in one solution may not be acceptable to
   others or will not meet the requirements for other solution. In that
   respect having multiple mechanisms (using multiple protocols)
   to be used in one or more solutions is a consequence
   of both the approach taken and the reality of ppvpn problem space
   -as being 'provider-centric technology/services' instead of
   being only 'protocol-centric' problem. Therefore I don't
   see the value of addressing this item (nothing wrong
   discussing the technical aspects though).

e) Concerns on the use of BGP (routing protocol) for implementing
   VPN functions.

   Using BGP for implementing VPN functions is a valid approach
   and so far since l3vpns we know about the applicability of
   BGP-based mechanisms in the field more than any other mechanism.

   It looks to me Yakov's request to put clearly on the table
   the IESG concerns (if any) for this item is a reasonable request.
   That will allow the WG to debate the items that are really of
   concerns or need to be addressed and highlighted..and that will just
   improve the quality of wg outputs.

<snip>

> BTW - I suggest tht we start dropping copies to the ppvpn-list for
> anything that is not vpn generic.
>

If I am not mistaken, I think the debate on l2vpn mailing list is on
the charter only.

Hamid.

------_=_NextPart_001_01C32463.CC184C14-- From mailnull@www1.ietf.org Thu May 29 02:06:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14701 for ; Thu, 29 May 2003 02:06:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T65sW16180 for l2vpn-archive@odin.ietf.org; Thu, 29 May 2003 02:05:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T65sB16177 for ; Thu, 29 May 2003 02:05:54 -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 CAA14174 for ; Thu, 29 May 2003 02:05:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LGWK-0003PX-00 for l2vpn-web-archive@ietf.org; Thu, 29 May 2003 02:04:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LGWJ-0003PT-00 for l2vpn-web-archive@ietf.org; Thu, 29 May 2003 02:04:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T65EB15650; Thu, 29 May 2003 02:05:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T64jB13994 for ; Thu, 29 May 2003 02:04:45 -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 CAA13093 for ; Thu, 29 May 2003 02:04:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LGVD-0003P6-00 for l2vpn@ietf.org; Thu, 29 May 2003 02:03:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19LGVC-0003P2-00 for l2vpn@ietf.org; Thu, 29 May 2003 02:03:03 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LGWm-000Apb-00 for l2vpn@ietf.org; Thu, 29 May 2003 06:04:40 +0000 Date: Wed, 28 May 2003 23:00:24 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <33443925030.20030528230024@psg.com> To: l2vpn@ietf.org Subject: Re: Draft charter for L2VPN - IPLS & ARP Mediation In-Reply-To: <200305161353.h4GDrSkL001465@rtp-core-1.cisco.com> References: <200305161353.h4GDrSkL001465@rtp-core-1.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 OK, the IPLS approach seems interesting to me, but I'd like to gauge interest within the WG a bit more. Can I ask people interested in this to answer the following questions (on this list): 1. Do you support including IPLS in the charter? 2. Would you be able to actively help the WG with this work (by reviewing the documents, participating in discussions, providing your feedback, etc.)? 3. Do you believe that draft-shah-ppvpn-ipls-01.txt would be the right starting point for the WG to approach the IPLS subject? (positive answer would mean that the doc would become a WG item) Draft authors pre-counted :) Regarding ARP Mediation. It seems that that this topic is part of a bigger interworking problem. I think we could put this in the list of potential future topics, and revisit it when/if we're done with basic IPLS. Thanks Alex From mailnull@www1.ietf.org Thu May 29 11:52:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08104 for ; Thu, 29 May 2003 11:52:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TFpjF31467 for l2vpn-archive@odin.ietf.org; Thu, 29 May 2003 11:51:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFpjB31464 for ; Thu, 29 May 2003 11:51:45 -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 LAA08096 for ; Thu, 29 May 2003 11:51:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPfJ-0000De-00 for l2vpn-web-archive@ietf.org; Thu, 29 May 2003 11:50:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LPfJ-0000Db-00 for l2vpn-web-archive@ietf.org; Thu, 29 May 2003 11:50:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFpEB31430; Thu, 29 May 2003 11:51:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFo4B31343 for ; Thu, 29 May 2003 11:50: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 LAA07960 for ; Thu, 29 May 2003 11:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPdg-0000CJ-00 for l2vpn@ietf.org; Thu, 29 May 2003 11:48:24 -0400 Received: from ext.wavesmithnetworks.com ([64.3.160.50] helo=telluride.wavesmithnet.com) by ietf-mx with smtp (Exim 4.12) id 19LPdf-0000CC-00 for l2vpn@ietf.org; Thu, 29 May 2003 11:48:23 -0400 Received: from wavesmithnetworks.com ([10.172.0.132]) by telluride.wavesmithnet.com (NAVGW 2.5.2.9) with SMTP id M2003052911493101252 ; Thu, 29 May 2003 11:49:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Date: Thu, 29 May 2003 11:49:30 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB7202152633@WHISTLER.WaveSmithNet.com> Thread-Topic: Draft charter for L2VPN - IPLS & ARP Mediation Thread-Index: AcMlqEc5uPX+JUzfQhmrIqTjOqgh+QAT6Sdg From: "Himanshu Shah" To: "Alex Zinin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4TFo4B31344 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: 8bit Content-Transfer-Encoding: 8bit Hi Alex, There were several people (non-authors) who expressed their support on ppvpn mailing list to make IPLS (as well as arp-mediation) as the WG charter. Do they need to re-express their opinion? Also, I am not sure how many people have changed ppvpn subscription to l2vpn. Do you think it would be helpful if your message was also posted on ppvpn mailing list? regards, himanshu > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Thursday, May 29, 2003 2:00 AM > To: l2vpn@ietf.org > Subject: Re: Draft charter for L2VPN - IPLS & ARP Mediation > > > > OK, the IPLS approach seems interesting to me, but I'd like to gauge > interest within the WG a bit more. Can I ask people interested in this > to answer the following questions (on this list): > > 1. Do you support including IPLS in the charter? > > 2. Would you be able to actively help the WG with this work > (by reviewing the documents, participating in discussions, > providing your feedback, etc.)? > > 3. Do you believe that draft-shah-ppvpn-ipls-01.txt would be > the right starting point for the WG to approach the IPLS > subject? (positive answer would mean that the doc would > become a WG item) > > Draft authors pre-counted :) > > Regarding ARP Mediation. It seems that that this topic is part of a > bigger interworking problem. I think we could put this in the list of > potential future topics, and revisit it when/if we're done with > basic IPLS. > > Thanks > > Alex > > From mailnull@www1.ietf.org Thu May 29 12:12:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08642 for ; Thu, 29 May 2003 12:12:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TGBoi01154 for l2vpn-archive@odin.ietf.org; Thu, 29 May 2003 12:11:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGBoB01151 for ; Thu, 29 May 2003 12:11:50 -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 MAA08636 for ; Thu, 29 May 2003 12:11:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPyk-0000Nn-00 for l2vpn-web-archive@ietf.org; Thu, 29 May 2003 12:10:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LPyj-0000Nk-00 for l2vpn-web-archive@ietf.org; Thu, 29 May 2003 12:10:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGB2B01082; Thu, 29 May 2003 12:11:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TG49B32139 for ; Thu, 29 May 2003 12:04: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 MAA08394 for ; Thu, 29 May 2003 12:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPrJ-0000II-00 for l2vpn@ietf.org; Thu, 29 May 2003 12:02:29 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19LPrI-0000IF-00 for l2vpn@ietf.org; Thu, 29 May 2003 12:02:28 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LPsr-000AcG-00; Thu, 29 May 2003 16:04:05 +0000 Date: Thu, 29 May 2003 09:03:51 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <181480131873.20030529090351@psg.com> To: "Himanshu Shah" CC: l2vpn@ietf.org Subject: Re: Draft charter for L2VPN - IPLS & ARP Mediation In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB7202152633@WHISTLER.WaveSmithNet.com> References: <049AAFED91851244B9FF74D0D9D0EB7202152633@WHISTLER.WaveSmithNet.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 Himanshu, > There were several people (non-authors) who expressed their > support on ppvpn mailing list to make IPLS > (as well as arp-mediation) as the WG charter. > Do they need to re-express their opinion? They may but do not need to. > Also, I am not sure how many people have > changed ppvpn subscription to l2vpn. Do you think > it would be helpful if your message was also > posted on ppvpn mailing list? I don't think we should be having this discussion on PPVPN. However, I will send a message to the PPVPN list explicitly redirecting the thread to this mailing list. Thanks. Alex From mailnull@www1.ietf.org Fri May 30 14:50:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21281 for ; Fri, 30 May 2003 14:50:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UInvr27657 for l2vpn-archive@odin.ietf.org; Fri, 30 May 2003 14:49:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UInvB27654 for ; Fri, 30 May 2003 14:49: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 OAA21259 for ; Fri, 30 May 2003 14:49:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LovD-0007nM-00 for l2vpn-web-archive@ietf.org; Fri, 30 May 2003 14:48:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LovC-0007nI-00 for l2vpn-web-archive@ietf.org; Fri, 30 May 2003 14:48:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UIn5B27622; Fri, 30 May 2003 14:49:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UImJB27545 for ; Fri, 30 May 2003 14:48: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 OAA21198 for ; Fri, 30 May 2003 14:48:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lotd-0007mG-00 for l2vpn@ietf.org; Fri, 30 May 2003 14:46:33 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19Lotc-0007lk-00 for l2vpn@ietf.org; Fri, 30 May 2003 14:46:32 -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 h4UIlc316648; Fri, 30 May 2003 14:47:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 14:47:38 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , l2vpn@ietf.org Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Date: Fri, 30 May 2003 14:47:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326DB.F0F99E50" 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_01C326DB.F0F99E50 Content-Type: text/plain; charset="iso-8859-1" > OK, the IPLS approach seems interesting to me, but I'd like to gauge > interest within the WG a bit more. Can I ask people interested in this > to answer the following questions (on this list): > > 1. Do you support including IPLS in the charter? > > 2. Would you be able to actively help the WG with this work > (by reviewing the documents, participating in discussions, > providing your feedback, etc.)? > > 3. Do you believe that draft-shah-ppvpn-ipls-01.txt would be > the right starting point for the WG to approach the IPLS > subject? (positive answer would mean that the doc would > become a WG item) > > Draft authors pre-counted :) > > Regarding ARP Mediation. It seems that that this topic is part of a > bigger interworking problem. I think we could put this in the list of > potential future topics, and revisit it when/if we're done with > basic IPLS. My suggestion would be to capture day one in the charter that "IP-only l2vpn" services needs to be developed that includes IPLS and IP-only l2vpn interworking - instead of specifying IPLS now and l2vpn interworking later on. It is beneficial to address ip-only interworking while l2vpn requirements and framework drafts are being worked out (and not later on), particularly there has been some work already done on this topic. Hamid. ------_=_NextPart_001_01C326DB.F0F99E50 Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L2VPN - IPLS & ARP Mediation

> OK, the IPLS approach seems interesting to me, but I'd like to gauge
> interest within the WG a bit more. Can I ask people interested in this
> to answer the following questions (on this list):
>
>  1. Do you support including IPLS in the charter?
>
>  2. Would you be able to actively help the WG with this work
>     (by reviewing the documents, participating in discussions,
>     providing your feedback, etc.)?
>
>  3. Do you believe that draft-shah-ppvpn-ipls-01.txt would be
>     the right starting point for the WG to approach the IPLS
>     subject? (positive answer would mean that the doc would
>     become a WG item)
>
> Draft authors pre-counted :)
>
> Regarding ARP Mediation. It seems that that this topic is part of a
> bigger interworking problem. I think we could put this in the list of
> potential future topics, and revisit it when/if we're done with
> basic IPLS.

My suggestion would be to capture day one in the charter that
"IP-only l2vpn" services needs to be developed that includes IPLS and
IP-only l2vpn interworking -
instead of specifying IPLS now and l2vpn interworking later on.

It is beneficial to address ip-only interworking while
l2vpn requirements and framework drafts are being worked out
(and not later on), particularly there has been some work
already done on this topic.

Hamid.

------_=_NextPart_001_01C326DB.F0F99E50-- From mailnull@www1.ietf.org Fri May 30 15:49:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24970 for ; Fri, 30 May 2003 15:49:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UJmWi32205 for l2vpn-archive@odin.ietf.org; Fri, 30 May 2003 15:48:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJmWB32202 for ; Fri, 30 May 2003 15:48:32 -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 PAA24958 for ; Fri, 30 May 2003 15:48:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lppy-0000jH-00 for l2vpn-web-archive@ietf.org; Fri, 30 May 2003 15:46:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lppx-0000jE-00 for l2vpn-web-archive@ietf.org; Fri, 30 May 2003 15:46:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJm3B32183; Fri, 30 May 2003 15:48:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJlEB32124 for ; Fri, 30 May 2003 15:47: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 PAA24929 for ; Fri, 30 May 2003 15:47:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lpoi-0000iy-00 for l2vpn@ietf.org; Fri, 30 May 2003 15:45:32 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Lpoh-0000iv-00 for l2vpn@ietf.org; Fri, 30 May 2003 15:45:31 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LpqJ-000209-00 for l2vpn@ietf.org; Fri, 30 May 2003 19:47:11 +0000 Date: Fri, 30 May 2003 12:46:53 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <191579914613.20030530124653@psg.com> To: l2vpn@ietf.org Subject: Re: Draft charter for L2VPN: Perfect LAN emulation In-Reply-To: References: 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 Summarizing... > 1. Should the charter define the level of transparency of > the L2 VPN mechanisms to the higher-layer protocols, and > if so, what should the required level be? It seems that there is a feeling that some clarification of the VPLS definition should be provided in the charter, yet it should not preclude us from working on IPLS. I suggest the text of the charter be changed to read-- 1. Virtual Private LAN Service--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 LAN segment. --then leave any further details to requirement/framework/app-stmt documents, plus add a separate item to the list of std'ized solutions that would cover IPLS (provided we agree the WG should take it on.) >> 2. Should the charter say that the WG will work with IEEE 802.1 >> to ensure proper interworking. Hamid Ould-Brahim wrote: > Not sure what you mean by "interworking" here but if you > mean coordinate with ieee, the answer is yes. Now that I've seen the discussion on this, I think it is not clear to me either. I assumed proper interworking between standard Ethernet devices and the VPLS service, but I think I'll just put a line saying the WG will coordinate with IEEE 802.1 Alex