From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 05:39:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03588 for ; Thu, 1 May 2003 05:39:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h419edX12157 for ; Thu, 1 May 2003 05:40:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h419eZS20828 for ; Thu, 1 May 2003 05:40:35 -0400 (EDT) Date: Thu, 01 May 2003 18:38:03 +0900 (JST) Message-Id: <20030501.183803.97286099.suzuki.muneyoshi@lab.ntt.co.jp> To: mark@mseery.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <20030430154647.72161.qmail@web13504.mail.yahoo.com> References: <20030430.184013.130229373.suzuki.muneyoshi@lab.ntt.co.jp> <20030430154647.72161.qmail@web13504.mail.yahoo.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark, > For the purposes of what I was inquiry about I don't > think it makes difference - more interesting in the > spanning tree processing points you are interested in. > But, for the sake of argument lets assume it is a > VLAN-aware Bridge (I realize there are important > differnces based on installed based interoperability) > > Otherwise, is it 1982-style Bridge or VLAN-aware > > Bridge without the Bridge Protocol Entity? > > In these case, it is not > > much meaningful to > > distinguish 2) and 3). > I was assuming with the Bridge Protocol Entity, in > which case there would be a difference, I believe. In > 3) Spanning tree may influence routing within the > VPLS, whereas it would not in 2) and obviously not in > 1) Could you see the attached text that is the latter half of my reply to Norm. I think there are two xSTP related issues; loop prevention and cache clear due to customer topology change. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. ------ Anyway, in the following, how to process xSTP is discussed because most interests relate on it. (1) The SP must ensure a single tree topology in the SP network. Manual configuration, provider-STP, and provider-RSTP can support it without any difficulties. In this process, the SP don't care customer-xSTP, because it is the SP's responsibility to ensure a tree topology, thus it is determined under the SP's policy and control. It is a quite unrealistic scenario that the SP network topology is changed by the customer-xSTP. (2) It is customer responsibility to ensure a single tree topology in the customer network which consists of customer sites interconnected by the SP network and backdoor links. This is because, the customer can cause a loop whether the SP forwards customer-xSTP transparently or the SP provides per-customer xSTP instances. If the customer does no use xSTP, there is a possibility to cause a loop. (3) If the SP forwards customer-xSTP transparently, and if the customer use customer-xSTP, it can avoid a loop even if it pass through the SP network. This is because, the SP ensures a single tree topology and a single customer Bridge that supports customer-xSTP in a loop is sufficient to detect and cut the loop. (4) However, it is highly desired to detect a customer loop in the SP network. But, (a) detection is not limited xSTP, another technology can also detect a loop, (b) provider core Bridges don't need to support per-customer xSTP instances, because Provider Edge Bridges that support pre-customer xSTP instances are sufficient to detect and cut the loop, and (c) the full-mesh scheme also has completely the same issues. (5) And it is highly desired for the SP network to detect customer network topology change and clear the cache for the customer, if the customer use xSTP and is multihomed. In this case, provider Bridges need to snoop customer-xSTP then forwards it transparently. However, both the xSTP based SP network and full-mesh scheme have completely the same issues. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 07:52:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05863 for ; Thu, 1 May 2003 07:52:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41Bs2X22498 for ; Thu, 1 May 2003 07:54:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h41BrxO07305 for ; Thu, 1 May 2003 07:53:59 -0400 (EDT) Message-Id: <200305011148.HAA05670@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Date: Thu, 01 May 2003 07:48:28 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Management Requirements for MPLS MIBs Author(s) : W. Lai, L. Chung Filename : draft-lai-mpls-mib-rqmts-00.txt Pages : 6 Date : 2003-4-30 In this document, requirements for three MPLS-related MIBs (LDP-MIB, VPN-MIB, and BGP4-MIB) are presented for the support of specific network management needs for fault and performance management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-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-lai-mpls-mib-rqmts-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-lai-mpls-mib-rqmts-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-4-30150803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lai-mpls-mib-rqmts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lai-mpls-mib-rqmts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-30150803.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 09:04:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07850 for ; Thu, 1 May 2003 09:04:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41D6FX13165 for ; Thu, 1 May 2003 09:06:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h41D6Aj02904 for ; Thu, 1 May 2003 09:06:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Date: Thu, 1 May 2003 08:01:34 -0500 Message-ID: <7AFE40EF30EE754DA967D1B5968457CA13704D@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Thread-Index: AcMP2C62Vf/xmb2vROSwc7V+gBejzgACZAHA From: "Lai, Wai S (Waisum), ALABS" To: X-SMTP-HELO: kcmso2.proxy.att.com X-SMTP-MAIL-FROM: wlai@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kcmso2.att.com [192.128.134.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA07850 Based on our testing of the VPN MIB, we have identified some requirements as described in the following draft. Your comments are welcome. Thanks, Wai Sum -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, May 01, 2003 7:48 AM Cc: mpls@uu.net; ppvpn@nortelnetworks.com Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Management Requirements for MPLS MIBs Author(s) : W. Lai, L. Chung Filename : draft-lai-mpls-mib-rqmts-00.txt Pages : 6 Date : 2003-4-30 In this document, requirements for three MPLS-related MIBs (LDP-MIB, VPN-MIB, and BGP4-MIB) are presented for the support of specific network management needs for fault and performance management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-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-lai-mpls-mib-rqmts-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-lai-mpls-mib-rqmts-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. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 12:05:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19600 for ; Thu, 1 May 2003 12:05:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41FpsY29989 for ; Thu, 1 May 2003 11:51:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h41FpoR17065 for ; Thu, 1 May 2003 11:51:51 -0400 (EDT) Message-ID: <3EB141EA.117775B5@alcatel.com> Date: Thu, 01 May 2003 11:48:58 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Norman Finn CC: erosen@cisco.com, Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200304221757.h3MHvi4W001390@rtp-core-1.cisco.com> <3EA966EB.88496ADB@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, Norm, Norman Finn wrote: > > I second the motion. :) > > Eric Rosen wrote: > > > > (Of course, all these problems can be eliminated by making all the CE > > devices be routers, and using an IPLS service instead ;-)) How does IPLS eliminate the problem where a CE router A cannot see B (and vice-versa), but CE router C can see CE router A and B (and vice-versa)? [This question has been raised before]. Customer routing protocols would still get an inconsistent view if this problem is not eliminated. Thanks Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 14:13:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26322 for ; Thu, 1 May 2003 14:13:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41IFDY20508 for ; Thu, 1 May 2003 14:15:13 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h41IF7n12175 for ; Thu, 1 May 2003 14:15:07 -0400 (EDT) From: "Mark Seery" To: "Muneyoshi Suzuki" Cc: Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Thu, 1 May 2003 11:09:52 -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: <20030501.183803.97286099.suzuki.muneyoshi@lab.ntt.co.jp> Importance: Normal X-SMTP-HELO: smtp016.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp016.mail.yahoo.com [216.136.174.113] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Muneyoshi, >> Could you see the attached text that is the latter half of my reply to Norm. I think there are two xSTP related issues; loop prevention and cache clear due to customer topology change. << I'm not sure anything short of a novel can do justice to the issues you raise, so I am going to raise a few issues for consideration, with hopefully an appropriate amount of brevity. With respect to a mechanism to clear cache, this mechanism should probably be a part of an Ethernet standard regardless of whether Ethernet is being transported over MPLS or not. There are situations in pure Ethernet networks where I could see this being useful, so I would suggest this is something for the IEEE to pursue. I would also add that this raises the question of whether a formal UNI interface between Ethernet client and server networks would be useful (I can also see models where the server layer is completely transparent as being useful too). Don't know to what extend this has been discussed, in this forum, already. With respect to loop prevention, VPLS needs to ensure correct routing for a variety of security reasons. If it can not do this, then the concern you raise is secondary to this issue. It has been suggested that routing transients are unavoidable - seems to me all technologies face some outages, we are just arguing expectations. Additionally, I am not convinced that forcing the MPLS network to behave in accordance with a IEEE 802.1 spanning tree, is the only way to solve this problem - perhaps I am misunderstanding what you suggest? I think you have to examine why you want to use MPLS or IP as a VPLS infrastructure and then ask yourslef are you getting that benefit if you impose this kind of behavior on the underlying network. Some other areas to consider below: Network Architecture ==================== You have already observed yourself that there are a couple of models floating around. Some clarity here is useful before getting in to the details of a solution. As always, perhaps requirements clarification is the place to start. Personally I am in favor of the model where the VPLS appears and behaves as a LAN segment with no higher layer Bridge function, purely MAC relay at best. I come to this conclusion for a variety of reasons, many too long to discuss in one email, but as the result of concerns in the areas of network architecture, system architecture, and standards (architecture). Certainly my mind is oriented to appreciating the value of separate transport and switching layers. And while I appreciate that taken to extreme this leads to too many layers in a network, I would also argue you can have to few layers from the perspectives of organizational efficiency, equipment issues, and network extensibility. Network architecture is too large of a subject to discuss in an email, but would simply be curious to understand the overall goals and perceived benefits of the network you are pursuing. System Architecture =================== While flatenning out networks can be a good thing, the attempt to mash all layers of a network into one system can have dramatic impacts on the cost and usefullness of a single system, and ultimatley network architecture flexibility - a point which seems to recognized in varying degrees by HVPLS, GVPLS, and DTLS. As you suggest that PEs have a fairly rich level of Ethernet switching/bridging capability I would suggest that is something you consider. There maybe otherways to skin the cat. Standards (Architecture) ======================== IMO, pursuing solutions that requires the least amount of interaction between two standards bodies is preferrable. Certainly to be avoided is the situation where one standards body is perceived as making changes to something that another standards body feels ownership for. There have been some comments that suggest that IEEE and IETF are in sync, so I won't challenge that assertion. I will simply observe that the road you are heading down would seem to, IMO, provide a fertile ground for such issues to germinate. In closing I am not one to suggest what technology should or should not be used as service and transport layers - I think that is completely dependent on application and the value chain a service provider is pursuing - and the market should support service providers pursuing different value chains. I would only suggest that the issues above be examined. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 14:21:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27185 for ; Thu, 1 May 2003 14:20:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41IN9Y24702 for ; Thu, 1 May 2003 14:23:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h41IN5n18661 for ; Thu, 1 May 2003 14:23:06 -0400 (EDT) Message-ID: <3EB140CB.731DCF3F@alcatel.com> Date: Thu, 01 May 2003 11:44:11 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: nfinn@cisco.com, suzuki.muneyoshi@lab.ntt.co.jp, jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <0536FC9B908BEC4597EE721BE6A35389025D6799@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Neil, Could you elaborate a little on how to use L1/2 to isolate the p2p Ethernet to different sites pls? If the end customer has an Ethernet interface to the provider, and needs to connect to multiple sites, what equipment is required at the customer site? Thanks, Cheng-Yin neil.2.harrison@bt.com wrote: > > Cheng-Yin.....well, our current view is that VLANs live in the > customer/corporate domain, and that the safest solution at this time is to > use hard BW partitioning at L1/2 to isolate them. > > regards, Neil > > > -----Original Message----- > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > Sent: 29 April 2003 21:06 > > To: Harrison,N,Neil,IKL2 R > > Cc: nfinn@cisco.com; suzuki.muneyoshi@lab.ntt.co.jp; > > jwils@coriolisnet.com; ppvpn@nortelnetworks.com > > Subject: Re: Comments on the L2 VPN framework and solutions documents > > > > > > Neil, > > > There is a massive difference in > > > > recognising the importance of ethernet as a key CPE > > *interface* and then > > > > (somehow) making the (wrong) extrapolation that this > > means ethernet is a > > > > great WAN technology. > > I think this is an important point. > > The next question then is what should end-customers with > > multiple sites > > but a single Ethernet interface to provider do? > > > > Thanks > > Cheng-Yin. > > > > neil.2.harrison@bt.com wrote: > > > > > > Norman...I'd go further than saying that.....it's proposing > > reinventing cnls > > > networking (data-plane aspects too). There is a massive > > difference in > > > recognising the importance of ethernet as a key CPE > > *interface* and then > > > (somehow) making the (wrong) extrapolation that this means > > ethernet is a > > > great WAN technology. All *scalable* WAN networking modes > > (of which there > > > are only 3, viz cnls, co pkt-sw and co cct-sw) must have at least 2 > > > functional components: > > > - addressing: from a space that is large enough, and carries > > > semantics of 'where' (not 'who'...that is a name) and thus > > aggregatable; > > > - consistent topological network map: whether centralised or > > > distributed, to allow consistent route calculation. > > > > > > They must also have other functional components to make make them > > > 'operationally viable', but addressing/routing are the min > > set. Ethernet as > > > a technology does not have addressing/routing functional > > components that > > > meet the WAN/scalability criteria. > > > > > > {Aside: As an aim (to stop doing stovepipes, ie > > 'technology==service' and > > > to minimise problematic gateways for data/control-plane > > functions) we > > > operators (or at least BT) are seeking functional > > convergence *within* each > > > of the networking modes but not *across* them (that one > > makes no technical > > > or commercial sense). So we agree with you that to try and > > turn ethernet > > > into a next generation cnls network is a 'bad idea'....we > > have IP for that > > > job.} > > > > > > Therefore, short of fundamentally re-working what ethernet > > is today, the > > > only pragmatic way to handle ethernet services in the WAN > > is to accept that > > > a proper WAN technology must act as a server layer to proxy > > for the missing > > > functions. SDH/GFP is a good solution. MPLS *could* be a good > > > solution.....but it would need recognition that: > > > - it is a layer network in its own right, eg it needs its own > > > addressing regime (actually it subconsciously(?) gets this, but its > > > different for each signalling type used and that is not a > > good idea); > > > - it belongs to the co pkt-sw mode (not the cnls > > mode, that is IP) and > > > thus does *not* have to be constrained by the limitations > > of a cnls mode, eg > > > in a client/server sense X/MPLS is *not* the same as > > X/IP.....and it saddens > > > me to see PWE3 try to treat them like this as though this > > is a 'good idea' > > > when its just dogma; > > > - it needs proper OAM solutions......but the only topological > > > constructs that make networking sense in a co pkt-sw mode > > are p2p and > > > p2mp......mp2p constructs just create problems for no > > benefit (if one wants > > > this sort of behaviour, use a proper IP/cnls mode which is > > designed for this > > > behaviour and where these problems don't exist). Further, > > given X/MPLS and > > > X/IP are different animals, then we want to see as much functional > > > independence between the client (X) and the server layers (MPLS or > > > IP).......and we don't want to see lots of in-between layer > > functions being > > > created (like PW OAM) that we also have to manage (noting > > that we still have > > > to manage the MPLS and IP layers anyway....so at least get > > these right in > > > their own right). > > > > > > regards, Neil > > > > > > > -----Original Message----- > > > > From: Norman Finn [mailto:nfinn@cisco.com] > > > > Sent: 25 April 2003 17:31 > > > > To: Muneyoshi Suzuki > > > > Cc: jwils@coriolisnet.com; ppvpn@nortelnetworks.com > > > > Subject: Re: Comments on the L2 VPN framework and > > solutions documents > > > > > > > > > > > > Muneyoshi, > > > > > > > > I think that adding a TTL field to the MAC frame is an attractive > > > > idea. I also think that it is an extraordinarily bad idea. If I > > > > may paraphrase your argument, it is: (Forgive me, > > please, for putting > > > > words in your mouth.) > > > > > > > > 1. Routing is not reliable enough to establish the connections > > > > that we need. Bridge A might be able to talk to Bridge B, but > > > > not to Bridge C. > > > > > > > > 2. Spanning trees and full meshes, which don't require TTL, are > > > > not good enough, for the reasons thoroughly discussed. (By > > > > the way, I very much agree with you that, for large N, a full > > > > mesh will not be reliable. My solution is to keep N fairly > > > > small.) > > > > > > > > 3. Therefore, we'll add TTL and use OSPF to route the MAC frames. > > > > > > > > What I don't understand is how you have solved the problem that > > > > Bridge A could not talk to Bridge C! Why is your toy > > routing system > > > > going to be any more robust than the existing routing system? > > > > > > > > This approach is not flawed because it is reinventing > > bridging. It > > > > is flawed because it is reinventing routing. > > > > > > > > -- Norm > > > > > > > > Muneyoshi Suzuki wrote: > > > > > > > > > > Joris, > > > > > > > > > > Thanks for clarification. > > > > > > > > > > First, needless to say, I aware link block problem of > > STP/RSTP. We > > > > > definitely need a solution. However, the solution must > > be robust. > > > > > To enable large scale deployment, it must not force the > > operators > > > > > and users to reboot boxes even if the worst case. The full mesh > > > > > approach is a fragility solution that has loop, blackhole > > > > or unreliable > > > > > flaky PEs problems, so we have no choice other than the > > > > conventional scheme. > > > > > > > > > > Second, if we regard xSTP as routing protocols, obviously > > > > there are less > > > > > efficient than OSPF/BGP. However, if we regard xSTP as > > protocols for > > > > > protection, these are not bad. If we reserve paths for fast > > > > protection > > > > > for the mesh, there are active and standby meshes. I think > > > > this problem > > > > > is not much different form xSTP link block problem. > > > > > > > > > > Finally, as far as I know, currently providers don't use > > > > STP due to long > > > > > recovery time; instead manually configure a single tree > > > > topology. However, > > > > > a single tree topology is not bad. Please image > > > > conventional telephone > > > > > network architecture; it is a tree. A tree is one of > > > > fundamental network > > > > > architecture. However, needless to say, topology free is > > > > much better than > > > > > a tree. Therefore, I proposed OSPF or BGP-4 extension for > > > > MAC routing > > > > > in Atlanta meeting (please see my slides in the last > > > > November). I think > > > > > it is not easy to progress this work in the IETF, but I > > > > believe we need > > > > > this kind of work in the near future. > > > > > > > > > > Thanks, > > > > > > > > > > Muneyoshi Suzuki > > > > > Nippon Telegraph and Telephone Corp. > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 14:41:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28325 for ; Thu, 1 May 2003 14:41:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41IiGY00900 for ; Thu, 1 May 2003 14:44:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h41IiCH02906 for ; Thu, 1 May 2003 14:44:13 -0400 (EDT) Message-Id: <200305011840.h41IekWS004609@rtp-core-1.cisco.com> To: Cheng-Yin.Lee@alcatel.com cc: Norman Finn , Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Thu, 01 May 2003 11:48:58 -0400. <3EB141EA.117775B5@alcatel.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: Thu, 01 May 2003 14:40:45 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Cheng-Yin> How does IPLS eliminate the problem where a CE router A cannot Cheng-Yin> see B (and vice-versa), but CE router C can see CE router A and B Cheng-Yin> (and vice-versa)? ... Customer routing protocols would still Cheng-Yin> get an inconsistent view if this problem is not eliminated. The precise effects depend on the routing protocol. If the protocol is RIP, for example, then A won't install any routes with B as the next hop, and B won't install any with A as the next hop. So it's possible that a packet that should go from A to B will actually go from A to C to B. If the protocol is OSPF, the analysis is more complex, and depends on whether A and/or B are trying to become the designated router. I think the worst that can happen is that some of the traffic which is routed across the emulated LAN won't make it. I don't think loops are possible. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 1 14:51:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28871 for ; Thu, 1 May 2003 14:50:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41IrHY05541 for ; Thu, 1 May 2003 14:53:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h41Ir7i13857 for ; Thu, 1 May 2003 14:53:08 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: ppvpn@nortelnetworks.com Subject: VPNID TLV in vkompella-lasserre draft... Date: Thu, 1 May 2003 14:49:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31012.5DA17446" X-LYRIS-Message-Id: 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_01C31012.5DA17446 Content-Type: text/plain; charset="iso-8859-1" Hi Vach, I appreciate a clarification on the vkompella-lasserre draft with respect to VPNID TLV mentioned in the following text in the draft. It says: "In a VPLS, we use a VCID (to be substituted with a VPNID TLV later, to address extending the scope of a VPLS) to identify an emulated LAN segment." Do you consider the substituted VPNID TLV mentioned here as the one included in Generalized ID FEC TLV described in draft-ietf-pwe3-control-protocol-02.txt (the AGI field) or this new TLV represents a *third* option for pseudo-wire signaling using LDP? In that case, are you planning to include this TLV in draft-ietf-pwe3-control-protocol-02.txt as well? Since in the text it says *substituted*, should we consider the 32 bits VCID option to be obsoleted in future revised versions of the draft? Thanks. Hamid. ------_=_NextPart_001_01C31012.5DA17446 Content-Type: text/html; charset="iso-8859-1" VPNID TLV in vkompella-lasserre draft...

Hi Vach,

I appreciate a clarification on the vkompella-lasserre draft
with respect to VPNID TLV mentioned in the following
text in the draft.

It says:

   "In a VPLS, we use a VCID (to be substituted with a VPNID TLV later,
   to address extending the scope of a VPLS) to identify an emulated
   LAN segment."

Do you consider the substituted VPNID TLV mentioned here
as the one included in Generalized ID FEC TLV described in
draft-ietf-pwe3-control-protocol-02.txt (the AGI field)
or this new TLV represents a *third* option for pseudo-wire
signaling using LDP?

In that case, are you planning to include this TLV in
draft-ietf-pwe3-control-protocol-02.txt as well?

Since in the text it says *substituted*, should we consider
the 32 bits VCID option to be obsoleted in future revised
versions of the draft?

Thanks.
Hamid. 
   



------_=_NextPart_001_01C31012.5DA17446-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 03:20:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08260 for ; Fri, 2 May 2003 03:20:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h427MKN21376 for ; Fri, 2 May 2003 03:22:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h427MG917538 for ; Fri, 2 May 2003 03:22:16 -0400 (EDT) X-Originating-IP: [203.124.140.97] X-Originating-Email: [sylvia_sugar@hotmail.com] From: "Sylvia Sugar" To: ppvpn@nortelnetworks.com Subject: Label and RD and CE-id Date: Fri, 02 May 2003 07:19:43 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 May 2003 07:19:43.0297 (UTC) FILETIME=[33D2A310:01C3107B] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: sylvia_sugar@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: bay1-f65.bay1.hotmail.com [65.54.245.65] X-LYRIS-Message-Id: Hello, If one is passing the inner label to the VRF via MBGP, why does one need to pass the CE-id? and the RD? -SylviaXO _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 04:19:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09094 for ; Fri, 2 May 2003 04:19:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h428LpN01395 for ; Fri, 2 May 2003 04:21:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h428Lm007067 for ; Fri, 2 May 2003 04:21:48 -0400 (EDT) Date: Fri, 02 May 2003 17:18:54 +0900 (JST) Message-Id: <20030502.171854.30174363.suzuki.muneyoshi@lab.ntt.co.jp> To: mark@mseery.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: References: <20030501.183803.97286099.suzuki.muneyoshi@lab.ntt.co.jp> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark, > With respect to a mechanism to clear cache, this mechanism should probably > be a part of an Ethernet standard regardless of whether Ethernet is being > transported over MPLS or not. There are situations in pure Ethernet networks > where I could see this being useful, so I would suggest this is something > for the IEEE to pursue. Agreed. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 04:45:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09398 for ; Fri, 2 May 2003 04:45:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h428liN06693 for ; Fri, 2 May 2003 04:47:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h428lbP15106 for ; Fri, 2 May 2003 04:47:37 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67B8@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: Cheng-Yin.Lee@alcatel.com Cc: nfinn@cisco.com, suzuki.muneyoshi@lab.ntt.co.jp, jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Fri, 2 May 2003 09:44:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Cheng-Yin, We will provide such services via either SDH or ATM networks using enhancements to the equipment that terminate these networks in a customer facing direction. Just think about it....we have shed-loads of SDH/ATM equipment and it would be barking mad not to leverage it (same must be true of many other large operators)......but its not simply that rather obvious fact, we also have technical reservations about both MPLS and the usuage of VLAN technology in a core/WAN network (esp if these 2 technologies are related). For example, just considering MPLS per se.......we would like to use MPLS as a convergent common core co pkt-sw technology.....so this refers to the 'stovepipe' + gateway problem I have raised on mails previously, and the need for functional convergence *within* each network mode but not *across* them. Each mode (ie cnls, co pkt-sw and co cct-sw) do different jobs, we need them all, and they require different behaviours. But if MPLS is going to assume this mantle it needs to become 'fit for purpose' and a proper layer network in its own right. This is actually very simple to do as its largely about 'removing' bad stuff, not trying to keep adding kludges to fix the errors....specifically we don't want the arch monstronsities that PWE3 are creating to expedite the 'errors' and the incorrect arch view that X/IP and X/MPLS must have the same treatment. As I noted earlier: there is a big difference in noting the *importance* of ethernet as a CPE interface and then (wrongly) interpolating that to mean we (operators) have to provide a WAN network with bridging/VLAN capabilities.....this simply does not follow. Ethernet does not scale as a WAN technology because it does not have proper addressing attributes/semantics and it has no routing ability.....other functionality is missing too, but these are the 2 most elemental functional requirements for *any* WAN technology (belonging to any network mode, be it cnls, co pkt-sw or co cct-sw) to scale/work, esp for arbitrary topologies. So we won't run with the herd if we don't agree with it. Check out what we recently bought at L1 and specifically the signalling protocol chosen. BTW - If I can find time over the next week I may post some observations on the 'my protocol is better than yours' debate wrt VPLS......they are all missing the key point...which is all tied up in addressing, and the fact that a L3 VPN is not the same as the VPLS/ethernet problem at all, and neither is it the same as providing an arbitrary L2 VPN. These are all quite different issues, commonly related by a lack of proper MPLS layer addressing. regards, Neil > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: 01 May 2003 16:44 > To: Harrison,N,Neil,IKL2 R > Cc: nfinn@cisco.com; suzuki.muneyoshi@lab.ntt.co.jp; > jwils@coriolisnet.com; ppvpn@nortelnetworks.com > Subject: Re: Comments on the L2 VPN framework and solutions documents > > > Neil, > Could you elaborate a little on how to use L1/2 to isolate the p2p > Ethernet to different sites pls? > If the end customer has an Ethernet interface to the > provider, and needs > to connect to multiple sites, what equipment is required at > the customer > site? > > Thanks, > Cheng-Yin > > neil.2.harrison@bt.com wrote: > > > > Cheng-Yin.....well, our current view is that VLANs live in the > > customer/corporate domain, and that the safest solution at > this time is to > > use hard BW partitioning at L1/2 to isolate them. > > > > regards, Neil > > > > > -----Original Message----- > > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > > Sent: 29 April 2003 21:06 > > > To: Harrison,N,Neil,IKL2 R > > > Cc: nfinn@cisco.com; suzuki.muneyoshi@lab.ntt.co.jp; > > > jwils@coriolisnet.com; ppvpn@nortelnetworks.com > > > Subject: Re: Comments on the L2 VPN framework and > solutions documents > > > > > > > > > Neil, > > > > There is a massive difference in > > > > > recognising the importance of ethernet as a key CPE > > > *interface* and then > > > > > (somehow) making the (wrong) extrapolation that this > > > means ethernet is a > > > > > great WAN technology. > > > I think this is an important point. > > > The next question then is what should end-customers with > > > multiple sites > > > but a single Ethernet interface to provider do? > > > > > > Thanks > > > Cheng-Yin. > > > > > > neil.2.harrison@bt.com wrote: > > > > > > > > Norman...I'd go further than saying that.....it's proposing > > > reinventing cnls > > > > networking (data-plane aspects too). There is a massive > > > difference in > > > > recognising the importance of ethernet as a key CPE > > > *interface* and then > > > > (somehow) making the (wrong) extrapolation that this means > > > ethernet is a > > > > great WAN technology. All *scalable* WAN networking modes > > > (of which there > > > > are only 3, viz cnls, co pkt-sw and co cct-sw) must > have at least 2 > > > > functional components: > > > > - addressing: from a space that is large enough, > and carries > > > > semantics of 'where' (not 'who'...that is a name) and thus > > > aggregatable; > > > > - consistent topological network map: whether > centralised or > > > > distributed, to allow consistent route calculation. > > > > > > > > They must also have other functional components to make > make them > > > > 'operationally viable', but addressing/routing are the min > > > set. Ethernet as > > > > a technology does not have addressing/routing functional > > > components that > > > > meet the WAN/scalability criteria. > > > > > > > > {Aside: As an aim (to stop doing stovepipes, ie > > > 'technology==service' and > > > > to minimise problematic gateways for data/control-plane > > > functions) we > > > > operators (or at least BT) are seeking functional > > > convergence *within* each > > > > of the networking modes but not *across* them (that one > > > makes no technical > > > > or commercial sense). So we agree with you that to try and > > > turn ethernet > > > > into a next generation cnls network is a 'bad idea'....we > > > have IP for that > > > > job.} > > > > > > > > Therefore, short of fundamentally re-working what ethernet > > > is today, the > > > > only pragmatic way to handle ethernet services in the WAN > > > is to accept that > > > > a proper WAN technology must act as a server layer to proxy > > > for the missing > > > > functions. SDH/GFP is a good solution. MPLS *could* be a good > > > > solution.....but it would need recognition that: > > > > - it is a layer network in its own right, eg it > needs its own > > > > addressing regime (actually it subconsciously(?) gets > this, but its > > > > different for each signalling type used and that is not a > > > good idea); > > > > - it belongs to the co pkt-sw mode (not the cnls > > > mode, that is IP) and > > > > thus does *not* have to be constrained by the limitations > > > of a cnls mode, eg > > > > in a client/server sense X/MPLS is *not* the same as > > > X/IP.....and it saddens > > > > me to see PWE3 try to treat them like this as though this > > > is a 'good idea' > > > > when its just dogma; > > > > - it needs proper OAM solutions......but the only > topological > > > > constructs that make networking sense in a co pkt-sw mode > > > are p2p and > > > > p2mp......mp2p constructs just create problems for no > > > benefit (if one wants > > > > this sort of behaviour, use a proper IP/cnls mode which is > > > designed for this > > > > behaviour and where these problems don't exist). Further, > > > given X/MPLS and > > > > X/IP are different animals, then we want to see as much > functional > > > > independence between the client (X) and the server > layers (MPLS or > > > > IP).......and we don't want to see lots of in-between layer > > > functions being > > > > created (like PW OAM) that we also have to manage (noting > > > that we still have > > > > to manage the MPLS and IP layers anyway....so at least get > > > these right in > > > > their own right). > > > > > > > > regards, Neil > > > > > > > > > -----Original Message----- > > > > > From: Norman Finn [mailto:nfinn@cisco.com] > > > > > Sent: 25 April 2003 17:31 > > > > > To: Muneyoshi Suzuki > > > > > Cc: jwils@coriolisnet.com; ppvpn@nortelnetworks.com > > > > > Subject: Re: Comments on the L2 VPN framework and > > > solutions documents > > > > > > > > > > > > > > > Muneyoshi, > > > > > > > > > > I think that adding a TTL field to the MAC frame is > an attractive > > > > > idea. I also think that it is an extraordinarily bad > idea. If I > > > > > may paraphrase your argument, it is: (Forgive me, > > > please, for putting > > > > > words in your mouth.) > > > > > > > > > > 1. Routing is not reliable enough to establish the > connections > > > > > that we need. Bridge A might be able to talk to > Bridge B, but > > > > > not to Bridge C. > > > > > > > > > > 2. Spanning trees and full meshes, which don't > require TTL, are > > > > > not good enough, for the reasons thoroughly > discussed. (By > > > > > the way, I very much agree with you that, for > large N, a full > > > > > mesh will not be reliable. My solution is to > keep N fairly > > > > > small.) > > > > > > > > > > 3. Therefore, we'll add TTL and use OSPF to route > the MAC frames. > > > > > > > > > > What I don't understand is how you have solved the > problem that > > > > > Bridge A could not talk to Bridge C! Why is your toy > > > routing system > > > > > going to be any more robust than the existing routing system? > > > > > > > > > > This approach is not flawed because it is reinventing > > > bridging. It > > > > > is flawed because it is reinventing routing. > > > > > > > > > > -- Norm > > > > > > > > > > Muneyoshi Suzuki wrote: > > > > > > > > > > > > Joris, > > > > > > > > > > > > Thanks for clarification. > > > > > > > > > > > > First, needless to say, I aware link block problem of > > > STP/RSTP. We > > > > > > definitely need a solution. However, the solution must > > > be robust. > > > > > > To enable large scale deployment, it must not force the > > > operators > > > > > > and users to reboot boxes even if the worst case. > The full mesh > > > > > > approach is a fragility solution that has loop, blackhole > > > > > or unreliable > > > > > > flaky PEs problems, so we have no choice other than the > > > > > conventional scheme. > > > > > > > > > > > > Second, if we regard xSTP as routing protocols, obviously > > > > > there are less > > > > > > efficient than OSPF/BGP. However, if we regard xSTP as > > > protocols for > > > > > > protection, these are not bad. If we reserve paths for fast > > > > > protection > > > > > > for the mesh, there are active and standby meshes. I think > > > > > this problem > > > > > > is not much different form xSTP link block problem. > > > > > > > > > > > > Finally, as far as I know, currently providers don't use > > > > > STP due to long > > > > > > recovery time; instead manually configure a single tree > > > > > topology. However, > > > > > > a single tree topology is not bad. Please image > > > > > conventional telephone > > > > > > network architecture; it is a tree. A tree is one of > > > > > fundamental network > > > > > > architecture. However, needless to say, topology free is > > > > > much better than > > > > > > a tree. Therefore, I proposed OSPF or BGP-4 extension for > > > > > MAC routing > > > > > > in Atlanta meeting (please see my slides in the last > > > > > November). I think > > > > > > it is not easy to progress this work in the IETF, but I > > > > > believe we need > > > > > > this kind of work in the near future. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Muneyoshi Suzuki > > > > > > Nippon Telegraph and Telephone Corp. > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 10:15:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15856 for ; Fri, 2 May 2003 10:15:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42EIBN11799 for ; Fri, 2 May 2003 10:18:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42EI6901179 for ; Fri, 2 May 2003 10:18:07 -0400 (EDT) Message-ID: From: "Newton, Jonathan" To: "'ppvpn@nortelnetworks.com'" Subject: subscribe Date: Fri, 2 May 2003 15:15:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-SMTP-HELO: mx.cwplc.com X-SMTP-MAIL-FROM: Jonathan.Newton@cwcom.cwplc.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mx.cwplc.com [194.6.6.20] X-LYRIS-Message-Id: subscribe ********************************************************************** This message may contain information which is confidential or privileged. If you are not the intended recipient, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. ********************************************************************** From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 10:27:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16208 for ; Fri, 2 May 2003 10:27:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42EC6N08651 for ; Fri, 2 May 2003 10:12:06 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42EC2K27245 for ; Fri, 2 May 2003 10:12:03 -0400 (EDT) Message-ID: From: "Busschbach, Peter B (Peter)" To: "'ppvpn@nortelnetworks.com'" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Fri, 2 May 2003 09:57:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: auemail1.firewall.lucent.com X-SMTP-MAIL-FROM: busschbach@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: auemail1.lucent.com [192.11.223.161] X-LYRIS-Message-Id: On Tue, 29 Apr 2003 08:02:01 -0400, Mike Duckett (Dotnet) wrote: >To determine which approach is better, we need to have a generally accepted >problem definition (a.k.a., requirements). With a robust set of present >and forward looking requirements, we can make better decisions. Which draft >represents a consensus relative to L2VPN (PWS[Frame Relay, .,.,*],VPLS) >requirements? Is draft-augustyn-ppvpn-l2vpn-requirements-00.txt >representative of the problem space? > >I am personally interested in a solution (where the solution has a minimal >number of unique protocols) that not only addresses VPLS but also supports >many AC types (e.g,. Frame Relay) and robust capabilities >signalling/negotiation. IOW, a solution optimized for VPLS that is not >suited for point to point is not desirable. I think this is an important point and one that is insufficiently recognized. Many (all) service providers will offer VPWS and VPLS services as two variations of the same service class (i.e. ethernet services). Both will run over the same network and they will be managed with the same management systems. Eric and Ali have given several arguments why even for VPLS, signaling is essentially a point-to-point action for which LDP is best suited. IMO, nobody has given good counter arguments. Instead, there seems to be an almost dogmatic insistence that BGP can do the job as well and that BGP is good because it can be used for auto-discovery and because it is used in IP VPNs. Personally, I think that a common approach for VPLS, VPWS and other L2 VPN incarnations is more important than commonality with IP VPNs. Therefore, I am strongly in favor of LDP for VPLS signaling. I think BGP is the wrong way to go. Peter >Step one should be gaining >agreement on requirements. Should we move to accept a single or small >number of requirements documents? Did I miss this event? > > >----- Original Message ----- >From: >To: >Cc: >Sent: Tuesday, April 29, 2003 4:53 AM >Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt > > >Hi Eric > >As I understand it a requirement would be to have a full mesh of LDP >sessions between the PEs in the participating AS domains. This means >configuration of each PE when for example a new site is added to an >already existing VPN. If BGP is used this is not necessary as RRs can be >used, minimizing the configuration to the new PE and the RR. >But perhaps there exist a solution similar to this for LDP as well? It >seems appealing to reuse the 2547bis structure we have also for VPLS if >it's possible. > >My point is that further investigation of the two different solutions >before rejecting one or the other would be good > >/Andreas > >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: den 28 april 2003 16:29 >To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 >Cc: ppvpn@nortelnetworks.com >Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > >Andreas> I would also like to know how inter-AS with the LDP >Andreas> approach in lasserre-vkompella is to be solved. > >Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 10:32:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16307 for ; Fri, 2 May 2003 10:32:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42EYnN18022 for ; Fri, 2 May 2003 10:34:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42EYhq10950 for ; Fri, 2 May 2003 10:34:43 -0400 (EDT) Date: Fri, 2 May 2003 16:31:57 +0200 Message-Id: Subject: =?iso-8859-1?Q?unsubscribe?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?dariobalmas@libero.it?=" To: "=?iso-8859-1?Q?ppvpn?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 163.162.41.4 X-SMTP-HELO: smtp3.libero.it X-SMTP-MAIL-FROM: dariobalmas@libero.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp3.libero.it [193.70.192.127] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16307 unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 10:43:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16639 for ; Fri, 2 May 2003 10:43:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42EjSN23484 for ; Fri, 2 May 2003 10:45:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42EjOg19186 for ; Fri, 2 May 2003 10:45:24 -0400 (EDT) Message-ID: <3EB28407.FA71DE00@softway.fr> Date: Fri, 02 May 2003 16:43:19 +0200 From: "jo garzon" X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: ppvpn Subject: unsubscribe Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SMTP-HELO: msweeper.softway.fr X-SMTP-MAIL-FROM: jgarzon@softway.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: msweeper.Softway.Fr [192.134.48.101] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 11:02:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17229 for ; Fri, 2 May 2003 11:02:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42F4QN21021 for ; Fri, 2 May 2003 11:04:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42F4H714149 for ; Fri, 2 May 2003 11:04:18 -0400 (EDT) Reply-To: From: "Vedavinayagam" To: Subject: unsubscribe Date: Fri, 2 May 2003 20:23:24 +0530 Message-Id: <00a701c310ba$956cc1c0$0604060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SMTP-HELO: fsnt.future.futsoft.com X-SMTP-MAIL-FROM: vedag@future.futsoft.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [203.197.140.35] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 11:06:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17378 for ; Fri, 2 May 2003 11:06:24 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42F8iN24923 for ; Fri, 2 May 2003 11:08:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42F8d723994 for ; Fri, 2 May 2003 11:08:39 -0400 (EDT) Message-ID: <3EB28917.211024BC@cisco.com> Date: Fri, 02 May 2003 17:04:56 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Busschbach, Peter B (Peter)" CC: "'ppvpn@nortelnetworks.com'" Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > Eric and Ali have given several arguments why even for VPLS, signaling is > essentially a point-to-point action for which LDP is best suited. > IMO, nobody has given good counter arguments. So for the benefit of those watching this list without blind believe that VPLS must be based on point to point pseudowires and that there are few more technologies other then LDP can some one come up with a real design arguments that VPLS should really be used over p2p pipes with full replication for broadcast & multicast at the ingress to SP core ? Are all providers educating their customers that VPLS service based on p2p PWs are not really ethernet, but a bunch of p2p pipes with all of the conseqences behind this especially for decent rate multicast traffic ? This entire argument for BGP versus LDP is completely unnecessary since if you provide VPLS without locking yourself into the p2p PWs in the core non of them is required. Further no signalling is required all together :-). One idea of much more effcient VPLS is presented here: draft-sajassi-mvpls-00.txt Are providers really keen on getting into all of those LDP/BGP configurations just to provide Metro VPLS service ? On the other hand when you are about to go Inter-AS with VPLS does this sound efficient to replicate each multicast packets or streams N times at their src PE (when N = the number of remote PEs for a given VPLS instance) and then ship it through in parallel over most likely decent distances ? Just to save some list bandwith ... * I am not claiming that draft-sajassi-mvpls-00.txt is the best solution possible but for sure this is a start into a valid direction * I am not subscribing to claims that since VPWS runs over p2p PWs VPLS also should do so as they are members of the same family etc ... * If one says back that IP muticast is not a scalable technology it would be much better to specify precisely the claim. Notice that for services like Multicast L3VPNs or MVPLS number of multicast states in the core is very limited to the number of PEs and completely unrelated to any thing on the SP customer side. R. > "Busschbach, Peter B (Peter)" wrote: > > On Tue, 29 Apr 2003 08:02:01 -0400, Mike Duckett (Dotnet) wrote: > > >To determine which approach is better, we need to have a generally accepted > >problem definition (a.k.a., requirements). With a robust set of present > >and forward looking requirements, we can make better decisions. Which draft > >represents a consensus relative to L2VPN (PWS[Frame Relay, .,.,*],VPLS) > >requirements? Is draft-augustyn-ppvpn-l2vpn-requirements-00.txt > >representative of the problem space? > > > >I am personally interested in a solution (where the solution has a minimal > >number of unique protocols) that not only addresses VPLS but also supports > >many AC types (e.g,. Frame Relay) and robust capabilities > >signalling/negotiation. IOW, a solution optimized for VPLS that is not > >suited for point to point is not desirable. > > I think this is an important point and one that is insufficiently recognized. Many (all) service providers will offer VPWS and VPLS services as two variations of the same service class (i.e. ethernet services). Both will run over the same network and they will be managed with the same management systems. > > Eric and Ali have given several arguments why even for VPLS, signaling is essentially a point-to-point action for which LDP is best suited. IMO, nobody has given good counter arguments. Instead, there seems to be an almost dogmatic insistence that BGP can do the job as well and that BGP is good because it can be used for auto-discovery and because it is used in IP VPNs. > > Personally, I think that a common approach for VPLS, VPWS and other L2 VPN incarnations is more important than commonality with IP VPNs. Therefore, I am strongly in favor of LDP for VPLS signaling. I think BGP is the wrong way to go. > > Peter > > >Step one should be gaining > >agreement on requirements. Should we move to accept a single or small > >number of requirements documents? Did I miss this event? > > > > > >----- Original Message ----- > >From: > >To: > >Cc: > >Sent: Tuesday, April 29, 2003 4:53 AM > >Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > >Hi Eric > > > >As I understand it a requirement would be to have a full mesh of LDP > >sessions between the PEs in the participating AS domains. This means > >configuration of each PE when for example a new site is added to an > >already existing VPN. If BGP is used this is not necessary as RRs can be > >used, minimizing the configuration to the new PE and the RR. > >But perhaps there exist a solution similar to this for LDP as well? It > >seems appealing to reuse the 2547bis structure we have also for VPLS if > >it's possible. > > > >My point is that further investigation of the two different solutions > >before rejecting one or the other would be good > > > >/Andreas > > > >-----Original Message----- > >From: Eric Rosen [mailto:erosen@cisco.com] > >Sent: den 28 april 2003 16:29 > >To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 >Cc: ppvpn@nortelnetworks.com > >Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > > >Andreas> I would also like to know how inter-AS with the LDP > >Andreas> approach in lasserre-vkompella is to be solved. > > > >Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 11:18:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17644 for ; Fri, 2 May 2003 11:18:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42FKaN29744 for ; Fri, 2 May 2003 11:20:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42FKUT16522 for ; Fri, 2 May 2003 11:20:32 -0400 (EDT) Message-ID: <3EB28C08.9000509@alcatel.fr> Date: Fri, 02 May 2003 17:17:28 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: "Shmunis, Gregory" Cc: "'Thomas D. Nadeau'" , ppvpn@nortelnetworks.com Subject: Re: Question regdg. MPLS/BGP VPN MIB References: <39469E08BD83D411A3D900204840EC55F2F9FF@vie-msgusr-01.dc.fore.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 05/02/2003 17:17:28, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 05/02/2003 17:17:29, Serialize complete at 05/02/2003 17:17:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new X-SMTP-HELO: smail3.alcatel.fr X-SMTP-MAIL-FROM: yacine.el_mghazli@alcatel.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: colt-na7.alcatel.fr [62.23.212.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit hi Greg, Shmunis, Gregory wrote: > Tom, > > thanks. I understand the technical aspect of using various criteria > (including the source address) in the PE-incoming traffic to identify the > right lookup VRF. What I'm trying to figure out is a concrete deployment > case where sharing of a PE interface between VRFs would be required, and > also - what are potential side-effects of such use. simplest example: a site S can be part of an intranet with sites from the only same organization (VPN-A) AND part of an extranet involving sites from other organizations (VPN-B). 1) quoted from the current 2547bis draft: [section 3.1. "VRFs and Attachment Circuits"] "We allow the case in which a single attachment circuit is associated with a set of VRFs, rather than with a single VRF. This can be useful if it is desired to divide a single VPN into several "sub- VPNs", each with different connectivity restrictions, where some characteristic of the customer packets is used to select from among the sub-VPNs. For simplicity though, we will usually speak of an attachment circuit as being associated with a single VRF." Then, considering the upper-cited text, you'll have to attach this site S both to VRF-A AND VRF-B... and you also need some mechanism to identify the right lookup VRF. 2) but the current 2547bis draft also mention this: [section 3.2. "Associating IP packets with VRF"]: "If an attachment circuit leads to a site which is in multiple VPNs, the attachment circuit may still associated with a single VRF, in which case the VRF will contain routes from the full set of VPNs of which the site is a member." from this standpoint, a (sub-)interface is attached to a single VRF, which belongs to several VPNs. What I pointed out some times ago on the MIB is that the VPN-id does not make sense for a given VRF, since it can belong to several VPNs. > For instance, the > example of using the source address alone on a VRF-shared interface implies > that the VRFs that share the interface cannot use overlapping address spaces > - otherwise the traffic in the reverse (PE-to-CE) direction would be > untreatable. > > Perhaps Yasin can give his example. Having said all the above I want to make > it clear that the question is less of a MIB nature - it pertains to the > general operational aspect of 2547bis. agree. > > > greg. thanks, yacine > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, April 30, 2003 4:47 PM > To: Shmunis, Gregory > Cc: ppvpn@nortelnetworks.com; Yacine.El_Mghazli@alcatel.fr > Subject: RE: Question regdg. MPLS/BGP VPN MIB > > > > >>Tom, >> >>can you please point to a previous thread where concrete operational >>scenarios with an interface belonging to more than one VRF were discussed ? >>If it is simpler for you, can you just mention a case or two ? >> > > I have two examples. First, Yacine pointed out > a case a while back that we discussed -- perhaps > he can explain his scenario. In my case, my products > allow for multiple VRFs to be associated with the same > interface, and then based on the source address, one > of the VRFs is chosen to do the route lookup. Admittedly, > this is not a widely used case, but I think it is still one > that is used enough that the standard MIB should handle > it. > > --Tom > > > > > > >>thank you, >> >>Greg. >> >>-----Original Message----- >>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>Sent: Tuesday, April 29, 2003 11:00 AM >>To: Siddharth Aanand >>Cc: ppvpn@nortelnetworks.com; "Harmen Van der Linde"hvdl@att.com >>Subject: Re: Question regdg. MPLS/BGP VPN MIB >> >> >>At 10:46 AM 4/29/2003 -0400, Siddharth Aanand wrote: >> >>>>>The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and >>>>>mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I >>>>> >>had >> >>>>>was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely >>>>>identify a row in this table ? Under what circumstances do we need >>>>> > both > >>>>>the vrfName as well as the ifIndex as keys? >>>>> >>>> Yes, but the operational feedback was that operators >>>>wanted to cycle through interfaces belonging to each VRF. >>>>We need to update this slightly because there are cases where >>>>one interface may belong to multiple VRFs. >>>> >>>Yes. If one interface belongs to multiple VRFs then we'd need the vrfName >>>as a key. Do you know what distinguishing feature of the incoming >>> > traffic, > >>>on that interface, would be used to decide which VRF to use? >>> >> I think that is orthogonal to the discussion at hand. >>What is important is that the MIB can handle these >>cases without regard to how the choice is being made. >>The reason being that it is often a proprietary feature/configuration >>that does the choosing. My implementation for instance, >>uses several rules to make this determination. I know of >>another that makes a simple choice based on source >>address. >> >> --Tom >> >> >> >> >>>-Sidd >>> > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 15:08:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27130 for ; Fri, 2 May 2003 15:08:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42J8YN10489 for ; Fri, 2 May 2003 15:08:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42J8VF04939 for ; Fri, 2 May 2003 15:08:31 -0400 (EDT) Message-Id: <200305021900.PAA26139@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-l2vpn-requirements-00.txt Date: Fri, 02 May 2003 15:00:37 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks Author(s) : W. Augustyn, Y. Serbest Filename : draft-ietf-ppvpn-l2vpn-requirements-00.txt Pages : 26 Date : 2003-5-2 This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (PPVPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint to multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2vpn-requirements-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-ietf-ppvpn-l2vpn-requirements-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-ietf-ppvpn-l2vpn-requirements-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-5-2151952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-l2vpn-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-l2vpn-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-2151952.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 18:44:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06096 for ; Fri, 2 May 2003 18:44:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h42MjHN02504 for ; Fri, 2 May 2003 18:45:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h42MjDA27700 for ; Fri, 2 May 2003 18:45:14 -0400 (EDT) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Cc: "Marco Carugi" , "'Rick Wilder'" Subject: PPVPN L3 solution space : TWO-WEEK WG LAST CALL on draft-ietf-ppv pn-rfc2547bis-03.txt and related draft-ietf-ppvpn-as2547-01.txt Date: Sat, 3 May 2003 00:41:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C310FC.06746440" X-LYRIS-Message-Id: 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_01C310FC.06746440 Content-Type: text/plain; charset="iso-8859-1" All, as anticipated in San Francisco (see WG status slides), we wish to progress asap some fundamental work in the L3 space. L3 requirements and L3 framework are currently under a new IESG review and, hopefully, they will progress soon to Informational RFCs. The Generic requirements draft update is going to be ready these days and will be submitted again to IESG review for similar path shortly. It's finally reasonable to start now progress in the L3 solution space : the basic VR and 2547 WG drafts have been waiting long time that L3 requirements and L3 framework make their way to RFC status. We are then calling here a TWO-WEEK WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt (to standard track). We associate it with a corresponding two-week WG Last Call on the related Applicability Statement draft-ietf-ppvpn-as2547-01.txt. NOTE : a similar call will be done separately for the basic VR WG draft and related AS WG draft. Thanks for your comments on the list. The call will end on Friday May 16th. Marco and Rick P.S. Following steps in the L3 space (hopefully soon) will consider the VR and 2547 related MIBs and the complementary 2547-related solution drafts. L2 space : L2 requirements and L2 framework WG drafts will be considered soon for progress. And, obviously, we will come back ASAP to the list about expected WG document progress in the solution space. ------_=_NextPart_001_01C310FC.06746440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PPVPN L3 solution space : TWO-WEEK WG LAST CALL on = draft-ietf-ppvpn-rfc2547bis-03.txt and related = draft-ietf-ppvpn-as2547-01.txt

All,

as anticipated in San Francisco (see = WG status slides), we wish to progress asap some fundamental work in = the L3 space.
L3 requirements and L3 framework are = currently under a new IESG review and, hopefully, they will progress = soon to Informational RFCs.

The Generic requirements draft update = is going to be ready these days and will be submitted again to IESG = review for similar path shortly.

It's finally reasonable to start now = progress in the L3 solution space : the basic VR and 2547 WG drafts = have been waiting long time that L3 requirements and L3 framework make = their way to RFC status. 

We are then calling here a TWO-WEEK WG = LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt (to standard track). = We associate it with a corresponding two-week WG Last Call on the = related Applicability = Statement           = draft-ietf-ppvpn-as2547-01.txt.

NOTE : a similar call will be done = separately for the basic VR WG draft and related AS WG draft.
Thanks for your comments on the list. = The call will end on Friday May 16th.

Marco and Rick

P.S. Following steps in the L3 space = (hopefully soon) will consider the VR and 2547 related MIBs and the = complementary 2547-related solution drafts. 

L2 space : L2 requirements and L2 = framework WG drafts will be considered soon for progress. And, = obviously, we will come back ASAP to the list about expected WG = document progress in the solution space. 





 





------_=_NextPart_001_01C310FC.06746440-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 2 22:19:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09639 for ; Fri, 2 May 2003 22:19:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h432JrN00814 for ; Fri, 2 May 2003 22:19:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h432Joi22888 for ; Fri, 2 May 2003 22:19:50 -0400 (EDT) Date: Fri, 2 May 2003 19:14:39 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <51133594448.20030502191439@psg.com> To: ppvpn@nortelnetworks.com Subject: On BGP and VPLS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks, As an Area Director, and an IESG member, I try to express my technical opinions during WG discussions only when it really matters, e.g., when I think a WG is going in a wrong direction, or a technically bad idea is being considered. However, I believe that ADs do need to do this to prevent surprises when documents get to the IESG. Also, when documents are ready to go to the RFC status, it is the responsible AD who takes them to the IESG and defends them there, so I think it is useful for ADs to communicate their concerns to the WGs when such exist. I have been watching the discussion about draft-kompella-ppvpn-vpls on the mailing list and didn't get the feeling that certain aspects of it have been taken seriously enough. Without an attempt to respin the heated discussion again, it seems it would be useful for the WG if I provided some feedback on the topic now, when the WG is discussing the direction in which it should proceed. First of all, let me remind you the message Scott and I brought to the WG in Yokohama--the IESG is very concerned about the tendency of using routing protocols (and BGP in particular) as a universal transport mechanism, and a _very_ strong case would need to be made if the WG decided to go with such a proposal. More specifically, below I tried to put together a list of concerns I have about the approach described in draft-kompella-ppvpn-vpls, that I would like the WG to consider. 1. Use of the NLRI field As an IP routing protocol, BGP uses the NLRI field to carry IP reachability information in the form of IP prefixes. Prefixes within the NLRI field are used for two main purposes in BGP: a) as the destination/mask pair in the routes installed by BGP in the routing table, and b) as a handle to an entry in the BGP RIBs. The document in subject changes the semantics of the NLRI field quite substantially even when compared to 2547. First, all of its IP prefix-related properties are lost. There is no more IP routing, or any addressing information in it. Second, the notion of TLVs is introduced inside this field, which a) is not needed in BGP as an IP routing protocol, and b) because of its variable length property changes the nature of the NLRI contents, i.e., it's being a stable handle in the BGP database. To solve these problems the implementations would need to use only a part of the contents of the NLRI field as the handle used to index within the RIBs, and store the rest as attributes. 2. Distribution of information When used as an IP routing protocol, BGP distributes routes among all participating routers. Each router (PE or P using VPN terminology) is interested in _all_ routes received from its peers; it selects the best path for each prefix if multiple are available and installs it in it's routing table; the best paths are propagated further to other peers. The way BGP is used in the document results in a situation where information relevant only to a subset of routers (e.g. PW-specific, or VPLS-specific info) is sent to all PEs participating in the BGP domain. More than that, P routers, usually used as route reflectors in IP routing, end up storing all information while they are not using any of it locally. Note also, that best path selection that is normally performed by BGP when it receives information about the same prefix from multiple peers, is not needed in the VPLS case, and (even if implementations decided to apply the same algo as in regular BGP) would just be an artifact. The above exposes the difference between the routing nature of BGP when used for IP (where reachability info is distributed and the path properties are as important as the info itself), and its purely transport application in the proposal (where only the fact of information delivery is important.) Interestingly enough, from the transport perspective, BGP, though reduces the number of sessions a given PE has to maintain (and thus the sender's complexity), introduces additional overhead from the receiver's perspective--if a PE router has multiple BGP sessions (which is normally the case), it will receive the same information more than once, while clearly a single copy is enough. 3. Aggregation of information for large-scale operation When distributing information among a large number of systems, it is important to be able to aggregate information as it travels further ahead to ensure scalability of the system. In routing this is achieved by summarizing a set of prefixes and announcing them as a less specific prefix. For example, AS'es in the Internet do not exchange granular IP prefixes visible inside IGPs, but instead send each other aggregate prefixes via BGP. It is not clear to me how, given the format of the NLRI field, VPLS information can be aggregated using the proposal in the document. The above gives me a very uncomfortable feeling that the proposal is stretching BGP to perform functions it was not designed for. Below are some additional points that should be taken into consideration. 4. Backwards compatibility and SW upgrade requirements Because the proposal suggests using a new AFI/SAFI combination, PE routers will not be able to announce VPLS information using the existing BGP infrastructure. All BGP speakers in a SP's network, including the P routers, will have to be upgraded with new SW, though information needs to be exchanged only among the PEs. 5. Coupling of VPLS and BGP SW Putting VPLS-related functions in BGP leads to two unwanted consequences: a) Lesser BGP code stability--bugs in the VPLS part of the code will likely affect parts of BGP used for Internet routing, thus increasing the chances of BGP failures in SP networks. The same argument works in the opposite direction. b) Potential dynamic effects--since with a BGP-based approach, VPLS- and routing-related processes are likely to share the same internal router resources (such as timers, threads, locks/mutex'es, queues, memory pools), dynamics of the VPLS system are likely to influence the dynamics of the routing- related functions and vice versa. The larger the overlap between the two systems, the higher are the chances of such interference. My recommendation would be for the WG to consider these points. Also, one quite important question I saw brought up by Eric in this discussion was about the p2p nature of PW signaling in VPLS. I think this is one of the key questions that we need an agreement on. The question asked by Robert today is also quite interesting. Regards. -- Alex Zinin IETF SUB-IP Area Co-Director From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 03:32:44 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25338 for ; Sat, 3 May 2003 03:32:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h437YoB26251 for ; Sat, 3 May 2003 03:34:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h437YlR18987 for ; Sat, 3 May 2003 03:34:47 -0400 (EDT) Message-ID: <20030503073228.13995.qmail@web13503.mail.yahoo.com> Date: Sat, 3 May 2003 00:32:28 -0700 (PDT) From: Mark Seery Subject: re: On BGP and VPLS To: zinin@psg.com Cc: PPVPN@NORTELNETWORKS.COM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13503.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: web13503.mail.yahoo.com [216.136.175.82] X-LYRIS-Message-Id: Alex, I think your instinct about engaging sooner rather than later, is correct. Some questions for you: There are (at least) two very distinct environments that VPLS is targeted at. There is of course the case of a stand-alone ISP for which an "optimal solution could be provided". There is also the case of complex orgainzations that have an ISP that might be already offering L3VPN and be very comfortable with BGP4 technology, and perhaps not already using LDP, and now wants to add VPLS. This is very different from the organization that wants to build a new network with VPLS as the initial offering, and wants to maintain characteristics of other layer 2 services offered within that organization (perhaps a NAP is yet another unique environment). Is it permissable in your eyes to pursue different solutions for these different types of groups, or is one solution what you would steer the group towards? Is operational comfort with an approach to networking a sufficient justification for an approach? For example, if an organization is more comfortable with p2p, from a variety of OAM, billing, and work procedure perspectives, is that sufficient justification for that approach, even though it is arguably less bandwidth efficient? Is a higher standard required? In section 2. you raise the important issue of load on the receiver due to the reception of the same information more than once. Does this ever occur in standard IP/BGP networks? In section 3. you raise the important attribute of scaling - summarization. Would you agree that all inter-domain proposals should address this issue? Also with respect to summarization, is the inability to summarize a function of the proposal in question, or a function of the fact that Ethernet does not have a summarizable address plane/structure (in L3VPNs even though a VPN idenitifer is required IP prefixes are still basically being used - I believe?). So without a good address plane for scalable networking, we are left with signaling names: VE IDs, PE IDs, VPLS IDs, Group IDs etc. What we are really dealing with here is members of a set, not subnetworks. Do we qualify these names? Do we create relationships for sets, and subsets,......Seems like this basic issue has to be dealt with. So strangely enough, multicast (where PEs in a VPLS are in the same multicast group) addresses this issue very nicely - if we stick to the concept of a LAN segment. If we continue to put more and more bridging functionality within a PE, then I think multicast is limited in its ability to address this problem, i.e. how many members are there in each multicast group when every PE is a bridge? More generally, a number of people have suggested inter-domain and intra-domain work/requirements be separated - what are your thoughts on that issue? Do you think there might be other important inter-domain issues that should be considered? Is it fair to drill down on one inter-domain issue until all the requirements have been laid out? WRT point 5. Coupling of VPLS and BGP SW. Is it your assertion that any software implementation is going to have the problem described in 5 b), or just that the installed base of software would have this problem and therefore that is sufficient reason to be concerned. Lastly, the "L2PE" concept introduced in this proposal is important I believe to maintain, as it allows for a constructive separation of functionality allowing routers as we know them today to be productively put to work; so whatever the result of your particular questions, it would be good to see this concept preserved in some fashion. Thanks, Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 04:05:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25795 for ; Sat, 3 May 2003 04:05:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h43883B04873 for ; Sat, 3 May 2003 04:08:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4387w005552 for ; Sat, 3 May 2003 04:07:59 -0400 (EDT) Date: Sat, 3 May 2003 01:05:20 -0700 (PDT) Message-Id: <200305030805.h4385Kd51107@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: ppvpn@nortelnetworks.com, idr@merit.edu Subject: On BGP and VPLS In-Reply-To: <51133594448.20030502191439@psg.com> References: <51133594448.20030502191439@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit [crossposted to idr WG mailing list] Alex Zinin writes: > More specifically, below I tried to put together a list of concerns > I have about the approach described in draft-kompella-ppvpn-vpls, > that I would like the WG to consider. > 1. Use of the NLRI field > As an IP routing protocol, BGP uses the NLRI field to carry IP > reachability information in the form of IP prefixes. Prefixes within > the NLRI field are used for two main purposes in BGP: a) as the > destination/mask pair in the routes installed by BGP in the routing > table, and b) as a handle to an entry in the BGP RIBs. > The document in subject changes the semantics of the NLRI field > quite substantially even when compared to 2547. First, all of its IP > prefix-related properties are lost. There is no more IP routing, or > any addressing information in it. Second, the notion of TLVs is > introduced inside this field, which a) is not needed in BGP as an IP > routing protocol, and b) because of its variable length property > changes the nature of the NLRI contents, i.e., it's being a stable > handle in the BGP database. To solve these problems the > implementations would need to use only a part of the contents of the > NLRI field as the handle used to index within the RIBs, and store > the rest as attributes. Alex, This point seems to be predicated in the statement that "BGP uses the NLRI field to carry IP reachability"... It opens up a sort of philosophical discussion on BGP. This is of course a highly subjective topic which is hard to quantify or to prove by logical terms. Allow me to present my personal view. BGP is a particular implementation of an algorithm that performs non looping database flooding distribution. That algorithm consists mostly on the path vector (used both in ebgp and route reflection) plus route advertisement rules. This is the publicly specified part of the beast. However that ends up being about 10% of the database exchange algorithm. Each implementation uses distinct algorithms to do the real heavy lifting: the advertisement of database updates to its peers, given that each peer is allowed to flow control and that the ammount of information to be distributed is typically non-trivial compared to the resources of the system. None of the functions above actually do depend on the format of your database records. As long as there is a primary key associated with each record. Modern implementations, given that they are required to handle 3/4 different types of records w/ different keys (ipv4, ipv6, 2547, 2547-for-ipv6, etc) will tend to treat these keys just as database systems do: as a bit string without any semantics associated w/ it. Note also that the number of distinct tables exchanged in a 2547 implementation may be in the thousands. So segregation of which record belongs to which table is necessarily a solved problem in practice. There is one part of BGP that however interacts w/ the semantics of the particular database being exchanged: route selection from the Loc-RIB. The Loc-RIB is by definition where BGP interacts w/ remaining users of the database and it includes rules that are system specific. As an exercise, if we take the existing spec and do: s/route/record/g s/IP prefix/key/g Do we still have a document that makes sense.. ? Except for the vague bits about aggregation, about which BGP itself does little about, i would contend that the result would be pretty much the same. 2547 which you cite is a particular good example, imho. A 2547 NLRI ends up being used to create IP reachability information, but while it is a safi 128 record, it is not IP reachability and it is not treated as such. > 2. Distribution of information > When used as an IP routing protocol, BGP distributes routes among > all participating routers. Each router (PE or P using VPN > terminology) is interested in _all_ routes received from its peers; > it selects the best path for each prefix if multiple are available > and installs it in it's routing table; the best paths are propagated > further to other peers. That is not the case w/ 2547. PE routers typically have interest in only a subset of the routing information. They tend to do inbound filtering in current network deployements but one can also do outbound filtering in the RRs via either extended-community ORF or subsequent improvements to ORF (draft-marques-ppvpn-rt-contrain). P routers do not carry 2547 routing information. > The way BGP is used in the document results in a situation where > information relevant only to a subset of routers (e.g. PW-specific, > or VPLS-specific info) is sent to all PEs participating in the BGP > domain. More than that, P routers, usually used as route reflectors > in IP routing, end up storing all information while they are not > using any of it locally. RR in VPN deployments are typically not in the topology. My understanding of the P-router term is that it is a transit node that does not have VPN information. > Note also, that best path selection that is normally performed by > BGP when it receives information about the same prefix from multiple > peers, is not needed in the VPLS case, and (even if implementations > decided to apply the same algo as in regular BGP) would just be an > artifact. Not really... i can advertise the same key from multiple sources in L2VPNs also. All policy mechanisms do work... igp distance, etc. It is just the semantics once the path is selected that are different. As an example think working and protect PE for a given emulated circuit (or lan). > The above exposes the difference between the routing nature of > BGP when used for IP (where reachability info is distributed and the > path properties are as important as the info itself), and its purely > transport application in the proposal (where only the fact of > information delivery is important.) > Interestingly enough, from the transport perspective, BGP, though > reduces the number of sessions a given PE has to maintain (and thus > the sender's complexity), introduces additional overhead from the > receiver's perspective--if a PE router has multiple BGP sessions > (which is normally the case), it will receive the same information > more than once, while clearly a single copy is enough. I don't know which model you have in mind but in a typical VPN deployment scenario (l3 or l2/vpls/etc) a PE has 2 peering sessions to a RR outside of the topology. The second copy of the information is there for redudancy... If a full mesh where used, only 1 copy would be present. > 3. Aggregation of information for large-scale operation > When distributing information among a large number of systems, it > is important to be able to aggregate information as it travels > further ahead to ensure scalability of the system. In routing this > is achieved by summarizing a set of prefixes and announcing them as > a less specific prefix. For example, AS'es in the Internet do not > exchange granular IP prefixes visible inside IGPs, but instead send > each other aggregate prefixes via BGP. > It is not clear to me how, given the format of the NLRI field, > VPLS information can be aggregated using the proposal in the > document. To give you an example, in JunOS aggregation is implemented as a separate routing protocol... if i'm not mistaken the model is lifted from 'gated'. Clearly the idea that aggregation may be a distinct component from BGP has been around for a while. VPLS doesn't really need aggregation although it does use an IGP :-) PE to PE connectivity is performed indepently from the 'forwarding distinguisher' advertisement (i.e. the inner label). Any or multiple routing and singaling protocols may be used for this functionality. Only the information exterior to the SP network (service attachements) is carried through BGP. > The above gives me a very uncomfortable feeling that the proposal > is stretching BGP to perform functions it was not designed for. Any succesful protocol will be used for means other than it was designed for. That is usually a sign that the designers got something right. Let me give you an example: BGP is currently used to block spam propaggating networks/hosts. What this an original goal of the design ? Hardly. When used to block spam BGP does not advertise any valid forwarding information for instance. And i'm sure it is a question of time until we add port information to the record keys. > Below are some additional points that should be taken into > consideration. > 4. Backwards compatibility and SW upgrade requirements > Because the proposal suggests using a new AFI/SAFI combination, > PE routers will not be able to announce VPLS information using the > existing BGP infrastructure. All BGP speakers in a SP's network, > including the P routers, will have to be upgraded with new SW, > though information needs to be exchanged only among the PEs. That is not an issue as we've seen above. The deployment model is different from what you assume. > 5. Coupling of VPLS and BGP SW > Putting VPLS-related functions in BGP leads to two unwanted > consequences: > a) Lesser BGP code stability--bugs in the VPLS part of the code > will likely affect parts of BGP used for Internet routing, thus > increasing the chances of BGP failures in SP networks. The same > argument works in the opposite direction. You have no basis to conclude that. Any modern BGP implementation worth its salt consists of AF-independent code + AF-specific code. The fact is that you can implement VPLS without touching the AF-independent code. Any line of code change that you make to an implementation as the potential to introduce bugs... > b) Potential dynamic effects--since with a BGP-based approach, > VPLS- and routing-related processes are likely to share the same > internal router resources (such as timers, threads, locks/mutex'es, > queues, memory pools), dynamics of the VPLS system are likely to > influence the dynamics of the routing- related functions and vice > versa. The larger the overlap between the two systems, the higher > are the chances of such interference. I'm sorry but this is just FUD. All router implementations do have some level of resource sharing between completly unrelated features. In some of them, all functionality shares all resources. Don't want BGP sharing timers w/ X.25-over-TCP... disable one of them. > My recommendation would be for the WG to consider these points. The way i see it there is an high likely-hood of this turning into an "Yes, it is" "No, it isn't" discussion. And I'd really like to avoid that. A question to you and to the WG(s) in general: - What are the main concerns that you have w/ the generic database exchange view of BGP (Lets call it the "Basically General Purpose" theory). - Can we have a reasonable discussion about the best engineering approach to provide database exchange services for routing-related-applications without getting into a religious argument about "2547 is evil" ? i.e. can we try to separate how highly each one of us rates the actual application from this discussion ? - I believe one of the preconditions for a resonable discussion is to realise that implementors are the most interested people in not introducing regressions to shipping code. They actually get to fix it after being screamed at for a considerable lenght of time. I'd really like to get past the "you can't implement a feature i don't want because your are going to break the code" kind of discussion. - Are we going to have a similiar discussion about LDP ? LDP is not any less relevant for network stability nor a protocol which is any simpler than BGP (if anything the level of complexity is higher given that LDP has all the db exchange problem of BGP + a non trivial ammount of issues of its own). regards, Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 04:54:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26195 for ; Sat, 3 May 2003 04:54:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h438u3B09738 for ; Sat, 3 May 2003 04:56:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h438txO13606 for ; Sat, 3 May 2003 04:55:59 -0400 (EDT) Date: Sat, 3 May 2003 01:53:39 -0700 (PDT) Message-Id: <200305030853.h438rdN51183@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Seery Cc: PPVPN@NORTELNETWORKS.COM Subject: re: On BGP and VPLS In-Reply-To: <20030503073228.13995.qmail@web13503.mail.yahoo.com> References: <20030503073228.13995.qmail@web13503.mail.yahoo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark Seery writes: > More generally, a number of people have suggested inter-domain and > intra-domain work/requirements be separated - what are your thoughts > on that issue? Do you think there might be other important > inter-domain issues that should be considered? Is it fair to drill > down on one inter-domain issue until all the requirements have been > laid out? Just a particular comment here... The argument that was constructed to justify the separation of inter and intra domain is one that imho is rather sketchy... The assertion was that as IP routing uses inter and inter domain protocols so should VPLS. The point that is missing in the argument is that VPLS already does that by separating the signaling/routing of PE-PE tunnels (LSPs) and 'forwarding designators' used for exterior traffic (so called Private Wires in a particular view of the world). The PE-PE LSP can be signaled using any mechanism: LDP, RSVP-TE, labeled-BGP on ASBR/ASBR boundaries, etc. In IP routing, exterior routes are not redistributed into IGPs (and typically vice-versa: an aggregate route is advertised given the presence of a more specific IGP route). There are many reasons not to redistriute 'exterior' information into IGPs but i would sumarize it as a separation of the task of learning the internal SP topology vs the external topology. In the case of VPNs, the external topology is the information about customer attachement points (and routes for L3VPN). Having distinct mechanisms for VPLS attachements that happen to belong to your AS and those than do not, is not necessarly a good idea. There is hardly any reason for a PE to know that for instance or have to deal w/ 2 different mechanisms. There may be other arguments to go that route but i don't think this is a valid one. It seems to me that the unstated argument, which may or may not be valid, is that "at the moment i'm not terribly concerned about the problem, lets get something working first". However it ends up coming back to potential reasons why pick LDP over BGP for signaling... the major technical advantage of a BGP based solution is that BGP has mechanisms to distribute the information more than one hop away. My very personal opinion is that we cannot, at this point resolve this as a tecnical issue. What ends up carrying more weight at this particular point w/ those that are entitled to make the decision (service providers) is mostly familiarity w/ the precursors of both proposals. This is actually a very reasonable position given that there is much more required to deploy a workable solution than just what ends up being described in this particular set of proposals. My guess is that the issues that people that work for equipement vendors have been focusing the most on on this particular discussion are rather small concerns when it comes to actually deploy a production network. "How can i fit a solution in existing network design and provisioning tools ?" may be a question more in the minds of SPs... This discussion started w/ the request to elevate both proposals to WG document status... it seems to me that the circularity of the discussion has proven that there is no strong argument to select one proposal over the other at this point. Personally, i believe that it would be best for the group to focus on completly both solutions further. I am under the impression, perhaps mistakenly, that there are few issues that have not been addressed. I'm sure that as SP gain more experience w/ implementation of both solutions that we will be able to discuss issues in less abstract terms than P-t-P and MP-t-P signaling ;-) thanks, Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 05:20:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26371 for ; Sat, 3 May 2003 05:20:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h439N0B21888 for ; Sat, 3 May 2003 05:23:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h439MvQ02555 for ; Sat, 3 May 2003 05:22:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16051.35384.861699.486223@harjus.eng.song.fi> Date: Sat, 3 May 2003 12:22:00 +0300 To: Pedro Roque Marques Cc: Mark Seery , PPVPN@nortelnetworks.com Subject: re: On BGP and VPLS In-Reply-To: <200305030853.h438rdN51183@roque-bsd.juniper.net> References: <20030503073228.13995.qmail@web13503.mail.yahoo.com> <200305030853.h438rdN51183@roque-bsd.juniper.net> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Pedro Roque Marques writes: > My very personal opinion is that we cannot, at this point resolve this > as a tecnical issue. What ends up carrying more weight at this > particular point w/ those that are entitled to make the decision > (service providers) is mostly familiarity w/ the precursors of both > proposals. i fully agree. if iesg starts to weight solutions based on their technical merit or purity, it makes itself irrelevant. the "market" has already decided (by the help of the big marketing muscle of major router vendors) that bgp/mpls is a good way to implement vpns. if some small players like me don't like the idea of requiring bgp and mpls for vpns, but would prefer a directory (radius) and ip based solution instead, they don't have any chance to get their message through. iesg is in the same boat and it better shut up or loose its face. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 12:06:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02321 for ; Sat, 3 May 2003 12:06:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h43G86B19554 for ; Sat, 3 May 2003 12:08:07 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h43G83913731 for ; Sat, 3 May 2003 12:08:03 -0400 (EDT) Message-ID: <20030503160550.80052.qmail@web13507.mail.yahoo.com> Date: Sat, 3 May 2003 09:05:50 -0700 (PDT) From: Mark Seery Subject: re: On BGP and VPLS To: Pedro Roque Marques Cc: PPVPN@NORTELNETWORKS.COM In-Reply-To: <200305030853.h438rdN51183@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13507.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: web13507.mail.yahoo.com [216.136.175.86] X-LYRIS-Message-Id: Pedro, Thank you for your well thought out comments. >> It seems to me that the unstated argument, which may or may not be valid, is that "at the moment i'm not terribly concerned about the problem, lets get something working first". << This is indeed the unstated argument and a very relevant one. There are SPs who are wishing to go implement VPLS, and I suspect (very strongly) that many of these SPs are no where near having to worry about inter-domain issues. Which, IMO, is a strong reason for removing the distraction of inter-domain requirements from the debate, and allowing intra-domain solution(s) to progress. WRT to the thrust of your argument. You present interesting view points. I would however suggest, that unless a robust debate occurs on inter-domain requirements, it can not be said with assurity that there are none. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 21:28:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12391 for ; Sat, 3 May 2003 21:28:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h441UvB16980 for ; Sat, 3 May 2003 21:30:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h441UsH13399 for ; Sat, 3 May 2003 21:30:54 -0400 (EDT) Date: Sat, 3 May 2003 18:23:22 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7011156071.20030503182322@psg.com> To: Mark Seery CC: PPVPN@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: <20030503073228.13995.qmail@web13503.mail.yahoo.com> References: <20030503073228.13995.qmail@web13503.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark, Thanks for your message. You asked several questions that I think the WG should discuss, so what I'll do is take some of them to separate threads and answer the rest here. See below, please. > I think your instinct about engaging sooner rather > than later, is correct. Some questions for you: > There are (at least) two very distinct environments > that VPLS is targeted at. There is of course the case > of a stand-alone ISP for which an "optimal solution > could be provided". There is also the case of complex > orgainzations that have an ISP that might be already > offering L3VPN and be very comfortable with BGP4 > technology, and perhaps not already using LDP, and now > wants to add VPLS. This is very different from the > organization that wants to build a new network with > VPLS as the initial offering, and wants to maintain > characteristics of other layer 2 services offered > within that organization (perhaps a NAP is yet another > unique environment). Is it permissable in your eyes to > pursue different solutions for these different types > of groups, or is one solution what you would steer the > group towards? I believe the goal for the WG should be to work out a single solution. Regarding the considerations you mention above, in my opinion it would be wrong for us to start the discussion by saying "SPs have X and Y deployed in their networks, so we just have to decide whether we piggy-back on X or on Y." Instead I'd like to see a discussion ala "What are the functions we need? How can we best implement them? Do we have an existing protocol that would be the right fit for this functionality or do we need a new one(s)?" > Is operational comfort with an approach to networking > a sufficient justification for an approach? For > example, if an organization is more comfortable with > p2p, from a variety of OAM, billing, and work > procedure perspectives, is that sufficient > justification for that approach, even though it is > arguably less bandwidth efficient? Is a higher > standard required? I don't believe operational comfort alone is enough of a justification. I think we need a technically strong solution. > In section 2. you raise the important issue of load on > the receiver due to the reception of the same > information more than once. Does this ever occur in > standard IP/BGP networks? Well, in the IP/BGP case, it is not necessarily the same info, as path attributes are likely to be different and the BGP speaker is interested in selecting the best among them while preserving others as the back-up. In the VPLS case, we don't need the best, just one copy is sufficient. This is not necessarily an issue per se, rather an interesting observation exposing the transport nature of this particular proposed application of BGP. We have similar properties (more than one copy received) in the flooding algorithm in IGPs, but we admit that flooding is a transport component very specific to IGPs (where every node needs all info, btw), and we don't keep track of where we receive PDUs from as we do in BGP. > In section 3. you raise the important attribute of > scaling - summarization. Would you agree that all > inter-domain proposals should address this issue? I took this one to a separate thread. > More generally, a number of people have suggested > inter-domain and intra-domain work/requirements be > separated - what are your thoughts on that issue? Same with this one. > WRT point 5. Coupling of VPLS and BGP SW. Is it your > assertion that any software implementation is going to > have the problem described in 5 b), or just that the > installed base of software would have this problem and > therefore that is sufficient reason to be concerned. Installed base is definitely an important consideration. However, I tend to look at this more broadly--putting VPLS functionality in BGP increases the chances of interference. Some consider this a strictly implementation-specific issue. I think that whether or not VPLS-specific functionality is sufficiently decoupled from base BGP is an implementation aspect; while increased risk of interference is an architectural one. > Lastly, the "L2PE" concept introduced in this proposal > is important I believe to maintain, as it allows for a > constructive separation of functionality allowing > routers as we know them today to be productively put > to work; so whatever the result of your particular > questions, it would be good to see this concept > preserved in some fashion. I did not have comments on this particular part. Thanks again. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 21:34:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12491 for ; Sat, 3 May 2003 21:34:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h441aNB21816 for ; Sat, 3 May 2003 21:36:23 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h441aJH18681 for ; Sat, 3 May 2003 21:36:20 -0400 (EDT) Date: Sat, 3 May 2003 18:28:05 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9911438888.20030503182805@psg.com> To: PPVPN@nortelnetworks.com Subject: Intra-domain & inter-domain MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark Seery wrote: ... > More generally, a number of people have suggested > inter-domain and intra-domain work/requirements be > separated - what are your thoughts on that issue? Do > you think there might be other important inter-domain > issues that should be considered? Is it fair to drill > down on one inter-domain issue until all the > requirements have been laid out? I think it would be wise if we tackled the intra-domain case first, while keeping the potential inter-domain issues in mind. I.e., take one step at a time, but be reasonably sure that we're moving in the right direction by having some estimation of the overall framework in the head. The reason I drilled down on one inter-domain issue (info summarization) is to bring attention to the fact that using BGP does not automagically mean a scalable solution. So, yes, I think it is fair to do so. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 21:35:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12513 for ; Sat, 3 May 2003 21:35:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h441cHB23935 for ; Sat, 3 May 2003 21:38:17 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h441cDH21061 for ; Sat, 3 May 2003 21:38:13 -0400 (EDT) Date: Sat, 3 May 2003 18:27:34 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1611408344.20030503182734@psg.com> To: PPVPN@nortelnetworks.com Subject: Info aggregation MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark Seery wrote: ... > In section 3. you raise the important attribute of > scaling - summarization. Would you agree that all > inter-domain proposals should address this issue? Definitely. The point in my message was to identify the difference between the way _BGP_ operates as an IP routing protocol where we know information can be aggregated, and the way _BGP_ would be used for VPLS. Nonetheless, this is an important generic issue I think the WG should discuss. Some data points for discussion below: > Also with respect to summarization, is the inability > to summarize a function of the proposal in question, > or a function of the fact that Ethernet does not have > a summarizable address plane/structure (in L3VPNs even > though a VPN idenitifer is required IP prefixes are > still basically being used - I believe?). So without a > good address plane for scalable networking, we are > left with signaling names: VE IDs, PE IDs, VPLS IDs, > Group IDs etc. What we are really dealing with here is > members of a set, not subnetworks. Do we qualify these > names? Do we create relationships for sets, and > subsets,......Seems like this basic issue has to be > dealt with. Indeed. Some more questions here: when taken to a large scale (not necessarily just one VPLS) o what VPLS info from other AS'es do PEs need to know? o given the edge-to-edge nature of PWs, is it feasible to summarize signalling information among AS'es at all? o if not, how do we scope distribution of signalling info so amount of info per participating node has reasonable growth characteristics? o is it feasible to summarize VPLS membership information among AS'es? o how do we get discovery, signaling, and data plane to work together in a scalable form? This topic is related to the one about whether intra-AS and inter-AS problem spaces should be addressed separately, which I will also comment on. Alex > So strangely enough, multicast (where PEs > in a VPLS are in the same multicast group) addresses > this issue very nicely - if we stick to the concept of > a LAN segment. If we continue to put more and more > bridging functionality within a PE, then I think > multicast is limited in its ability to address this > problem, i.e. how many members are there in each > multicast group when every PE is a bridge? From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 22:45:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13109 for ; Sat, 3 May 2003 22:45:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h442lDB09844 for ; Sat, 3 May 2003 22:47:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h442l9412235 for ; Sat, 3 May 2003 22:47:10 -0400 (EDT) Date: Sat, 3 May 2003 19:36:55 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2415569617.20030503193655@psg.com> To: Juha Heinanen CC: Pedro Roque Marques , Mark Seery , PPVPN@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: <16051.35384.861699.486223@harjus.eng.song.fi> References: <20030503073228.13995.qmail@web13503.mail.yahoo.com> <200305030853.h438rdN51183@roque-bsd.juniper.net> <16051.35384.861699.486223@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Juha, I think you might be confusing the IETF with the market. However, this discussion is well outside the scope of this WG, and if you'd like to continue it, I suggest we take it to the IETF problem statement mailing list (problem-statement@alvestrand.no). So far, I am not shutting up and will continue steering the Internet engineering process. -- Alex http://www.psg.com/~zinin/ Saturday, May 3, 2003, 2:22:00 AM, Juha Heinanen wrote: > Pedro Roque Marques writes: > > My very personal opinion is that we cannot, at this point resolve this > > as a tecnical issue. What ends up carrying more weight at this > > particular point w/ those that are entitled to make the decision > > (service providers) is mostly familiarity w/ the precursors of both > > proposals. > i fully agree. if iesg starts to weight solutions based on their > technical merit or purity, it makes itself irrelevant. the "market" has > already decided (by the help of the big marketing muscle of major router > vendors) that bgp/mpls is a good way to implement vpns. if some small > players like me don't like the idea of requiring bgp and mpls for vpns, > but would prefer a directory (radius) and ip based solution instead, > they don't have any chance to get their message through. iesg is in the > same boat and it better shut up or loose its face. > -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 3 23:28:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13579 for ; Sat, 3 May 2003 23:28:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h443UuB17830 for ; Sat, 3 May 2003 23:30:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h443Ur924188 for ; Sat, 3 May 2003 23:30:53 -0400 (EDT) Message-ID: <20030504032851.41287.qmail@web13506.mail.yahoo.com> Date: Sat, 3 May 2003 20:28:51 -0700 (PDT) From: Mark Seery Subject: re: Intra-domain & inter-domain To: zinin@psg.com Cc: PPVPN@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13506.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: web13506.mail.yahoo.com [216.136.175.85] X-LYRIS-Message-Id: Alex, >> The reason I drilled down on one inter-domain issue (info summarization) is to bring attention to the fact that using BGP does not automagically mean a scalable solution. So, yes, I think it is fair to do so. << Fair enough, and point taken. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 4 03:15:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26911 for ; Sun, 4 May 2003 03:14:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h447Gwr07790 for ; Sun, 4 May 2003 03:16:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h447GsH01939 for ; Sun, 4 May 2003 03:16:55 -0400 (EDT) Date: Sun, 4 May 2003 00:11:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2032066549.20030504001152@psg.com> To: ppvpn@nortelnetworks.com CC: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: IMPORTANT: Strategy for VPN work in IETF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks, Since San Francisco IETF meeting the IESG has been considering the situation in the SUB-IP area and in the PPVPN Working Group in particular. Such close attention to this WG was triggered by numerous concerns that the IESG members received from the WG participants about limited and slow progress within the WG despite the efforts of the WG chairs and its members. The IESG also used this opportunity to consider the IETF area that the PPVPN work would fit best. After much deliberation, the involved ADs (Bert, Thomas, and I) are considering the following organizational changes in order to improve WG focus and productivity and ensure faster progress of the VPN-related work: 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. The L2 and L3 VPN work spaces are each big enough to warrant a separate WG. While concentration of all VPN-related work in a single forum was the right thing to do to ensure coordination of efforts when the PPVPN WG was created and L2 VPN work came in, such concentration is causing scaling problems within the WG at this moment. Migration of work into two separate WGs for L2 and L3 VPN technologies with more specific WG charters will help to focus discussions, prevent staff and meeting time overloading, and will aid faster progress of corresponding technologies. 2. Migration of the VPN-related work to the Internet area. As previously discussed, VPN-related work could be argued to belong to more than one area. Tunneling mechanisms are the property that gravitates this work to the Internet area, which is where we believe the VPN work should go. As part of this move, we are also considering moving PWE3 into INT, so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the same area. Based on the above considerations, we are considering the following steps: 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. The mailing lists will be established and the discussion of the proposed charters of the new WGs will be initiated shortly. 2. Once the charters of the new WGs are agreed upon and approved by the IESG, creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will be performed simultaneously. PPVPN WG documents will be migrated to the corresponding new WGs. It is our intention to complete this process by the Vienna IETF meeting. Also, these changes are being made for management reasons and are not intended to be a "reset" on WG activities or to halt or interrupt progress on current ongoing WG activities. We'd like to hear from the WG members if they see any fatal flaws with the proposed approach. Please send us your feedback by May 11th. Regards, -- Alex Zinin IETF SUB-IP Area Co-Director From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 4 08:14:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28871 for ; Sun, 4 May 2003 08:14:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h44CGpr28818 for ; Sun, 4 May 2003 08:16:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h44CGkV21353 for ; Sun, 4 May 2003 08:16:47 -0400 (EDT) Message-ID: <4t8n5n496$491ud2u@a20.sk533j> From: "Cecilia Dennis" To: Subject: Now is the time .................... durango Date: Sun, 04 May 03 18:10:48 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".FD_6_BE000_3_1BAD2B02." X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: 47.234.0.32 X-SMTP-MAIL-FROM: annamckelvey@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [212.253.129.11] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --.FD_6_BE000_3_1BAD2B02. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
   How would you feel about some quick
   Debt Relief with N= O credit check or
   hom= eowner requirement?  Easy and fast! 
 
     petroleumGuaranteed to
   Lower Your Monthly Payments by Up= To 80%  
One minute = quotes - no obligation - totally free
 
 
 

Please note that we do n= ot want to send you information regarding our special offers if you do not w= ish to receive it. If you would no longer like us to contact you or you fee= l that you have received this email in error, you may go here to unsubscribe.

sue = i conscript hatfield
courage eternity articulate clive proposal nutate
ambrose edwardine decorticate cosponsor st panic

--.FD_6_BE000_3_1BAD2B02.-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 4 16:26:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06123 for ; Sun, 4 May 2003 16:25:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h44KS8r28878 for ; Sun, 4 May 2003 16:28:08 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h44KS5G25865 for ; Sun, 4 May 2003 16:28:06 -0400 (EDT) Message-Id: <200305042024.h44KOwKK052346@mailserver2.hushmail.com> Date: Sun, 4 May 2003 13:24:58 -0700 To: ppvpn@nortelnetworks.com Cc: problem-statement@alvestrand.no Subject: Strategy for VPN work in IETF From: X-SMTP-HELO: smtp3.hushmail.com X-SMTP-MAIL-FROM: auto92679@hushmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp3.hushmail.com [65.39.178.33] X-LYRIS-Message-Id: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Zinin writes: > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group in > particular. > Such close attention to this WG was triggered by numerous concerns > thatthe IESG members received from the WG participants about limited > and slow progress within the WG despite the efforts of the WG chairs > and its members. The IESG also used this opportunity to consider > the IETF area that the PPVPN work would fit best. > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to > improve WG focus and productivity and ensure faster progress of the > VPN-related work: > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > The L2 and L3 VPN work spaces are each big enough to warrant a > separate WG. While concentration of all VPN-related work in a > single forum was the right thing to do to ensure coordination > of efforts when the PPVPN WG was created and L2 VPN work came in, > such concentration is causing scaling problems within the WG at > this moment. > Migration of work into two separate WGs for L2 and L3 VPN > technologies with more specific WG charters will help to focus > discussions, prevent staff and meeting time overloading, and will > aid faster progress of corresponding technologies. Alex, The proposed solution ignores the origins of the problem. The fact that PPVPN has been making any progress at all, despite the bureaucracy imposed on it by the IESG is rather comendable. This is a typically example of a WG which was setup despite many architectural objections that it doesn't fit in the "internet" design. One cannot help but to suspect that there was the hope ammoung the inner circles that it would fail altogether. At least giving the ammount of "framework" nonsense required and the interdiction to discuss solutions before a framework is agreed upon. The work of this working group is particularly harder given that this is todays "fashion" area... work is much harder on such areas (like mpls was a couple of years ago). One would suspect that the IESG efforts to slow the WG steem also from concerns that fashion areas tend to create a fair ammount of nonsense proposals most of which tend to be naturally eliminated by the WGs. Given the environment the performance of the ppvpn WG seems to me to rather positive. It has actually come up with several documents that are useful and deserve publication. One of the reasons given here for this proposed disolution of the WG is that the "L2VPN and L3VPN work spaces are big enought". However both in the list and WG meetings it seems to me that the current l3vpn WG is close to 0. The base document on l3vpn has been rather stable for a while and it is not likely to change. The IESG/inner-circle has chosen for mostly ideological reasons to attempt to marginalize this work so it can hardly expect to be heard now. It seems to me that if there is a problem w/ PPVPN that problem lies within the IESG itself. As such i would like to propose to split the IESG in two WGs: one that concerns itself w/ architecture and one group that concerns itself with the process of documenting interoperable solutions that are not known to be good or bad ideas until used in pratice. This latter group should have the task to assure that the process is fair and that both the pluses and minus of a solution are considered and documented. One of the ideal caractheristics of the latter group would be if they where to realize that by definition an IESG member is much less of an expert in a given domain than the membership of the WG it steers. It is humanly impossible for it to be otherwise. Unless you assume that the membership of WG is 100% incompetent which is never the case. A steerer cannot possibly be an expert in 20 groups it oversees... usually it can't even keep up with the problems and technology due to the fact that there is only 24 hours in each day. In the rather arrogant terms of internet engineering, the IESG is by definition the set of people that are "clueless". It is not possible for it to be the other way around. No matter how wise and inteligent IESG memebers are... It is necessarly that the IESG understands that latter point and restricts its job to document in a timely manner interoperable solutions for the problems at hand regardless of personal opinion on the value of such problems and technologies. - ---- -----BEGIN PGP SIGNATURE----- Version: Hush 2.2 (Java) Note: This signature can be verified at https://www.hushtools.com/verify wl4EARECAB4FAj61dxQXHGF1dG85MjY3OUBodXNobWFpbC5jb20ACgkQEMGDJWtDWfpc ewCfaWN5FVNhieXVzimDk9cNYOZlgKAAnj3Hf8eWFmikSCDmAw1eMQVdEUb/ =GLPS -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 4 17:45:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07046 for ; Sun, 4 May 2003 17:44:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h44Ll8r06808 for ; Sun, 4 May 2003 17:47:08 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h44Ll4m10640 for ; Sun, 4 May 2003 17:47:04 -0400 (EDT) Date: Sun, 4 May 2003 23:44:48 +0200 Message-Id: Subject: =?iso-8859-1?Q?unsubscribe?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?dariobalmas@libero.it?=" To: "=?iso-8859-1?Q?ppvpn?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 151.25.209.203 X-SMTP-HELO: smtp1.libero.it X-SMTP-MAIL-FROM: dariobalmas@libero.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp1.libero.it [193.70.192.51] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07046 unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 4 23:13:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11982 for ; Sun, 4 May 2003 23:13:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h453FFr06872 for ; Sun, 4 May 2003 23:15:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h453FBQ27891 for ; Sun, 4 May 2003 23:15:12 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E606489D64@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'ppvpn@nortelnetworks.com'" Subject: FW: Re: Strategy for VPN work in IETF Date: Sun, 4 May 2003 23:13:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C312B4.40D58376" X-LYRIS-Message-Id: 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_01C312B4.40D58376 Content-Type: text/plain > Alex, > > This is a really bad idea and will slow down progress in this WG more than > it would speed it up. > > - The L3 VPN work is wrapping up - what you are proposing will create more > churn than it's worth. > - The common VPN building blocks and documents are better suited under a > single WG. > > Also, browsing through the archives of the ppvpn mailing list, I haven't > seen any complaining that indicates there is a problem that warrants > restructuring- So is there really a problem here or is one being creating? > > Bilel. > > > Date: Sun, 4 May 2003 00:11:52 -0700 > Reply-To: Alex Zinin > Sender: PPVPN > From: Alex Zinin > Subject: IMPORTANT: Strategy for VPN work in IETF > Comments: To: ppvpn@nortelnetworks.com > Comments: cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , > Thomas Narten , > "Peterson, Jon" , > Allison Mankin > Content-Type: text/plain; charset=us-ascii > > > Folks, > > > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group in particular. > > > Such close attention to this WG was triggered by numerous concerns that > the IESG members received from the WG participants about limited and > slow progress within the WG despite the efforts of the WG chairs and its > members. The IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to improve WG > focus and productivity and ensure faster progress of the VPN-related work: > > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > > The L2 and L3 VPN work spaces are each big enough to warrant a > separate > WG. While concentration of all VPN-related work in a single forum was > the right thing to do to ensure coordination of efforts when the PPVPN > WG was created and L2 VPN work came in, such concentration is causing > scaling problems within the WG at this moment. > > > Migration of work into two separate WGs for L2 and L3 VPN technologies > with more specific WG charters will help to focus discussions, prevent > staff and meeting time overloading, and will aid faster progress of > corresponding technologies. > > > 2. Migration of the VPN-related work to the Internet area. > > > As previously discussed, VPN-related work could be argued to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where we believe > the VPN work should go. > > > As part of this move, we are also considering moving PWE3 into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the same > area. > > > Based on the above considerations, we are considering the following steps: > > > 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. > The mailing lists will be established and the discussion of the > proposed > charters of the new WGs will be initiated shortly. > > > 2. Once the charters of the new WGs are agreed upon and approved by the > IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will > be > performed simultaneously. PPVPN WG documents will be migrated to the > corresponding new WGs. > > > It is our intention to complete this process by the Vienna IETF meeting. > Also, these changes are being made for management reasons and are not > intended > to be a "reset" on WG activities or to halt or interrupt progress on > current > ongoing WG activities. > > > We'd like to hear from the WG members if they see any fatal flaws with > the proposed approach. Please send us your feedback by May 11th. > > > Regards, > > > -- > Alex Zinin > IETF SUB-IP Area Co-Director > > ------_=_NextPart_001_01C312B4.40D58376 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: Re: Strategy for VPN work in IETF

Alex,

This is a really bad idea and = will slow down progress in this WG more than it would speed it = up.

- The L3 VPN work is wrapping = up - what you are proposing will create more churn than it's = worth.
- The common VPN building = blocks and documents are better suited under a single WG.

Also, browsing through the = archives of the ppvpn mailing list, I haven't seen any complaining that = indicates there is a problem that warrants restructuring- So is there = really a problem here or is one being creating?

Bilel.


Date:         Sun, 4 May 2003 = 00:11:52 -0700
Reply-To:     Alex Zinin = <zinin@psg.com>
Sender:       = PPVPN <PPVPN@NORTELNETWORKS.COM>
From:         Alex Zinin = <zinin@PSG.COM>
Subject:      IMPORTANT: = Strategy for VPN work in IETF
Comments: To: ppvpn@nortelnetworks.com
Comments: cc: pwe3@ietf.org, "Wijnen, Bert = (Bert)" <bwijnen@lucent.com>,
          Thomas = Narten <narten@us.ibm.com>,
          = "Peterson, Jon" <jon.peterson@neustar.biz>,
          Allison = Mankin <mankin@psg.com>
Content-Type: = text/plain; charset=3Dus-ascii


Folks,


Since San Francisco IETF meeting = the IESG has been considering the
situation in the SUB-IP area = and in the PPVPN Working Group in particular.


Such close attention to this WG = was triggered by numerous concerns that
the IESG members received from = the WG participants about limited and
slow progress within the WG = despite the efforts of the WG chairs and its
members. The IESG also used = this opportunity to consider the IETF area
that the PPVPN work would fit = best.


After much deliberation, the = involved ADs (Bert, Thomas, and I) are
considering the following = organizational changes in order to improve WG
focus and productivity and = ensure faster progress of the VPN-related work:


 1. Split of Layer-2 and = Layer-3 VPN work in separate Working Groups.


    The L2 and L3 = VPN work spaces are each big enough to warrant a separate
    WG. While = concentration of all VPN-related work in a single forum was
    the right = thing to do to ensure coordination of efforts when the PPVPN
    WG was = created and L2 VPN work came in, such concentration is causing
    scaling = problems within the WG at this moment.


    Migration of = work into two separate WGs for L2 and L3 VPN technologies
    with more = specific WG charters will help to focus discussions, prevent
    staff and = meeting time overloading, and will aid faster progress of
    = corresponding technologies.


 2. Migration of the = VPN-related work to the Internet area.


    As previously = discussed, VPN-related work could be argued to belong
    to more than = one area. Tunneling mechanisms are the property that
    gravitates = this work to the Internet area, which is where we believe
    the VPN work = should go.


    As part of = this move, we are also considering moving PWE3 into INT,
    so that = L2TPEXT, PWE3, and thew new VPN WGs are operating in the same
    area.


Based on the above = considerations, we are considering the following steps:


 1. Two new WGs--L2VPN and = L3VPN--will be created in the Internet area.
    The mailing = lists will be established and the discussion of the proposed
    charters of = the new WGs will be initiated shortly.


 2. Once the charters of = the new WGs are agreed upon and approved by the IESG,
    creation of = the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will be
    performed = simultaneously. PPVPN WG documents will be migrated to the
    = corresponding new WGs.


It is our intention to complete = this process by the Vienna IETF meeting.
Also, these changes are being = made for management reasons and are not intended
to be a "reset" on WG = activities or to halt or interrupt progress on current
ongoing WG activities.


We'd like to hear from the WG = members if they see any fatal flaws with
the proposed approach. Please = send us your feedback by May 11th.


Regards,


--
Alex Zinin
IETF SUB-IP Area = Co-Director


------_=_NextPart_001_01C312B4.40D58376-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 00:33:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13019 for ; Mon, 5 May 2003 00:33:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h454Zf216753 for ; Mon, 5 May 2003 00:35:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h454ZcX18288 for ; Mon, 5 May 2003 00:35:38 -0400 (EDT) Message-ID: <3EB5E991.5040604@nxp.com> Date: Mon, 05 May 2003 00:33:21 -0400 From: Waldemar Augustyn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: Re: IMPORTANT: Strategy for VPN work in IETF References: <2032066549.20030504001152@psg.com> In-Reply-To: <2032066549.20030504001152@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: smtp01.mrf.mail.rcn.net X-SMTP-MAIL-FROM: waldemar@nxp.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp01.mrf.mail.rcn.net [207.172.4.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Well, as the co-originator, with Tissa, of the L2 VPN work within PPVPN, I would like to say I am glad to see this effort finally recognized as significant. But the two year delay does not impress me. What is being proposed should have been done at that time, two years ago. At the very least, the charter of ppvpn should have been adjusted as it was promised but never done. The good thing is, we were able to progress and we will continue to progress regardless of what IESG does or does not do. It appears, what we're talking about is playing catch up. The issue is really the charter which makes no sense, but I do not see the point of splitting the WG after these years. But, if all we're being asked to do is change a few header lines on our documents, then that's fine. We're easy, glad to make somebody happy. Waldemar Alex Zinin wrote: >Folks, > >Since San Francisco IETF meeting the IESG has been considering the >situation in the SUB-IP area and in the PPVPN Working Group in particular. > [snip] >We'd like to hear from the WG members if they see any fatal flaws with >the proposed approach. Please send us your feedback by May 11th. > >Regards, > >-- >Alex Zinin >IETF SUB-IP Area Co-Director > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 02:02:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15840 for ; Mon, 5 May 2003 02:02:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45648201347 for ; Mon, 5 May 2003 02:04:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45645l19334 for ; Mon, 5 May 2003 02:04:05 -0400 (EDT) X-Originating-IP: [66.7.144.1] X-Originating-Email: [tsenevir@hotmail.com] From: "Tissa Senevirathne" To: "Bilel Jamoussi" , ppvpn@nortelnetworks.com Subject: Re: FW: Re: Strategy for VPN work in IETF Date: Mon, 05 May 2003 06:00:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 May 2003 06:00:30.0023 (UTC) FILETIME=[A1E3D570:01C312CB] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: tsenevir@hotmail.com X-SMTP-RCPT-TO: jamoussi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: bay2-f163.bay2.hotmail.com [65.54.247.163] X-LYRIS-Message-Id: I ditto Bilel here... I Simply can not understand How would this benifit speeding up the closure of work ? Alex you need to convine how you would speed up the things than it is now, given the delay you are just about to induce.. Oh. BTW Who will be the WG chair for the new group ? >From: "Bilel Jamoussi" >To: "'ppvpn@nortelnetworks.com'" >Subject: FW: Re: Strategy for VPN work in IETF >Date: Sun, 4 May 2003 23:13:09 -0400 > > > Alex, > > > > This is a really bad idea and will slow down progress in this WG more >than > > it would speed it up. > > > > - The L3 VPN work is wrapping up - what you are proposing will create >more > > churn than it's worth. > > - The common VPN building blocks and documents are better suited under a > > single WG. > > > > Also, browsing through the archives of the ppvpn mailing list, I haven't > > seen any complaining that indicates there is a problem that warrants > > restructuring- So is there really a problem here or is one being >creating? > > > > Bilel. > > > > > > Date: Sun, 4 May 2003 00:11:52 -0700 > > Reply-To: Alex Zinin > > Sender: PPVPN > > From: Alex Zinin > > Subject: IMPORTANT: Strategy for VPN work in IETF > > Comments: To: ppvpn@nortelnetworks.com > > Comments: cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , > > Thomas Narten , > > "Peterson, Jon" , > > Allison Mankin > > Content-Type: text/plain; charset=us-ascii > > > > > > Folks, > > > > > > Since San Francisco IETF meeting the IESG has been considering the > > situation in the SUB-IP area and in the PPVPN Working Group in >particular. > > > > > > Such close attention to this WG was triggered by numerous concerns that > > the IESG members received from the WG participants about limited and > > slow progress within the WG despite the efforts of the WG chairs and its > > members. The IESG also used this opportunity to consider the IETF area > > that the PPVPN work would fit best. > > > > > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > > considering the following organizational changes in order to improve WG > > focus and productivity and ensure faster progress of the VPN-related >work: > > > > > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > > > > > The L2 and L3 VPN work spaces are each big enough to warrant a > > separate > > WG. While concentration of all VPN-related work in a single forum >was > > the right thing to do to ensure coordination of efforts when the >PPVPN > > WG was created and L2 VPN work came in, such concentration is >causing > > scaling problems within the WG at this moment. > > > > > > Migration of work into two separate WGs for L2 and L3 VPN >technologies > > with more specific WG charters will help to focus discussions, >prevent > > staff and meeting time overloading, and will aid faster progress of > > corresponding technologies. > > > > > > 2. Migration of the VPN-related work to the Internet area. > > > > > > As previously discussed, VPN-related work could be argued to belong > > to more than one area. Tunneling mechanisms are the property that > > gravitates this work to the Internet area, which is where we believe > > the VPN work should go. > > > > > > As part of this move, we are also considering moving PWE3 into INT, > > so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the >same > > area. > > > > > > Based on the above considerations, we are considering the following >steps: > > > > > > 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. > > The mailing lists will be established and the discussion of the > > proposed > > charters of the new WGs will be initiated shortly. > > > > > > 2. Once the charters of the new WGs are agreed upon and approved by the > > IESG, > > creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG >will > > be > > performed simultaneously. PPVPN WG documents will be migrated to the > > corresponding new WGs. > > > > > > It is our intention to complete this process by the Vienna IETF meeting. > > Also, these changes are being made for management reasons and are not > > intended > > to be a "reset" on WG activities or to halt or interrupt progress on > > current > > ongoing WG activities. > > > > > > We'd like to hear from the WG members if they see any fatal flaws with > > the proposed approach. Please send us your feedback by May 11th. > > > > > > Regards, > > > > > > -- > > Alex Zinin > > IETF SUB-IP Area Co-Director > > > > _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 10:47:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04622 for ; Mon, 5 May 2003 10:46:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45EmP221535 for ; Mon, 5 May 2003 10:48:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45EmLi07663 for ; Mon, 5 May 2003 10:48:22 -0400 (EDT) Message-Id: <200305051444.h45EiXu17709@merlot.juniper.net> To: Ali Sajassi cc: vkompella@timetra.com, raszuk@cisco.com, "Mourad BERKANE" , ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 16:53:26 PDT." <4.3.2.7.2.20030429162252.01db9050@airborne.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84461.1052145872.1@juniper.net> Date: Mon, 05 May 2003 07:44:32 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Ali, > > > Sure, but the number of TCP connections inter-AS is as many as LDP, unles s > > > you are telling me that eBGP uses RR! > > > >If one would read 2547bis, then one should be able to fine the following: > > > > To improve scalability, one can have the multi-hop EBGP > > connections exist only between a route reflector in one AS and > > a route reflector in another. (However, when the route > > reflectors distribute routes over this connection, they do not > > modify the BGP next hop attribute of the routes.) > > > >Precisely the same applies for VPLS when autodiscovery and signaling > >is done via BGP. > > No, it doesn't !! You forgot to mention the magic word, PtP PW > scalability, which doesn't exist in L3VPN. By connecting all the PEs of a > VPLS instance in one AS in a full-mesh to all other PEs of the same VPLS > instance in a different AS, you've just increased the number of PWs by > four-folds. Now as number of ASs increases, the number of PWs increases by > N^2. The reason for hierarchical-VPLS topology which is also referred to in > your draft is to address such scalability issues and to reduce the number > of PWs. When you refer to "PtP PW scalability" do you refer to the scalability in the data plane (number of labels required), or to the scalability in the control plane (number of signaling peerings required) ? > Therefore, connecting different ASes via hubs is intended to address such > scalability issue and make the number of PWs grow linearly with number of > ASes. While it intended to address the scalability issue with PWs, it introduces new scalability issues, namely the need to perform MAC lookup on ASBRs, and the need to run STP on a per VPLS basis. > So if number of PWs among ASes are small, then there is no issue with > MD5 among small number of sessions and if the number of PWs is large, then > you have scalability issue of PWs itsef (and maintenance of them). You certainly do have the scalability issue of maintaining PWs if you use LDP for signaling these PWs, as a PW between a pair of PEs requires an LDP session between these PEs. In contrast if one uses BGP for distributing labels, there is no need for a set of PEs that support a given VPLS to have direct BGP peering with each other. That is one of the reasons why I think that BGP for both autodiscovery and label distribution has better scaling properties than BGP for autodiscovery + LDP for label distribution. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 11:06:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05002 for ; Mon, 5 May 2003 11:06:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45F8j209909 for ; Mon, 5 May 2003 11:08:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45F8YE18262 for ; Mon, 5 May 2003 11:08:34 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C1805@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: auto92679@hushmail.com, ppvpn@nortelnetworks.com Cc: problem-statement@alvestrand.no Subject: RE: Strategy for VPN work in IETF Date: Mon, 5 May 2003 15:21:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: hoemail1.firewall.lucent.com X-SMTP-MAIL-FROM: bwijnen@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: hoemail1.lucent.com [192.11.226.161] X-LYRIS-Message-Id: Isn't it nice to "accuse" while not having to identify yourself. We will certainly take this anonymous positive advise to heart. Thanks, Bert > -----Original Message----- > From: auto92679@hushmail.com [mailto:auto92679@hushmail.com] > Sent: zondag 4 mei 2003 22:25 > To: ppvpn@nortelnetworks.com > Cc: problem-statement@alvestrand.no > Subject: Strategy for VPN work in IETF > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alex Zinin writes: > > > Since San Francisco IETF meeting the IESG has been considering the > > situation in the SUB-IP area and in the PPVPN Working Group in > > particular. > > > Such close attention to this WG was triggered by numerous concerns > > > thatthe IESG members received from the WG participants about limited > > and slow progress within the WG despite the efforts of the WG chairs > > and its members. The IESG also used this opportunity to consider > > the IETF area that the PPVPN work would fit best. > > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > > considering the following organizational changes in order to > > improve WG focus and productivity and ensure faster progress of the > > VPN-related work: > > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > > The L2 and L3 VPN work spaces are each big enough to warrant a > > separate WG. While concentration of all VPN-related work in a > > single forum was the right thing to do to ensure coordination > > of efforts when the PPVPN WG was created and L2 VPN work came in, > > > such concentration is causing scaling problems within the WG at > > this moment. > > > Migration of work into two separate WGs for L2 and L3 VPN > > technologies with more specific WG charters will help to focus > > discussions, prevent staff and meeting time overloading, and will > > aid faster progress of corresponding technologies. > > Alex, > The proposed solution ignores the origins of the problem. > > The fact that PPVPN has been making any progress at all, despite the > bureaucracy imposed on it by the IESG is rather comendable. > > This is a typically example of a WG which was setup despite > many architectural > objections that it doesn't fit in the "internet" design. One > cannot help > but to suspect that there was the hope ammoung the inner circles that > it would fail altogether. At least giving the ammount of "framework" > nonsense required and the interdiction to discuss solutions before a > framework is agreed upon. > > The work of this working group is particularly harder given that this > is todays "fashion" area... work is much harder on such areas > (like mpls > was a couple of years ago). One would suspect that the IESG > efforts to slow the WG steem also from concerns that fashion > areas tend > to create a fair ammount of nonsense proposals most of which tend to > be naturally eliminated by the WGs. > > Given the environment the performance of the ppvpn WG seems to me to > rather positive. It has actually come up with several documents that > are useful and deserve publication. > > One of the reasons given here for this proposed disolution of the WG > is that the "L2VPN and L3VPN work spaces are big enought". > However both > in the list and WG meetings it seems to me that the current l3vpn WG > is close to 0. The base document on l3vpn has been rather stable for > a while and it is not likely to change. The IESG/inner-circle > has chosen > for mostly ideological reasons to attempt to marginalize this work so > it can hardly expect to be heard now. > > It seems to me that if there is a problem w/ PPVPN that problem lies > within the IESG itself. As such i would like to propose to split the > IESG in two WGs: one that concerns itself w/ architecture and > one group > that concerns itself with the process of documenting > interoperable solutions > that are not known to be good or bad ideas until used in pratice. This > latter group should have the task to assure that the process is fair > and that both the pluses and minus of a solution are > considered and documented. > > > One of the ideal caractheristics of the latter group would be if they > where to realize that by definition an IESG member is much less of an > expert in a given domain than the membership of the WG it steers. It > is humanly impossible for it to be otherwise. Unless you assume that > the membership of WG is 100% incompetent which is never the > case. A steerer > cannot possibly be an expert in 20 groups it oversees... > usually it can't > even keep up with the problems and technology due to the fact > that there > is only 24 hours in each day. > > In the rather arrogant terms of internet engineering, the IESG is by > definition the set of people that are "clueless". It is not possible > for it to be the other way around. No matter how wise and inteligent > IESG memebers are... > > It is necessarly that the IESG understands that latter point > and restricts > its job to document in a timely manner interoperable solutions for the > problems at hand regardless of personal opinion on the value of such > problems and technologies. > - ---- > -----BEGIN PGP SIGNATURE----- > Version: Hush 2.2 (Java) > Note: This signature can be verified at https://www.hushtools.com/verify wl4EARECAB4FAj61dxQXHGF1dG85MjY3OUBodXNobWFpbC5jb20ACgkQEMGDJWtDWfpc ewCfaWN5FVNhieXVzimDk9cNYOZlgKAAnj3Hf8eWFmikSCDmAw1eMQVdEUb/ =GLPS -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 11:13:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05140 for ; Mon, 5 May 2003 11:13:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45FG6214286 for ; Mon, 5 May 2003 11:16:07 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45FG2R11730 for ; Mon, 5 May 2003 11:16:02 -0400 (EDT) Message-Id: <200305051443.h45EhvWS012444@rtp-core-1.cisco.com> To: Alex Zinin cc: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: Re: IMPORTANT: Strategy for VPN work in IETF In-reply-to: Your message of Sun, 04 May 2003 00:11:52 -0700. <2032066549.20030504001152@psg.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: Mon, 05 May 2003 10:43:56 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Alex> these changes are being made for management reasons and are not Alex> intended to be a "reset" on WG activities or to halt or interrupt Alex> progress on current ongoing WG activities. That being the case, I think the proposed changes make sense, at least from the 50,000 foot level. (One could hardly say that things are fine the way they are!) I do have the following concerns: 1. Before being comfortable with a reorganization, I'd like to see what the new charters will be. I'd particularly like to be sure that the L3VPN charter is not constructed so as to cause a reset. Same with the PWE3 charter; we don't want to have to refight old wars. 2. From ground level, the most important aspect of a particular WG being in a particular area is the attitude of that area's ADs towards the work that the WG is doing. This is an unknown to us. Given that at least one IESG member (though not one involved in this reorg) has been quoted in the trade tabloids as saying that this work is all a scam which will destroy the network, you can see why we might react cautiously to any proposed change. Despite these concerns, I do think that L2VPN and L3VPN are separate pieces of work which need separate focus, and I don't think that there should be a "sub-ip" area into which one throws anything that might possibly have anything to do with MPLS. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 11:28:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05533 for ; Mon, 5 May 2003 11:28:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45FUj219646 for ; Mon, 5 May 2003 11:30:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45FUbr12501 for ; Mon, 5 May 2003 11:30:38 -0400 (EDT) Date: Mon, 5 May 2003 16:54:24 +0200 Message-Id: Subject: =?iso-8859-1?Q?unsubscribe?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?dariobalmas@libero.it?=" To: "=?iso-8859-1?Q?yakov?=" Cc: "=?iso-8859-1?Q?sajassi?=" Cc: "=?iso-8859-1?Q?vkompella?=" Cc: "=?iso-8859-1?Q?raszuk?=" Cc: "=?iso-8859-1?Q?mourad.berkane?=" Cc: "=?iso-8859-1?Q?ppvpn?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 163.162.41.4 X-SMTP-HELO: smtp0.libero.it X-SMTP-MAIL-FROM: dariobalmas@libero.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp0.libero.it [193.70.192.33] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05533 unsubscribe !! You forgot to mention the magic word, PtP PW > scalability, which doesn't exist in L3VPN. By connecting all the PEs of a > VPLS instance in one AS in a full-mesh to all other PEs of the same VPLS > instance in a different AS, you've just increased the number of PWs by > four-folds. Now as number of ASs increases, the number of PWs increases by > N^2. The reason for hierarchical-VPLS topology which is also referred to in > your draft is to address such scalability issues and to reduce the number > of PWs. When you refer to "PtP PW scalability" do you refer to the scalability in the data plane (number of labels required), or to the scalability in the control plane (number of signaling peerings required) ? > Therefore, connecting different ASes via hubs is intended to address such > scalability issue and make the number of PWs grow linearly with number of > ASes. While it intended to address the scalability issue with PWs, it introduces new scalability issues, namely the need to perform MAC lookup on ASBRs, and the need to run STP on a per VPLS basis. > So if number of PWs among ASes are small, then there is no issue with > MD5 among small number of sessions and if the number of PWs is large, then > you have scalability issue of PWs itsef (and maintenance of them). You certainly do have the scalability issue of maintaining PWs if you use LDP for signaling these PWs, as a PW between a pair of PEs requires an LDP session between these PEs. In contrast if one uses BGP for distributing labels, there is no need for a set of PEs that support a given VPLS to have direct BGP peering with each other. That is one of the reasons why I think that BGP for both autodiscovery and label distribution has better scaling properties than BGP for autodiscovery + LDP for label distribution. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 11:38:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05767 for ; Mon, 5 May 2003 11:38:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45Fea224543 for ; Mon, 5 May 2003 11:40:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45FeWr22567 for ; Mon, 5 May 2003 11:40:32 -0400 (EDT) Date: Mon, 05 May 2003 17:05:01 +0200 From: Cantone Concetta Subject: unsubscribe To: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C31317.B392615A" Content-transfer-encoding: 7bit Importance: normal Priority: normal Thread-Topic: unsubscribe Thread-Index: AcMTF7Oop6gN5oyiTEmV7rOjap7vHw== content-class: urn:content-classes:message X-OriginalArrivalTime: 05 May 2003 15:05:07.0217 (UTC) FILETIME=[B703F010:01C31317] X-SMTP-HELO: dns2.tilab.com X-SMTP-MAIL-FROM: Concetta.Cantone@TILAB.COM X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dns2.tilab.com [163.162.42.5] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C31317.B392615A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== ------_=_NextPart_001_01C31317.B392615A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
CONFIDENTIALITY NOTICE
This message and its attachments are = addressed solely to the persons
above and may contain confidential = information. If you have received
the message in error, be informed = that any use of the content hereof
is prohibited. Please return it = immediately to the sender and delete
the message. Should you have any = questions, please contact us by
replying to MailAdmin@tilab.com. = Thank = you
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C31317.B392615A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 11:43:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05963 for ; Mon, 5 May 2003 11:43:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45FjZ228581 for ; Mon, 5 May 2003 11:45:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45FjTf27284 for ; Mon, 5 May 2003 11:45:30 -0400 (EDT) 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_01C31317.C006A79C" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 10:05:22 -0500 Message-ID: <1DA3AEE851515549A5D2C5BD7F8FB2471FF2BE@PKDWB06C.ad.sprint.com> Thread-Topic: IMPORTANT: Strategy for VPN work in IETF Thread-Index: AcMSDTfFE+/T1tyLQqSRuBsUCtrwywBCgyqi From: "Nagarajan, Ananth [CC]" To: "Alex Zinin" , Cc: , "Wijnen, Bert (Bert)" , "Thomas Narten" , "Peterson, Jon" , "Allison Mankin" X-OriginalArrivalTime: 05 May 2003 15:05:22.0051 (UTC) FILETIME=[BFDB6D30:01C31317] X-SMTP-HELO: smtpgw6.sprintspectrum.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpgw6.sprintspectrum.com [207.40.188.14] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C31317.C006A79C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW55IGVmZm9ydCB0byBzcGVlZCB1cCB0aGUgd29yayBpbiB0aGUgV0cgaXMgd2VsY29tZS4gIFRo ZSBpZGVhIHNlZW1zIGxvZ2ljYWwsIGJ1dCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgYXMgc29vbiBh cyB0aGUgcHB2cG4gV0cgc3RhcnRlZCBhY2NlcHRpbmcgTDJWUE4gd2l0aGluIHRoZSBjaGFydGVy LiAgUmlnaHQgbm93LCBJIGFtIGFmcmFpZCBpdCB3b3VsZCBjcmVhdGUgYW5vdGhlciBhZG1pbmlz dHJhdGl2ZSBkZWxheSAgaW4gdGhlIHdvcmsgLSBiZWNhdXNlIHRoZSBMMyB3b3JrIGlzIG1vcmUg b3IgbGVzcyBkb25lLiAgKEkgYW0gYW50aWNpcGF0aW5nIHRoYXQgaW4gdGhlIG5leHQgZmV3IG1v bnRocywgdGhlIFdHIHdpbGwgY29uY2VudHJhdGUgZnVsbHkgb24gTDIgd29yaykuDQogDQpJZiwg aW4gZmFjdCwgdGhlIFdHIGRvZXMgc3BsaXQsIHRoZW4gd2UgYWxzbyBuZWVkIHRvIHRoaW5rIGFi b3V0IHdoYXQgdG8gZG8gd2l0aCBhIGZldyBkb2N1bWVudHMgc3VjaCBhcyB0aGUgZ2VuZXJpYyBy ZXF0cyBkcmFmdCwgdGhhdCB3aWxsIGJlIHJlYWR5IGZvciBJRVNHIGxhc3QgY2FsbCB0aGlzIHdl ZWssIHRoYXQgcmVhbGx5IGlzIGFuIHVtYnJlbGxhIGRvY3VtZW50IGZvciBib3RoIEwyIGFuZCBM MyBWUE5zLiAgU2ltaWxhcmx5LCBJIHRoaW5rIHdlIGhhdmUgdGhlIHRlcm1pbm9sb2d5IGRyYWZ0 IHRvbyB0aGF0IHdlIG5lZWQgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gd2l0aC4NCiANClRoYW5r cywNCkFuYW50aA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogQWxleCBa aW5pbiBbbWFpbHRvOnppbmluQHBzZy5jb21dIA0KCVNlbnQ6IFN1biA1LzQvMjAwMyAyOjExIEFN IA0KCVRvOiBwcHZwbkBub3J0ZWxuZXR3b3Jrcy5jb20gDQoJQ2M6IHB3ZTNAaWV0Zi5vcmc7IFdp am5lbiwgQmVydCAoQmVydCk7IFRob21hcyBOYXJ0ZW47IFBldGVyc29uLCBKb247IEFsbGlzb24g TWFua2luIA0KCVN1YmplY3Q6IElNUE9SVEFOVDogU3RyYXRlZ3kgZm9yIFZQTiB3b3JrIGluIElF VEYNCgkNCgkNCg0KCUZvbGtzLA0KCQ0KCVNpbmNlIFNhbiBGcmFuY2lzY28gSUVURiBtZWV0aW5n IHRoZSBJRVNHIGhhcyBiZWVuIGNvbnNpZGVyaW5nIHRoZQ0KCXNpdHVhdGlvbiBpbiB0aGUgU1VC LUlQIGFyZWEgYW5kIGluIHRoZSBQUFZQTiBXb3JraW5nIEdyb3VwIGluIHBhcnRpY3VsYXIuDQoJ DQoJU3VjaCBjbG9zZSBhdHRlbnRpb24gdG8gdGhpcyBXRyB3YXMgdHJpZ2dlcmVkIGJ5IG51bWVy b3VzIGNvbmNlcm5zIHRoYXQNCgl0aGUgSUVTRyBtZW1iZXJzIHJlY2VpdmVkIGZyb20gdGhlIFdH IHBhcnRpY2lwYW50cyBhYm91dCBsaW1pdGVkIGFuZA0KCXNsb3cgcHJvZ3Jlc3Mgd2l0aGluIHRo ZSBXRyBkZXNwaXRlIHRoZSBlZmZvcnRzIG9mIHRoZSBXRyBjaGFpcnMgYW5kIGl0cw0KCW1lbWJl cnMuIFRoZSBJRVNHIGFsc28gdXNlZCB0aGlzIG9wcG9ydHVuaXR5IHRvIGNvbnNpZGVyIHRoZSBJ RVRGIGFyZWENCgl0aGF0IHRoZSBQUFZQTiB3b3JrIHdvdWxkIGZpdCBiZXN0Lg0KCQ0KCUFmdGVy IG11Y2ggZGVsaWJlcmF0aW9uLCB0aGUgaW52b2x2ZWQgQURzIChCZXJ0LCBUaG9tYXMsIGFuZCBJ KSBhcmUNCgljb25zaWRlcmluZyB0aGUgZm9sbG93aW5nIG9yZ2FuaXphdGlvbmFsIGNoYW5nZXMg aW4gb3JkZXIgdG8gaW1wcm92ZSBXRw0KCWZvY3VzIGFuZCBwcm9kdWN0aXZpdHkgYW5kIGVuc3Vy ZSBmYXN0ZXIgcHJvZ3Jlc3Mgb2YgdGhlIFZQTi1yZWxhdGVkIHdvcms6DQoJDQoJIDEuIFNwbGl0 IG9mIExheWVyLTIgYW5kIExheWVyLTMgVlBOIHdvcmsgaW4gc2VwYXJhdGUgV29ya2luZyBHcm91 cHMuDQoJDQoJICAgIFRoZSBMMiBhbmQgTDMgVlBOIHdvcmsgc3BhY2VzIGFyZSBlYWNoIGJpZyBl bm91Z2ggdG8gd2FycmFudCBhIHNlcGFyYXRlDQoJICAgIFdHLiBXaGlsZSBjb25jZW50cmF0aW9u IG9mIGFsbCBWUE4tcmVsYXRlZCB3b3JrIGluIGEgc2luZ2xlIGZvcnVtIHdhcw0KCSAgICB0aGUg cmlnaHQgdGhpbmcgdG8gZG8gdG8gZW5zdXJlIGNvb3JkaW5hdGlvbiBvZiBlZmZvcnRzIHdoZW4g dGhlIFBQVlBODQoJICAgIFdHIHdhcyBjcmVhdGVkIGFuZCBMMiBWUE4gd29yayBjYW1lIGluLCBz dWNoIGNvbmNlbnRyYXRpb24gaXMgY2F1c2luZw0KCSAgICBzY2FsaW5nIHByb2JsZW1zIHdpdGhp biB0aGUgV0cgYXQgdGhpcyBtb21lbnQuDQoJDQoJICAgIE1pZ3JhdGlvbiBvZiB3b3JrIGludG8g dHdvIHNlcGFyYXRlIFdHcyBmb3IgTDIgYW5kIEwzIFZQTiB0ZWNobm9sb2dpZXMNCgkgICAgd2l0 aCBtb3JlIHNwZWNpZmljIFdHIGNoYXJ0ZXJzIHdpbGwgaGVscCB0byBmb2N1cyBkaXNjdXNzaW9u cywgcHJldmVudA0KCSAgICBzdGFmZiBhbmQgbWVldGluZyB0aW1lIG92ZXJsb2FkaW5nLCBhbmQg d2lsbCBhaWQgZmFzdGVyIHByb2dyZXNzIG9mDQoJICAgIGNvcnJlc3BvbmRpbmcgdGVjaG5vbG9n aWVzLg0KCQ0KCSAyLiBNaWdyYXRpb24gb2YgdGhlIFZQTi1yZWxhdGVkIHdvcmsgdG8gdGhlIElu dGVybmV0IGFyZWEuDQoJDQoJICAgIEFzIHByZXZpb3VzbHkgZGlzY3Vzc2VkLCBWUE4tcmVsYXRl ZCB3b3JrIGNvdWxkIGJlIGFyZ3VlZCB0byBiZWxvbmcNCgkgICAgdG8gbW9yZSB0aGFuIG9uZSBh cmVhLiBUdW5uZWxpbmcgbWVjaGFuaXNtcyBhcmUgdGhlIHByb3BlcnR5IHRoYXQNCgkgICAgZ3Jh dml0YXRlcyB0aGlzIHdvcmsgdG8gdGhlIEludGVybmV0IGFyZWEsIHdoaWNoIGlzIHdoZXJlIHdl IGJlbGlldmUNCgkgICAgdGhlIFZQTiB3b3JrIHNob3VsZCBnby4NCgkNCgkgICAgQXMgcGFydCBv ZiB0aGlzIG1vdmUsIHdlIGFyZSBhbHNvIGNvbnNpZGVyaW5nIG1vdmluZyBQV0UzIGludG8gSU5U LA0KCSAgICBzbyB0aGF0IEwyVFBFWFQsIFBXRTMsIGFuZCB0aGV3IG5ldyBWUE4gV0dzIGFyZSBv cGVyYXRpbmcgaW4gdGhlIHNhbWUNCgkgICAgYXJlYS4NCgkNCglCYXNlZCBvbiB0aGUgYWJvdmUg Y29uc2lkZXJhdGlvbnMsIHdlIGFyZSBjb25zaWRlcmluZyB0aGUgZm9sbG93aW5nIHN0ZXBzOg0K CQ0KCSAxLiBUd28gbmV3IFdHcy0tTDJWUE4gYW5kIEwzVlBOLS13aWxsIGJlIGNyZWF0ZWQgaW4g dGhlIEludGVybmV0IGFyZWEuDQoJICAgIFRoZSBtYWlsaW5nIGxpc3RzIHdpbGwgYmUgZXN0YWJs aXNoZWQgYW5kIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZA0KCSAgICBjaGFydGVycyBv ZiB0aGUgbmV3IFdHcyB3aWxsIGJlIGluaXRpYXRlZCBzaG9ydGx5Lg0KCQ0KCSAyLiBPbmNlIHRo ZSBjaGFydGVycyBvZiB0aGUgbmV3IFdHcyBhcmUgYWdyZWVkIHVwb24gYW5kIGFwcHJvdmVkIGJ5 IHRoZSBJRVNHLA0KCSAgICBjcmVhdGlvbiBvZiB0aGUgTDJWUE4gYW5kIEwzVlBOIFdHcyBhbmQg c2h1dGRvd24gb2YgdGhlIFBQVlBOIFdHIHdpbGwgYmUNCgkgICAgcGVyZm9ybWVkIHNpbXVsdGFu ZW91c2x5LiBQUFZQTiBXRyBkb2N1bWVudHMgd2lsbCBiZSBtaWdyYXRlZCB0byB0aGUNCgkgICAg Y29ycmVzcG9uZGluZyBuZXcgV0dzLg0KCQ0KCUl0IGlzIG91ciBpbnRlbnRpb24gdG8gY29tcGxl dGUgdGhpcyBwcm9jZXNzIGJ5IHRoZSBWaWVubmEgSUVURiBtZWV0aW5nLg0KCUFsc28sIHRoZXNl IGNoYW5nZXMgYXJlIGJlaW5nIG1hZGUgZm9yIG1hbmFnZW1lbnQgcmVhc29ucyBhbmQgYXJlIG5v dCBpbnRlbmRlZA0KCXRvIGJlIGEgInJlc2V0IiBvbiBXRyBhY3Rpdml0aWVzIG9yIHRvIGhhbHQg b3IgaW50ZXJydXB0IHByb2dyZXNzIG9uIGN1cnJlbnQNCglvbmdvaW5nIFdHIGFjdGl2aXRpZXMu DQoJDQoJV2UnZCBsaWtlIHRvIGhlYXIgZnJvbSB0aGUgV0cgbWVtYmVycyBpZiB0aGV5IHNlZSBh bnkgZmF0YWwgZmxhd3Mgd2l0aA0KCXRoZSBwcm9wb3NlZCBhcHByb2FjaC4gUGxlYXNlIHNlbmQg dXMgeW91ciBmZWVkYmFjayBieSBNYXkgMTF0aC4NCgkNCglSZWdhcmRzLA0KCQ0KCS0tDQoJQWxl eCBaaW5pbg0KCUlFVEYgU1VCLUlQIEFyZWEgQ28tRGlyZWN0b3INCgkNCgkNCgkNCgkNCg0K ------_=_NextPart_001_01C31317.C006A79C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8v RU4iPg0KPEhUTUw+DQo8SEVBRD4NCg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5UPSJN UyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA2LjAuNjM4OS4wIj4NCjxUSVRMRT5JTVBPUlRBTlQ6 IFN0cmF0ZWd5IGZvciBWUE4gd29yayBpbiBJRVRGPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZIGRp cj1sdHI+DQo8RElWPkFueSBlZmZvcnQgdG8gc3BlZWQgdXAgdGhlIHdvcmsgaW4gdGhlIFdHIGlz IHdlbGNvbWUuJm5ic3A7IFRoZSBpZGVhIHNlZW1zIA0KbG9naWNhbCwgYnV0IHNob3VsZCBoYXZl IGJlZW4gZG9uZSBhcyBzb29uIGFzIHRoZSBwcHZwbiBXRyBzdGFydGVkIGFjY2VwdGluZyANCkwy VlBOIHdpdGhpbiB0aGUgY2hhcnRlci4mbmJzcDsgUmlnaHQgbm93LCBJIGFtIGFmcmFpZCBpdCB3 b3VsZCBjcmVhdGUgYW5vdGhlciANCmFkbWluaXN0cmF0aXZlIGRlbGF5Jm5ic3A7IGluIHRoZSB3 b3JrIC0gYmVjYXVzZSB0aGUgTDMgd29yayBpcyBtb3JlIG9yIGxlc3MgDQpkb25lLiZuYnNwOyAo SSBhbSBhbnRpY2lwYXRpbmcgdGhhdCBpbiB0aGUgbmV4dCBmZXcgbW9udGhzLCB0aGUgV0cgd2ls bCANCmNvbmNlbnRyYXRlIGZ1bGx5IG9uIEwyIHdvcmspLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+SWYsIGluIGZhY3QsIHRoZSBXRyBkb2VzIHNwbGl0LCB0aGVuIHdlIGFsc28gbmVl ZCB0byB0aGluayBhYm91dCB3aGF0IHRvIGRvIA0Kd2l0aCBhIGZldyBkb2N1bWVudHMgc3VjaCBh cyB0aGUgZ2VuZXJpYyByZXF0cyBkcmFmdCwgdGhhdCB3aWxsIGJlIHJlYWR5IGZvciANCklFU0cg bGFzdCBjYWxsIHRoaXMgd2VlaywgdGhhdCByZWFsbHkgaXMgYW4gdW1icmVsbGEgZG9jdW1lbnQg Zm9yIGJvdGggTDIgYW5kIEwzIA0KVlBOcy4mbmJzcDsgU2ltaWxhcmx5LCBJIHRoaW5rIHdlIGhh dmUgdGhlIHRlcm1pbm9sb2d5IGRyYWZ0IHRvbyB0aGF0IHdlIG5lZWQgdG8gDQpkZXRlcm1pbmUg d2hhdCB0byBkbyB3aXRoLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzLDwv RElWPg0KPERJVj5BbmFudGg8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gPEJSPjxCPkZyb206PC9CPiBBbGV4IFppbmluIA0KICBbbWFpbHRvOnppbmluQHBzZy5j b21dIDxCUj48Qj5TZW50OjwvQj4gU3VuIDUvNC8yMDAzIDI6MTEgQU0gPEJSPjxCPlRvOjwvQj4g DQogIHBwdnBuQG5vcnRlbG5ldHdvcmtzLmNvbSA8QlI+PEI+Q2M6PC9CPiBwd2UzQGlldGYub3Jn OyBXaWpuZW4sIEJlcnQgKEJlcnQpOyANCiAgVGhvbWFzIE5hcnRlbjsgUGV0ZXJzb24sIEpvbjsg QWxsaXNvbiBNYW5raW4gPEJSPjxCPlN1YmplY3Q6PC9CPiBJTVBPUlRBTlQ6IA0KICBTdHJhdGVn eSBmb3IgVlBOIHdvcmsgaW4gSUVURjxCUj48QlI+PC9GT05UPjwvRElWPg0KICA8UD48Rk9OVCBz aXplPTI+Rm9sa3MsPEJSPjxCUj5TaW5jZSBTYW4gRnJhbmNpc2NvIElFVEYgbWVldGluZyB0aGUg SUVTRyBoYXMgDQogIGJlZW4gY29uc2lkZXJpbmcgdGhlPEJSPnNpdHVhdGlvbiBpbiB0aGUgU1VC LUlQIGFyZWEgYW5kIGluIHRoZSBQUFZQTiBXb3JraW5nIA0KICBHcm91cCBpbiBwYXJ0aWN1bGFy LjxCUj48QlI+U3VjaCBjbG9zZSBhdHRlbnRpb24gdG8gdGhpcyBXRyB3YXMgdHJpZ2dlcmVkIGJ5 IA0KICBudW1lcm91cyBjb25jZXJucyB0aGF0PEJSPnRoZSBJRVNHIG1lbWJlcnMgcmVjZWl2ZWQg ZnJvbSB0aGUgV0cgcGFydGljaXBhbnRzIA0KICBhYm91dCBsaW1pdGVkIGFuZDxCUj5zbG93IHBy b2dyZXNzIHdpdGhpbiB0aGUgV0cgZGVzcGl0ZSB0aGUgZWZmb3J0cyBvZiB0aGUgV0cgDQogIGNo YWlycyBhbmQgaXRzPEJSPm1lbWJlcnMuIFRoZSBJRVNHIGFsc28gdXNlZCB0aGlzIG9wcG9ydHVu aXR5IHRvIGNvbnNpZGVyIHRoZSANCiAgSUVURiBhcmVhPEJSPnRoYXQgdGhlIFBQVlBOIHdvcmsg d291bGQgZml0IGJlc3QuPEJSPjxCUj5BZnRlciBtdWNoIA0KICBkZWxpYmVyYXRpb24sIHRoZSBp bnZvbHZlZCBBRHMgKEJlcnQsIFRob21hcywgYW5kIEkpIGFyZTxCUj5jb25zaWRlcmluZyB0aGUg DQogIGZvbGxvd2luZyBvcmdhbml6YXRpb25hbCBjaGFuZ2VzIGluIG9yZGVyIHRvIGltcHJvdmUg V0c8QlI+Zm9jdXMgYW5kIA0KICBwcm9kdWN0aXZpdHkgYW5kIGVuc3VyZSBmYXN0ZXIgcHJvZ3Jl c3Mgb2YgdGhlIFZQTi1yZWxhdGVkIA0KICB3b3JrOjxCUj48QlI+Jm5ic3A7MS4gU3BsaXQgb2Yg TGF5ZXItMiBhbmQgTGF5ZXItMyBWUE4gd29yayBpbiBzZXBhcmF0ZSANCiAgV29ya2luZyBHcm91 cHMuPEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlIEwyIGFuZCBMMyBWUE4gd29yayBzcGFj ZXMgYXJlIA0KICBlYWNoIGJpZyBlbm91Z2ggdG8gd2FycmFudCBhIHNlcGFyYXRlPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyBXRy4gV2hpbGUgDQogIGNvbmNlbnRyYXRpb24gb2YgYWxsIFZQTi1yZWxh dGVkIHdvcmsgaW4gYSBzaW5nbGUgZm9ydW0gDQogIHdhczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsg dGhlIHJpZ2h0IHRoaW5nIHRvIGRvIHRvIGVuc3VyZSBjb29yZGluYXRpb24gb2YgDQogIGVmZm9y dHMgd2hlbiB0aGUgUFBWUE48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdHIHdhcyBjcmVhdGVkIGFu ZCBMMiBWUE4gd29yayANCiAgY2FtZSBpbiwgc3VjaCBjb25jZW50cmF0aW9uIGlzIGNhdXNpbmc8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNjYWxpbmcgcHJvYmxlbXMgDQogIHdpdGhpbiB0aGUgV0cg YXQgdGhpcyBtb21lbnQuPEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgTWlncmF0aW9uIG9mIHdv cmsgaW50byANCiAgdHdvIHNlcGFyYXRlIFdHcyBmb3IgTDIgYW5kIEwzIFZQTiB0ZWNobm9sb2dp ZXM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGggDQogIG1vcmUgc3BlY2lmaWMgV0cgY2hhcnRl cnMgd2lsbCBoZWxwIHRvIGZvY3VzIGRpc2N1c3Npb25zLCANCiAgcHJldmVudDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgc3RhZmYgYW5kIG1lZXRpbmcgdGltZSBvdmVybG9hZGluZywgYW5kIHdpbGwg YWlkIA0KICBmYXN0ZXIgcHJvZ3Jlc3Mgb2Y8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcnJlc3Bv bmRpbmcgDQogIHRlY2hub2xvZ2llcy48QlI+PEJSPiZuYnNwOzIuIE1pZ3JhdGlvbiBvZiB0aGUg VlBOLXJlbGF0ZWQgd29yayB0byB0aGUgDQogIEludGVybmV0IGFyZWEuPEJSPjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgQXMgcHJldmlvdXNseSBkaXNjdXNzZWQsIFZQTi1yZWxhdGVkIA0KICB3b3Jr IGNvdWxkIGJlIGFyZ3VlZCB0byBiZWxvbmc8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIG1vcmUg dGhhbiBvbmUgYXJlYS4gDQogIFR1bm5lbGluZyBtZWNoYW5pc21zIGFyZSB0aGUgcHJvcGVydHkg dGhhdDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgZ3Jhdml0YXRlcyANCiAgdGhpcyB3b3JrIHRvIHRo ZSBJbnRlcm5ldCBhcmVhLCB3aGljaCBpcyB3aGVyZSB3ZSANCiAgYmVsaWV2ZTxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgdGhlIFZQTiB3b3JrIHNob3VsZCANCiAgZ28uPEJSPjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsgQXMgcGFydCBvZiB0aGlzIG1vdmUsIHdlIGFyZSBhbHNvIGNvbnNpZGVyaW5nIA0K ICBtb3ZpbmcgUFdFMyBpbnRvIElOVCw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvIHRoYXQgTDJU UEVYVCwgUFdFMywgYW5kIHRoZXcgDQogIG5ldyBWUE4gV0dzIGFyZSBvcGVyYXRpbmcgaW4gdGhl IHNhbWU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZWEuPEJSPjxCUj5CYXNlZCANCiAgb24gdGhl IGFib3ZlIGNvbnNpZGVyYXRpb25zLCB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIGZvbGxvd2luZyAN CiAgc3RlcHM6PEJSPjxCUj4mbmJzcDsxLiBUd28gbmV3IFdHcy0tTDJWUE4gYW5kIEwzVlBOLS13 aWxsIGJlIGNyZWF0ZWQgaW4gdGhlIA0KICBJbnRlcm5ldCBhcmVhLjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsgVGhlIG1haWxpbmcgbGlzdHMgd2lsbCBiZSBlc3RhYmxpc2hlZCBhbmQgDQogIHRoZSBk aXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2hhcnRlcnMg b2YgdGhlIG5ldyBXR3MgDQogIHdpbGwgYmUgaW5pdGlhdGVkIHNob3J0bHkuPEJSPjxCUj4mbmJz cDsyLiBPbmNlIHRoZSBjaGFydGVycyBvZiB0aGUgbmV3IFdHcyANCiAgYXJlIGFncmVlZCB1cG9u IGFuZCBhcHByb3ZlZCBieSB0aGUgSUVTRyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNyZWF0aW9u IG9mIA0KICB0aGUgTDJWUE4gYW5kIEwzVlBOIFdHcyBhbmQgc2h1dGRvd24gb2YgdGhlIFBQVlBO IFdHIHdpbGwgDQogIGJlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBwZXJmb3JtZWQgc2ltdWx0YW5l b3VzbHkuIFBQVlBOIFdHIGRvY3VtZW50cyB3aWxsIGJlIA0KICBtaWdyYXRlZCB0byB0aGU8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcnJlc3BvbmRpbmcgbmV3IFdHcy48QlI+PEJSPkl0IGlzIG91 ciANCiAgaW50ZW50aW9uIHRvIGNvbXBsZXRlIHRoaXMgcHJvY2VzcyBieSB0aGUgVmllbm5hIElF VEYgbWVldGluZy48QlI+QWxzbywgdGhlc2UgDQogIGNoYW5nZXMgYXJlIGJlaW5nIG1hZGUgZm9y IG1hbmFnZW1lbnQgcmVhc29ucyBhbmQgYXJlIG5vdCBpbnRlbmRlZDxCUj50byBiZSBhIA0KICAi cmVzZXQiIG9uIFdHIGFjdGl2aXRpZXMgb3IgdG8gaGFsdCBvciBpbnRlcnJ1cHQgcHJvZ3Jlc3Mg b24gDQogIGN1cnJlbnQ8QlI+b25nb2luZyBXRyBhY3Rpdml0aWVzLjxCUj48QlI+V2UnZCBsaWtl IHRvIGhlYXIgZnJvbSB0aGUgV0cgbWVtYmVycyANCiAgaWYgdGhleSBzZWUgYW55IGZhdGFsIGZs YXdzIHdpdGg8QlI+dGhlIHByb3Bvc2VkIGFwcHJvYWNoLiBQbGVhc2Ugc2VuZCB1cyB5b3VyIA0K ICBmZWVkYmFjayBieSBNYXkgMTF0aC48QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj4tLTxCUj5BbGV4 IFppbmluPEJSPklFVEYgU1VCLUlQIA0KICBBcmVhIENvLURpcmVjdG9yPEJSPjxCUj48QlI+PEJS PjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C31317.C006A79C-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 13:19:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08578 for ; Mon, 5 May 2003 13:19:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45HM0222138 for ; Mon, 5 May 2003 13:22:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45HLvm06589 for ; Mon, 5 May 2003 13:21:57 -0400 (EDT) Message-Id: <200305051718.h45HIOu29899@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: Your message of "Sat, 03 May 2003 18:23:22 PDT." <7011156071.20030503182322@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38234.1052155104.1@juniper.net> Date: Mon, 05 May 2003 10:18:24 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, [clipped...] > I believe the goal for the WG should be to work out > a single solution. That is certainly not in the charter. In fact the goal you stated above directly contradicts what is in the charter: Multiple approaches are being developed as each approach has particular characteristics and differing scope of applicability. And if you believe that for VPLS the goal should be a single solution, then why wouldn't you insist to have the same goal for L3 VPNs ? Also, if you insist on a single solution, wouldn't that imply a single auto-discovery mechanism for VPLS ? Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 13:24:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08660 for ; Mon, 5 May 2003 13:24:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45HQp225083 for ; Mon, 5 May 2003 13:26:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45HQlm10398 for ; Mon, 5 May 2003 13:26:48 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , ppvpn@nortelnetworks.com Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 13:24:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3132B.2F6090C8" X-LYRIS-Message-Id: 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_01C3132B.2F6090C8 Content-Type: text/plain; charset="iso-8859-1" Alex, > > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group > in particular. > > Such close attention to this WG was triggered by numerous > concerns that > the IESG members received from the WG participants about limited and > slow progress within the WG despite the efforts of the WG > chairs and its > members. [clipped...] Wouldn't be more appropriate to first discuss what these concerns are and if they are indeed justified concerns, and solicit feedback from the wg to discuss options or improvements on how to move the wg forward and get consensus on that. If I recall, similar open approach has been taken for sup-ip area in Atlanta meeting. Kind of hard to be *confident* that the proposed reorganization will actually address the raised concerns without actually knowing what these concerns are in the first place! After all, the amount of work after the split is exactly the same as before the split if not bigger (given that l3vpns work is almost done and the split will introduce additional administrative overhead). Hamid. ------_=_NextPart_001_01C3132B.2F6090C8 Content-Type: text/html; charset="iso-8859-1" RE: IMPORTANT: Strategy for VPN work in IETF

Alex,

>
> Since San Francisco IETF meeting the IESG has been considering the
> situation in the SUB-IP area and in the PPVPN Working Group
> in particular.
>
> Such close attention to this WG was triggered by numerous
> concerns that
> the IESG members received from the WG participants about limited and
> slow progress within the WG despite the efforts of the WG
> chairs and its
> members.

[clipped...]

Wouldn't be more appropriate to first discuss what these
concerns are and if they are indeed justified concerns, and
solicit feedback from the wg to discuss options or
improvements on how to move the wg forward and get consensus
on that. If I recall, similar open approach has been taken for
sup-ip area in Atlanta meeting.

Kind of hard to be *confident* that the proposed reorganization
will actually address the raised concerns without actually
knowing what these concerns are in the first place!

After all, the amount of work after the split is exactly
the same as before the split if not bigger (given that
l3vpns work is almost done and the split will
introduce additional administrative overhead).

Hamid.

------_=_NextPart_001_01C3132B.2F6090C8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 13:29:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08746 for ; Mon, 5 May 2003 13:29:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45HVl229177 for ; Mon, 5 May 2003 13:31:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45HVgk16732 for ; Mon, 5 May 2003 13:31:43 -0400 (EDT) Message-Id: <200305051728.h45HS4u31142@merlot.juniper.net> To: Alex Zinin cc: Juha Heinanen , Pedro Roque Marques , Mark Seery , PPVPN@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: Your message of "Sat, 03 May 2003 19:36:55 PDT." <2415569617.20030503193655@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41944.1052155684.1@juniper.net> Date: Mon, 05 May 2003 10:28:04 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Juha, > > I think you might be confusing the IETF with the market. However, To avoid any confusion it would be very useful if you'll elaborate on what is in your mind the relation between the IETF and the market. > this discussion is well outside the scope of this WG, and if you'd > like to continue it, I suggest we take it to the IETF problem > statement mailing list (problem-statement@alvestrand.no). > > So far, I am not shutting up and will continue steering the Internet > engineering process. One may ask whether that steering of the Internet engineering process will make it less or more relevant to the market. Or whether that question is relevant to the Internet engineering process in the first place. Yakov. > > -- > Alex > http://www.psg.com/~zinin/ > > Saturday, May 3, 2003, 2:22:00 AM, Juha Heinanen wrote: > > Pedro Roque Marques writes: > > > > My very personal opinion is that we cannot, at this point resolve this > > > as a tecnical issue. What ends up carrying more weight at this > > > particular point w/ those that are entitled to make the decision > > > (service providers) is mostly familiarity w/ the precursors of both > > > proposals. > > > i fully agree. if iesg starts to weight solutions based on their > > technical merit or purity, it makes itself irrelevant. the "market" has > > already decided (by the help of the big marketing muscle of major router > > vendors) that bgp/mpls is a good way to implement vpns. if some small > > players like me don't like the idea of requiring bgp and mpls for vpns, > > but would prefer a directory (radius) and ip based solution instead, > > they don't have any chance to get their message through. iesg is in the > > same boat and it better shut up or loose its face. > > > -- juha > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 14:46:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11037 for ; Mon, 5 May 2003 14:46:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45ImQ201457 for ; Mon, 5 May 2003 14:48:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45ImLC27475 for ; Mon, 5 May 2003 14:48:21 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com, Alex Zinin Cc: ppvpn@nortelnetworks.com, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: RE: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 14:44:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31336.6A100A86" X-LYRIS-Message-Id: 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_01C31336.6A100A86 Content-Type: text/plain; charset="iso-8859-1" Eric, > > > Alex> these changes are being made for management > reasons and are not > Alex> intended to be a "reset" on WG activities or to > halt or interrupt > Alex> progress on current ongoing WG activities. > > > 1. Before being comfortable with a reorganization, I'd like > to see what the new charters will be. I'd particularly > like to be sure > that the L3VPN charter is not constructed so as to cause a reset. Same > with the PWE3 > charter; we don't want to have to refight old wars. > > Valid concern! and if the split implies rechartering, debate around the charters, approval, etc, etc, one cannot claim that this proposed organizational change is purely an administrative operation. Hamid. ------_=_NextPart_001_01C31336.6A100A86 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF

Eric,

>
>
> Alex> these  changes are  being  made  for management 
> reasons  and are  not
> Alex> intended to  be a  "reset" on  WG activities or  to
> halt  or interrupt
> Alex> progress on current ongoing WG activities.
>
<snip>
>
> 1. Before being comfortable with a  reorganization, I'd like
> to see what the new charters  will be.  I'd particularly 
> like to be sure 
> that the L3VPN   charter is  not constructed so as to  cause a reset.  Same
>  with the PWE3
>    charter; we don't want to have to refight old wars.
>
>

Valid concern! and if the split implies rechartering,
debate around the charters, approval, etc, etc, one cannot
claim that this proposed organizational change is purely
an administrative operation.

Hamid.

 

------_=_NextPart_001_01C31336.6A100A86-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 15:05:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11891 for ; Mon, 5 May 2003 15:05:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45J7a221560 for ; Mon, 5 May 2003 15:07:36 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45J7W210845 for ; Mon, 5 May 2003 15:07:32 -0400 (EDT) Message-Id: <200305051857.h45IvPu40066@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Info aggregation In-Reply-To: Your message of "Sat, 03 May 2003 18:27:34 PDT." <1611408344.20030503182734@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75990.1052161045.1@juniper.net> Date: Mon, 05 May 2003 11:57:25 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, [clipped...] > > Also with respect to summarization, is the inability > > to summarize a function of the proposal in question, > > or a function of the fact that Ethernet does not have > > a summarizable address plane/structure (in L3VPNs even > > though a VPN idenitifer is required IP prefixes are > > still basically being used - I believe?). So without a > > good address plane for scalable networking, we are > > left with signaling names: VE IDs, PE IDs, VPLS IDs, > Group IDs etc. What we are really dealing with here is > > members of a set, not subnetworks. Do we qualify these > > names? Do we create relationships for sets, and > > subsets,......Seems like this basic issue has to be > > dealt with. > > Indeed. > Some more questions here: when taken to a large scale > (not necessarily just one VPLS) few more questions - see in-line... > o what VPLS info from other AS'es do PEs need to know? - what VPLS info from other PEs do PEs need to know? Is that different when PEs are in the same AS vs in different ASs ? > > o given the edge-to-edge nature of PWs, is it feasible > to summarize signalling information among AS'es at all? > > o if not, how do we scope distribution of signalling info > so amount of info per participating node has reasonable > growth characteristics? - given the edge-to-edge nature of PWs, is it feasible to have a PW between a pair of PEs without requiring signaling peering between these PEs ? - if not, how do we scope the amount of signaling peering required ? - what is the addition overhead (in addition to the overhead associated with autodiscovery), if any, associated with distribution of signaling info ? > o is it feasible to summarize VPLS membership information > among AS'es? if not, how to we scope distribution of membership info so amount of info per participating node has reasonable growth characteristics ? > o how do we get discovery, signaling, and data plane to work > together in a scalable form? Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 16:13:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14442 for ; Mon, 5 May 2003 16:13:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45KFN213720 for ; Mon, 5 May 2003 16:15:24 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45KFKs04384 for ; Mon, 5 May 2003 16:15:20 -0400 (EDT) Message-Id: <200305052012.h45KCku45738@merlot.juniper.net> To: Alex Zinin cc: PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: Re: IMPORTANT: Strategy for VPN work in IETF MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95811.1052165566.1@juniper.net> Date: Mon, 05 May 2003 13:12:46 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Folks, > > > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group in particular. > > > Such close attention to this WG was triggered by numerous concerns that > the IESG members received from the WG participants about limited and > slow progress within the WG despite the efforts of the WG chairs and its > members. The IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to improve WG > focus and productivity and ensure faster progress of the VPN-related work: > > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > > The L2 and L3 VPN work spaces are each big enough to warrant a separate > WG. While concentration of all VPN-related work in a single forum was > the right thing to do to ensure coordination of efforts when the PPVPN > WG was created and L2 VPN work came in, such concentration is causing > scaling problems within the WG at this moment. As was pointed by other folks, there is practically no L3 VPN related activities now. Practically all the discussion is about L2 VPN, or to be even more precise, above VPLS. Just count the number of messages posted to the list over the last 12 months related to L3 VPNs vs L2 VPNs. With this in mind please explain how moving L3 VPN into a separate WG would help to address the scaling problems that you mentioned above. > Migration of work into two separate WGs for L2 and L3 VPN technologies > with more specific WG charters will help to focus discussions, prevent > staff and meeting time overloading, and will aid faster progress of > corresponding technologies. As I mentioned above - there isn't any discussion on L3 VPN technologies. The WG focuses on L2 VPN, and mostly on VPLS. Are you suggesting that the WG need more discussion on L3 VPNs (e.g., 2547bis) ? > 2. Migration of the VPN-related work to the Internet area. > > As previously discussed, VPN-related work could be argued to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where we believe > the VPN work should go. > > As part of this move, we are also considering moving PWE3 into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the same > area. > > Based on the above considerations, we are considering the following steps: > > > 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. > The mailing lists will be established and the discussion of the proposed > charters of the new WGs will be initiated shortly. > > 2. Once the charters of the new WGs are agreed upon and approved by the IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will be > performed simultaneously. PPVPN WG documents will be migrated to the > corresponding new WGs. > > > It is our intention to complete this process by the Vienna IETF meeting. > Also, these changes are being made for management reasons and are not > intended to be a "reset" on WG activities or to halt or interrupt progress > on current ongoing WG activities. > > We'd like to hear from the WG members if they see any fatal flaws with > the proposed approach. Please send us your feedback by May 11th. I find the justifications for the steps you suggested above highly dubious (to say the least). The absence of solid justifications is one of the fatal flaws of the proposed approach. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 16:22:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14546 for ; Mon, 5 May 2003 16:21:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45KO9218137 for ; Mon, 5 May 2003 16:24:10 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45KO6s10778 for ; Mon, 5 May 2003 16:24:07 -0400 (EDT) Message-ID: <3EB6C4F9.ED4E4A92@cisco.com> Date: Mon, 05 May 2003 22:09:29 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: Re: IMPORTANT: Strategy for VPN work in IETF References: <2032066549.20030504001152@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex, I think that auto92679 is partially correct that it is just impossible to master every piece of technology for AD or IESG member... :) Well reg the split I have a mixed feelings, but I guess I will be fine either way provided that charters actually and explicitely allow for something productive to be done in the new groups. R. > Alex Zinin wrote: > > Folks, > > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group in particular. > > Such close attention to this WG was triggered by numerous concerns that > the IESG members received from the WG participants about limited and > slow progress within the WG despite the efforts of the WG chairs and its > members. The IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to improve WG > focus and productivity and ensure faster progress of the VPN-related work: > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > The L2 and L3 VPN work spaces are each big enough to warrant a separate > WG. While concentration of all VPN-related work in a single forum was > the right thing to do to ensure coordination of efforts when the PPVPN > WG was created and L2 VPN work came in, such concentration is causing > scaling problems within the WG at this moment. > > Migration of work into two separate WGs for L2 and L3 VPN technologies > with more specific WG charters will help to focus discussions, prevent > staff and meeting time overloading, and will aid faster progress of > corresponding technologies. > > 2. Migration of the VPN-related work to the Internet area. > > As previously discussed, VPN-related work could be argued to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where we believe > the VPN work should go. > > As part of this move, we are also considering moving PWE3 into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the same > area. > > Based on the above considerations, we are considering the following steps: > > 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. > The mailing lists will be established and the discussion of the proposed > charters of the new WGs will be initiated shortly. > > 2. Once the charters of the new WGs are agreed upon and approved by the IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will be > performed simultaneously. PPVPN WG documents will be migrated to the > corresponding new WGs. > > It is our intention to complete this process by the Vienna IETF meeting. > Also, these changes are being made for management reasons and are not intended > to be a "reset" on WG activities or to halt or interrupt progress on current > ongoing WG activities. > > We'd like to hear from the WG members if they see any fatal flaws with > the proposed approach. Please send us your feedback by May 11th. > > Regards, > > -- > Alex Zinin > IETF SUB-IP Area Co-Director From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 16:25:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14581 for ; Mon, 5 May 2003 16:25:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45KRu221977 for ; Mon, 5 May 2003 16:27:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45KRqs15395 for ; Mon, 5 May 2003 16:27:52 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Yakov Rekhter'" , "'Alex Zinin'" Cc: "'PPVPN'" , , "'Wijnen, Bert \(Bert\)'" , "'Thomas Narten'" , "'Peterson, Jon'" , "'Allison Mankin'" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 16:21:19 -0400 Organization: Cisco Systems, Inc. Message-ID: <15a601c31343$e66c9c40$6401a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200305052012.h45KCku45738@merlot.juniper.net> Importance: Normal X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Monday, May 05, 2003 4:13 PM > To: Alex Zinin > Cc: PPVPN; pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten; > Peterson, Jon; Allison Mankin > Subject: Re: IMPORTANT: Strategy for VPN work in IETF > > > Alex, > > > Folks, > > > > > > Since San Francisco IETF meeting the IESG has been considering the > > situation in the SUB-IP area and in the PPVPN Working Group in > > particular. > > > > > > Such close attention to this WG was triggered by numerous concerns > > that the IESG members received from the WG participants > about limited > > and slow progress within the WG despite the efforts of the > WG chairs > > and its members. The IESG also used this opportunity to > consider the > > IETF area that the PPVPN work would fit best. > > > > > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > > considering the following organizational changes in order > to improve > > WG focus and productivity and ensure faster progress of the > > VPN-related work: > > > > > > 1. Split of Layer-2 and Layer-3 VPN work in separate > Working Groups. > > > > > > The L2 and L3 VPN work spaces are each big enough to > warrant a separate > > WG. While concentration of all VPN-related work in a > single forum was > > the right thing to do to ensure coordination of efforts > when the PPVPN > > WG was created and L2 VPN work came in, such > concentration is causing > > scaling problems within the WG at this moment. > > As was pointed by other folks, there is practically no L3 VPN > related activities now. Practically all the discussion is > about L2 VPN, or to be even more precise, above VPLS. Just > count the number of messages posted to the list over the last > 12 months related to L3 VPNs vs L2 VPNs. > > With this in mind please explain how moving L3 VPN into a > separate WG would help to address the scaling problems that > you mentioned above. This may be the case because a) all of the existing L3 VPN work is wrapped up and b) no new L3 VPN work has been added to the work queue due to lack of bandwidth in general, which I think Alex's proposal is trying to address. There was work proposed at the SF meeting that was discouraged to move forward due to the current list of things on the WG's plate. --Tom > > Migration of work into two separate WGs for L2 and L3 > VPN technologies > > with more specific WG charters will help to focus > discussions, prevent > > staff and meeting time overloading, and will aid faster > progress of > > corresponding technologies. > > As I mentioned above - there isn't any discussion on L3 VPN > technologies. The WG focuses on L2 VPN, and mostly on VPLS. > > Are you suggesting that the WG need more discussion on L3 VPNs (e.g., > 2547bis) ? > > 2. Migration of the VPN-related work to the Internet area. > > > > As previously discussed, VPN-related work could be > argued to belong > > to more than one area. Tunneling mechanisms are the > property that > > gravitates this work to the Internet area, which is > where we believe > > the VPN work should go. > > > > As part of this move, we are also considering moving > PWE3 into INT, > > so that L2TPEXT, PWE3, and thew new VPN WGs are > operating in the same > > area. > > > > Based on the above considerations, we are considering the following > > steps: > > > > > > 1. Two new WGs--L2VPN and L3VPN--will be created in the > Internet area. > > The mailing lists will be established and the > discussion of the proposed > > charters of the new WGs will be initiated shortly. > > > > 2. Once the charters of the new WGs are agreed upon and > approved by the IESG, > > creation of the L2VPN and L3VPN WGs and shutdown of the > PPVPN WG will be > > performed simultaneously. PPVPN WG documents will be > migrated to the > > corresponding new WGs. > > > > > > It is our intention to complete this process by the Vienna IETF > > meeting. Also, these changes are being made for management > reasons and > > are not intended to be a "reset" on WG activities or to halt or > > interrupt progress on current ongoing WG activities. > > > > We'd like to hear from the WG members if they see any fatal > flaws with > > the proposed approach. Please send us your feedback by May 11th. > > I find the justifications for the steps you suggested above > highly dubious > (to say the least). The absence of solid justifications is > one of the fatal flaws of the proposed approach. > > Yakov. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 16:29:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15147 for ; Mon, 5 May 2003 16:29:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45KVW225547 for ; Mon, 5 May 2003 16:31:33 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45KVRf19756 for ; Mon, 5 May 2003 16:31:27 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Alex Zinin'" , Subject: RE: [PWE3] IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 16:27:58 -0400 Organization: Cisco Systems, Inc. Message-ID: <15ae01c31344$d46f6580$6401a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <2032066549.20030504001152@psg.com> Importance: Normal X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I personally like the approach. A few questions about clarifications. Will new framework/requirements be needed, or will the existing ones just be re-assigned accordingly? There are some cases where some documents straddle the fence; how will these be handled? --Tom > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Alex Zinin > Sent: Sunday, May 04, 2003 3:12 AM > To: ppvpn@nortelnetworks.com > Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten; > Peterson, Jon; Allison Mankin > Subject: [PWE3] IMPORTANT: Strategy for VPN work in IETF > > > Folks, > > Since San Francisco IETF meeting the IESG has been > considering the situation in the SUB-IP area and in the PPVPN > Working Group in particular. > > Such close attention to this WG was triggered by numerous > concerns that the IESG members received from the WG > participants about limited and slow progress within the WG > despite the efforts of the WG chairs and its members. The > IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to > improve WG > focus and productivity and ensure faster progress of the > VPN-related work: > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > The L2 and L3 VPN work spaces are each big enough to > warrant a separate > WG. While concentration of all VPN-related work in a > single forum was > the right thing to do to ensure coordination of efforts > when the PPVPN > WG was created and L2 VPN work came in, such > concentration is causing > scaling problems within the WG at this moment. > > Migration of work into two separate WGs for L2 and L3 VPN > technologies > with more specific WG charters will help to focus > discussions, prevent > staff and meeting time overloading, and will aid faster > progress of > corresponding technologies. > > 2. Migration of the VPN-related work to the Internet area. > > As previously discussed, VPN-related work could be argued > to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where > we believe > the VPN work should go. > > As part of this move, we are also considering moving PWE3 > into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating > in the same > area. > > Based on the above considerations, we are considering the > following steps: > > 1. Two new WGs--L2VPN and L3VPN--will be created in the > Internet area. > The mailing lists will be established and the discussion > of the proposed > charters of the new WGs will be initiated shortly. > > 2. Once the charters of the new WGs are agreed upon and > approved by the IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the > PPVPN WG will be > performed simultaneously. PPVPN WG documents will be > migrated to the > corresponding new WGs. > > It is our intention to complete this process by the Vienna > IETF meeting. > Also, these changes are being made for management reasons and > are not intended > to be a "reset" on WG activities or to halt or interrupt > progress on current > ongoing WG activities. > > We'd like to hear from the WG members if they see any fatal > flaws with the proposed approach. Please send us your > feedback by May 11th. > > Regards, > > -- > Alex Zinin > IETF SUB-IP Area Co-Director > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 16:34:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15424 for ; Mon, 5 May 2003 16:34:05 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45KaS229436 for ; Mon, 5 May 2003 16:36:28 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45KaOf26137 for ; Mon, 5 May 2003 16:36:25 -0400 (EDT) Message-ID: <20030505203327.42556.qmail@web13507.mail.yahoo.com> Date: Mon, 5 May 2003 13:33:27 -0700 (PDT) From: Mark Seery Subject: Re: Info aggregation To: yakov@juniper.net Cc: PPVPN@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13507.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: web13507.mail.yahoo.com [216.136.175.86] X-LYRIS-Message-Id: Yakov, Another set of questions to add to yours: -Why does one AS need to know anything other than that the other AS is a member of the VPLS? -Why should one AS be restricted to how it distributes/signals information internally based on the model the other AS wants it to work on (for example what if one AS wants to pursue multicast and the other does not?, or one wants to pursue BGP signaling and the other does not? how does a network gracefully evolve over time?). -Why should one SP, open up their AS to the running of OAM and other management PDUs through their AS? -Why should one AS expose how many PEs are in its portion of the VPLS; especially if it is a service-oriented VPLS rather than an enterprise interconnect. -In today's IP networks why doesn't every router within the AS peer with every other router in other ASs that its traffic passes through? -Why has a GMPLS overlay proposal been submitted to CCAMP: are these not end-to-end connections? Are the issues not ultimately similar? All, If these issues have already been discussed and we are rehashing old territory then just say so and happy to move on. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 17:09:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16404 for ; Mon, 5 May 2003 17:09:52 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45LCG200195 for ; Mon, 5 May 2003 17:12:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45LCC126644 for ; Mon, 5 May 2003 17:12:13 -0400 (EDT) Date: Mon, 5 May 2003 14:05:01 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <24168455476.20030505140501@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: Strategy for VPN work in IETF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Guys, [I removed the capitalized word from the subject, since it triggers some spam filters, people say] Let me provide some clarifications wrt the questions raised in this thread. 1. Changes will induce additional delays I should have communicated this better, I think. The fact that we're talking about two separate WGs does NOT mean that work within PPVPN is stopped. As my message said, the new WGs would be announced at the same time as the current one would be closed. Until then, the only discussion happening on the new WG's mailing lists would be about the charter and the PPVPN would conduct business as usual. We're closely coordinating with Marco and Rick, so all decisions taken within PPVPN will be effective in the new WGs. So, the changes will not affect how the PPVPN documents are progressed. 2. Not much L3 stuff is left anyway, so putting it in a separate WG won't help. This is, of course, the first thing that was checked before deciding whether separate WGs are needed or not. The proposed charter of the L3VPN WG will give a clear view of what's left and how much time it needs (see also my answer to the next question). Long story short, it does look like that there's enough work left to warrant a separate WG. 3. What are the new charters going to be like and who are the chairs? I am in the process of creating the new mailing lists, as soon as they are ready (shouldn't take the secretariat more than 2 days), I will inform this list and will post the proposed charters there for discussion. 4. "that area AD's" attitude To start with, let me point out that the following part of the message-- > Also, these changes are being made for management reasons and are not > intended to be a "reset" on WG activities or to halt or interrupt progress > on current ongoing WG activities. --was suggested by Thomas who is the proposed responsible AD for the new WGs. Thomas and I will keep coordinating during and after the transition. Regarding other IESG members--this matter (splitting the work in two WGs), as well as the proposed new charters have been intensively discussed and reviewed within the IESG. 5. What to do with "generic" documents like requirements and terminology? For documents that span both WGs, one of the WGs will be made the host for each them based on the discussion with the community, authors, and WG chairs. 6. Let's see who's complaining, what the concerns are, whether they are valid, etc, etc. Management of WGs within areas is part of the AD's responsibilities. While doing so, we talk to different IETF participants, document authors, WG chairs, collect opinions, then compare those with our observations, and apply our judgement to decide whether something needs to be changed and how. Given that these processes happen under the confidentiality conditions, it would not be productive and/or constructive to do this in public. It does mean that a leap of faith in ADs is needed, but I don't think we can efficiently operate without it--someone has to be able to make the decisions. Hope this helps. Regards -- Alex Zinin From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 17:13:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16552 for ; Mon, 5 May 2003 17:13:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45LFu201760 for ; Mon, 5 May 2003 17:15:56 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45LFqk28640 for ; Mon, 5 May 2003 17:15:52 -0400 (EDT) Message-ID: <3EB6CF6C.FF8BD60E@cisco.com> Date: Mon, 05 May 2003 22:54:04 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Alex Zinin , PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: Re: IMPORTANT: Strategy for VPN work in IETF References: <200305052012.h45KCku45738@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Yakov, > As was pointed by other folks, there is practically no L3 VPN > related activities now. Well I can't agree with this one submitting few new drafts within the last couple of months proposing some new improvements to L3VPNs ;). What may be the reason for not much work is the current charter's below quote: "Note that it is not a goal of this WG to develop new protocols or extend existing ones." So if the split allows to remove that one line I think it could be beneficial. Also it could very well get rid of all the framework/requirements and applicability statements ;). On the other hand there is work common to both L2VPN & L3VPNs - if we split ppvpn where such a work is going to end up ? In both :) ? R. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 17:20:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16706 for ; Mon, 5 May 2003 17:20:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45LNM205655 for ; Mon, 5 May 2003 17:23:22 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45LNIk04193 for ; Mon, 5 May 2003 17:23:19 -0400 (EDT) Message-Id: <200305052119.RAA13282@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Alex Zinin , PPVPN cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-reply-to: Your message of "Mon, 05 May 2003 13:12:46 PDT." <200305052012.h45KCku45738@merlot.juniper.net> Date: Mon, 05 May 2003 17:19:31 -0400 From: George Swallow X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: swallow@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: I don't see the need for two work groups. Just encourage the chairs to get two meeting slots (until the level of activity settles down). ///George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 17:33:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17171 for ; Mon, 5 May 2003 17:33:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45LZk211527 for ; Mon, 5 May 2003 17:35:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45LZgW16886 for ; Mon, 5 May 2003 17:35:42 -0400 (EDT) Date: Mon, 5 May 2003 14:26:32 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <107169745951.20030505142632@psg.com> To: PPVPN@nortelnetworks.com CC: Yakov Rekhter Subject: Single vs many solution(s) In-Reply-To: <200305051718.h45HIOu29899@merlot.juniper.net> References: <200305051718.h45HIOu29899@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single > solution, then why wouldn't you insist to have the same goal > for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 17:47:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17621 for ; Mon, 5 May 2003 17:47:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45Lo5218192 for ; Mon, 5 May 2003 17:50:05 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45LnxR28845 for ; Mon, 5 May 2003 17:50:01 -0400 (EDT) Date: Mon, 5 May 2003 14:38:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10170473728.20030505143840@psg.com> To: George Swallow CC: PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , =?ISO-8859-15?B?UGV0ZXJzb24sDQogICAgSm9u?= , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: <200305052119.RAA13282@bifocal.cisco.com> References: <200305052119.RAA13282@bifocal.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit George, Interesting that you mention this... I actually believe that if a WG consistently needs more than one meeting slot, it is a good sign of it having more on its plate than can efficiently deal with or poor management of the meeting time. Cheers. -- Alex Monday, May 5, 2003, 2:19:31 PM, George Swallow wrote: > I don't see the need for two work groups. Just encourage the > chairs to get two meeting slots (until the level of activity settles > down). > ///George > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 19:43:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21637 for ; Mon, 5 May 2003 19:43:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45Nk3223952 for ; Mon, 5 May 2003 19:46:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h45NjxV15416 for ; Mon, 5 May 2003 19:46:00 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: zinin@psg.com, PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 00:40:51 +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" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Alex, How is the word 'solution' to be interpreted in the sentence below? "I believe the goal for the WG should be to work out a single solution." Does 'solution' = 'protocol'... i.e. LDP vs. BGP? If so then I do not think working towards a single solution based on which protocol is better for X or Y is the best way forward. I think the seemingly never-ending debate on this subject proves this point. If however the word solution was replaced with 'set of detailed functional specifications' then maybe we can move away from the LDP vs. BGP debate and concentrate on developing a set of functional specifications created from the ground up. This is in contrast to some of the existing 'solutions' which seem to me to have been developed the wrong way round, i.e. we already use protocol X for service Z, what changes do we need to make to protocol X in order for it to be used for this new service Y. If the functional specifications are well defined it should be clear which protocols are most suited and there may be more than one. For example, one protocol may be more suited for a specific function intra-AS and another inter-AS. To use a simple analogy, OSPF is more suited for intra-AS routing and BGP is more suited for inter-AS routing, but they both perform the function 'routing'. Some of the foundations for the functional specifications probably already exist within the various requirement and solution drafts and just need extracting. The main advantages of separate functional specifications being (1) that they can be developed independently without having any impact on each other (2) operators would be able to choose which protocol they wish to use to perform a certain function based on their own specific requirements. Richard -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: 05 May 2003 22:27 To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single > solution, then why wouldn't you insist to have the same goal > for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 21:09:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23507 for ; Mon, 5 May 2003 21:09:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h461B7213222 for ; Mon, 5 May 2003 21:11:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h461B4E28485 for ; Mon, 5 May 2003 21:11:05 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6064DFF10@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Alex Zinin'" , "'PPVPN@nortelnetworks.com'" Subject: RE: Strategy for VPN work in IETF Date: Mon, 5 May 2003 21:07:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3136B.E75CCB34" X-LYRIS-Message-Id: 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_01C3136B.E75CCB34 Content-Type: text/plain Alex, 1. Changes will induce additional delays I should have communicated this better, I think. The fact that we're talking about two separate WGs does NOT mean that work within PPVPN is stopped. As my message said, the new WGs would be announced at the same time as the current one would be closed. Until then, the only discussion happening on the new WG's mailing lists would be about the charter and the PPVPN would conduct business as usual. We're closely coordinating with Marco and Rick, so all decisions taken within PPVPN will be effective in the new WGs. bnj> Are you implying that the current WG chairs agreed to the split? Or are they also being "informed" of a decision? <...>. 6. Let's see who's complaining, what the concerns are, whether they are valid, etc, etc. Management of WGs within areas is part of the AD's responsibilities. While doing so, we talk to different IETF participants, document authors, WG chairs, collect opinions, then compare those with our observations, and apply our judgement to decide whether something needs to be changed and how. Given that these processes happen under the confidentiality conditions, it would not be productive and/or constructive to do this in public. It does mean that a leap of faith in ADs is needed, but I don't think we can efficiently operate without it--someone has to be able to make the decisions. Hope this helps. bnj> not really - it looks like a solution was cooked up behind closed door to an inexistent / unexplained problem - this goes counter to the open and transparent process the IETF prides itself of! Bilel. ------_=_NextPart_001_01C3136B.E75CCB34 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strategy for VPN work in IETF

Alex,

<cut>
 
1. Changes will induce additional delays

   I should have communicated this better, = I think. The fact that
   we're talking about two separate WGs = does NOT mean that work within
   PPVPN is stopped. As my message said, = the new WGs would be
   announced at the same time as the = current one would be closed.
   Until then, the only discussion = happening on the new WG's mailing
   lists would be about the charter and = the PPVPN would conduct
   business as usual. We're closely = coordinating with Marco and Rick,
   so all decisions taken within PPVPN = will be effective in the new
   WGs.

bnj> Are you implying that the current WG chairs = agreed to the split? Or are they also being "informed" of a = decision?

<...>.


6. Let's see who's complaining, what the concerns = are, whether they
   are valid, etc, etc.

   Management of WGs within areas is part = of the AD's
   responsibilities. While doing so, we = talk to different IETF
   participants, document authors, WG = chairs, collect opinions, then
   compare those with our observations, = and apply our judgement to
   decide whether something needs to be = changed and how.

   Given that these processes happen under = the confidentiality
   conditions, it would not be productive = and/or constructive to do
   this in public. It does mean that a = leap of faith in ADs is needed,
   but I don't think we can efficiently = operate without it--someone
   has to be able to make the = decisions.

Hope this helps.

bnj> not really - it looks like a solution was = cooked up behind closed door to an inexistent / unexplained problem - = this goes counter to the open and transparent process the IETF prides = itself of!

Bilel.




------_=_NextPart_001_01C3136B.E75CCB34-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 5 23:22:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25484 for ; Mon, 5 May 2003 23:22:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h463Ol203672 for ; Mon, 5 May 2003 23:24:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h463OiW17704 for ; Mon, 5 May 2003 23:24:44 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6BBC@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Alex Zinin'" , PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Date: Mon, 5 May 2003 23:21:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3137E.8E4554C2" X-LYRIS-Message-Id: 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_01C3137E.8E4554C2 Content-Type: text/plain Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------_=_NextPart_001_01C3137E.8E4554C2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Single vs many solution(s)

Alex,

  I think the ideal goal is to have only one = solution, but such ideal usual can be achieved if we are working in a = pure theoretical environment, without market considerations. In reality = the market is driving in most of the cases, and some assumptions made = two years ago are not any more valid - there are categories of SPs that = pretty much have disappeared from the map.

  You stated very clear that a problem space = needs to have a single solution. I fully agree with you as a goal, but = ut the issue that we face right now is that the problem space is not = well concluded and well understood just purely from technical = considerations.

 The L2 VPLS is a complex space with multiple = dimensions, and the vendors - in the last two years -  have worked = from different angles, optimizing one or more dimension(s) of the = problem space (probable the downturn in the market it self, was part of = the problem). Without to contradict each other, most of the solutions = are closed in a specific dimension, based on some objective/subjective = parameters or experience and some criteria of optimization. Moving in = only one dimension doesn't scale it self.

 
 The fact we do have more than one solution, I = think is a good thing, and doesn't contradict that we can't move toward = one solution, if we are driving diligently, and willing to make = compromises. Taken such research value in consideration, would be a = positive sign that IETF is looking to create a solution that would be = valid for a while. Reading the mailing list, I observed the same wise = advise from most of the SPs, and this reflect not a "problem" = but a reality.


Cheers
   Vasile
 
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, May 05, 2003 5:27 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject = line]

>> I believe the goal for the WG should be to = work out
>> a single solution.

> That is certainly not in the charter. In fact = the goal
> you stated above directly contradicts what is = in the charter:

>    Multiple approaches are being = developed as each approach
>    has particular = characteristics and differing scope of
> applicability.

Thanks for pointing out a possible contradiction. I = don't think it exists.

My opinion (and I think it would be safe for me to = say it is consistent with that of the IESG) is that as long as = different solutions are solving different problems (or, as the text of = the charter says, have different scopes of applicability), it is fine = to have more than one solution. However, for a single problem, we only = need a single STD'ized solution.

> And if you believe that for VPLS the goal should = be a single solution,
> then why wouldn't you insist to have the same = goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on = a single solution for L3 VPNs, then why do you insist on this for L2 = VPNs" ;-)

The reason is I don't want to restart the L3 VPN work = in the IETF and/or revisit the decisions that have been made in the = past, while I still see a reasonable opportunity to steer the L2 VPN = work.

> Also, if you insist on a single solution, = wouldn't that
> imply a single auto-discovery mechanism for = VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C3137E.8E4554C2-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 02:13:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08996 for ; Tue, 6 May 2003 02:13:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h466G4R06049 for ; Tue, 6 May 2003 02:16:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h466G0Y09127 for ; Tue, 6 May 2003 02:16:00 -0400 (EDT) Date: Mon, 5 May 2003 23:11:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <90201253777.20030505231140@psg.com> To: PPVPN@nortelnetworks.com CC: richard.spencer@bt.com, yakov@juniper.net Subject: Re: Single vs many solution(s) In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Richard, Thanks for your input, it is indeed very important for us to be on the same page here, and I happen to agree with most of what you said. I don't think that "solution" == "protocol", but rather a set of functional components, each addressing its particular problem. The framework would then put them all together. I also view as reasonable an approach where there is a difference between how intra-domain and inter-domain issues are solved. So, from this perspective, the framework MAY very easily look like this (mechanism == protocol or protocol extension): Data-plane : mechanism A Intra-domain discovery : mechanism B Intra-domain signaling : mechanism C Inter-domain discovery : mechanism D Inter-domain signaling : mechanism C++ Of course there must be some architectural glue that brings all the pieces together. What I would like us to avoid is solution space exploration, where we have many mechanisms for the same function we need, i.e, I would be disappointed to see us end up with a framework looking like: Data-plane : mechanism A, or B, or C Intra-domain discovery : mechanism D, or E, or F Intra-domain signaling : mechanism G, or H, or I Inter-domain discovery : mechanism J, or K, or L Inter-domain signaling : mechanism M, or N, or O This would, in view, impact interoperability. We also seem to agree on the point I brought in my message to Mark: > Regarding the considerations you mention above, in my > opinion it would be wrong for us to start the discussion > by saying "SPs have X and Y deployed in their networks, > so we just have to decide whether we piggy-back on X or > on Y." Instead I'd like to see a discussion ala "What are > the functions we need? How can we best implement them? > Do we have an existing protocol that would be the right > fit for this functionality or do we need a new one(s)?" Yakov, regarding your question again-- > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? --to refine my answer, I would say, my preference would be for the WG to come up with a single solution consisting with at most two discovery mechanisms--one for intra-domain and one for inter-domain problem space. It is ok if the intra-domain only part comes first. -- Alex http://www.psg.com/~zinin/ Monday, May 5, 2003, 4:40:51 PM, richard.spencer@bt.com wrote: > Alex, > How is the word 'solution' to be interpreted in the sentence below? > "I believe the goal for the WG should be to work out a single solution." > Does 'solution' = 'protocol'... i.e. LDP vs. BGP? If so then I do not think > working towards a single solution based on which protocol is better for X or > Y is the best way forward. I think the seemingly never-ending debate on this > subject proves this point. > If however the word solution was replaced with 'set of detailed functional > specifications' then maybe we can move away from the LDP vs. BGP debate and > concentrate on developing a set of functional specifications created from > the ground up. This is in contrast to some of the existing 'solutions' which > seem to me to have been developed the wrong way round, i.e. we already use > protocol X for service Z, what changes do we need to make to protocol X in > order for it to be used for this new service Y. > If the functional specifications are well defined it should be clear which > protocols are most suited and there may be more than one. For example, one > protocol may be more suited for a specific function intra-AS and another > inter-AS. To use a simple analogy, OSPF is more suited for intra-AS routing > and BGP is more suited for inter-AS routing, but they both perform the > function 'routing'. > Some of the foundations for the functional specifications probably already > exist within the various requirement and solution drafts and just need > extracting. > The main advantages of separate functional specifications being (1) that > they can be developed independently without having any impact on each other > (2) operators would be able to choose which protocol they wish to use to > perform a certain function based on their own specific requirements. > Richard > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: 05 May 2003 22:27 > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > Yakov, > [I took the liberty to change the subject line] >>> I believe the goal for the WG should be to work out >>> a single solution. >> That is certainly not in the charter. In fact the goal >> you stated above directly contradicts what is in the charter: >> Multiple approaches are being developed as each approach >> has particular characteristics and differing scope of applicability. > Thanks for pointing out a possible contradiction. I don't think > it exists. > My opinion (and I think it would be safe for me to say it is > consistent with that of the IESG) is that as long as different > solutions are solving different problems (or, as the text of the > charter says, have different scopes of applicability), it is fine to > have more than one solution. However, for a single problem, we only > need a single STD'ized solution. >> And if you believe that for VPLS the goal should be a single >> solution, then why wouldn't you insist to have the same goal >> for L3 VPNs ? > you forgot to add "and if you wouldn't insist on a single solution for > L3 VPNs, then why do you insist on this for L2 VPNs" ;-) > The reason is I don't want to restart the L3 VPN work in the IETF > and/or revisit the decisions that have been made in the past, while I > still see a reasonable opportunity to steer the L2 VPN work. >> Also, if you insist on a single solution, wouldn't that >> imply a single auto-discovery mechanism for VPLS ? > This would definitely be my preference. > Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 04:10:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11370 for ; Tue, 6 May 2003 04:10:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h468CvR19811 for ; Tue, 6 May 2003 04:12:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h468Csw26577 for ; Tue, 6 May 2003 04:12:54 -0400 (EDT) Date: Tue, 6 May 2003 01:08:13 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1208246793.20030506010813@psg.com> To: "Bilel Jamoussi" CC: "'PPVPN@nortelnetworks.com'" Subject: Re: Strategy for VPN work in IETF In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6064DFF10@zcard0ke.ca.nortel.com> References: <0D7FC1D8D861D511AEA70002A52CE5E6064DFF10@zcard0ke.ca.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: jamoussi@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bilel, > 1. Changes will induce additional delays > I should have communicated this better, I think. The fact that > we're talking about two separate WGs does NOT mean that work within > PPVPN is stopped. As my message said, the new WGs would be > announced at the same time as the current one would be closed. > Until then, the only discussion happening on the new WG's mailing > lists would be about the charter and the PPVPN would conduct > business as usual. We're closely coordinating with Marco and Rick, > so all decisions taken within PPVPN will be effective in the new > WGs. bnj>> Are you implying that the current WG chairs agreed to the split? bnj>> Or are they also being "informed" of a decision? I imply what I say, and I don't appreciate people putting words in my mouth. Regarding your question, we did have a number of conversations with the chairs before I sent the message to this list. If you would like to know Marco's or Rick's opinion on this subject, my recommendation would be to send them an e-mail and ask. > Hope this helps. bnj>> not really - it looks like a solution was cooked up behind closed door > to an inexistent / unexplained problem - this goes counter to the open and > transparent process the IETF prides itself of! You are misrepresenting the situation here. It is perfectly reasonable for ADs to form an opinion by talking to IETF participants and WG chairs not using the microphone in the room and by exchanging e-mails not using a public mailing list. It is also reasonable for them to analyze the situation and bring a proposed solution to the community. Regarding openness of the process, you probably noticed that we're discussing the proposed plan in the open. Based on the feedback received, the involved ADs will decide whether it needs to be changed or not. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 04:33:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11700 for ; Tue, 6 May 2003 04:33:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h468ZpR24984 for ; Tue, 6 May 2003 04:35:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h468Zli05128 for ; Tue, 6 May 2003 04:35:47 -0400 (EDT) Date: Tue, 06 May 2003 17:34:00 +0900 (JST) Message-Id: <20030506.173400.78701593.suzuki.muneyoshi@lab.ntt.co.jp> To: zinin@psg.com, PPVPN@nortelnetworks.com Cc: suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Strategy for VPN work in IETF From: Muneyoshi Suzuki In-Reply-To: <24168455476.20030505140501@psg.com> References: <24168455476.20030505140501@psg.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I fully agree with the new strategy for VPN work in the IETF. It seems painful process, but IMHO, the PPVPN charter covers too large technical area. The WG need to progress L3 solution and L2 architecture work simultaneously; it is too much for one WG. I think this re-organization is good chance to reduce overhead of the PPVPN WG. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 04:52:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11979 for ; Tue, 6 May 2003 04:52:09 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h468sXR00269 for ; Tue, 6 May 2003 04:54:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h468sUl16461 for ; Tue, 6 May 2003 04:54:30 -0400 (EDT) Message-Id: <200305060851.h468pkD24104@zcars0ms.ca.nortel.com> From: "vivienne" Subject: =?GB2312?B?MjC80tDF0/663LrDtcS5+s3iw+K30desx67N+NW+ILK7v8myu7+0?= To: ppvpn@nortelnetworks.com Content-Type: text/plain;charset="GB2312" Reply-To: guanfeng324@eyou.com Date: Tue, 6 May 2003 16:47:09 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-SMTP-HELO: eyou.com X-SMTP-MAIL-FROM: guanfeng324@eyou.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [218.62.69.56] X-LYRIS-Message-Id: ppvpn:ÄúºÃ! Õ¼ÓÃÄú¼¸·ÖÖÓʱ¼ä£¬×Ðϸä¯ÀÀ²¢×¢²áÕâЩÍøÕ¾¡£Èç¹ûÄú¶®Ó¢ÎÄ×îºÃÁË£¬Èç¹û²»¶®Ã»¹Øϵ£¬¼ÓÎÒQQ£º 52404916£¬¸øÄúÏêϸ½â´ðÈçºÎ×¢²áºÍÔõÑù׬Ǯ£¡ ÔÚ×¢²áÕâЩÍøվ֮ǰ£¬×îºÃÏÈÔÚÕâÀïhttps://www.e-gold.com/newacct/ ÉêÇëe-gold±Ò£¬ÒÔ·ÀһЩ¹úÄÚµØ Ö·ÊÕ²»µ½Ö§Æ±¡£ÎÒ¿ÉÒÔÒÔ1£º7.8µÄ±ÈÀý°ïÄú¶Ò»»G±Ò£¬ËùÒÔÇë¼ÇÏÂÎÒµÄQQ£¬»òÕß±£ÁôÕâ·âmail¡£ Ç¿ÁÒÍƼö--------------- Ò»¡¢½éÉÜÐÂÈ˼ÓÈëÀà 4ÔÂ15ÈÕпªÍ¨£¬Ä¿Ç°¼ÓÈëµÄ²»×ã100ÈË£¬ºÜÐÂÏÊÉú¶¯µÄ·½°¸£¬Ãâ·Ñ¼ÓÈ룬Ãâ·ÑÉý¼¶£¡ http://sixgoldenstars.com/servlet/SGS?sponsor=ccy00 »áÓ¢Îĵģ¬Ó¦¸Ã²»ÓÃÎÒ½âÊÍÁË£¬ÎÒÖ»°ÑËüµÄÔË×÷¹£¸ÅдÔÚÕâÀ¸ø´ó¼Ò²Î¿¼¡£ ÄãÏÈÃâ·Ñ×¢²á³ÉΪÃâ·Ñ»áÔ±£¬ÄãµÄÃû×ֻᱻÁÐÈëµÈºòÃûµ¥ÖС£ ÿµ±Äã½éÉÜÒ»Ãû³ÉÔ±¼ÓÈ룬ÄãµÄÏÖ½ðÕÊ»§»á³öÏÖ5ÃÀ½ð£¬Í¬Ê±ÔڵȺòÃûµ¥ÖÐÄ㻹ÓÐÒ»¸öÐÇÐÇÕÊ»§£¬Ò²»á±»¼ÓÈë5 ÃÀ½ð¡£µ±ÄãµÄÏÖ½ðÕÊ»§ÀۼƵ½20ÃÀ½ð£¨Ò²¾ÍÊÇ˵£¬µ±Äã½éÉÜÁË4Ãû³ÉÔ±ºó£©£¬Äã»á×Ô¶¯Éý¼¶Îª½ð¼¶»áÔ±£¬²¢´ÓµÈ ºòÃûµ¥ÒÆÖÁÐÇÐÇÃûµ¥ÖС£ £¨×¢Ò⣺ 1£® ÄãÒªÏë¿ìЩ¼ÓÈëµ½ÐÇÐÇÃûµ¥ÖУ¬»¹¿ÉÒÔͨ¹ýPaypalµÈ·½Ê½Ö§¸¶20ÃÀ½ð¼´¿É£¬²»¹ý£¬¼ÈȻĿǰ·¢²¼³õÆÚ¿ÉÒÔ Ãâ·ÑµÈ´ý£¬ºÎÀÖ¶ø²»ÎªÄØ£¿ 2£® ÄãÔڵȺòÃûµ¥ÖÐÖ»ÄÜÍ£Áô×î¶à90Ì죬²»¹ý3¸öÔµÄʱ¼ä½éÉÜ4Ãû³ÉÔ±¼ÓÈ룬´Â´ÂÓÐÓàÀ²£© ºÃÁË£¬ÏÖÔÚÄãÔÚÐÇÐÇÃûµ¥ÖÐÁË£¬ ¿ªÊ¼½øÈëÄãµÄÊÕÒæ½×¶ÎÁË£¡ ÄãµÄÏÖ½ðÕÊ»§ÖеÄ20ÃÀ½ðʵ¼Ê±»ÓÃÀ´Ö§¸¶ÁËÄãµÄ½ð¼¶»áÔ±µÄµÚÒ»¸öÔµÄÔ·ѣ¬¾ßÌåÀ´Ëµ£¬ÆäÖÐ5ÃÀ½ð¸¶½øÄãµÄÉÏ ÏßµÄÏÖ½ðÕÊ»§£¬ÓàϵÄ10ÃÀ½ð±»Ëæ»úµØ·ÖÅä¸øÐÇÐÇÃûµ¥ÖеÄÆäËû³ÉÔ±£¨Ã¿ÈË1ÃÀ½ð£©¡£ Õâʱºò£¬µ±Äã½éÉܵijÉÔ±Éý¼¶Îª½ð¼¶»áÔ±ºó£¬ËûµÄ20ÃÀ½ðÒ²»áÒÔÈçÉϵķ½Ê½±»·ÖÅä¡£ÕâÖÖÏÖ½ð·ÖÅäʱ¿ÌÔÚ½ø ÐУ¬Äã»á²»¶ÏµÄÊÕµ½Ëæ»úµÄÏÖ½ð£¬AGAIN AND AGAIN£¡ÔõôÑù£¬¿´µ½ÄãµÄÊÕÒæÁË°É£¡ ÄãµÄ½ð¼¶»áÔ±×ʸñÐèÒª°´ÔÂÒÔ20ÃÀ½ðÐø·Ñ£¬Õâ20ÃÀ½ðÍêÈ«À´×ÔÄãµÄÏÖ½ðÕÊ»§£¬Ò²¾ÍÊÇ˵ÄãֻҪÿÔ±£³ÖÄãµÄÏÖ ½ðÕÊ»§ÓÐÖÁÉÙ20ÃÀ½ð£¬¶à³öµÄ²¿·Ö£¬Äã¿ÉÒÔËæʱ֧ȡ³öÀ´£¡£¡ µ±Äã½øÈëÐÇÐÇÃûµ¥ÖУ¬Äã¾ÍµÃµ½ÁËÒ»¿ÅÐÇ£» µ±ÄãµÄÐÇÐÇÕÊ»§´ïµ½$ 2,000£¬Äã¾ÍµÃµ½ÁËÁ½¿ÅÐÇ£» µ±ÄãµÄÐÇÐÇÕÊ»§´ïµ½$ 4,000£¬Äã¾ÍµÃµ½ÁËÈý¿ÅÐÇ£» µ±ÄãµÄÐÇÐÇÕÊ»§´ïµ½$ 6,000£¬Äã¾ÍµÃµ½ÁËËÄ¿ÅÐÇ£» µ±ÄãµÄÐÇÐÇÕÊ»§´ïµ½$ 8,000£¬Äã¾ÍµÃµ½ÁËÎå¿ÅÐÇ£» µ±ÄãµÄÐÇÐÇÕÊ»§´ïµ½$ 10,000£¬Äã¾Í×öÂúÁù¿ÅÐÇ£¡£¡Õâʱºò£¬Äã¾Í¿ÉÒÔ°ÑÄãÐÇÐÇÕÊ»§µÄÈ«²¿1ÍòÃÀ½ð֧ȡ³öÀ´£¡ È»ºó×Ô¶¯ÔÙÆðÒ»ÂÖ£¬ÖØÐÂÀ´¹ý£¡ ¼ÌÐøÄãµÄ׬½ðÖ®Âã¡£¡£¡ £¨ÒòΪÄãµÄÏÖ½ðÕÊ»§Ã¿Ô³¬¹ý20ÃÀ½ðµÄ²¿·ÖÄã¿ÉÒÔËæʱ֧ȡ£¬ËùÒÔËãÏÂÀ´£¬ÄãµÄÿÂÖµÄÊÕÒæʵ¼ÊÊÇ20£¬000ÃÀ½ð Ŷ£¡£¡£¡ ÔçÒ»¿ÌÐж¯£¬ÔçÒ»¿Ì´ïµ½6¿ÅÐÇ£¡ Òª³ÃÔçŶ£¡£¡£© ÒѾ­ÐĶ¯ÁË°É£¬½øÒ»²½Ï¸½Ú£¬»¹ÊÇ×Ô¼º¿ìÈ¥¿´¿´°¡£¡£¡ http://sixgoldenstars.com/servlet/SGS?sponsor=ccy00 2¡¢http://www.iwantprofit.ca/?refid=ccy00 ÐÅÓþºÜºÃµÄÀ­ÏÂÏß׬ǮÍøÕ¾¡£Ã¿½éÉÜÒ»È˵Ã0.1$£¬Ö§³Ö7¼¶ÏÂÏß¡£ ÕÒµ½¼¸¸öÀ÷º¦µÄÏÂÏ߾ͿÉÒÔÌÉ×ÅÊÕÇ®À²~£¡£»b ---------------------- ¶þ¡¢µã»÷¡¢×¢²á¡¢Óʼþ׬ǮÀà 1¡¢http://www.ozloop.com/pages/index.php?refid=ccy00 пªÕÅ°Ä´óÀûÑǹ«Ë¾£¬Ò»¼¶ÏÂÏßÌá³É50%£¬ÖµµÃÒ»ÊÔ¡£ 20ÃÀ½ðÆ𸶣¬Ö§³ÖE -GOLD£¬PAYPAL£¬Ö§Æ±£¬Ã¿ÔÂÖ§¸¶£¬7²ãÏÂÏߣºµÚÒ»²ã-£º50%£¬µÚ¶þ²ã £º 25%£¬µÚÈý ²ã£º12. 5 %£¬µÚËIJ㣺6.25%£¬µÚÎå²ã£º3.15%£¬µÚÁù²ã£º1.56%£¬µÚÆ߲㣺0 .78%£¬Ã¿ÍƼöÒ»¸öÏÂÏß»áµÃµ½1ÃÀ ½ð£¬ÕâÑù£¬ÔÙÓÐ15¸öÏÂÏß¾ÍÄܸ¶¿îÁË¡£×¢²áºÜ¼òµ¥¡£ ÀÏÅÆÐÅÓþ¹«Ë¾penniesbyemailÕýÔÚÇ¿ÁÒÍƼöÕâ¼Ò¹«Ë¾£¬ÎÒ4ÔÂ6ÈÕ×¢²áʱÊǵÚ1240¸ö»áÔ±£¬Çë´ó¼Ò¾¡¿ì¶¯ ÊÖ¡£ Ç°¼¸Ìì×¢²áµÄÈËÌ«¶à£¬Ò»Ö±ºÜÄѵǽ£¬½ñÌì¿ÉÒԵǽÁË£¬¿ìÓ´~~~ £¨²»¶®Ó¢ÎĵĿÉÒÔÓÿì ÒëÈí¼þµÄ£¬ºÜ¼òµ¥Ó´£© ×¢²á˵Ã÷ £º http://www.ozloop.com/pages/index.php?refid=ccy00 °ÑÕâ¸öÁ´½Ó¸´Ó¡µ½µØÖ·À¸ ºó°´»Ø³µ£¬½ÓºóÇëÔÚ×ó ±ß°´ signup ¿ªÊ¼×¢²á,»áµ¯³öÒ»¸ö×¢²á´°¿Ú£¬ÊäÈëÄãµÄÐÅÏä--µãcontinu e £¨¼ÌÐø£©.Óò»Á˶à¾Ã¾Í»áÔÚÄãÐÅ ÏäÀïÊÕµ½Ò»·â¸æËßÄã·¾¶µÄ»ØÐÅ£¬µã»÷ÉϱߵÄÍøÖ·¼ÌÐø×¢²á£» ÒÔÏÂÊÇ×¢²áÐÅÏ¢Ïê½â Username ---------- ÊäÈëÄãµÄÓû§Ãû E-mail ------------ £¨²»ÓÃÊäÁË£¬ÒÑÓУ¬¾ÍÊÇÄã¸ÕÌîµÄÄǸö£© First Name -------- ÊäÈëÄãµÄÐÕ Last name --------- ÊäÈëÄãµÄÃû Address ------------ÊäÈëÄãµÄ¼ÒÍ¥µØÖ· City -------------- ÊäÈëÄãµÄËùÔÚ³ÇÊÐ State -------ÊäÈëÄãµÄËùÔÚÊ¡·Ý Post code ---------- ÊäÈëÄãµÄÓʱà Country ------------ÊäÈëÄãµÄ¹ú¼Ò£¬( china) Referred by --------ÊäÈ룺ccy00 (½éÉÜÈË£© Interests* (choose at least 2) ---- Ñ¡ÔñÄãµÄ°®ºÃ(ÖÁÉÙ2Ïî) > Paymentmethod ---------------------Ñ¡ÄãµÄ¸¶¿î·½Ê½ Payment account ID: -------------ÌîÄãµÄ×îС֧¸¶¶î£¬ÊäÈë20.00 ¾ÍÐÐ Password -----------ÊäÈëÄãµÄÃÜÂë Verify password ----Öظ´Ò»´ÎÃÜÂë Ö®ºóµã signup ¾ÍÐÐÁË£¡ ¹þ¡­¡­ÔÚÎÒдÕâƪ˵Ã÷ʱÓÖÓкöàÈ˼ÓÈë Ó´£¡£¡¿ìÓ´£¬Ôç¼ÓÈëϵͳҲÐí»á×Ô¶¯°ïÄãÕÒÏÂÏßÓ´ ×¢Ò⣺Äã×¢²áºóÓ¦°ÑÉÏÃæµÄÐû´«²ÄÁϸ´ÖƽøÐÐÐû´«£¨ÄãÒª°ÑÉÏÃæÍøÖ·µÄµÈºÅºóÃæµÄccy00»»³ÉÄãµÄÓû§Ãû£¬½éÉÜ ÈËÒ²»¹³ÉÄãµÄÓû§Ãû¡££© 2¡¢http://www.noeys-place-pays.com/pages/index.php?refid=ccy00 3¡¢http://www.lightspeed-cash-ad.com/pages/index.php?refid=adidas ÿÌìÓкܶàÐÅ£¬Õ¾ÄÚµã»÷¶à£¬×¢²á¶à£¬ÐÅÓþÒ»Á÷¡«¡«£¡æ¢Ãù«Ë¾¡£×¢²á·½·¨Í¬ÉÏ¡£ 4¡¢http://www.paid-email-from-the-great-white-north.com/pages/index.php?refid=ccy00 ×¢²á½±Àø1µ¶ 3µ¶¸¶¿î 5 Referral Levels 20%,10%,5%,2%,1% ÿÌìµÄµã»÷ºÍÐÅ»¹ºÜ¶à ×¢²áµÄʱºòÒªÌîÍƼöÈË,Â鷳дÉÏccy00 лл 5¡¢http://www.ProfitFromEmail.com/pages/index.php?refid=ccy00 6¡¢http://www.tnt-e-mail.com/pages/index.php?refid=ccy00 Õâ2¼Ò¶¼ÊÇÐÅÓþºÜºÃµÄ¹«Ë¾¡£2$Æ𸶣¬1¼¶ÏÂÏßÌá³É50%£¡£¡¶àÀ­¼¸¸öÇÚÀ͵ÄÏÂÏß²»ÓÃ×Ô¼º¶¯Ê־ͿÉÒÔÄÃÇ® ¿©£¡£¡£»b 7¡¢paidemailbizÊÇÒ»¼Òй«Ë¾£¬Óʼþ¼Óµã»÷£¬3$Ö§¸¶pp/eg£¬Ã¿¸öÓʼþ/µã»÷²»µÍÓÚ0.01$ http://paidemailbiz.com/cgi-bin/isl/in.cgi?ccy00 8¡¢Ä¿Ç°³ÉǧÉÏÍò¼ÒÓʼþ"¹«Ë¾"ÖÐÕæÕýµÄ¹É·ÝÖƹ«Ë¾!15$¸¶¿î,¾Ý˵ּÔÚ³¬¹ýoptϵÁС£µÇ¼ºó,ÔÚÄãÕÊ»§×ó ±ßµÄcurrent active linkÖÐ,ÊÇÓÐЧµã»÷,Á´½ÓµÄ×îºóÓдËÁ´½ÓµÄ¼ÛÖµ¼°Ê£ÓàÊý,Èç1000 @ .6 cents,Ç°ÃæµÄ 1000ΪʣÓàµÄÓÐЧµã»÷,ºóÃæΪÁ´½ÓµÄ¼ÛÖµ http://www.clickaddicts.com/pages.pl?ref=ccy00 9¡¢Íæ·¨ºÍoptϵÁÐÒ»ÑùµÄºÃ¹«Ë¾,ûÓÐ×îµÍ¸¶¿î,ÕâÔµÄÇ°½áËãµ½ÏÂÔ¸¶¿î,Ö§³Öe-gold,ÿ¸öÁ´½Ó1ÃÀ·Ö http://www.getpaid2click.com/joinnow.php?r=3483 10¡¢http://www.askmikysmail.com/pages/index.php?refid=ccy00 ¹ã¸æÁ¬½ÓºÜ¶à 11¡¢http://www.paidmailbox.com/pages/index.php?refid=ccy00 12¡¢http://www.WhatCash.com/pages/index.php?refid=ccy00 13¡¢http://www.mailingcash.com/pages/index.php?refid=ccy00 14¡¢http://www.rw-bucks.com/pages/index.php?refid=ccy00 15¡¢http://www.trinitys-treasure.com/pages/index.php?refid=ccy00 16¡¢http://www.paid2clicknsurf.us/pages/index.php?refid=ccy00 ×¢²á¾ÍËÍ5$ Õ⼸¼ÒµÄ×¢²á·½·¨ºÍ׬ǮÖÖÀàºÍÇ°ÃæµÄ¼¸¼Ò²î²»¶à£¬Ò»ÇÐ×ö°É£¡Ã¿¼ÒÒ»Ìì¿ÉÒÔ׬0.1-0.2ÃÀ½ð£¬10¼¸¼Ò¼ÓÆð À´¾ÍÊÇ2¡¢3¿éÄØ£¡¿É²»ÊǸöСÊýÄ¿£¡£º£© 17¡¢http://www.Paid2link.com/index.php?ref=358 Õâ¼ÒºÍÇ°10¼¸¼ÒÓÐÒ»µã²»Í¬£¬Ëü²»Êǵã»÷ͼ±ê£¬¶øÊÇÎÄ×ÖÁ¬½Ó¡£ÊµÐĵÄÊǸ¶·ÑµÄ£¬¿ÕÐĵÄûǮÄõģ¡£º£© --------------------------- Èý¡¢³åÀ˹«Ë¾ 1¡¢http://www.HybridTraffic.com/index.php?referrer=ccy00 ×¢²á·½Ê½ºÍÉÏÃæ½éÉܵĹ«Ë¾²î²»¶à¡£ ×¢²á³É¹¦ÒÔºóµÇ½£¬»á¿´µ½2¸öÁ¬½Ó£¬ÆäÖÐÒ»¸ö´øÓÐÄãÓû§ÃûµÄ¿ÉÒÔÓÃËüÀ´·¢Õ¹ÏÂÏߣ¬ÁíÍâÒ»¸ö´øÊý×ÖµÄÁ¬ ½Ó¾ÍÊÇ׬ǮÓõģ¡ µãÕâ¸öÁ¬½Ó£¬³öÏÖµÄÐÂÒ³ÃæµÄÕýÉÏ·½»á³öÏÖ4¸öÊý×Ö¡£Êý×ÖÉÏ·½ÓÐ chick * µÄ×ÖÑù¡£Èç¹ûÊÇchick 4£¬¾Íµã ÏÂÃæµÄ4£¬Èç¹ûÒ³Ãæ×Ô¶¯Ë¢Ð£¬³öÏÖ20ÃëµÄµ¹¼Æʱ£¬¼ÆʱÍê³ÉºóÖظ´ÉÏÃæµÄ²½Öè¡£ ÿµã»÷Ò»´Î1µã£¬100µã0.01$¡£Èç¹ûÄúÉÏÍøʱ¼äºÜ³¤£¬Ò»Ìì׬1¡¢2ëǮûÎÊÌâµÄ£¡Ç°ÌáÊÇ£¬ÓÐ×ã¹»µÄÄÍÐÄ£¡ Ö»ÒªÄúÈÏÕæ×ö£¬³ÖÖ®ÒԺ㣬һ¶¨»áÓв»Ð¡µÄ»Ø±¨µÄ£¡ÓÐʲô²»¶®µÄ¿ÉÒÔÎÊÎÒ¡£ÁªÏµQQ:52404916 »¶Ó­·ÃÎÊÎҵĶÌÐŵ꣺http://ccy00.shop.18dx.com ¸ü¶àÁåÉù¡¢Í¼Æ¬µÈ×ÅÄ㣡 ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Ö Àñ! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ vivienne ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ guanfeng324@eyou.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ 2003-05-06 From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 06:09:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13314 for ; Tue, 6 May 2003 06:09:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46ABGR29815 for ; Tue, 6 May 2003 06:11:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46ABCv02331 for ; Tue, 6 May 2003 06:11:13 -0400 (EDT) Date: Tue, 6 May 2003 12:08:53 +0200 Message-Id: Subject: =?iso-8859-1?Q?Help!!!?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?dariobalmas@libero.it?=" To: "=?iso-8859-1?Q?ppvpn?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 163.162.41.4 X-SMTP-HELO: smtp0.libero.it X-SMTP-MAIL-FROM: dariobalmas@libero.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp0.libero.it [193.70.192.33] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA13314 The automatic way to unsubscribe myself doesn't work! Does anyone unsubscribe me manually? Dario Balmas From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 08:07:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16448 for ; Tue, 6 May 2003 08:07:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46BnaR15727 for ; Tue, 6 May 2003 07:49:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46BnWB13642 for ; Tue, 6 May 2003 07:49:32 -0400 (EDT) Message-Id: <200305061141.HAA15311@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-vpn-vr-04.txt Date: Tue, 06 May 2003 07:41:36 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Network based IP VPN Architecture using Virtual Routers Author(s) : H. Ould-Brahim et al. Filename : draft-ietf-ppvpn-vpn-vr-04.txt Pages : 19 Date : 2003-5-5 This draft describes a network-based VPN architecture using virtual routers. The VPN service is built based on the virtual router (VR) concept, which has exactly the same mechanisms as a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Within a VPN domain, an instance of routing is used to distribute VPN reachability information among VR routers. Any routing protocol can be used, and no VPN-related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Virtual routers can be deployed in different VPN configurations, direct VR to VR connectivity through layer-2 or by aggregating multiple VRs into a single VR combined with IP or MPLS based tunnels. This architecture accommodates various backbone deployment scenarios, both where the VPN service provider owns the backbone, and where the VPN service provider obtains backbone service from one or more other service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpn-vr-04.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-ietf-ppvpn-vpn-vr-04.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-ietf-ppvpn-vpn-vr-04.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-5-5151132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-vpn-vr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-vpn-vr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5151132.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 08:49:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18944 for ; Tue, 6 May 2003 08:49:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46CpaR01053 for ; Tue, 6 May 2003 08:51:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46CpW616551 for ; Tue, 6 May 2003 08:51:32 -0400 (EDT) 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: Strategy for VPN work in IETF Date: Tue, 6 May 2003 08:48:45 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB7202152603@WHISTLER.WaveSmithNet.com> Thread-Topic: Strategy for VPN work in IETF Thread-Index: AcMTp1gL47fMZ6sQSOaIOh7rKPqajQAI/+xw From: "Himanshu Shah" To: "Alex Zinin" Cc: X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18944 Alex, I support formation of two working groups; L3VPN and L2VPN. There are enough non-overlapping issues to warrant such split. Albeit, this should have been done a long time ago, but better late than never. We also need better understanding of how overlapping issues would be handled between the two working groups. Himanshu Shah Wavesmith networks From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 09:27:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20511 for ; Tue, 6 May 2003 09:27:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46DOER19136 for ; Tue, 6 May 2003 09:24:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46DO8d26563 for ; Tue, 6 May 2003 09:24:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313D2.15460B5A" Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 09:19:11 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB7202152604@WHISTLER.WaveSmithNet.com> Thread-Topic: Single vs many solution(s) Thread-Index: AcMTfxu02uWzqlqKRJmkfP/SLSiQPQAUBnSg From: "Himanshu Shah" To: "Vasile Radoaca" , "Alex Zinin" , Cc: "Yakov Rekhter" X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C313D2.15460B5A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for=20 two solutions to the same problem. =20 A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been=20 discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based=20 signaling for L2VPN) is that my previous company could not find any = customer=20 demand for BGP-based solution (we did not look into Italy though :-)=20 However, there was greater interest in LDP based solution and public forums to test interoperability with.=20 =20 I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. =20 /himanshu Wavesmith Networks =20 =20 =20 -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex,=20 I think the ideal goal is to have only one solution, but such ideal = usual can be achieved if we are working in a pure theoretical = environment, without market considerations. In reality the market is = driving in most of the cases, and some assumptions made two years ago = are not any more valid - there are categories of SPs that pretty much = have disappeared from the map. You stated very clear that a problem space needs to have a single = solution. I fully agree with you as a goal, but ut the issue that we = face right now is that the problem space is not well concluded and well = understood just purely from technical considerations.=20 The L2 VPLS is a complex space with multiple dimensions, and the = vendors - in the last two years - have worked from different angles, = optimizing one or more dimension(s) of the problem space (probable the = downturn in the market it self, was part of the problem). Without to = contradict each other, most of the solutions are closed in a specific = dimension, based on some objective/subjective parameters or experience = and some criteria of optimization. Moving in only one dimension doesn't = scale it self. The fact we do have more than one solution, I think is a good thing, = and doesn't contradict that we can't move toward one solution, if we are = driving diligently, and willing to make compromises. Taken such research = value in consideration, would be a positive sign that IETF is looking to = create a solution that would be valid for a while. Reading the mailing = list, I observed the same wise advise from most of the SPs, and this = reflect not a "problem" but a reality. Cheers=20 Vasile=20 =20 -----Original Message-----=20 From: Alex Zinin [ mailto:zinin@psg.com]=20 Sent: Monday, May 05, 2003 5:27 PM=20 To: PPVPN@nortelnetworks.com=20 Cc: Yakov Rekhter=20 Subject: Single vs many solution(s)=20 Yakov,=20 [I took the liberty to change the subject line]=20 >> I believe the goal for the WG should be to work out=20 >> a single solution.=20 > That is certainly not in the charter. In fact the goal=20 > you stated above directly contradicts what is in the charter:=20 > Multiple approaches are being developed as each approach=20 > has particular characteristics and differing scope of=20 > applicability.=20 Thanks for pointing out a possible contradiction. I don't think it = exists.=20 My opinion (and I think it would be safe for me to say it is consistent = with that of the IESG) is that as long as different solutions are = solving different problems (or, as the text of the charter says, have = different scopes of applicability), it is fine to have more than one = solution. However, for a single problem, we only need a single STD'ized = solution. > And if you believe that for VPLS the goal should be a single solution, = > then why wouldn't you insist to have the same goal for L3 VPNs ?=20 you forgot to add "and if you wouldn't insist on a single solution for = L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or = revisit the decisions that have been made in the past, while I still see = a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that=20 > imply a single auto-discovery mechanism for VPLS ?=20 This would definitely be my preference.=20 Alex=20 ------_=_NextPart_001_01C313D2.15460B5A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Single vs many solution(s)
I=20 believe that there can exist multiple solutions for different=20 sets
of=20 problems. However, one must not confuse the solution = with
signaling. We oughta not have two signaling mechanisms for=20
two=20 solutions to the same problem.
 
A=20 while back, it was determined that PW setup signaling is = not
the=20 charter of PPVPN but of PWE3. Lately, we have been
discussing again whether BGP based signaling is better than=20 LDP
based=20 signaling. We have got to get past this issue once and = for
all.=20 My personal experience (having implemented BGP based =
signaling for L2VPN) is that my previous = company could not find=20 any customer
demand=20 for BGP-based solution (we did not look into Italy = though :-)=20
However, there was greater interest in LDP based solution=20 and
public=20 forums to test interoperability with. 
 
I=20 think we have learned enough lessons from CR-LDP vs = RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
/himanshu
Wavesmith Networks
 

 
 
 -----Original=20 Message-----
From: Vasile Radoaca=20 [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, 2003 = 11:21=20 PM
To: 'Alex Zinin'; PPVPN@nortelnetworks.com
Cc: = Yakov=20 Rekhter
Subject: RE: Single vs many=20 solution(s)

Alex,

  I think the ideal goal is to have only one = solution,=20 but such ideal usual can be achieved if we are working in a pure = theoretical=20 environment, without market considerations. In reality the market is = driving=20 in most of the cases, and some assumptions made two years ago are not = any more=20 valid - there are categories of SPs that pretty much have disappeared = from the=20 map.

  You stated very clear that a problem space = needs to=20 have a single solution. I fully agree with you as a goal, but ut the = issue=20 that we face right now is that the problem space is not well concluded = and=20 well understood just purely from technical considerations.

 The L2 VPLS is a complex space with multiple = dimensions,=20 and the vendors - in the last two years -  have worked from = different=20 angles, optimizing one or more dimension(s) of the problem space = (probable the=20 downturn in the market it self, was part of the problem). Without to=20 contradict each other, most of the solutions are closed in a specific=20 dimension, based on some objective/subjective parameters or experience = and=20 some criteria of optimization. Moving in only one dimension doesn't = scale it=20 self.


 The fact we do have = more than=20 one solution, I think is a good thing, and doesn't contradict that we = can't=20 move toward one solution, if we are driving diligently, and willing to = make=20 compromises. Taken such research value in consideration, would be a = positive=20 sign that IETF is looking to create a solution that would be valid for = a=20 while. Reading the mailing list, I observed the same wise advise from = most of=20 the SPs, and this reflect not a "problem" but a = reality.


Cheers
   = Vasile=20
 
-----Original=20 Message-----
From: Alex Zinin [mailto:zinin@psg.com] =
Sent: Monday, May 05, 2003 5:27 PM
To:=20 PPVPN@nortelnetworks.com
Cc: Yakov = Rekhter=20
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject = line]

>> I believe the goal for the WG should be to = work=20 out
>> a single solution.

> That is certainly not in the charter. In fact = the=20 goal
> you stated above directly = contradicts what=20 is in the charter:

>    Multiple approaches are being = developed=20 as each approach
>    has = particular=20 characteristics and differing scope of
>=20 applicability.

Thanks for pointing out a possible contradiction. I = don't=20 think it exists.

My opinion (and I think it would be safe for me to = say it is=20 consistent with that of the IESG) is that as long as different = solutions are=20 solving different problems (or, as the text of the charter says, have=20 different scopes of applicability), it is fine to have more than one = solution.=20 However, for a single problem, we only need a single STD'ized=20 solution.

> And if you believe that for VPLS the goal = should be a=20 single solution,
> then why wouldn't you = insist to=20 have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a = single=20 solution for L3 VPNs, then why do you insist on this for L2 VPNs"=20 ;-)

The reason is I don't want to restart the L3 VPN = work in the=20 IETF and/or revisit the decisions that have been made in the past, = while I=20 still see a reasonable opportunity to steer the L2 VPN = work.

> Also, if you insist on a single solution, = wouldn't=20 that
> imply a single auto-discovery = mechanism for=20 VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C313D2.15460B5A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 10:06:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22407 for ; Tue, 6 May 2003 10:06:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46E8wR13256 for ; Tue, 6 May 2003 10:08:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46E8qB03034 for ; Tue, 6 May 2003 10:08:52 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6BC3@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Himanshu Shah'" , Alex Zinin , PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 10:05:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313D8.89BBB630" X-LYRIS-Message-Id: 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_01C313D8.89BBB630 Content-Type: text/plain Himanshu, Alex BGP signaling is a different story - I do belive that underline principle is to evaluate if we can decouple signaling from the vertical VPLS solution. We do the same with Auto-discovery. Eric did a good analysis of the problem, but I don't believe that was very forceful in rejecting BGP signaling for Any to ANy model. I am looking to have another stage of discussion without rejecting the current proposals. The problem is that we do not exactly how the VPLS as service will evolve in the future - also the SPs they do not exactly how this service would be use. It would complement the IP VPN, it would be an alternative of the IP VPN, or it would be a commodity [like LAN/VLAN are today in the Enterprise space]. Your e-mail also reflects different vendors experience, which is worth by it self to be evaluated. CHeers Vasile -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Tuesday, May 06, 2003 9:19 AM To: Radoaca, Vasile [BL60:X624:EXCH]; Alex Zinin; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for two solutions to the same problem. A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based signaling for L2VPN) is that my previous company could not find any customer demand for BGP-based solution (we did not look into Italy though :-) However, there was greater interest in LDP based solution and public forums to test interoperability with. I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. /himanshu Wavesmith Networks -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com ] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------_=_NextPart_001_01C313D8.89BBB630 Content-Type: text/html Message
         Himanshu, Alex
 
           BGP signaling is a different story - I do belive that underline principle is to evaluate
           if we can decouple signaling from the vertical VPLS solution.  We do the same with
           Auto-discovery. Eric did a good analysis of the problem, but I don't believe that was very forceful
           in rejecting BGP signaling for Any to ANy model. I am looking to have another stage of discussion
           without rejecting the current proposals.
 
           The problem is that we do not exactly how the VPLS as  service will evolve in the future - also the SPs
           they do not exactly how this service would be use. It would complement the IP VPN, it would be an
           alternative of the IP VPN, or it would be a commodity [like LAN/VLAN are today in the Enterprise space].
 
           Your e-mail also reflects different  vendors experience, which is worth by it self to be evaluated.
 
         CHeers
              Vasile
        
-----Original Message-----
From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com]
Sent: Tuesday, May 06, 2003 9:19 AM
To: Radoaca, Vasile [BL60:X624:EXCH]; Alex Zinin; PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

I believe that there can exist multiple solutions for different sets
of problems. However, one must not confuse the solution with
signaling. We oughta not have two signaling mechanisms for
two solutions to the same problem.
 
A while back, it was determined that PW setup signaling is not
the charter of PPVPN but of PWE3. Lately, we have been
discussing again whether BGP based signaling is better than LDP
based signaling. We have got to get past this issue once and for
all. My personal experience (having implemented BGP based
signaling for L2VPN) is that my previous company could not find any customer
demand for BGP-based solution (we did not look into Italy though :-)
However, there was greater interest in LDP based solution and
public forums to test interoperability with. 
 
I think we have learned enough lessons from CR-LDP vs RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
/himanshu
Wavesmith Networks
 

 
 
 -----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, 2003 11:21 PM
To: 'Alex Zinin'; PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

Alex,

  I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map.

  You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations.

 The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years -  have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self.


 The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality.


Cheers
   Vasile
 
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, May 05, 2003 5:27 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject line]

>> I believe the goal for the WG should be to work out
>> a single solution.

> That is certainly not in the charter. In fact the goal
> you stated above directly contradicts what is in the charter:

>    Multiple approaches are being developed as each approach
>    has particular characteristics and differing scope of
> applicability.

Thanks for pointing out a possible contradiction. I don't think it exists.

My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution.

> And if you believe that for VPLS the goal should be a single solution,
> then why wouldn't you insist to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work.

> Also, if you insist on a single solution, wouldn't that
> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C313D8.89BBB630-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 10:37:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24548 for ; Tue, 6 May 2003 10:37:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46EdfR21928 for ; Tue, 6 May 2003 10:39:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Edat21614 for ; Tue, 6 May 2003 10:39:36 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6064E0313@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Alex Zinin'" Cc: "'PPVPN@nortelnetworks.com'" Subject: RE: Strategy for VPN work in IETF Date: Tue, 6 May 2003 10:36:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313DC.F33A6D32" X-LYRIS-Message-Id: 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_01C313DC.F33A6D32 Content-Type: text/plain Alex, Bilel, > 1. Changes will induce additional delays > I should have communicated this better, I think. The fact that > we're talking about two separate WGs does NOT mean that work within > PPVPN is stopped. As my message said, the new WGs would be > announced at the same time as the current one would be closed. > Until then, the only discussion happening on the new WG's mailing > lists would be about the charter and the PPVPN would conduct > business as usual. We're closely coordinating with Marco and Rick, > so all decisions taken within PPVPN will be effective in the new > WGs. bnj>> Are you implying that the current WG chairs agreed to the split? bnj>> Or are they also being "informed" of a decision? I imply what I say, and I don't appreciate people putting words in my mouth. BNJ> no one is doing that - it's a question for clarification. Regarding your question, we did have a number of conversations with the chairs before I sent the message to this list. If you would like to know Marco's or Rick's opinion on this subject, my recommendation would be to send them an e-mail and ask. BNJ> it would be good if you clarify your statement instead of pointing me to the chairs. > Hope this helps. bnj>> not really - it looks like a solution was cooked up behind closed bnj>> door > to an inexistent / unexplained problem - this goes counter to the open > and transparent process the IETF prides itself of! You are misrepresenting the situation here. BNJ> I am calling the situation as I see it unfold. Others have made the same remarks on the list. It is perfectly reasonable for ADs to form an opinion by talking to IETF participants and WG chairs not using the microphone in the room and by exchanging e-mails not using a public mailing list. It is also reasonable for them to analyze the situation and bring a proposed solution to the community. Regarding openness of the process, you probably noticed that we're discussing the proposed plan in the open. Based on the feedback received, the involved ADs will decide whether it needs to be changed or not. BNJ> this is a much different position than what was implied by your original message. The theme/tone of your initial email was one of informing the WG of a decision that has already been taken - You are now saying you are soliciting input to make an informed decision. That's different. Alex BNJ> Bilel. ------_=_NextPart_001_01C313DC.F33A6D32 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strategy for VPN work in IETF

Alex,



Bilel,

> 1. Changes will induce additional delays

>    I should have communicated = this better, I think. The fact that
>    we're talking about two = separate WGs does NOT mean that work within
>    PPVPN is stopped. As my = message said, the new WGs would be
>    announced at the same time as = the current one would be closed.
>    Until then, the only = discussion happening on the new WG's mailing
>    lists would be about the = charter and the PPVPN would conduct
>    business as usual. We're = closely coordinating with Marco and Rick,
>    so all decisions taken within = PPVPN will be effective in the new
>    WGs.

bnj>> Are you implying that the current WG = chairs agreed to the split?
bnj>> Or are they also being = "informed" of a decision?

I imply what I say, and I don't appreciate people = putting words in my mouth.

BNJ> no one is doing that - it's a question for = clarification.

Regarding your question, we did have a number of = conversations with the chairs before I sent the message to this list. = If you would like to know Marco's or Rick's opinion on this subject, my = recommendation would be to send them an e-mail and ask.

BNJ> it would be good if you clarify your = statement instead of pointing me to the chairs.

> Hope this helps.

bnj>> not really - it looks like a solution was = cooked up behind closed
bnj>> door
> to an inexistent / unexplained problem - this = goes counter to the open
> and transparent process the IETF prides itself = of!

You are misrepresenting the situation here.

BNJ> I am calling the situation as I see it = unfold. Others have made the same remarks on the list.

It is perfectly reasonable for ADs to form an opinion = by talking to IETF participants and WG chairs not using the microphone = in the room and by exchanging e-mails not using a public mailing = list.

It is also reasonable for them to analyze the = situation and bring a proposed solution to the community.

Regarding openness of the process, you probably = noticed that we're discussing the proposed plan in the open. Based on = the feedback received, the involved ADs will decide whether it needs to = be changed or not.

BNJ> this is a much different position than what = was implied by your original message. The theme/tone of your initial = email was one of informing the WG of a decision that has already been = taken - You are now saying you are soliciting input to make an informed = decision. That's different.

Alex

BNJ> Bilel.

------_=_NextPart_001_01C313DC.F33A6D32-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 10:44:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24768 for ; Tue, 6 May 2003 10:44:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46EkWR26567 for ; Tue, 6 May 2003 10:46:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46EkPx00152 for ; Tue, 6 May 2003 10:46:26 -0400 (EDT) Message-Id: <200305061442.KAA23011@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Alex Zinin cc: George Swallow , PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , =?ISO-8859-15?B?UGV0ZXJzb24sDQogICAgSm9u?= , Allison Mankin , swallow@cisco.com Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-reply-to: Your message of "Mon, 05 May 2003 14:38:40 PDT." <10170473728.20030505143840@psg.com> Date: Tue, 06 May 2003 10:42:03 -0400 From: George Swallow X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: swallow@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Alex - > Interesting that you mention this... I actually believe that if a WG > consistently needs more than one meeting slot, it is a good sign of > it having more on its plate than can efficiently deal with or poor > management of the meeting time. I thought the IESG was concerned about the overall number of Workgroups. They are much easier to create than to shut down. So if meeting twice per IETF for a short while until the work settles down lets you have one less, seems like a good idea. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 10:58:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25128 for ; Tue, 6 May 2003 10:57:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46F0NR10251 for ; Tue, 6 May 2003 11:00:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46F0IW18910 for ; Tue, 6 May 2003 11:00:18 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: hshah@wavesmithnetworks.com, "Vasile Radoaca" , zinin@psg.com, PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 15:27:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313DB.9AA86A80" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: 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_01C313DB.9AA86A80 Content-Type: text/plain; charset="iso-8859-1" Himanshu, I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for two solutions to the same problem. [RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based signaling for L2VPN) is that my previous company could not find any customer demand for BGP-based solution (we did not look into Italy though :-) However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly): Draft Vendor Support SP Support BGP 4 19 LDP 7 3 These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.] I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. ...Richard -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com ] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------_=_NextPart_001_01C313DB.9AA86A80 Content-Type: text/html; charset="iso-8859-1" RE: Single vs many solution(s)
Himanshu,
 
 
I believe that there can exist multiple solutions for different sets
of problems. However, one must not confuse the solution with
signaling. We oughta not have two signaling mechanisms for
two solutions to the same problem.
 
[RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] 
 
A while back, it was determined that PW setup signaling is not
the charter of PPVPN but of PWE3. Lately, we have been
discussing again whether BGP based signaling is better than LDP
based signaling. We have got to get past this issue once and for
all. My personal experience (having implemented BGP based
signaling for L2VPN) is that my previous company could not find any customer
demand for BGP-based solution (we did not look into Italy though :-)
However, there was greater interest in LDP based solution and
public forums to test interoperability with.
[RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly):
 
Draft     Vendor Support    SP Support
BGP              4                      19
LDP               7                       3
 
These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.]
 
I think we have learned enough lessons from CR-LDP vs RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
...Richard 
 

 
 
 -----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, 2003 11:21 PM
To: 'Alex Zinin'; PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

Alex,

  I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map.

  You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations.

 The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years -  have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self.


 The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality.


Cheers
   Vasile
 
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, May 05, 2003 5:27 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject line]

>> I believe the goal for the WG should be to work out
>> a single solution.

> That is certainly not in the charter. In fact the goal
> you stated above directly contradicts what is in the charter:

>    Multiple approaches are being developed as each approach
>    has particular characteristics and differing scope of
> applicability.

Thanks for pointing out a possible contradiction. I don't think it exists.

My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution.

> And if you believe that for VPLS the goal should be a single solution,
> then why wouldn't you insist to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work.

> Also, if you insist on a single solution, wouldn't that
> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C313DB.9AA86A80-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 11:07:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25412 for ; Tue, 6 May 2003 11:07:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46FALR01179 for ; Tue, 6 May 2003 11:10:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46FAGW17345 for ; Tue, 6 May 2003 11:10:16 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6BC4@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Alex Zinin'" , PPVPN@nortelnetworks.com Cc: richard.spencer@bt.com, yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 11:02:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313E0.81D2C302" X-LYRIS-Message-Id: 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_01C313E0.81D2C302 Content-Type: text/plain Alex, In addition of intra-domain/inter-domain issues, the VPLS problem space add also specific issues: 1. A large variety of access type networks: LAN/VLAN, Q-in-Q, PWs, MinM 2. A variety of CPE devices: L2, L3 devices 3. A significant customer mac accumulation [oversubscription factor is a key component of the VPLS Etehrnet service value], without any proper model to poof that would not impact the performance, security or stability of the VPLS core mainly when it would work in paralel with other services like IP VPN 4. Legacy inter-working 5. Different deployment scenarios - A VPLS solution maps on different network topologies: a) it is possibile to start from the core and to extend to the access, by employing simple access configurations - simple P2P or VLAN based. b) it is possible to start from the access and build VPLS without any MPLS core. Later when the metro is growing an MPLS core can be employed to glu such access networks. c) overlapping with current IP VPN networks How we can deal with such issues, using your model below? Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Tuesday, May 06, 2003 2:12 AM To: PPVPN@nortelnetworks.com Cc: richard.spencer@bt.com; yakov@juniper.net Subject: Re: Single vs many solution(s) Richard, Thanks for your input, it is indeed very important for us to be on the same page here, and I happen to agree with most of what you said. I don't think that "solution" == "protocol", but rather a set of functional components, each addressing its particular problem. The framework would then put them all together. I also view as reasonable an approach where there is a difference between how intra-domain and inter-domain issues are solved. So, from this perspective, the framework MAY very easily look like this (mechanism == protocol or protocol extension): Data-plane : mechanism A Intra-domain discovery : mechanism B Intra-domain signaling : mechanism C Inter-domain discovery : mechanism D Inter-domain signaling : mechanism C++ Of course there must be some architectural glue that brings all the pieces together. What I would like us to avoid is solution space exploration, where we have many mechanisms for the same function we need, i.e, I would be disappointed to see us end up with a framework looking like: Data-plane : mechanism A, or B, or C Intra-domain discovery : mechanism D, or E, or F Intra-domain signaling : mechanism G, or H, or I Inter-domain discovery : mechanism J, or K, or L Inter-domain signaling : mechanism M, or N, or O This would, in view, impact interoperability. We also seem to agree on the point I brought in my message to Mark: > Regarding the considerations you mention above, in my > opinion it would be wrong for us to start the discussion > by saying "SPs have X and Y deployed in their networks, > so we just have to decide whether we piggy-back on X or > on Y." Instead I'd like to see a discussion ala "What are > the functions we need? How can we best implement them? > Do we have an existing protocol that would be the right > fit for this functionality or do we need a new one(s)?" Yakov, regarding your question again-- > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? --to refine my answer, I would say, my preference would be for the WG to come up with a single solution consisting with at most two discovery mechanisms--one for intra-domain and one for inter-domain problem space. It is ok if the intra-domain only part comes first. -- Alex http://www.psg.com/~zinin/ Monday, May 5, 2003, 4:40:51 PM, richard.spencer@bt.com wrote: > Alex, > How is the word 'solution' to be interpreted in the sentence below? > "I believe the goal for the WG should be to work out a single > solution." > Does 'solution' = 'protocol'... i.e. LDP vs. BGP? If so then I do not > think working towards a single solution based on which protocol is > better for X or Y is the best way forward. I think the seemingly > never-ending debate on this subject proves this point. > If however the word solution was replaced with 'set of detailed > functional specifications' then maybe we can move away from the LDP > vs. BGP debate and concentrate on developing a set of functional > specifications created from the ground up. This is in contrast to some > of the existing 'solutions' which seem to me to have been developed > the wrong way round, i.e. we already use protocol X for service Z, > what changes do we need to make to protocol X in order for it to be > used for this new service Y. > If the functional specifications are well defined it should be clear > which protocols are most suited and there may be more than one. For > example, one protocol may be more suited for a specific function > intra-AS and another inter-AS. To use a simple analogy, OSPF is more > suited for intra-AS routing and BGP is more suited for inter-AS > routing, but they both perform the function 'routing'. > Some of the foundations for the functional specifications probably > already exist within the various requirement and solution drafts and > just need extracting. > The main advantages of separate functional specifications being (1) > that they can be developed independently without having any impact on > each other > (2) operators would be able to choose which protocol they wish to use to > perform a certain function based on their own specific requirements. > Richard > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: 05 May 2003 22:27 > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > Yakov, > [I took the liberty to change the subject line] >>> I believe the goal for the WG should be to work out >>> a single solution. >> That is certainly not in the charter. In fact the goal >> you stated above directly contradicts what is in the charter: >> Multiple approaches are being developed as each approach >> has particular characteristics and differing scope of >> applicability. > Thanks for pointing out a possible contradiction. I don't think it > exists. > My opinion (and I think it would be safe for me to say it is > consistent with that of the IESG) is that as long as different > solutions are solving different problems (or, as the text of the > charter says, have different scopes of applicability), it is fine to > have more than one solution. However, for a single problem, we only > need a single STD'ized solution. >> And if you believe that for VPLS the goal should be a single >> solution, then why wouldn't you insist to have the same goal for L3 >> VPNs ? > you forgot to add "and if you wouldn't insist on a single solution for > L3 VPNs, then why do you insist on this for L2 VPNs" ;-) > The reason is I don't want to restart the L3 VPN work in the IETF > and/or revisit the decisions that have been made in the past, while I > still see a reasonable opportunity to steer the L2 VPN work. >> Also, if you insist on a single solution, wouldn't that imply a >> single auto-discovery mechanism for VPLS ? > This would definitely be my preference. > Alex ------_=_NextPart_001_01C313E0.81D2C302 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Single vs many solution(s)

Alex,

 In addition of intra-domain/inter-domain = issues, the VPLS problem space add also specific issues:

1. A large variety of access type networks: LAN/VLAN, = Q-in-Q, PWs, MinM
2. A variety of CPE devices: L2, L3 devices
3. A significant customer mac accumulation = [oversubscription factor is a key component of the VPLS Etehrnet = service value], without any proper  model to poof that would not = impact the performance, security or stability of the VPLS core mainly = when it would work in paralel with other services like IP = VPN

4. Legacy inter-working
5. Different deployment scenarios - A VPLS solution = maps on different network topologies:
 a) it is possibile to start from the core and = to extend to the access, by employing simple access configurations - = simple P2P or VLAN based.

 b) it is possible to start from the access and = build VPLS without any MPLS core. Later when the metro is growing an = MPLS core can be employed to glu such access networks.

 c) overlapping with current IP VPN = networks
 
How we can deal with such issues, using your model = below?

Cheers
  Vasile

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Tuesday, May 06, 2003 2:12 AM
To: PPVPN@nortelnetworks.com
Cc: richard.spencer@bt.com; yakov@juniper.net
Subject: Re: Single vs many solution(s)


Richard,

 Thanks for your input, it is indeed very = important for us to be on  the same page here, and I happen to = agree with most of what you said.

 I don't think that "solution" =3D=3D = "protocol", but rather a set of  functional components, = each addressing its particular problem. The  framework would then = put them all together.

 I also view as reasonable an approach where = there is a difference  between how intra-domain and inter-domain = issues are solved.

 So, from this perspective, the framework MAY = very easily look  like this (mechanism =3D=3D protocol or protocol = extension):

  = Data-plane          &n= bsp;   : mechanism A
  Intra-domain discovery  : mechanism = B
  Intra-domain signaling  : mechanism = C
  Inter-domain discovery  : mechanism = D
  Inter-domain signaling  : mechanism = C++

 Of course there must be some architectural glue = that brings all  the pieces together.
 
 What I would like us to avoid is solution = space exploration, where  we have many mechanisms for the same = function we need, i.e, I would  be disappointed to see us end up = with a framework looking like:

  = Data-plane          &n= bsp;   : mechanism A, or B, or C
  Intra-domain discovery  : mechanism D, = or E, or F
  Intra-domain signaling  : mechanism G, = or H, or I
  Inter-domain discovery  : mechanism J, = or K, or L
  Inter-domain signaling  : mechanism M, = or N, or O

 This would, in view, impact = interoperability.

 We also seem to agree on the point I brought in = my message
 to Mark:

> Regarding the considerations you mention above, = in my
> opinion it would be wrong for us to start the = discussion
> by saying "SPs have X and Y deployed in = their networks,
> so we just have to decide whether we piggy-back = on X or
> on Y." Instead I'd like to see a = discussion ala "What are
> the functions we need? How can we best = implement them?
> Do we have an existing protocol that would be = the right
> fit for this functionality or do we need a new = one(s)?"


 Yakov, regarding your question again--
 
> Also, if you insist on a single solution, = wouldn't that
> imply a single auto-discovery mechanism for = VPLS ?

 --to refine my answer, I would say, my = preference would be for the WG  to come up with a single solution = consisting with at most two  discovery mechanisms--one for = intra-domain and one for inter-domain  problem space. It is ok if = the intra-domain only part comes first.

--
Alex
http://www.psg.com/~zinin/

Monday, May 5, 2003, 4:40:51 PM, = richard.spencer@bt.com wrote:
> Alex,

> How is the word 'solution' to be interpreted in = the sentence below?

> "I believe the goal for the WG should be to = work out a single
> solution."

> Does 'solution' =3D 'protocol'... i.e. LDP vs. = BGP? If so then I do not
> think working towards a single solution based = on which protocol is
> better for X or Y is the best way forward. I = think the seemingly
> never-ending debate on this subject proves this = point.

> If however the word solution was replaced with = 'set of detailed
> functional specifications' then maybe we can = move away from the LDP
> vs. BGP debate and concentrate on developing a = set of functional
> specifications created from the ground up. This = is in contrast to some
> of the existing 'solutions' which seem to me to = have been developed
> the wrong way round, i.e. we already use = protocol X for service Z,
> what changes do we need to make to protocol X = in order for it to be
> used for this new service Y.

> If the functional specifications are well = defined it should be clear
> which protocols are most suited and there may = be more than one. For
> example, one protocol may be more suited for a = specific function
> intra-AS and another inter-AS. To use a simple = analogy, OSPF is more
> suited for intra-AS routing and BGP is more = suited for inter-AS
> routing, but they both perform the function = 'routing'.

> Some of the foundations for the functional = specifications probably
> already exist within the various requirement = and solution drafts and
> just need extracting.

> The main advantages of separate functional = specifications being (1)
> that they can be developed independently = without having any impact on
> each other
> (2) operators would be able to choose which = protocol they wish to use to
> perform a certain function based on their own = specific requirements.

> Richard

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: 05 May 2003 22:27
> To: PPVPN@nortelnetworks.com
> Cc: Yakov Rekhter
> Subject: Single vs many solution(s)


> Yakov,

> [I took the liberty to change the subject = line]

>>> I believe the goal for the WG should be = to work out
>>> a single solution.

>> That is certainly not in the charter. In = fact the goal
>> you stated above directly contradicts what = is in the charter:

>>    Multiple approaches are = being developed as each approach
>>    has particular = characteristics and differing scope of
>> applicability.

> Thanks for pointing out a possible = contradiction. I don't think it
> exists.

> My opinion (and I think it would be safe for me = to say it is
> consistent with that of the IESG) is that as = long as different
> solutions are solving different problems (or, = as the text of the
> charter says, have different scopes of = applicability), it is fine to
> have more than one solution. However, for a = single problem, we only
> need a single STD'ized solution.

>> And if you believe that for VPLS the goal = should be a single
>> solution, then why wouldn't you insist to = have the same goal for L3
>> VPNs ?

> you forgot to add "and if you wouldn't = insist on a single solution for
> L3 VPNs, then why do you insist on this for L2 = VPNs" ;-)

> The reason is I don't want to restart the L3 VPN = work in the IETF
> and/or revisit the decisions that have been = made in the past, while I
> still see a reasonable opportunity to steer the = L2 VPN work.

>> Also, if you insist on a single solution, = wouldn't that imply a
>> single auto-discovery mechanism for VPLS = ?

> This would definitely be my preference.

> Alex


------_=_NextPart_001_01C313E0.81D2C302-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 11:19:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25932 for ; Tue, 6 May 2003 11:19:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46FM6R06768 for ; Tue, 6 May 2003 11:22:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46FM1s23172 for ; Tue, 6 May 2003 11:22:02 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6BC5@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'richard.spencer@bt.com'" , hshah@wavesmithnetworks.com, zinin@psg.com, PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 11:10:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313E1.B023D114" X-LYRIS-Message-Id: 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_01C313E1.B023D114 Content-Type: text/plain Richard, You rise an interesting aspect of the problem - It seems that is desire or there are requirements from the SPs to simplify the signaling, auto-discovery and to overlap the VPLS deployment with the current IP VPN market. Unfortunately, such requirements were not captured at the right time in the PPVN Requirement document, which was finalized only little bit ago. It is wrong that they are looking to have such elegance or simplicity or is wrong that we don't have the right tools, or imagination to solve such problems? Vasile -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tuesday, May 06, 2003 10:27 AM To: hshah@wavesmithnetworks.com; Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Himanshu, I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for two solutions to the same problem. [RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based signaling for L2VPN) is that my previous company could not find any customer demand for BGP-based solution (we did not look into Italy though :-) However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly): Draft Vendor Support SP Support BGP 4 19 LDP 7 3 These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.] I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. ...Richard -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com ] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------_=_NextPart_001_01C313E1.B023D114 Content-Type: text/html Message
         Richard,
 
             You rise an interesting aspect of the problem - It seems that is desire or  there are requirements from the
              SPs to simplify the signaling, auto-discovery and to overlap the VPLS deployment with the current IP VPN market.  Unfortunately, such requirements were not captured at the right time in the PPVN Requirement document, which was finalized only little bit ago.
             It is wrong that they are looking to have such elegance or simplicity or is wrong that we don't have the right tools, or imagination to solve such problems?
 
 
           Vasile
-----Original Message-----
From: richard.spencer@bt.com [mailto:richard.spencer@bt.com]
Sent: Tuesday, May 06, 2003 10:27 AM
To: hshah@wavesmithnetworks.com; Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com
Cc: yakov@juniper.net
Subject: RE: Single vs many solution(s)

Himanshu,
 
 
I believe that there can exist multiple solutions for different sets
of problems. However, one must not confuse the solution with
signaling. We oughta not have two signaling mechanisms for
two solutions to the same problem.
 
[RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] 
 
A while back, it was determined that PW setup signaling is not
the charter of PPVPN but of PWE3. Lately, we have been
discussing again whether BGP based signaling is better than LDP
based signaling. We have got to get past this issue once and for
all. My personal experience (having implemented BGP based
signaling for L2VPN) is that my previous company could not find any customer
demand for BGP-based solution (we did not look into Italy though :-)
However, there was greater interest in LDP based solution and
public forums to test interoperability with.
[RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly):
 
Draft     Vendor Support    SP Support
BGP              4                      19
LDP               7                       3
 
These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.]
 
I think we have learned enough lessons from CR-LDP vs RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
...Richard 
 

 
 
 -----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, 2003 11:21 PM
To: 'Alex Zinin'; PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

Alex,

  I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map.

  You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations.

 The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years -  have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self.


 The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality.


Cheers
   Vasile
 
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, May 05, 2003 5:27 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject line]

>> I believe the goal for the WG should be to work out
>> a single solution.

> That is certainly not in the charter. In fact the goal
> you stated above directly contradicts what is in the charter:

>    Multiple approaches are being developed as each approach
>    has particular characteristics and differing scope of
> applicability.

Thanks for pointing out a possible contradiction. I don't think it exists.

My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution.

> And if you believe that for VPLS the goal should be a single solution,
> then why wouldn't you insist to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work.

> Also, if you insist on a single solution, wouldn't that
> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C313E1.B023D114-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 11:27:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26155 for ; Tue, 6 May 2003 11:27:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46FTgR11636 for ; Tue, 6 May 2003 11:29:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46FTas04546 for ; Tue, 6 May 2003 11:29:36 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313E3.779C29DC" Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 11:23:38 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB7202152606@WHISTLER.WaveSmithNet.com> Thread-Topic: Single vs many solution(s) Thread-Index: AcMT3hNKb0uznaw/SjOViHyP1WcnTAAAKRqg From: "Himanshu Shah" To: , "Vasile Radoaca" , , Cc: X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C313E3.779C29DC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard, =20 Like it or not - this entire debate is about which signaling protocol to use. K.Kompella VPLS (decoupled feature) could also be supported using LDP signaling. However, that is not the focus of the debate. =20 As for inter-AS case, I remember the discussion in one of the design team meetings (in Boston) where Yakov himself suggested that inter-AS = can be handled by one AS handing off the traffic on the Ethernet and other AS picking that up as customer facing inter-carrier traffic. May be I misunderstood him. =20 I am (personally) skeptical about the BGP vs LDP support numbers. There is danger in delaying this decision, it impedes the L2VPN standardization effort, which in turn causes reluctance=20 and spurious in offering such service. =20 /himanshu -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tuesday, May 06, 2003 10:27 AM To: Himanshu Shah; vasile@nortelnetworks.com; zinin@psg.com; = PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Himanshu,=20 =20 =20 I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for=20 two solutions to the same problem. =20 [RS: I agree that there should only be one 'functional specification'. = However, I don't think we can rule out the possibility of having to use = more than one protocol for each function until the functional = specifications have been developed.]=20 =20 A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been=20 discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based=20 signaling for L2VPN) is that my previous company could not find any = customer=20 demand for BGP-based solution (we did not look into Italy though :-)=20 However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed = support on this mailing list for the two opposing drafts (K.Kompella vs. = V.Kompella/Lasserre), based on whether they work for an SP or a vendor = the results are (roughly): =20 Draft Vendor Support SP Support BGP 4 19 LDP 7 3 =20 These results would suggest that customers (i.e. SPs) prefer the BGP = approach. I am not saying that I agree, far from it, but I don't think = that we should rule out protocols at this stage, especially in the = inter-AS case. Instead we should be focussing on getting the functional = specifications correct.] =20 I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. =20 ...Richard=20 =20 =20 =20 -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex,=20 I think the ideal goal is to have only one solution, but such ideal = usual can be achieved if we are working in a pure theoretical = environment, without market considerations. In reality the market is = driving in most of the cases, and some assumptions made two years ago = are not any more valid - there are categories of SPs that pretty much = have disappeared from the map. You stated very clear that a problem space needs to have a single = solution. I fully agree with you as a goal, but ut the issue that we = face right now is that the problem space is not well concluded and well = understood just purely from technical considerations.=20 The L2 VPLS is a complex space with multiple dimensions, and the = vendors - in the last two years - have worked from different angles, = optimizing one or more dimension(s) of the problem space (probable the = downturn in the market it self, was part of the problem). Without to = contradict each other, most of the solutions are closed in a specific = dimension, based on some objective/subjective parameters or experience = and some criteria of optimization. Moving in only one dimension doesn't = scale it self. The fact we do have more than one solution, I think is a good thing, = and doesn't contradict that we can't move toward one solution, if we are = driving diligently, and willing to make compromises. Taken such research = value in consideration, would be a positive sign that IETF is looking to = create a solution that would be valid for a while. Reading the mailing = list, I observed the same wise advise from most of the SPs, and this = reflect not a "problem" but a reality. Cheers=20 Vasile=20 =20 -----Original Message-----=20 From: Alex Zinin [ mailto:zinin@psg.com]=20 Sent: Monday, May 05, 2003 5:27 PM=20 To: PPVPN@nortelnetworks.com=20 Cc: Yakov Rekhter=20 Subject: Single vs many solution(s)=20 Yakov,=20 [I took the liberty to change the subject line]=20 >> I believe the goal for the WG should be to work out=20 >> a single solution.=20 > That is certainly not in the charter. In fact the goal=20 > you stated above directly contradicts what is in the charter:=20 > Multiple approaches are being developed as each approach=20 > has particular characteristics and differing scope of=20 > applicability.=20 Thanks for pointing out a possible contradiction. I don't think it = exists.=20 My opinion (and I think it would be safe for me to say it is consistent = with that of the IESG) is that as long as different solutions are = solving different problems (or, as the text of the charter says, have = different scopes of applicability), it is fine to have more than one = solution. However, for a single problem, we only need a single STD'ized = solution. > And if you believe that for VPLS the goal should be a single solution, = > then why wouldn't you insist to have the same goal for L3 VPNs ?=20 you forgot to add "and if you wouldn't insist on a single solution for = L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or = revisit the decisions that have been made in the past, while I still see = a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that=20 > imply a single auto-discovery mechanism for VPLS ?=20 This would definitely be my preference.=20 Alex=20 ------_=_NextPart_001_01C313E3.779C29DC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Single vs many solution(s)
Richard,
 
Like=20 it or not - this entire debate is about which signaling=20 protocol
to=20 use. K.Kompella VPLS (decoupled feature) could also be=20 supported
using=20 LDP signaling. However, that is not the focus of the = debate.
 
As for=20 inter-AS case, I remember the discussion in one of the=20 design
team=20 meetings (in Boston) where Yakov himself suggested that inter-AS = can=20 be
handled by one AS handing off the traffic on the Ethernet and=20 other
AS=20 picking that up as customer facing inter-carrier traffic. May=20 be
I=20 misunderstood him.
 
I am=20 (personally) skeptical about the BGP vs LDP support
numbers. There is danger in delaying this decision, it=20 impedes
the=20 L2VPN standardization effort, which in turn causes = reluctance=20
and=20 spurious in offering such service.
 
/himanshu
-----Original Message-----
From: = richard.spencer@bt.com=20 [mailto:richard.spencer@bt.com]
Sent: Tuesday, May 06, 2003 = 10:27=20 AM
To: Himanshu Shah; vasile@nortelnetworks.com; = zinin@psg.com;=20 PPVPN@nortelnetworks.com
Cc: = yakov@juniper.net
Subject:=20 RE: Single vs many solution(s)

Himanshu,
 
 
I believe that there can exist multiple solutions for = different=20 sets
of problems. However, one must not confuse the solution=20 with
signaling. We oughta not have two signaling mechanisms for=20
two solutions to the same = problem.
 
[RS: I = agree that=20 there should only be one 'functional specification'. However, I = don't=20 think we can rule out the possibility of having to use more than one = protocol=20 for each function until the functional specifications have been=20 developed.] 
 
A while back, it was determined that PW setup signaling is=20 not
the charter of PPVPN but of PWE3. Lately, we have been=20
discussing again whether BGP based signaling is better than=20 LDP
based signaling. We have got to get past this issue once and=20 for
all. My personal experience (having implemented BGP based=20
signaling for L2VPN) is that my previous = company could not=20 find any customer
demand for BGP-based solution (we did not = look into Italy=20 though :-)
However, there was greater interest in LDP based solution=20 and
public forums to test interoperability=20 with.
[RS: = Carrying out a=20 quick count of the individuals that have expressed support on this = mailing=20 list for the two opposing drafts (K.Kompella vs. = V.Kompella/Lasserre),=20 based on whether they work for an SP or a vendor the results are=20 (roughly):
 
Draft     Vendor=20 Support    SP = Support
BGP       &= nbsp;     =20 = 4            =          =20 19
LDP       &= nbsp;      =20 = 7            =           =20 3
 
These = results would=20 suggest that customers (i.e. SPs) prefer the BGP approach. I am not = saying=20 that I agree, far from it, but I don't think that we should rule out = protocols=20 at this stage, especially in the inter-AS case. Instead we should be = focussing=20 on getting the functional specifications=20 correct.]
 
I think we have learned enough lessons from CR-LDP vs=20 RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
...Richard 
 

 
 
 -----Original=20 Message-----
From: Vasile Radoaca=20 [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, = 2003=20 11:21 PM
To: 'Alex Zinin'; = PPVPN@nortelnetworks.com
Cc:=20 Yakov Rekhter
Subject: RE: Single vs many=20 solution(s)

Alex,

  I think the ideal goal is to have only = one=20 solution, but such ideal usual can be achieved if we are working = in a pure=20 theoretical environment, without market considerations. In reality = the=20 market is driving in most of the cases, and some assumptions made = two=20 years ago are not any more valid - there are categories of SPs = that pretty=20 much have disappeared from the map.

  You stated very clear that a problem = space needs to=20 have a single solution. I fully agree with you as a goal, but ut = the issue=20 that we face right now is that the problem space is not well = concluded and=20 well understood just purely from technical considerations. =

 The L2 VPLS is a complex space with = multiple=20 dimensions, and the vendors - in the last two years -  have = worked=20 from different angles, optimizing one or more dimension(s) of the = problem=20 space (probable the downturn in the market it self, was part of = the=20 problem). Without to contradict each other, most of the solutions = are=20 closed in a specific dimension, based on some objective/subjective = parameters or experience and some criteria of optimization. Moving = in only=20 one dimension doesn't scale it self.


 The fact we do = have more=20 than one solution, I think is a good thing, and doesn't contradict = that we=20 can't move toward one solution, if we are driving diligently, and = willing=20 to make compromises. Taken such research value in consideration, = would be=20 a positive sign that IETF is looking to create a solution that = would be=20 valid for a while. Reading the mailing list, I observed the same = wise=20 advise from most of the SPs, and this reflect not a "problem" but = a=20 reality.


Cheers
   = Vasile=20
 
-----Original=20 Message-----
From: Alex Zinin [mailto:zinin@psg.com] =
Sent: Monday, May 05, 2003 5:27 PM
To:=20 PPVPN@nortelnetworks.com
Cc: Yakov = Rekhter=20
Subject: Single vs many solution(s) =


Yakov,

[I took the liberty to change the subject = line]=20

>> I believe the goal for the WG should be = to work=20 out
>> a single solution. =

> That is certainly not in the charter. In = fact the=20 goal
> you stated above directly = contradicts=20 what is in the charter:

>    Multiple approaches are = being=20 developed as each approach
>   =20 has particular characteristics and differing scope of =
> applicability.

Thanks for pointing out a possible = contradiction. I don't=20 think it exists.

My opinion (and I think it would be safe for me = to say it=20 is consistent with that of the IESG) is that as long as different=20 solutions are solving different problems (or, as the text of the = charter=20 says, have different scopes of applicability), it is fine to have = more=20 than one solution. However, for a single problem, we only need a = single=20 STD'ized solution.

> And if you believe that for VPLS the goal = should be a=20 single solution,
> then why wouldn't = you insist=20 to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on = a single=20 solution for L3 VPNs, then why do you insist on this for L2 VPNs"=20 ;-)

The reason is I don't want to restart the L3 VPN = work in=20 the IETF and/or revisit the decisions that have been made in the = past,=20 while I still see a reasonable opportunity to steer the L2 VPN=20 work.

> Also, if you insist on a single solution, = wouldn't=20 that
> imply a single auto-discovery = mechanism=20 for VPLS ?

This would definitely be my preference. =

Alex=20


------_=_NextPart_001_01C313E3.779C29DC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 11:43:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26646 for ; Tue, 6 May 2003 11:43:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46FibR18366 for ; Tue, 6 May 2003 11:44:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46FiVD18014 for ; Tue, 6 May 2003 11:44:31 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67D2@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: "Vasile Radoaca" , zinin@psg.com, PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 16:15:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313E2.61CDFD55" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: 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_01C313E2.61CDFD55 Content-Type: text/plain; charset="iso-8859-1" Vasile/Alex, -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: 06 May 2003 04:21 To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, NH=> Which 'market'? Is this (i) the Internet (big 'I') (ii) the traditional operator (iii) the ISP (iv) the vendor market or some other market? Speaking as an operator, we are not driving this market and neither are our end customers. Our end customers usually don't care how we implement our WANs....unless we screw-up through ill-defined solutions. Their main concerns are cost per bit and reliability/security. And my concerns are therefore these plus getting architecturally clean solutions that drive down my capex/opex.....but that might conflict with the aims of those wanting shift boxes (who are IMO driving the market) and perhaps some technology religion/dogma that is creating bad architectures (which at some point will impact my capex/opex downstream). and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. NH=> Yes indeed. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. NH=> I agree. I have problems with this 'single solution' view *if* it based on some (G)MPLS/IP unified view of the networking world. The fact is cnls, co pkt-sw and co cct-sw modes are *all* needed and they require different functional solutions.....this is actually at the root of most of the current day problems/discussions. Ethernet is something else again.....it simply does not have the right functional attributes to scale/work in the WAN environment. There are some things that are common to VPNs, but these relate to the setting up/mtce of the *server* layer (lets say MPLS.....but it could be other) and not the *client* layer distribution (of routing, if appropriate) that lies above this. So IPoverMPLS is different to arbitrary_L2overMPLS is different to EthernetoverMPLS at the *client* level.....and these are all different (architecturally) to X/IP cases of same at the *server* level (and some of which we would deprecate....but that's our call as an operator on what we regard as sensible or not client/server layer network relationships). The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). NH=> The *server* layer aspects are more simple IMO and these can be unified (see my related posting). The difficult aspects relate to client-layer distribution stuff above this . Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. NH=> I saw no good architectural rationale given for a vote from any SPs........other than to say we have X so want to keep X for all applications, without arguments to show why X is still 'right'. The main technical arguments have been provided by Eric, Yakov, etc who are not SPs....but this is largely at a protocol level not the wider arch view. I have given some of my views in the past as a traditional operator, looking to create a sustainable/logical networking world in which cnls, co pkt-sw and co cct-sw modes can all harmoniously co-exist. Cheers Vasile -----Original Message----- From: Alex Zinin [ mailto:zinin@psg.com ] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------_=_NextPart_001_01C313E2.61CDFD55 Content-Type: text/html; charset="iso-8859-1" RE: Single vs many solution(s)
Vasile/Alex,
-----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: 06 May 2003 04:21
To: 'Alex Zinin'; PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

Alex,

  I think the ideal goal is to have only one solution,  but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, 

NH=> Which 'market'?  Is this (i) the Internet (big 'I') (ii) the traditional operator (iii) the ISP (iv) the vendor market or some other market?  Speaking as an operator, we are not driving this market and neither are our end customers.  Our end customers usually don't care how we implement our WANs....unless we screw-up through ill-defined solutions.  Their main concerns are cost per bit and reliability/security.  And my concerns are therefore these plus getting architecturally clean solutions that drive down my capex/opex.....but that might conflict with the aims of those wanting shift boxes (who are IMO driving the market) and perhaps some technology religion/dogma that is creating bad architectures (which at some point will impact my capex/opex downstream).

 

  and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. 

NH=> Yes indeed. 

  You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations.  

NH=> I agree.  I have problems with this 'single solution' view *if* it based on some (G)MPLS/IP unified view of the networking world.  The fact is cnls, co pkt-sw and co cct-sw modes are *all* needed and they require different functional solutions.....this is actually at the root of most of the current day problems/discussions.  Ethernet is something else again.....it simply does not have the right functional attributes to scale/work in the WAN environment.  There are some things that are common to VPNs, but these relate to the setting up/mtce of the *server* layer (lets say MPLS.....but it could be other) and not the *client* layer distribution (of routing, if appropriate) that lies above this.  So IPoverMPLS is different to arbitrary_L2overMPLS is different to EthernetoverMPLS at the *client* level.....and these are all different (architecturally) to X/IP cases of same at the *server* level (and some of which we would deprecate....but that's our call as an operator on what we regard as sensible or not client/server layer network relationships).

 The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years -  have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). 

NH=> The *server* layer aspects are more simple IMO and these can be unified (see my related posting).  The difficult aspects relate to client-layer distribution stuff above this .

 Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self.

 
 The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. 

NH=> I saw no good architectural rationale given for a vote from any SPs........other than to say we have X so want to keep X for all applications, without arguments to show why X is still 'right'.  The main technical arguments have been provided by Eric, Yakov, etc who are not SPs....but this is largely at a protocol level not the wider arch view.  I have given some of my views in the past as a traditional operator, looking to create a sustainable/logical networking world in which cnls, co pkt-sw and co cct-sw modes can all harmoniously co-exist.


Cheers
   Vasile
 
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, May 05, 2003 5:27 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject line]

>> I believe the goal for the WG should be to work out
>> a single solution.

> That is certainly not in the charter. In fact the goal
> you stated above directly contradicts what is in the charter:

>    Multiple approaches are being developed as each approach
>    has particular characteristics and differing scope of
> applicability.

Thanks for pointing out a possible contradiction. I don't think it exists.

My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution.

> And if you believe that for VPLS the goal should be a single solution,
> then why wouldn't you insist to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work.

> Also, if you insist on a single solution, wouldn't that
> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C313E2.61CDFD55-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 12:16:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28021 for ; Tue, 6 May 2003 12:16:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46GJ6R21839 for ; Tue, 6 May 2003 12:19:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46GIw826433 for ; Tue, 6 May 2003 12:18:58 -0400 (EDT) Reply-To: From: "Vach Kompella" To: , , "Vasile Radoaca" , , Cc: Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 09:14:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0140_01C313AF.E0237310" 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: 06 May 2003 16:14:37.0287 (UTC) FILETIME=[96FBDF70:01C313EA] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0140_01C313AF.E0237310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Single vs many solution(s)Richard, Were you at the IETF in San Francisco? Did you count the vendor/provider support there? There is an incorrect notion that just because a number of "individuals who work for providers" have supported the BGP draft, that there is provider support for it. To continue this further: how would you evaluate the "support" an individual who works for a vendor that does not have a box that even remotely can perform L2VPN functions? How would you evaluate the "support" of an individual who works for a provider that is not remotely connected to the department that would either make the decision to provide L2VPNs or implement or support L2VPNs? Individuals at the IETF cast their support as individuals. If you want to qualify it as vendor or provider support, then please take the extra step of figuring out if they really speak for the company. Thanks. -Vach -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tuesday, May 06, 2003 7:27 AM To: hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Himanshu, I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for two solutions to the same problem. [RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based signaling for L2VPN) is that my previous company could not find any customer demand for BGP-based solution (we did not look into Italy though :-) However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly): Draft Vendor Support SP Support BGP 4 19 LDP 7 3 These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.] I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. ...Richard -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------=_NextPart_000_0140_01C313AF.E0237310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Single vs many solution(s)
Richard,
 
Were=20 you at the IETF in San Francisco?  Did you count the = vendor/provider=20 support there?  There is an incorrect notion that just because a = number of=20 "individuals who work for providers" have supported the BGP draft, that = there is=20 provider support for it.
 
To=20 continue this further: how would you evaluate the "support" an = individual=20 who works for a vendor that does not have a box that even remotely = can=20 perform L2VPN functions?  How would you evaluate the "support" of = an=20 individual who works for a provider that is not remotely connected to = the=20 department that would either make the decision to provide L2VPNs or = implement or=20 support L2VPNs?
 
Individuals at the IETF cast their support as = individuals.  If you=20 want to qualify it as vendor or provider support, then please take the = extra=20 step of figuring out if they really speak for the company. =20 Thanks.
 
-Vach
-----Original Message-----
From: = richard.spencer@bt.com=20 [mailto:richard.spencer@bt.com]
Sent: Tuesday, May 06, 2003 = 7:27=20 AM
To: hshah@wavesmithnetworks.com; Vasile Radoaca; = zinin@psg.com;=20 PPVPN@nortelnetworks.com
Cc: = yakov@juniper.net
Subject:=20 RE: Single vs many solution(s)

Himanshu,
 
 
I believe that there can exist multiple solutions for = different=20 sets
of problems. However, one must not confuse the solution=20 with
signaling. We oughta not have two signaling mechanisms for=20
two solutions to the same = problem.
 
[RS: I = agree that=20 there should only be one 'functional specification'. However, I = don't=20 think we can rule out the possibility of having to use more than one = protocol=20 for each function until the functional specifications have been=20 developed.] 
 
A while back, it was determined that PW setup signaling is=20 not
the charter of PPVPN but of PWE3. Lately, we have been=20
discussing again whether BGP based signaling is better than=20 LDP
based signaling. We have got to get past this issue once and=20 for
all. My personal experience (having implemented BGP based=20
signaling for L2VPN) is that my previous = company could not=20 find any customer
demand for BGP-based solution (we did not = look into Italy=20 though :-)
However, there was greater interest in LDP based solution=20 and
public forums to test interoperability=20 with.
[RS: = Carrying out a=20 quick count of the individuals that have expressed support on this = mailing=20 list for the two opposing drafts (K.Kompella vs. = V.Kompella/Lasserre),=20 based on whether they work for an SP or a vendor the results are=20 (roughly):
 
Draft     Vendor=20 Support    SP = Support
BGP       &= nbsp;     =20 = 4            =          =20 19
LDP       &= nbsp;      =20 = 7            =           =20 3
 
These = results would=20 suggest that customers (i.e. SPs) prefer the BGP approach. I am not = saying=20 that I agree, far from it, but I don't think that we should rule out = protocols=20 at this stage, especially in the inter-AS case. Instead we should be = focussing=20 on getting the functional specifications=20 correct.]
 
I think we have learned enough lessons from CR-LDP vs=20 RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
...Richard 
 

 
 
 -----Original=20 Message-----
From: Vasile Radoaca=20 [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, = 2003=20 11:21 PM
To: 'Alex Zinin'; = PPVPN@nortelnetworks.com
Cc:=20 Yakov Rekhter
Subject: RE: Single vs many=20 solution(s)

Alex,

  I think the ideal goal is to have only = one=20 solution, but such ideal usual can be achieved if we are working = in a pure=20 theoretical environment, without market considerations. In reality = the=20 market is driving in most of the cases, and some assumptions made = two=20 years ago are not any more valid - there are categories of SPs = that pretty=20 much have disappeared from the map.

  You stated very clear that a problem = space needs to=20 have a single solution. I fully agree with you as a goal, but ut = the issue=20 that we face right now is that the problem space is not well = concluded and=20 well understood just purely from technical considerations. =

 The L2 VPLS is a complex space with = multiple=20 dimensions, and the vendors - in the last two years -  have = worked=20 from different angles, optimizing one or more dimension(s) of the = problem=20 space (probable the downturn in the market it self, was part of = the=20 problem). Without to contradict each other, most of the solutions = are=20 closed in a specific dimension, based on some objective/subjective = parameters or experience and some criteria of optimization. Moving = in only=20 one dimension doesn't scale it self.


 The fact we do = have more=20 than one solution, I think is a good thing, and doesn't contradict = that we=20 can't move toward one solution, if we are driving diligently, and = willing=20 to make compromises. Taken such research value in consideration, = would be=20 a positive sign that IETF is looking to create a solution that = would be=20 valid for a while. Reading the mailing list, I observed the same = wise=20 advise from most of the SPs, and this reflect not a "problem" but = a=20 reality.


Cheers
   = Vasile=20
 
-----Original=20 Message-----
From: Alex Zinin [mailto:zinin@psg.com] =
Sent: Monday, May 05, 2003 5:27 PM
To:=20 PPVPN@nortelnetworks.com
Cc: Yakov = Rekhter=20
Subject: Single vs many solution(s) =


Yakov,

[I took the liberty to change the subject = line]=20

>> I believe the goal for the WG should be = to work=20 out
>> a single solution. =

> That is certainly not in the charter. In = fact the=20 goal
> you stated above directly = contradicts=20 what is in the charter:

>    Multiple approaches are = being=20 developed as each approach
>   =20 has particular characteristics and differing scope of =
> applicability.

Thanks for pointing out a possible = contradiction. I don't=20 think it exists.

My opinion (and I think it would be safe for me = to say it=20 is consistent with that of the IESG) is that as long as different=20 solutions are solving different problems (or, as the text of the = charter=20 says, have different scopes of applicability), it is fine to have = more=20 than one solution. However, for a single problem, we only need a = single=20 STD'ized solution.

> And if you believe that for VPLS the goal = should be a=20 single solution,
> then why wouldn't = you insist=20 to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on = a single=20 solution for L3 VPNs, then why do you insist on this for L2 VPNs"=20 ;-)

The reason is I don't want to restart the L3 VPN = work in=20 the IETF and/or revisit the decisions that have been made in the = past,=20 while I still see a reasonable opportunity to steer the L2 VPN=20 work.

> Also, if you insist on a single solution, = wouldn't=20 that
> imply a single auto-discovery = mechanism=20 for VPLS ?

This would definitely be my preference. =

Alex=20


------=_NextPart_000_0140_01C313AF.E0237310-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 12:32:11 2003 Received: from zcars0m9.nortelnetworks.com (h39s128a249n47.user.nortelnetworks.com [47.249.128.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28595 for ; Tue, 6 May 2003 12:32:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46GYVR27314 for ; Tue, 6 May 2003 12:34:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46GYSb08589 for ; Tue, 6 May 2003 12:34:28 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6BC9@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'vkompella@timetra.com'" , richard.spencer@bt.com, hshah@wavesmithnetworks.com, zinin@psg.com, PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 12:31:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313EC.E1FCB330" X-LYRIS-Message-Id: 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_01C313EC.E1FCB330 Content-Type: text/plain Vach, This is the culture that we build - did we built the constrains before we started the selection vote? Do you think that showing hands in the ppvn group, at your singular request was better then working via e-mails? Can you guarantee a fair distribution of the participants during your call? Vasile -----Original Message----- From: Vach Kompella [mailto:vkompella@timetra.com] Sent: Tuesday, May 06, 2003 12:14 PM To: richard.spencer@bt.com; hshah@wavesmithnetworks.com; Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Richard, Were you at the IETF in San Francisco? Did you count the vendor/provider support there? There is an incorrect notion that just because a number of "individuals who work for providers" have supported the BGP draft, that there is provider support for it. To continue this further: how would you evaluate the "support" an individual who works for a vendor that does not have a box that even remotely can perform L2VPN functions? How would you evaluate the "support" of an individual who works for a provider that is not remotely connected to the department that would either make the decision to provide L2VPNs or implement or support L2VPNs? Individuals at the IETF cast their support as individuals. If you want to qualify it as vendor or provider support, then please take the extra step of figuring out if they really speak for the company. Thanks. -Vach -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tuesday, May 06, 2003 7:27 AM To: hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Himanshu, I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for two solutions to the same problem. [RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based signaling for L2VPN) is that my previous company could not find any customer demand for BGP-based solution (we did not look into Italy though :-) However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly): Draft Vendor Support SP Support BGP 4 19 LDP 7 3 These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.] I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. ...Richard -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com ] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------_=_NextPart_001_01C313EC.E1FCB330 Content-Type: text/html Message
         Vach,
 
              This is the culture that we build - did we built the constrains before we started the selection vote?
              Do you think that showing hands in the ppvn group, at your singular request was better then working
              via e-mails? Can you guarantee  a fair distribution of the participants during your call?
             
 
          Vasile
-----Original Message-----
From: Vach Kompella [mailto:vkompella@timetra.com]
Sent: Tuesday, May 06, 2003 12:14 PM
To: richard.spencer@bt.com; hshah@wavesmithnetworks.com; Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com
Cc: yakov@juniper.net
Subject: RE: Single vs many solution(s)

Richard,
 
Were you at the IETF in San Francisco?  Did you count the vendor/provider support there?  There is an incorrect notion that just because a number of "individuals who work for providers" have supported the BGP draft, that there is provider support for it.
 
To continue this further: how would you evaluate the "support" an individual who works for a vendor that does not have a box that even remotely can perform L2VPN functions?  How would you evaluate the "support" of an individual who works for a provider that is not remotely connected to the department that would either make the decision to provide L2VPNs or implement or support L2VPNs?
 
Individuals at the IETF cast their support as individuals.  If you want to qualify it as vendor or provider support, then please take the extra step of figuring out if they really speak for the company.  Thanks.
 
-Vach
-----Original Message-----
From: richard.spencer@bt.com [mailto:richard.spencer@bt.com]
Sent: Tuesday, May 06, 2003 7:27 AM
To: hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; PPVPN@nortelnetworks.com
Cc: yakov@juniper.net
Subject: RE: Single vs many solution(s)

Himanshu,
 
 
I believe that there can exist multiple solutions for different sets
of problems. However, one must not confuse the solution with
signaling. We oughta not have two signaling mechanisms for
two solutions to the same problem.
 
[RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] 
 
A while back, it was determined that PW setup signaling is not
the charter of PPVPN but of PWE3. Lately, we have been
discussing again whether BGP based signaling is better than LDP
based signaling. We have got to get past this issue once and for
all. My personal experience (having implemented BGP based
signaling for L2VPN) is that my previous company could not find any customer
demand for BGP-based solution (we did not look into Italy though :-)
However, there was greater interest in LDP based solution and
public forums to test interoperability with.
[RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly):
 
Draft     Vendor Support    SP Support
BGP              4                      19
LDP               7                       3
 
These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.]
 
I think we have learned enough lessons from CR-LDP vs RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
...Richard 
 

 
 
 -----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, 2003 11:21 PM
To: 'Alex Zinin'; PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

Alex,

  I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map.

  You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations.

 The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years -  have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self.


 The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality.


Cheers
   Vasile
 
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, May 05, 2003 5:27 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject line]

>> I believe the goal for the WG should be to work out
>> a single solution.

> That is certainly not in the charter. In fact the goal
> you stated above directly contradicts what is in the charter:

>    Multiple approaches are being developed as each approach
>    has particular characteristics and differing scope of
> applicability.

Thanks for pointing out a possible contradiction. I don't think it exists.

My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution.

> And if you believe that for VPLS the goal should be a single solution,
> then why wouldn't you insist to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work.

> Also, if you insist on a single solution, wouldn't that
> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C313EC.E1FCB330-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 12:39:41 2003 Received: from zcars0m9.nortelnetworks.com (h39s128a249n47.user.nortelnetworks.com [47.249.128.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28801 for ; Tue, 6 May 2003 12:39:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46Gg3R01342 for ; Tue, 6 May 2003 12:42:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Gfxb17333 for ; Tue, 6 May 2003 12:41:59 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6BCA@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'neil.2.harrison@bt.com'" , zinin@psg.com, PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 12:37:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313ED.D3083254" X-LYRIS-Message-Id: 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_01C313ED.D3083254 Content-Type: text/plain Neil/Alex You pointed out clearly mw own concern with Alex' model. What Alex is proposing assumes that most of work was done, and now we are in the process of simple selecting a single "solution". Also, his model assumes that once one solution is chosen than the work is to perfect the solution - but what is happen if we need to change something fundamental - then solution A is still A or would become B? And if B was part of initial proposals then what would become B. Personal, I believe that talking of only solution at this point in time is a just misunderstanding of the current situation. If we want a solution to be chosen just to proof that a VPLS can be implemented than I am fine. Vasile -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Tuesday, May 06, 2003 11:16 AM To: Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Vasile/Alex, -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: 06 May 2003 04:21 To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, NH=> Which 'market'? Is this (i) the Internet (big 'I') (ii) the traditional operator (iii) the ISP (iv) the vendor market or some other market? Speaking as an operator, we are not driving this market and neither are our end customers. Our end customers usually don't care how we implement our WANs....unless we screw-up through ill-defined solutions. Their main concerns are cost per bit and reliability/security. And my concerns are therefore these plus getting architecturally clean solutions that drive down my capex/opex.....but that might conflict with the aims of those wanting shift boxes (who are IMO driving the market) and perhaps some technology religion/dogma that is creating bad architectures (which at some point will impact my capex/opex downstream). and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. NH=> Yes indeed. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. NH=> I agree. I have problems with this 'single solution' view *if* it based on some (G)MPLS/IP unified view of the networking world. The fact is cnls, co pkt-sw and co cct-sw modes are *all* needed and they require different functional solutions.....this is actually at the root of most of the current day problems/discussions. Ethernet is something else again.....it simply does not have the right functional attributes to scale/work in the WAN environment. There are some things that are common to VPNs, but these relate to the setting up/mtce of the *server* layer (lets say MPLS.....but it could be other) and not the *client* layer distribution (of routing, if appropriate) that lies above this. So IPoverMPLS is different to arbitrary_L2overMPLS is different to EthernetoverMPLS at the *client* level.....and these are all different (architecturally) to X/IP cases of same at the *server* level (and some of which we would deprecate....but that's our call as an operator on what we regard as sensible or not client/server layer network relationships). The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). NH=> The *server* layer aspects are more simple IMO and these can be unified (see my related posting). The difficult aspects relate to client-layer distribution stuff above this . Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. NH=> I saw no good architectural rationale given for a vote from any SPs........other than to say we have X so want to keep X for all applications, without arguments to show why X is still 'right'. The main technical arguments have been provided by Eric, Yakov, etc who are not SPs....but this is largely at a protocol level not the wider arch view. I have given some of my views in the past as a traditional operator, looking to create a sustainable/logical networking world in which cnls, co pkt-sw and co cct-sw modes can all harmoniously co-exist. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com ] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex ------_=_NextPart_001_01C313ED.D3083254 Content-Type: text/html Message
          Neil/Alex
 
               You pointed out clearly mw own concern with Alex' model. What Alex is proposing assumes
                that most of work was done, and now we are in the process of simple selecting a single "solution".
 
                Also, his model assumes that once one solution is chosen than the work is to perfect the solution - but
                what is happen if we need to change something fundamental - then solution A is still A or would become
                B? And if B was part of initial proposals then what would become B.
 
                Personal, I believe that talking of only solution at this point in time is a just misunderstanding of the
                current situation. If we want  a solution to be chosen just to proof that a VPLS can be implemented than
                I am fine. 
 
          Vasile    
            
-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Tuesday, May 06, 2003 11:16 AM
To: Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com
Cc: yakov@juniper.net
Subject: RE: Single vs many solution(s)

Vasile/Alex,
-----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: 06 May 2003 04:21
To: 'Alex Zinin'; PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

Alex,

  I think the ideal goal is to have only one solution,  but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, 

NH=> Which 'market'?  Is this (i) the Internet (big 'I') (ii) the traditional operator (iii) the ISP (iv) the vendor market or some other market?  Speaking as an operator, we are not driving this market and neither are our end customers.  Our end customers usually don't care how we implement our WANs....unless we screw-up through ill-defined solutions.  Their main concerns are cost per bit and reliability/security.  And my concerns are therefore these plus getting architecturally clean solutions that drive down my capex/opex.....but that might conflict with the aims of those wanting shift boxes (who are IMO driving the market) and perhaps some technology religion/dogma that is creating bad architectures (which at some point will impact my capex/opex downstream).

 

  and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. 

NH=> Yes indeed. 

  You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations.  

NH=> I agree.  I have problems with this 'single solution' view *if* it based on some (G)MPLS/IP unified view of the networking world.  The fact is cnls, co pkt-sw and co cct-sw modes are *all* needed and they require different functional solutions.....this is actually at the root of most of the current day problems/discussions.  Ethernet is something else again.....it simply does not have the right functional attributes to scale/work in the WAN environment.  There are some things that are common to VPNs, but these relate to the setting up/mtce of the *server* layer (lets say MPLS.....but it could be other) and not the *client* layer distribution (of routing, if appropriate) that lies above this.  So IPoverMPLS is different to arbitrary_L2overMPLS is different to EthernetoverMPLS at the *client* level.....and these are all different (architecturally) to X/IP cases of same at the *server* level (and some of which we would deprecate....but that's our call as an operator on what we regard as sensible or not client/server layer network relationships).

 The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years -  have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). 

NH=> The *server* layer aspects are more simple IMO and these can be unified (see my related posting).  The difficult aspects relate to client-layer distribution stuff above this .

 Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self.


 The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. 

NH=> I saw no good architectural rationale given for a vote from any SPs........other than to say we have X so want to keep X for all applications, without arguments to show why X is still 'right'.  The main technical arguments have been provided by Eric, Yakov, etc who are not SPs....but this is largely at a protocol level not the wider arch view.  I have given some of my views in the past as a traditional operator, looking to create a sustainable/logical networking world in which cnls, co pkt-sw and co cct-sw modes can all harmoniously co-exist.


Cheers
   Vasile
 
-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, May 05, 2003 5:27 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Single vs many solution(s)


Yakov,

[I took the liberty to change the subject line]

>> I believe the goal for the WG should be to work out
>> a single solution.

> That is certainly not in the charter. In fact the goal
> you stated above directly contradicts what is in the charter:

>    Multiple approaches are being developed as each approach
>    has particular characteristics and differing scope of
> applicability.

Thanks for pointing out a possible contradiction. I don't think it exists.

My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution.

> And if you believe that for VPLS the goal should be a single solution,
> then why wouldn't you insist to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work.

> Also, if you insist on a single solution, wouldn't that
> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex


------_=_NextPart_001_01C313ED.D3083254-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 12:51:33 2003 Received: from zcars0m9.nortelnetworks.com (h39s128a249n47.user.nortelnetworks.com [47.249.128.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29161 for ; Tue, 6 May 2003 12:51:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46GrvR05792 for ; Tue, 6 May 2003 12:53:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Grqe24652 for ; Tue, 6 May 2003 12:53:53 -0400 (EDT) X-Original-Recipient: vasile@nortelnetworks.com Message-ID: <3EB7E734.5060401@pi.se> Date: Tue, 06 May 2003 18:47:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vasile Radoaca" CC: "'neil.2.harrison@bt.com'" , zinin@psg.com, PPVPN@nortelnetworks.com, yakov@juniper.net Subject: Re: Single vs many solution(s) References: <8B888AAAAB0FD31189590008C79184430C7A6BCA@zbl6c002.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailc.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailc.telia.com [194.22.190.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vasile, should we read this as you in principle want several solutions for the same problem? /Loa Vasile Radoaca wrote: > Neil/Alex > > You pointed out clearly mw own concern with Alex' model. > What Alex is proposing assumes > that most of work was done, and now we are in the > process of simple selecting a single "solution". > Also, his model assumes that once one solution is chosen > than the work is to perfect the solution - but > what is happen if we need to change something > fundamental - then solution A is still A or would become > B? And if B was part of initial proposals then what > would become B. > > Personal, I believe that talking of only solution at > this point in time is a just misunderstanding of the > current situation. If we want a solution to be chosen > just to proof that a VPLS can be implemented than > I am fine. > > Vasile > > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, May 06, 2003 11:16 AM > To: Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; > PPVPN@nortelnetworks.com > Cc: yakov@juniper.net > Subject: RE: Single vs many solution(s) > > Vasile/Alex, > > -----Original Message----- > From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] > Sent: 06 May 2003 04:21 > To: 'Alex Zinin'; PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: RE: Single vs many solution(s) > > Alex, > > I think the ideal goal is to have only one solution, but such > ideal usual can be achieved if we are working in a pure > theoretical environment, without market considerations. In > reality the market is driving in most of the cases, > > NH=> Which 'market'? Is this (i) the Internet (big 'I') (ii) the > traditional operator (iii) the ISP (iv) the vendor market or > some other market? Speaking as an operator, we are not driving > this market and neither are our end customers. Our end > customers usually don't care how we implement our WANs....unless > we screw-up through ill-defined solutions. Their main concerns > are cost per bit and reliability/security. And my concerns are > therefore these plus getting architecturally clean solutions > that drive down my capex/opex.....but that might conflict with > the aims of those wanting shift boxes (who are IMO driving the > market) and perhaps some technology religion/dogma that is > creating bad architectures (which at some point will impact my > capex/opex downstream). > > > > and some assumptions made two years ago are not any more valid > - there are categories of SPs that pretty much have disappeared > from the map. > > NH=> Yes indeed. > > You stated very clear that a problem space needs to have a > single solution. I fully agree with you as a goal, but ut the > issue that we face right now is that the problem space is not > well concluded and well understood just purely from technical > considerations. > > NH=> I agree. I have problems with this 'single solution' > view *if* it based on some (G)MPLS/IP unified view of the > networking world. The fact is cnls, co pkt-sw and co cct-sw > modes are *all* needed and they require different functional > solutions.....this is actually at the root of most of the > current day problems/discussions. Ethernet is something else > again.....it simply does not have the right functional > attributes to scale/work in the WAN environment. There are some > things that are common to VPNs, but these relate to the setting > up/mtce of the *server* layer (lets say MPLS.....but it could be > other) and not the *client* layer distribution (of routing, if > appropriate) that lies above this. So IPoverMPLS is different > to arbitrary_L2overMPLS is different to EthernetoverMPLS at the > *client* level.....and these are all different (architecturally) > to X/IP cases of same at the *server* level (and some of which > we would deprecate....but that's our call as an operator on what > we regard as sensible or not client/server layer network > relationships). > > The L2 VPLS is a complex space with multiple dimensions, and > the vendors - in the last two years - have worked from > different angles, optimizing one or more dimension(s) of the > problem space (probable the downturn in the market it self, was > part of the problem). > > NH=> The *server* layer aspects are more simple IMO and these can > be unified (see my related posting). The difficult aspects > relate to client-layer distribution stuff above this . > > Without to contradict each other, most of the solutions are > closed in a specific dimension, based on some > objective/subjective parameters or experience and some criteria > of optimization. Moving in only one dimension doesn't scale it self. > > > The fact we do have more than one solution, I think is a good > thing, and doesn't contradict that we can't move toward one > solution, if we are driving diligently, and willing to make > compromises. Taken such research value in consideration, would > be a positive sign that IETF is looking to create a solution > that would be valid for a while. Reading the mailing list, I > observed the same wise advise from most of the SPs, and this > reflect not a "problem" but a reality. > > NH=> I saw no good architectural rationale given for a vote from > any SPs........other than to say we have X so want to keep X for > all applications, without arguments to show why X is still > 'right'. The main technical arguments have been provided by > Eric, Yakov, etc who are not SPs....but this is largely at a > protocol level not the wider arch view. I have given some of my > views in the past as a traditional operator, looking to create a > sustainable/logical networking world in which cnls, co pkt-sw > and co cct-sw modes can all harmoniously co-exist. > > > Cheers > Vasile > > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, May 05, 2003 5:27 PM > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > > > Yakov, > > [I took the liberty to change the subject line] > > >> I believe the goal for the WG should be to work out > >> a single solution. > > > That is certainly not in the charter. In fact the goal > > you stated above directly contradicts what is in the charter: > > > Multiple approaches are being developed as each approach > > has particular characteristics and differing scope of > > applicability. > > Thanks for pointing out a possible contradiction. I don't think > it exists. > > My opinion (and I think it would be safe for me to say it is > consistent with that of the IESG) is that as long as different > solutions are solving different problems (or, as the text of the > charter says, have different scopes of applicability), it is > fine to have more than one solution. However, for a single > problem, we only need a single STD'ized solution. > > > And if you believe that for VPLS the goal should be a single > solution, > > then why wouldn't you insist to have the same goal for L3 VPNs ? > > you forgot to add "and if you wouldn't insist on a single > solution for L3 VPNs, then why do you insist on this for L2 > VPNs" ;-) > > The reason is I don't want to restart the L3 VPN work in the > IETF and/or revisit the decisions that have been made in the > past, while I still see a reasonable opportunity to steer the L2 > VPN work. > > > Also, if you insist on a single solution, wouldn't that > > imply a single auto-discovery mechanism for VPLS ? > > This would definitely be my preference. > > Alex > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 13:10:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29761 for ; Tue, 6 May 2003 13:10:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46HCQR02088 for ; Tue, 6 May 2003 13:12:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46HCK312988 for ; Tue, 6 May 2003 13:12:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313F1.FB93771B" Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 19:07:32 +0200 Message-ID: Thread-Topic: Single vs many solution(s) Thread-Index: AcMT60nKY22OjQcwTKu87Hpx5msIQAAAjOkA From: "Hector Avalos" To: , X-OriginalArrivalTime: 06 May 2003 17:07:33.0389 (UTC) FILETIME=[FC1693D0:01C313F1] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C313F1.FB93771B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vach, =20 -----Original Message----- From: Vach Kompella [mailto:vkompella@timetra.com]=20 Sent: mardi 6 mai 2003 18:14 To: richard.spencer@bt.com; hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Richard, =20 Were you at the IETF in San Francisco? Did you count the vendor/provider support there? There is an incorrect notion that just because a number of "individuals who work for providers" have supported the BGP draft, that there is provider support for it. =20 To continue this further: how would you evaluate the "support" an individual who works for a vendor that does not have a box that even remotely can perform L2VPN functions? =20 =20 How would you evaluate the "support" of an individual who works for a provider that is not remotely connected to the department that would either make the decision to provide L2VPNs or implement or support L2VPNs?=20 [Hector: from the 19 SP supporting the kompella approach you have Telefonica, Equant, FT, Telia and Lambdanet..... and the individuals who sent the e-mails are connected to the decission to implement or support L2VPNs in their companies.=20 ] =20 =20 Individuals at the IETF cast their support as individuals. If you want to qualify it as vendor or provider support, then please take the extra step of figuring out if they really speak for the company. Thanks. =20 -Vach -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tuesday, May 06, 2003 7:27 AM To: hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Himanshu,=20 =20 =20 I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for=20 two solutions to the same problem. =20 [RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.]=20 =20 A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been=20 discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based=20 signaling for L2VPN) is that my previous company could not find any customer=20 demand for BGP-based solution (we did not look into Italy though :-)=20 However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly): =20 Draft Vendor Support SP Support BGP 4 19 LDP 7 3 =20 These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.] =20 I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. =20 ...Richard=20 =20 =20 =20 -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex,=20 I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations.=20 The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers=20 Vasile=20 =20 -----Original Message-----=20 From: Alex Zinin [mailto:zinin@psg.com]=20 Sent: Monday, May 05, 2003 5:27 PM=20 To: PPVPN@nortelnetworks.com=20 Cc: Yakov Rekhter=20 Subject: Single vs many solution(s)=20 Yakov,=20 [I took the liberty to change the subject line]=20 >> I believe the goal for the WG should be to work out=20 >> a single solution.=20 > That is certainly not in the charter. In fact the goal=20 > you stated above directly contradicts what is in the charter:=20 > Multiple approaches are being developed as each approach=20 > has particular characteristics and differing scope of=20 > applicability.=20 Thanks for pointing out a possible contradiction. I don't think it exists.=20 My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ?=20 you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that=20 > imply a single auto-discovery mechanism for VPLS ?=20 This would definitely be my preference.=20 Alex=20 ------_=_NextPart_001_01C313F1.FB93771B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Vach,
 
-----Original = Message-----
From: Vach=20 Kompella [mailto:vkompella@timetra.com]
Sent: mardi 6 mai = 2003=20 18:14
To: richard.spencer@bt.com; hshah@wavesmithnetworks.com; = Vasile=20 Radoaca; zinin@psg.com; PPVPN@nortelnetworks.com
Cc: Yakov=20 Rekhter
Subject: RE: Single vs many = solution(s)

Richard,
 
Were=20 you at the IETF in San Francisco?  Did you count the = vendor/provider=20 support there?  There is an incorrect notion that just because a = number of=20 "individuals who work for providers" have supported the BGP draft, that = there is=20 provider support for it.
 
To=20 continue this further: how would you evaluate the "support" an = individual=20 who works for a vendor that does not have a box that even remotely = can=20 perform L2VPN functions?   
 
 How would you evaluate the = "support" of an=20 individual who works for a provider that is not remotely connected to = the=20 department that would either make the decision to provide L2VPNs or = implement or=20 support L2VPNs? 
[Hector: =20 from the 19 SP supporting the kompella approach you have Telefonica, = Equant, FT,=20 Telia and Lambdanet.....
and the individuals who sent the = e-mails are=20 connected to the decission to implement or support L2VPNs in their=20 companies. 
]
 
 
Individuals at the IETF cast their support as = individuals.  If you=20 want to qualify it as vendor or provider support, then please take the = extra=20 step of figuring out if they really speak for the company. =20 Thanks.
 
-Vach
-----Original Message-----
From: = richard.spencer@bt.com=20 [mailto:richard.spencer@bt.com]
Sent: Tuesday, May 06, 2003 = 7:27=20 AM
To: hshah@wavesmithnetworks.com; Vasile Radoaca; = zinin@psg.com;=20 PPVPN@nortelnetworks.com
Cc: = yakov@juniper.net
Subject:=20 RE: Single vs many solution(s)

Himanshu,
 
 
I believe that there can exist multiple solutions for = different=20 sets
of problems. However, one must not confuse the solution=20 with
signaling. We oughta not have two signaling mechanisms for=20
two solutions to the same = problem.
 
[RS: I = agree that=20 there should only be one 'functional specification'. However, I = don't=20 think we can rule out the possibility of having to use more than one = protocol=20 for each function until the functional specifications have been=20 developed.] 
 
A while back, it was determined that PW setup signaling is=20 not
the charter of PPVPN but of PWE3. Lately, we have been=20
discussing again whether BGP based signaling is better than=20 LDP
based signaling. We have got to get past this issue once and=20 for
all. My personal experience (having implemented BGP based=20
signaling for L2VPN) is that my previous = company could not=20 find any customer
demand for BGP-based solution (we did not = look into Italy=20 though :-)
However, there was greater interest in LDP based solution=20 and
public forums to test interoperability=20 with.
[RS: = Carrying out a=20 quick count of the individuals that have expressed support on this = mailing=20 list for the two opposing drafts (K.Kompella vs. = V.Kompella/Lasserre),=20 based on whether they work for an SP or a vendor the results are=20 (roughly):
 
Draft     Vendor=20 Support    SP = Support
BGP       &= nbsp;     =20 = 4            =          =20 19
LDP       &= nbsp;      =20 = 7            =           =20 3
 
These = results would=20 suggest that customers (i.e. SPs) prefer the BGP approach. I am not = saying=20 that I agree, far from it, but I don't think that we should rule out = protocols=20 at this stage, especially in the inter-AS case. Instead we should be = focussing=20 on getting the functional specifications=20 correct.]
 
I think we have learned enough lessons from CR-LDP vs=20 RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
...Richard 
 

 
 
 -----Original=20 Message-----
From: Vasile Radoaca=20 [mailto:vasile@nortelnetworks.com]
Sent: Monday, May 05, = 2003=20 11:21 PM
To: 'Alex Zinin'; = PPVPN@nortelnetworks.com
Cc:=20 Yakov Rekhter
Subject: RE: Single vs many=20 solution(s)

Alex,

  I think the ideal goal is to have only = one=20 solution, but such ideal usual can be achieved if we are working = in a pure=20 theoretical environment, without market considerations. In reality = the=20 market is driving in most of the cases, and some assumptions made = two=20 years ago are not any more valid - there are categories of SPs = that pretty=20 much have disappeared from the map.

  You stated very clear that a problem = space needs to=20 have a single solution. I fully agree with you as a goal, but ut = the issue=20 that we face right now is that the problem space is not well = concluded and=20 well understood just purely from technical considerations. =

 The L2 VPLS is a complex space with = multiple=20 dimensions, and the vendors - in the last two years -  have = worked=20 from different angles, optimizing one or more dimension(s) of the = problem=20 space (probable the downturn in the market it self, was part of = the=20 problem). Without to contradict each other, most of the solutions = are=20 closed in a specific dimension, based on some objective/subjective = parameters or experience and some criteria of optimization. Moving = in only=20 one dimension doesn't scale it self.


 The fact we do = have more=20 than one solution, I think is a good thing, and doesn't contradict = that we=20 can't move toward one solution, if we are driving diligently, and = willing=20 to make compromises. Taken such research value in consideration, = would be=20 a positive sign that IETF is looking to create a solution that = would be=20 valid for a while. Reading the mailing list, I observed the same = wise=20 advise from most of the SPs, and this reflect not a "problem" but = a=20 reality.


Cheers
   = Vasile=20
 
-----Original=20 Message-----
From: Alex Zinin [mailto:zinin@psg.com] =
Sent: Monday, May 05, 2003 5:27 PM
To:=20 PPVPN@nortelnetworks.com
Cc: Yakov = Rekhter=20
Subject: Single vs many solution(s) =


Yakov,

[I took the liberty to change the subject = line]=20

>> I believe the goal for the WG should be = to work=20 out
>> a single solution. =

> That is certainly not in the charter. In = fact the=20 goal
> you stated above directly = contradicts=20 what is in the charter:

>    Multiple approaches are = being=20 developed as each approach
>   =20 has particular characteristics and differing scope of =
> applicability.

Thanks for pointing out a possible = contradiction. I don't=20 think it exists.

My opinion (and I think it would be safe for me = to say it=20 is consistent with that of the IESG) is that as long as different=20 solutions are solving different problems (or, as the text of the = charter=20 says, have different scopes of applicability), it is fine to have = more=20 than one solution. However, for a single problem, we only need a = single=20 STD'ized solution.

> And if you believe that for VPLS the goal = should be a=20 single solution,
> then why wouldn't = you insist=20 to have the same goal for L3 VPNs ?

you forgot to add "and if you wouldn't insist on = a single=20 solution for L3 VPNs, then why do you insist on this for L2 VPNs"=20 ;-)

The reason is I don't want to restart the L3 VPN = work in=20 the IETF and/or revisit the decisions that have been made in the = past,=20 while I still see a reasonable opportunity to steer the L2 VPN=20 work.

> Also, if you insist on a single solution, = wouldn't=20 that
> imply a single auto-discovery = mechanism=20 for VPLS ?

This would definitely be my preference. =

Alex=20


------_=_NextPart_001_01C313F1.FB93771B-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 13:15:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29943 for ; Tue, 6 May 2003 13:15:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46HI3R06201 for ; Tue, 6 May 2003 13:18:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46HHrZ18120 for ; Tue, 6 May 2003 13:17:54 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6BCC@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Loa Andersson'" Cc: "'neil.2.harrison@bt.com'" , zinin@psg.com, PPVPN@nortelnetworks.com, yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 13:15:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313F3.06CB9CB6" X-LYRIS-Message-Id: 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_01C313F3.06CB9CB6 Content-Type: text/plain Loa, Did we identify clearly only one problem? I wish to have only one final solution - but what Alex doesn't show us how we can move toward such solution. What are the intermediate points to get to the final destination - and here I think we need to be little bit more inventive. Can we use intermediate "solutions/mechanisms" that are not fundamental in contradiction to converge toward a single solution? Cheers Vasile -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Tuesday, May 06, 2003 12:48 PM To: Radoaca, Vasile [BL60:X624:EXCH] Cc: 'neil.2.harrison@bt.com'; zinin@psg.com; PPVPN@nortelnetworks.com; yakov@juniper.net Subject: Re: Single vs many solution(s) Vasile, should we read this as you in principle want several solutions for the same problem? /Loa Vasile Radoaca wrote: > Neil/Alex > > You pointed out clearly mw own concern with Alex' model. > What Alex is proposing assumes > that most of work was done, and now we are in the > process of simple selecting a single "solution". > Also, his model assumes that once one solution is chosen > than the work is to perfect the solution - but > what is happen if we need to change something > fundamental - then solution A is still A or would become > B? And if B was part of initial proposals then what > would become B. > > Personal, I believe that talking of only solution at > this point in time is a just misunderstanding of the > current situation. If we want a solution to be chosen > just to proof that a VPLS can be implemented than > I am fine. > > Vasile > > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, May 06, 2003 11:16 AM > To: Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; > PPVPN@nortelnetworks.com > Cc: yakov@juniper.net > Subject: RE: Single vs many solution(s) > > Vasile/Alex, > > -----Original Message----- > From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] > Sent: 06 May 2003 04:21 > To: 'Alex Zinin'; PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: RE: Single vs many solution(s) > > Alex, > > I think the ideal goal is to have only one solution, but such > ideal usual can be achieved if we are working in a pure > theoretical environment, without market considerations. In > reality the market is driving in most of the cases, > > NH=> Which 'market'? Is this (i) the Internet (big 'I') (ii) the > traditional operator (iii) the ISP (iv) the vendor market or > some other market? Speaking as an operator, we are not driving > this market and neither are our end customers. Our end > customers usually don't care how we implement our WANs....unless > we screw-up through ill-defined solutions. Their main concerns > are cost per bit and reliability/security. And my concerns are > therefore these plus getting architecturally clean solutions > that drive down my capex/opex.....but that might conflict with > the aims of those wanting shift boxes (who are IMO driving the > market) and perhaps some technology religion/dogma that is > creating bad architectures (which at some point will impact my > capex/opex downstream). > > > > and some assumptions made two years ago are not any more valid > - there are categories of SPs that pretty much have disappeared > from the map. > > NH=> Yes indeed. > > You stated very clear that a problem space needs to have a > single solution. I fully agree with you as a goal, but ut the > issue that we face right now is that the problem space is not > well concluded and well understood just purely from technical > considerations. > > NH=> I agree. I have problems with this 'single solution' > view *if* it based on some (G)MPLS/IP unified view of the > networking world. The fact is cnls, co pkt-sw and co cct-sw > modes are *all* needed and they require different functional > solutions.....this is actually at the root of most of the > current day problems/discussions. Ethernet is something else > again.....it simply does not have the right functional > attributes to scale/work in the WAN environment. There are some > things that are common to VPNs, but these relate to the setting > up/mtce of the *server* layer (lets say MPLS.....but it could be > other) and not the *client* layer distribution (of routing, if > appropriate) that lies above this. So IPoverMPLS is different > to arbitrary_L2overMPLS is different to EthernetoverMPLS at the > *client* level.....and these are all different (architecturally) > to X/IP cases of same at the *server* level (and some of which > we would deprecate....but that's our call as an operator on what > we regard as sensible or not client/server layer network > relationships). > > The L2 VPLS is a complex space with multiple dimensions, and > the vendors - in the last two years - have worked from > different angles, optimizing one or more dimension(s) of the > problem space (probable the downturn in the market it self, was > part of the problem). > > NH=> The *server* layer aspects are more simple IMO and these can > be unified (see my related posting). The difficult aspects > relate to client-layer distribution stuff above this . > > Without to contradict each other, most of the solutions are > closed in a specific dimension, based on some > objective/subjective parameters or experience and some criteria > of optimization. Moving in only one dimension doesn't scale it > self. > > > The fact we do have more than one solution, I think is a good > thing, and doesn't contradict that we can't move toward one > solution, if we are driving diligently, and willing to make > compromises. Taken such research value in consideration, would > be a positive sign that IETF is looking to create a solution > that would be valid for a while. Reading the mailing list, I > observed the same wise advise from most of the SPs, and this > reflect not a "problem" but a reality. > > NH=> I saw no good architectural rationale given for a vote from > any SPs........other than to say we have X so want to keep X for > all applications, without arguments to show why X is still > 'right'. The main technical arguments have been provided by > Eric, Yakov, etc who are not SPs....but this is largely at a > protocol level not the wider arch view. I have given some of my > views in the past as a traditional operator, looking to create a > sustainable/logical networking world in which cnls, co pkt-sw > and co cct-sw modes can all harmoniously co-exist. > > > Cheers > Vasile > > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, May 05, 2003 5:27 PM > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > > > Yakov, > > [I took the liberty to change the subject line] > > >> I believe the goal for the WG should be to work out > >> a single solution. > > > That is certainly not in the charter. In fact the goal > > you stated above directly contradicts what is in the > charter: > > > Multiple approaches are being developed as each approach > > has particular characteristics and differing scope of > > applicability. > > Thanks for pointing out a possible contradiction. I don't think > it exists. > > My opinion (and I think it would be safe for me to say it is > consistent with that of the IESG) is that as long as different > solutions are solving different problems (or, as the text of the > charter says, have different scopes of applicability), it is > fine to have more than one solution. However, for a single > problem, we only need a single STD'ized solution. > > > And if you believe that for VPLS the goal should be a single > solution, > > then why wouldn't you insist to have the same goal for L3 > VPNs ? > > you forgot to add "and if you wouldn't insist on a single > solution for L3 VPNs, then why do you insist on this for L2 > VPNs" ;-) > > The reason is I don't want to restart the L3 VPN work in the > IETF and/or revisit the decisions that have been made in the > past, while I still see a reasonable opportunity to steer the L2 > VPN work. > > > Also, if you insist on a single solution, wouldn't that > > imply a single auto-discovery mechanism for VPLS ? > > This would definitely be my preference. > > Alex > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se ------_=_NextPart_001_01C313F3.06CB9CB6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Single vs many solution(s)

Loa,

 Did we identify clearly only one problem? =
 
 I wish to have only one final solution - but = what Alex doesn't show us how we can
 move toward such solution. What are the = intermediate points to get to the final
 destination - and here I think we need to be = little bit more inventive.
 Can we use intermediate = "solutions/mechanisms" that are not fundamental in = contradiction to
 converge toward a single solution?
 
 
Cheers
  Vasile

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Tuesday, May 06, 2003 12:48 PM
To: Radoaca, Vasile [BL60:X624:EXCH]
Cc: 'neil.2.harrison@bt.com'; zinin@psg.com; = PPVPN@nortelnetworks.com; yakov@juniper.net
Subject: Re: Single vs many solution(s)


Vasile,

should we read this as you in principle want several = solutions for the same problem?

/Loa

Vasile Radoaca wrote:
> Neil/Alex
> 
> You pointed out clearly mw own concern with = Alex' model.
> What Alex is proposing assumes
> that most of work was done, and now we are in = the
> process of simple selecting a single = "solution".
> Also, his model assumes that once one solution = is chosen
> than the work is to perfect the solution - = but
> what is happen if we need to change something =
> fundamental - then solution A is still A or = would become
> B? And if B was part of initial proposals then = what
> would become B.
> 
> Personal, I believe that talking of only = solution at
> this point in time is a just misunderstanding = of the
> current situation. If we want a solution to be = chosen
> just to proof that a VPLS can be implemented = than
> I am fine.
> 
>          = ; Vasile   
>          = ;  
>
>     -----Original = Message-----
>     From: = neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com= ]
>     Sent: Tuesday, May 06, = 2003 11:16 AM
>     To: Radoaca, Vasile = [BL60:X624:EXCH]; zinin@psg.com;
>     = PPVPN@nortelnetworks.com
>     Cc: = yakov@juniper.net
>     Subject: RE: Single vs = many solution(s)
>
>     Vasile/Alex,
>
>         = -----Original Message-----
>         = From: Vasile Radoaca [mailto:vasile@nortelnetworks.c= om]
>         = Sent: 06 May 2003 04:21
>         = To: 'Alex Zinin'; PPVPN@nortelnetworks.com
>         = Cc: Yakov Rekhter
>         = Subject: RE: Single vs many solution(s)
>
>         = Alex,
>
>          = ; I think the ideal goal is to have only one solution,  but = such
>         = ideal usual can be achieved if we are working in a pure
>         = theoretical environment, without market considerations. In
>         = reality the market is driving in most of the cases,
>
>         = NH=3D>  Which 'market'?  Is this (i) the Internet (big = 'I') (ii) the
>         = traditional operator (iii) the ISP (iv) the vendor market or
>         = some other market?  Speaking as an operator, we are not = driving
>         = this market and neither are our end customers.  Our end
>         = customers usually don't care how we implement our WANs....unless
>         = we screw-up through ill-defined solutions.  Their main = concerns
>         = are cost per bit and reliability/security.  And my concerns = are
>         = therefore these plus getting architecturally clean solutions
>         = that drive down my capex/opex.....but that might conflict with
>         = the aims of those wanting shift boxes (who are IMO driving the
>         = market) and perhaps some technology religion/dogma that is
>         = creating bad architectures (which at some point will impact my
>         = capex/opex downstream).
>
>          =
>
>          = ; and some assumptions made two years ago are not any more valid
>         = - there are categories of SPs that pretty much have disappeared
>         = from the map.
>
>         = NH=3D>  Yes indeed.
>
>          = ; You stated very clear that a problem space needs to have a
>         = single solution. I fully agree with you as a goal, but ut the
>         = issue that we face right now is that the problem space is not
>         = well concluded and well understood just purely from technical
>         = considerations.
>
>         = NH=3D>  I agree.  I have problems with this 'single = solution'
>         = view *if* it based on some (G)MPLS/IP unified view of the
>         = networking world.  The fact is cnls, co pkt-sw and co = cct-sw
>         = modes are *all* needed and they require different functional
>         = solutions.....this is actually at the root of most of the
>         = current day problems/discussions.  Ethernet is something = else
>         = again.....it simply does not have the right functional
>         = attributes to scale/work in the WAN environment.  There are = some
>         = things that are common to VPNs, but these relate to the setting
>         = up/mtce of the *server* layer (lets say MPLS.....but it could be
>         = other) and not the *client* layer distribution (of routing, if
>         = appropriate) that lies above this.  So IPoverMPLS is = different
>         = to arbitrary_L2overMPLS is different to EthernetoverMPLS at the
>         = *client* level.....and these are all different (architecturally)
>         = to X/IP cases of same at the *server* level (and some of which
>         = we would deprecate....but that's our call as an operator on what
>         = we regard as sensible or not client/server layer network
>         = relationships).
>
>          The = L2 VPLS is a complex space with multiple dimensions, and
>         = the vendors - in the last two years -  have worked from
>         = different angles, optimizing one or more dimension(s) of the
>         = problem space (probable the downturn in the market it self, was
>         = part of the problem).
>
>         = NH=3D>  The *server* layer aspects are more simple IMO and = these can
>         = be unified (see my related posting).  The difficult aspects
>         = relate to client-layer distribution stuff above this .
>
>          = Without to contradict each other, most of the solutions are
>         = closed in a specific dimension, based on some
>         = objective/subjective parameters or experience and some criteria
>         = of optimization. Moving in only one dimension doesn't scale it
> self.
>
>
>          The = fact we do have more than one solution, I think is a good
>         = thing, and doesn't contradict that we can't move toward one
>         = solution, if we are driving diligently, and willing to make
>         = compromises. Taken such research value in consideration, would
>         = be a positive sign that IETF is looking to create a solution
>         = that would be valid for a while. Reading the mailing list, I
>         = observed the same wise advise from most of the SPs, and this
>         = reflect not a "problem" but a reality.
>
>         = NH=3D>  I saw no good architectural rationale given for a vote = from
>         = any SPs........other than to say we have X so want to keep X for
>         = all applications, without arguments to show why X is still
>         = 'right'.  The main technical arguments have been provided = by
>         = Eric, Yakov, etc who are not SPs....but this is largely at a
>         = protocol level not the wider arch view.  I have given some of = my
>         = views in the past as a traditional operator, looking to create a
>         = sustainable/logical networking world in which cnls, co pkt-sw
>         = and co cct-sw modes can all harmoniously co-exist.
>
>
>         = Cheers
>          = ;  Vasile
>          =
>         = -----Original Message-----
>         = From: Alex Zinin [mailto:zinin@psg.com]
>         = Sent: Monday, May 05, 2003 5:27 PM
>         = To: PPVPN@nortelnetworks.com
>         = Cc: Yakov Rekhter
>         = Subject: Single vs many solution(s)
>
>
>         = Yakov,
>
>         = [I took the liberty to change the subject line]
>
>          = >> I believe the goal for the WG should be to work out
>          = >> a single solution.
>
>          = > That is certainly not in the charter. In fact the goal
>          = > you stated above directly contradicts what is in the
> charter:
>
>          = >    Multiple approaches are being developed as each = approach
>          = >    has particular characteristics and differing = scope of
>          = > applicability.
>
>         = Thanks for pointing out a possible contradiction. I don't think
>         = it exists.
>
>         = My opinion (and I think it would be safe for me to say it is
>         = consistent with that of the IESG) is that as long as different
>         = solutions are solving different problems (or, as the text of the
>         = charter says, have different scopes of applicability), it is
>         = fine to have more than one solution. However, for a single
>         = problem, we only need a single STD'ized solution.
>
>          = > And if you believe that for VPLS the goal should be a = single
>         = solution,
>          = > then why wouldn't you insist to have the same goal for L3
> VPNs ?
>
>         = you forgot to add "and if you wouldn't insist on a single
>         = solution for L3 VPNs, then why do you insist on this for L2
>         = VPNs" ;-)
>
>         = The reason is I don't want to restart the L3 VPN work in the
>         = IETF and/or revisit the decisions that have been made in the
>         = past, while I still see a reasonable opportunity to steer the L2
>         = VPN work.
>
>          = > Also, if you insist on a single solution, wouldn't that
>          = > imply a single auto-discovery mechanism for VPLS ?
>
>         = This would definitely be my preference.
>
>         = Alex
>
>


--
Loa Andersson

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


------_=_NextPart_001_01C313F3.06CB9CB6-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 13:57:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01389 for ; Tue, 6 May 2003 13:57:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46HxsR21047 for ; Tue, 6 May 2003 13:59:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46HxnJ07409 for ; Tue, 6 May 2003 13:59:49 -0400 (EDT) Date: Tue, 6 May 2003 10:53:41 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1336000257.20030506105341@psg.com> To: "Bilel Jamoussi" CC: "'PPVPN@nortelnetworks.com'" Subject: Re: Strategy for VPN work in IETF In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6064E0313@zcard0ke.ca.nortel.com> References: <0D7FC1D8D861D511AEA70002A52CE5E6064E0313@zcard0ke.ca.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: jamoussi@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bilel, BNJ>> it would be good if you clarify your statement instead of pointing me > to the chairs. "Coordinating with Marco and Rick" means that all steps taken by Marco and Rick as the WG chairs in PPVPN are checked with the involved ADs and that we are working closer than usually. BNJ>> this is a much different position than what was implied by your > original message. The theme/tone of your initial email was one of informing > the WG of a decision that has already been taken - You are now saying you > are soliciting input to make an informed decision. That's different. From my initial message: ... > After much deliberation, the involved ADs... are considering ... > Based on the above considerations, we are considering... ... > We'd like to hear from the WG members if they see any fatal flaws with > the proposed approach. Please send us your feedback by May 11th. It's been open from the beginning. There is no conspiracy here. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 14:02:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01559 for ; Tue, 6 May 2003 14:02:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46I4kR07704 for ; Tue, 6 May 2003 14:04:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46I4er22663 for ; Tue, 6 May 2003 14:04:40 -0400 (EDT) Date: Tue, 6 May 2003 10:57:21 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <166220604.20030506105721@psg.com> To: "Vasile Radoaca" CC: "'vkompella@timetra.com'" , richard.spencer@bt.com, hshah@wavesmithnetworks.com, , Subject: Re: support numbers for BGP and LDP In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6BC9@zbl6c002.corpeast.baynetworks.com> References: <8B888AAAAB0FD31189590008C79184430C7A6BC9@zbl6c002.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vasile, Vach, et al- I suggest we drop the subject of 'votes' and 'counting' right here. This could have been an interesting discussion some other time, but now it is distracting. At the end, gauging and declaring consensus is the responsibility of the WG chairs, so let them do their job. -- Alex Tuesday, May 6, 2003, 9:31:02 AM, Vasile Radoaca wrote: > Vach, > This is the culture that we build - did we built the > constrains before we started the selection vote? > Do you think that showing hands in the ppvn group, at your > singular request was better then working > via e-mails? Can you guarantee a fair distribution of the > participants during your call? > Vasile > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Tuesday, May 06, 2003 12:14 PM > To: richard.spencer@bt.com; hshah@wavesmithnetworks.com; Radoaca, Vasile > [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com > Cc: yakov@juniper.net > Subject: RE: Single vs many solution(s) > Richard, > Were you at the IETF in San Francisco? Did you count the vendor/provider > support there? There is an incorrect notion that just because a number of > "individuals who work for providers" have supported the BGP draft, that > there is provider support for it. > To continue this further: how would you evaluate the "support" an individual > who works for a vendor that does not have a box that even remotely can > perform L2VPN functions? How would you evaluate the "support" of an > individual who works for a provider that is not remotely connected to the > department that would either make the decision to provide L2VPNs or > implement or support L2VPNs? > Individuals at the IETF cast their support as individuals. If you want to > qualify it as vendor or provider support, then please take the extra step of > figuring out if they really speak for the company. Thanks. > -Vach > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Tuesday, May 06, 2003 7:27 AM > To: hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; > PPVPN@nortelnetworks.com > Cc: yakov@juniper.net > Subject: RE: Single vs many solution(s) > Himanshu, > I believe that there can exist multiple solutions for different sets > of problems. However, one must not confuse the solution with > signaling. We oughta not have two signaling mechanisms for > two solutions to the same problem. > [RS: I agree that there should only be one 'functional specification'. > However, I don't think we can rule out the possibility of having to use more > than one protocol for each function until the functional specifications have > been developed.] > A while back, it was determined that PW setup signaling is not > the charter of PPVPN but of PWE3. Lately, we have been > discussing again whether BGP based signaling is better than LDP > based signaling. We have got to get past this issue once and for > all. My personal experience (having implemented BGP based > signaling for L2VPN) is that my previous company could not find any customer > demand for BGP-based solution (we did not look into Italy though :-) > However, there was greater interest in LDP based solution and > public forums to test interoperability with. > [RS: Carrying out a quick count of the individuals that have expressed > support on this mailing list for the two opposing drafts (K.Kompella vs. > V.Kompella/Lasserre), based on whether they work for an SP or a vendor the > results are (roughly): > Draft Vendor Support SP Support > BGP 4 19 > LDP 7 3 > These results would suggest that customers (i.e. SPs) prefer the BGP > approach. I am not saying that I agree, far from it, but I don't think that > we should rule out protocols at this stage, especially in the inter-AS case. > Instead we should be focussing on getting the functional specifications > correct.] > I think we have learned enough lessons from CR-LDP vs RSVP-TE > debacle. Lets not repeat it for L2VPN. > ...Richard > -----Original Message----- > From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] > Sent: Monday, May 05, 2003 11:21 PM > To: 'Alex Zinin'; PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: RE: Single vs many solution(s) > Alex, > I think the ideal goal is to have only one solution, but such ideal usual > can be achieved if we are working in a pure theoretical environment, without > market considerations. In reality the market is driving in most of the > cases, and some assumptions made two years ago are not any more valid - > there are categories of SPs that pretty much have disappeared from the map. > You stated very clear that a problem space needs to have a single > solution. I fully agree with you as a goal, but ut the issue that we face > right now is that the problem space is not well concluded and well > understood just purely from technical considerations. > The L2 VPLS is a complex space with multiple dimensions, and the vendors - > in the last two years - have worked from different angles, optimizing one > or more dimension(s) of the problem space (probable the downturn in the > market it self, was part of the problem). Without to contradict each other, > most of the solutions are closed in a specific dimension, based on some > objective/subjective parameters or experience and some criteria of > optimization. Moving in only one dimension doesn't scale it self. > The fact we do have more than one solution, I think is a good thing, and > doesn't contradict that we can't move toward one solution, if we are driving > diligently, and willing to make compromises. Taken such research value in > consideration, would be a positive sign that IETF is looking to create a > solution that would be valid for a while. Reading the mailing list, I > observed the same wise advise from most of the SPs, and this reflect not a > "problem" but a reality. > Cheers > Vasile > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com ] > Sent: Monday, May 05, 2003 5:27 PM > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > Yakov, > [I took the liberty to change the subject line] >>> I believe the goal for the WG should be to work out >>> a single solution. >> That is certainly not in the charter. In fact the goal >> you stated above directly contradicts what is in the charter: >> Multiple approaches are being developed as each approach >> has particular characteristics and differing scope of >> applicability. > Thanks for pointing out a possible contradiction. I don't think it exists. > My opinion (and I think it would be safe for me to say it is consistent with > that of the IESG) is that as long as different solutions are solving > different problems (or, as the text of the charter says, have different > scopes of applicability), it is fine to have more than one solution. > However, for a single problem, we only need a single STD'ized solution. >> And if you believe that for VPLS the goal should be a single solution, >> then why wouldn't you insist to have the same goal for L3 VPNs ? > you forgot to add "and if you wouldn't insist on a single solution for L3 > VPNs, then why do you insist on this for L2 VPNs" ;-) > The reason is I don't want to restart the L3 VPN work in the IETF and/or > revisit the decisions that have been made in the past, while I still see a > reasonable opportunity to steer the L2 VPN work. >> Also, if you insist on a single solution, wouldn't that >> imply a single auto-discovery mechanism for VPLS ? > This would definitely be my preference. > Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 14:21:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01930 for ; Tue, 6 May 2003 14:21:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46INhR15753 for ; Tue, 6 May 2003 14:23:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46INdp23134 for ; Tue, 6 May 2003 14:23:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 13:18:16 -0500 Message-ID: Thread-Topic: RE: Single vs many solution(s) Thread-Index: AcMT+8kl0rmwYn/OEdejAADAT2jDug== From: "Fang, Luyuan, ALABS" To: X-SMTP-HELO: kcmso1.proxy.att.com X-SMTP-MAIL-FROM: luyuanfang@att.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kcmso1.att.com [192.128.133.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01930 I'd like to support the three main solutions for L2 VPNs: draft-lasserre-vkompella-ppvpn-vpls, draft-kompella-ppvpn-vpls, draft-radoaca-ppvpn-gvpls,(and possibly others) to become PPVPN WG documents. Each solution has its own merits, and may satisfy different needs for the providers. It is conceivable that all solutions get deployed by different providers (indeed, this seems to be what is happening), and will eventually coexist. I think the PPVPN WG should define the solutions and then let the market decide. Thanks, Luyuan From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 14:25:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02049 for ; Tue, 6 May 2003 14:25:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46IRhR20295 for ; Tue, 6 May 2003 14:27:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46IRdp28347 for ; Tue, 6 May 2003 14:27:39 -0400 (EDT) Date: Tue, 6 May 2003 11:22:23 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <627721923.20030506112223@psg.com> To: "Vasile Radoaca" CC: PPVPN@nortelnetworks.com, richard.spencer@bt.com, yakov@juniper.net Subject: Re: Single vs many solution(s) In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6BC4@zbl6c002.corpeast.baynetworks.com> References: <8B888AAAAB0FD31189590008C79184430C7A6BC4@zbl6c002.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vasile, > In addition of intra-domain/inter-domain issues, the VPLS problem space add > also specific issues: > 1. A large variety of access type networks: LAN/VLAN, Q-in-Q, PWs, MinM > 2. A variety of CPE devices: L2, L3 devices > 3. A significant customer mac accumulation [oversubscription factor is a key > component of the VPLS Etehrnet service value], without any proper model to > poof that would not impact the performance, security or stability of the > VPLS core mainly when it would work in paralel with other services like IP > VPN > 4. Legacy inter-working > 5. Different deployment scenarios - A VPLS solution maps on different > network topologies: > a) it is possibile to start from the core and to extend to the access, by > employing simple access configurations - simple P2P or VLAN based. > b) it is possible to start from the access and build VPLS without any MPLS > core. Later when the metro is growing an MPLS core can be employed to glu > such access networks. > c) overlapping with current IP VPN networks Nice list of considerations. I certainly hope we are not going to see a separate solution for each possible combination. > How we can deal with such issues, using your model below? What problems do you see? Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 14:39:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02505 for ; Tue, 6 May 2003 14:39:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46IfvR25217 for ; Tue, 6 May 2003 14:41:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Ifsm09732 for ; Tue, 6 May 2003 14:41:54 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67D5@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: zinin@psg.com Cc: ppvpn@nortelnetworks.com Subject: FW: Single vs many solution(s) Date: Tue, 6 May 2003 17:11:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hi Alex.....A timely mail/comment IMO. My view is the protocol war (ie 'my protocol is better than yours') is completely missing the point, and is simply a symptom of a far deeper architectural problem. We have to understand this and get this right first.....because IMO it is this lack of architectural regonition/understanding of the real problem (whether accidental or malicious) that is causing so many kludges to appear. The basic problem IETF face is that it is trying to serve 2 completely different masters: There is the public Internet (big 'I') and there is the commercial exploitation of layer networks.....where the cnls mode (with IP as the dominant cnls technology) is but 1 mode here....witness GMPLS and MPLS: not at all clear to me why these are that relevant to the Internet, and where the former dabbles in the technologies that belong to the (L1) co cct-sw mode, whilst the latter does its best to pretend it's not dealing with a co pkt-sw mode. This is where the architectural rot starts. As I have said many times before on various IETF mail lists (but will repeat because its so important to recognise and is really at the heart of this discussion IMO), there are 3 fundamental network modes: - cnls - co pkt-sw - co cct-sw *All* technologies map to one of these modes. Operators need *all* 3 modes to optimally deliver all the different types of services required by customers. Each mode has different functional behaviours that are determined by the technical/commercial requirements it has to satisfy. It makes no sense to try and force functional convergence across *all* the modes, but it does make lots of sense to functionally converge different technologies that belong to the *same* mode....this mitigates against the 'stovepipe' problem (ie technology=service) and gateway problem of protocol/function conversion in both the data and control planes. So what I am looking for as an operator is to be able to select a common core technology for *each* of the above modes. cnls is easy, its IP. co cct-sw is easy, today it's SDH and tomorrow it will be OTNs (though I don't expect SDH to go away in the forseeable future). I would also like MPLS to become the common co pkt-sw core (and I would like to do edge conversion to grandfather other co pkt-sw technologies , eg FR and ATM).....but this can only happen if MPLS is correctly functionally specified. Note - One can have client/server relationships between the 3 different modes (though only some relationships make sense in our view), but one cannot have peer-interworking (ie protocol-conversion) between the modes. If one accepts this then several consequential 'networking truths' must also be accepted. For example, there is no need for the functional components of each mode to be the same....in fact to do would be far from optimal. Further, there is no need for the functional components to come as 1 amorphous set with no choices per functional component. What I mean by this is as follows: As an operator I have a requirement to be able to choose addressing, routing, signalling (for the 2 co modes), OAM, etc functional components *independently* (using best-of-breed selection criteria) both per mode and within each mode. If anyone tells me that I can apply the same common networking solution to an IP network as I can to an optical network then I would regard such an individual as barking mad.....and yet that is the what all the (G)MPLS stuff is supposed to be about. Now let's specifically look at the VPN problem which triggered the 'protocol war' discussions and Alex's original mail in the context of the above: Let's consider the VPN problem we are trying to address using MPLS as the common co pkt-sw core server layer technology and see if we can identify what is common and what is not common. Let's consider 3 types of VPN: - those with IP as the client layer type, eg rfc2547 type - those with ethernet as the client type, eg VPLS/VLANs - those with no specific client type....so this would be the MPLS equivalent of FR or ATM today.....and of course this fits the bill when one wants to offer an MPLS transit service. We can split the problem up as follows: 1 We must have some means of identifying MPLS data-plane access points that is independent of the client networks that are supported.....specifically both client and server layer networks require their own addressing (even if same format, they come from disjoint spaces). This does happen today in MPLS, but seems to occur subconciously(?) based on whatever signalling protocol is used to define the 'tunnel IDs'....so we don't have a consistent/single addressing scheme for MPLS access points. Note also that these are not *IP* v4 addresses, but some new addresses that have been created from combining a v4 address-type with some 'tunnel IDs', ie these addresses don't belong in the 'IP layer network space' at all but only in the 'MPLS network space', and also *specific* to the signalling protocol used to define them. However, speaking as an operator I would like to see a consistent/single way to identify MPLS data-plane access points emerge (irrespective of which signalling protocol is used, including 'none')....for exmaple, we could define these based on the v6 format (but it is not the *IP* v6 space for the reasons noted previously). 2 The next issue is that we need to associate a given set of MPLS access point addresses with the site locations of VPNs. So we need a VPN-ID that is unique and common to all the MPLS access point addresses which are going to be used to create the VPN server layer topology. We use this information to perform *discovery* (in the MPLS server layer) using protocol X say. 3 Next, having identified the access points of a given VPN's MPLS server layer, we need to set-up, via *signalling* using protocol Y say, the LSPs that create the VPN topology. {Aside. Note that the above is *common* to all types of MPLS-based VPN. Now we can consider the specific VPN types themselves, which are effectively differentiated by the client they support.} 4 RFC2547 VPNs. The client is IPv4. This has its own address challenges. So we add an 8 octet RD to the v4 addresses within the VPNs to make them unique in their own layer. It seems natural to use BGP4 to distribute the client layer addressing information because this is a routing protocol designed for this type of client.....but note this is strictly a client layer address distribution issue. The fact we are using the provider's BPG4 to do this stems from the fact that this is what BGP4 was designed for, ie IP layer address distribution. We also ask BGP to distribute some labels for use by the MPLS data-plane that are bound with specific client layer address prefixs. This again arguably makes sense because the client is IP. 5 ethernet/VLANs. The client is ethernet with or without VLAN identifiers. Client layer address distribution is done directly in the client's data-plane based on broadcasting/learning/aging. There is no *forced* need for an operator to own this problem.....all the ethernet/VLAN/bridging/etc functionality can be done in the client layer and all the operator doing is providing a simple MPLS VPN (like ATM/FR today). If one wants to go further than this and take on the client layer address distribution role in the core network, then the problems of scaling/fault-managing/resilience/etc that have been discussed have to be addressed. These are not trivial issues because the ethernet client layer was never designed with WAN deployment in mind. Its not at all obvious *why* an operator would wish to take these functions on board at the current time. 6 Simple MPLS VPNs. The client is irrelevant (or at least ought to me....cue entrance of LDP/ECMP/MPLS_PID kludge however). But what is wrong with providing a simple MPLS managed BW service? Might this not be attractive to certain customers who wish to own/control their own client layer network(s) above this.....which is also a simple MPLS transit service if you think about it. Note this is also what the previous ethernet/VLAN service defaults to when the operator does not take on the role of client layer 'address' distribution. So if I look at the base/common required functional behaviour we want from L2 VPNs it seems to me we need: - a set of globally unique addressed access points - a means to associate a set of these addresses with a VPN ID - a means to distribute those addresses amongst members of a VPN - a means to automatically set-up trails (and thereby the topology) between the access points that belong to the same VPN - plus a means to authenticate ad hoc 'joins' to a VPN These are the common MPLS *server* layer issues across VPN types. The key differences occur in the handling of the specific *client* layer IMO, and I think we should separate these 2 aspects. Its not clear to me that anyone is actually thinking along these lines as yet, but I see this as the most obvious logical split. regards, Neil From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 14:48:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02758 for ; Tue, 6 May 2003 14:48:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46IopR00421 for ; Tue, 6 May 2003 14:50:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Ioll16502 for ; Tue, 6 May 2003 14:50:48 -0400 (EDT) Date: Tue, 6 May 2003 11:45:04 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <319082870.20030506114504@psg.com> To: "Vasile Radoaca" CC: "'neil.2.harrison@bt.com'" , PPVPN@nortelnetworks.com, Subject: Re: Single vs many solution(s) In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6BCA@zbl6c002.corpeast.baynetworks.com> References: <8B888AAAAB0FD31189590008C79184430C7A6BCA@zbl6c002.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vasile, > Neil/Alex > You pointed out clearly mw own concern with Alex' model. What Alex > is proposing assumes that most of work was done, and now we are in > the process of simple selecting a single "solution". Actually, I don't assume that. In fact, I have stated at least twice, that we need to approach the problem as a group of engineers from ground up, looking at what functions we need and how we best implement them, instead of just picking what we have on the table already. The reason I used the notion of a 'mechanism ' in my message is to highlight that some ports of the overall solution are functionally separateable. > Also, his model assumes that once one solution is chosen than the > work is to perfect the solution - but what is happen if we need to > change something fundamental - then solution A is still A or would > become B? And if B was part of initial proposals then what would > become B. Frankly, you lost me here. You seem to have some specific example in mind while still operating abstract terms. Can you help me and give a real example? > Personal, I believe that talking of only solution at this point in > time is a just misunderstanding of the current situation. See my other e-mail I just sent to you. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 14:52:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02881 for ; Tue, 6 May 2003 14:52:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46IsVR03784 for ; Tue, 6 May 2003 14:54:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46IsRl21292 for ; Tue, 6 May 2003 14:54:27 -0400 (EDT) Date: Tue, 6 May 2003 11:44:18 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <849036694.20030506114418@psg.com> To: "Vasile Radoaca" CC: PPVPN@nortelnetworks.com, Yakov Rekhter Subject: Re: Single vs many solution(s) In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6BBC@zbl6c002.corpeast.baynetworks.com> References: <8B888AAAAB0FD31189590008C79184430C7A6BBC@zbl6c002.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vasile, Hopefully my reply to Richard last night helped clarify some points. Regarding the complexity of the L2 VPLS space and hence the difficulty of agreeing on a single solution--can I ask you to clearly formalize a few problem scopes where you believe different solutions are needed and explain why? I would expect that each scope would have a distinct set of characteristics. Alex > Alex, > I think the ideal goal is to have only one solution, but such ideal usual > can be achieved if we are working in a pure theoretical environment, without > market considerations. In reality the market is driving in most of the > cases, and some assumptions made two years ago are not any more valid - > there are categories of SPs that pretty much have disappeared from the map. > You stated very clear that a problem space needs to have a single > solution. I fully agree with you as a goal, but ut the issue that we face > right now is that the problem space is not well concluded and well > understood just purely from technical considerations. > The L2 VPLS is a complex space with multiple dimensions, and the vendors - > in the last two years - have worked from different angles, optimizing one > or more dimension(s) of the problem space (probable the downturn in the > market it self, was part of the problem). Without to contradict each other, > most of the solutions are closed in a specific dimension, based on some > objective/subjective parameters or experience and some criteria of > optimization. Moving in only one dimension doesn't scale it self. > The fact we do have more than one solution, I think is a good thing, and > doesn't contradict that we can't move toward one solution, if we are driving > diligently, and willing to make compromises. Taken such research value in > consideration, would be a positive sign that IETF is looking to create a > solution that would be valid for a while. Reading the mailing list, I > observed the same wise advise from most of the SPs, and this reflect not a > "problem" but a reality. > Cheers > Vasile > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, May 05, 2003 5:27 PM > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > Yakov, > [I took the liberty to change the subject line] >>> I believe the goal for the WG should be to work out >>> a single solution. >> That is certainly not in the charter. In fact the goal >> you stated above directly contradicts what is in the charter: >> Multiple approaches are being developed as each approach >> has particular characteristics and differing scope of >> applicability. > Thanks for pointing out a possible contradiction. I don't think it exists. > My opinion (and I think it would be safe for me to say it is consistent with > that of the IESG) is that as long as different solutions are solving > different problems (or, as the text of the charter says, have different > scopes of applicability), it is fine to have more than one solution. > However, for a single problem, we only need a single STD'ized solution. >> And if you believe that for VPLS the goal should be a single solution, >> then why wouldn't you insist to have the same goal for L3 VPNs ? > you forgot to add "and if you wouldn't insist on a single solution for L3 > VPNs, then why do you insist on this for L2 VPNs" ;-) > The reason is I don't want to restart the L3 VPN work in the IETF and/or > revisit the decisions that have been made in the past, while I still see a > reasonable opportunity to steer the L2 VPN work. >> Also, if you insist on a single solution, wouldn't that >> imply a single auto-discovery mechanism for VPLS ? > This would definitely be my preference. > Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 15:22:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05109 for ; Tue, 6 May 2003 15:22:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46JPDv15545 for ; Tue, 6 May 2003 15:25:13 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46JP8L00526 for ; Tue, 6 May 2003 15:25:09 -0400 (EDT) Content-Class: urn:content-classes:message Subject: RE: Single vs many solution(s) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 2003 15:22:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A0DEF87@m-va-bsod03.add0.masergy.com> Thread-Topic: Single vs many solution(s) thread-index: AcMT33va0RbCB++JS1KFBH19I4AN2gAIguhw From: "Ron Haberman" To: , , "Vasile Radoaca" , , Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: ronh@masergy.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05109 Richard, There is a flaw in the way you counted the votes, you didn't count my vote for the LDP solution (I work for a SP). The reason you didn't count it that you couldn't, I didn't send it until now. Like most people (both SP and vendors) that support the LDP solution, I was following the instructions from the chairs which were different for the two drafts. While Lasserre-VKompella was already voted on in SF, the chairs solicited mainly negative input as in "tell me why this shouldn't move forward or it will" while authors of Kompella-VPLS were requested to get support in order to move forward. Since I support the first and not the later I just remained silent. On that topic I would like to ask the chairs what is the current status of moving drafts to WG documents. According to the last email about that (about 4 weeks ago?) the WG had only a week to respond before the document moves forward. Any news about it? Thanks, Ron. -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tuesday, May 06, 2003 10:27 AM To: hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Himanshu, I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for two solutions to the same problem. [RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based signaling for L2VPN) is that my previous company could not find any customer demand for BGP-based solution (we did not look into Italy though :-) However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly): Draft Vendor Support SP Support BGP 4 19 LDP 7 3 These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.] I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. ...Richard -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 15:40:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05808 for ; Tue, 6 May 2003 15:40:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46JhFv24504 for ; Tue, 6 May 2003 15:43:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46JhBO12285 for ; Tue, 6 May 2003 15:43:12 -0400 (EDT) Message-ID: <20030506194052.93631.qmail@web13507.mail.yahoo.com> Date: Tue, 6 May 2003 12:40:52 -0700 (PDT) From: Mark Seery Subject: Plug-and-play components (was FW: Single vs many solution(s)) To: neil.2.harrison@bt.com Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13507.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13507.mail.yahoo.com [216.136.175.86] X-LYRIS-Message-Id: Neil, [clipped] >> As an operator I have a requirement to be able to choose addressing, routing, signalling (for the 2 co modes), OAM, etc functional components *independently* (using best-of-breed selection criteria) both per mode and within each mode.<< Not sure how this can be achieved in practice (under current industry structure/system architectures). I doubt it can be achieved by many startups - actually any; unless I misunderstand your meaning. Perhaps you could give some thoughts on how this could be achieved in practice, but ultimately maybe this group can not really tackle this issue and the IESG should take it up in some way. Perhaps this is yet another reason for an "architecture" function/WG/BOF in the IETF. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 15:50:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06017 for ; Tue, 6 May 2003 15:50:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46Jr9v27643 for ; Tue, 6 May 2003 15:53:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Jr5L22094 for ; Tue, 6 May 2003 15:53:06 -0400 (EDT) Message-ID: <20030506193255.11544.qmail@web13502.mail.yahoo.com> Date: Tue, 6 May 2003 12:32:55 -0700 (PDT) From: Mark Seery Subject: re: FW: Single vs many solution(s) To: neil.2.harrison@bt.com Cc: ppvpn@nortelnetworks.com, zinin@psg.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13502.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13502.mail.yahoo.com [216.136.175.81] X-LYRIS-Message-Id: Neil, >> NH: Operators need *all* 3 mode....<< Is there any publicly available information explaining the rationale for this statement? Not disputing it, just like to understand the details of the logic. >> NH: Let's consider the VPN problem we are trying to address using MPLS as the common co pkt-sw core server layer technology and see if we can identify what is common and what is not common. << When you say "we" I assume you mean BT. It is not clear to me that is a generally accepted truth. Forgetting about the IP option for a second, it would seem that the very presence of PWE suggests another server layer (as I think you have essentially stated). But more importantly, it is not clear that there is consenus that LDP provides a co pkt-sw capability, in fact I've seen many arguments to the contrary, certainly within the MPLS WG; and I know at some level you are yourself concerned that it does not, so seems some consensus on this issue is required if we go down the road of defining functional requirements. >> NH: 5. ethernet/VLANs. The client is ethernet with or without VLAN identifiers. Client layer address distribution is done directly in the client's data-plane based on broadcasting/learning/aging. There is no *forced* need for an operator to own this problem.....all the ethernet/VLAN/bridging/etc functionality can be done in the client layer and all the operator doing is providing a simple MPLS VPN (like ATM/FR today). << So I think I have argued one way or another that I am concerned about putting too much Ethernet client stuff in the network so keep that in mind as I make the following comments. The problem with today's client/server model is that the server layer is a point-to-point trail, that means if the operator wants to offer a switched service based on the client payload, then the PDU has to be popped out of the trail and switched by a different piece of equipment, i.e. there is a difference between a switched transport infrastructure and a switched service. Seems to me that the unspoken aim of VPLS is to avoid this. Now should we intermingle the client layer switching/briding solution together with the server layer solution - this is where I see potential for inter-standards body conflict and architectural conerns. Additionally, with point-to-point trails a mesh is required. What VPLS is trying to do is move that mesh from the subscriber/access to inside the edge/core network. This is one incremental step in the right direction; and maybe an important first step to get to market etc. Ultimately though, the option of having a true multipoint server layer might be an interesting option to pursue - if it can be managed etc. What some VPLS solutions are saying is that we have solved the mesh problem by automating the provisioning - excellent answer, and important. But another way of solving the problem would be to provide a multipoint server layer. That would leave three options for service providers to choose from: 1. point-to-point transport to a client layer switching function 2. edge-to-edge mesh that emulates a client layer switching function 3. multi-point server layer So then the question I would ask the WG, chairs, and ADs is it acceptable to solve one problem along three different (network)architectural paradigms, where you have one solution per paradigm, or must we select one? (we are of course looking like getting 1) and 2) anyway so we will already have more than one); Why would we need both 2) and 3) well it may turn out that solving QoS, traffic engineering, and management problems are very complex to solve with 3) and therefore 3) may give some charateristics which are suitable for some service descriptions/operators but not others. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 15:55:44 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06170 for ; Tue, 6 May 2003 15:55:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46Jw7v00419 for ; Tue, 6 May 2003 15:58:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Jw2L26007 for ; Tue, 6 May 2003 15:58:03 -0400 (EDT) Content-Class: urn:content-classes:message Subject: RE: Single vs many solution(s) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 2003 15:55:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A0DEF88@m-va-bsod03.add0.masergy.com> Thread-Topic: Single vs many solution(s) thread-index: AcMT4wQ2WM3bRcHFQcy5Fgj7VohSoAAIix7Q From: "Ron Haberman" To: Cc: "Vasile Radoaca" X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: ronh@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA06170 Vasile, I don't think that it either one is "wrong" as someone that works for a SP I would like to get simple signaling. I can live without auto-discovery because I have access to other tools that provide the same end result. I will however use auto-discovery if it was done in a way that makes sense to me, and that precludes BGP as it is a push protocol (send all information everywhere) as oppose to any directory service which is using a pull protocol (each device requests information related to it self). As to the "current IP VPN market", I was running Martini long before 2547. If I had to run VPLS in a similar fashion to either one I would choose Martini and not 2547. As to the "lack" of vendors to give SP everything they want now, I don't think that is a problem, I will (and I am sure others do) select the vendors they believe are going at the right direction. If a vendor doesn't have auto-discovery now, but I believe will at some point have an auto-discovery mechanism that makes sense to me, I will choose that vendor. Masergy Communications is an example for a company that actually IS running all three VPNs. We are running L2 point to point for about two years, 2547 for more than a year and are actually currently running (currently as in not planning to, thinking about it, evaluating) VPLS service for about a month and a half in our production network. Although I think the argument of 'run type X of VPLS because you also run type Y of some other VPN' is flawed I will participate and tell you that what I have implemented in Masergy's network is: *) Edge device 1: Used for L3: Internet access, 2547. The device is running IGP, BGP, RSVP. *) Edge device 2: Used for L2: Point-to-point services, VPLS service. The device is running IGP, RSVP, TLDP. IMHO It is much easier to manage L2VPN devices when they don't need to run BGP at all (less configuration) not to mention that customers are much more comfortable when they hear that the devices running their L2 VPNs are not connected to the Internet (read BGP). Thanks, Ron. -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Tuesday, May 06, 2003 11:11 AM To: 'richard.spencer@bt.com'; hshah@wavesmithnetworks.com; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Richard, You rise an interesting aspect of the problem - It seems that is desire or there are requirements from the SPs to simplify the signaling, auto-discovery and to overlap the VPLS deployment with the current IP VPN market. Unfortunately, such requirements were not captured at the right time in the PPVN Requirement document, which was finalized only little bit ago. It is wrong that they are looking to have such elegance or simplicity or is wrong that we don't have the right tools, or imagination to solve such problems? Vasile -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tuesday, May 06, 2003 10:27 AM To: hshah@wavesmithnetworks.com; Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; PPVPN@nortelnetworks.com Cc: yakov@juniper.net Subject: RE: Single vs many solution(s) Himanshu, I believe that there can exist multiple solutions for different sets of problems. However, one must not confuse the solution with signaling. We oughta not have two signaling mechanisms for two solutions to the same problem. [RS: I agree that there should only be one 'functional specification'. However, I don't think we can rule out the possibility of having to use more than one protocol for each function until the functional specifications have been developed.] A while back, it was determined that PW setup signaling is not the charter of PPVPN but of PWE3. Lately, we have been discussing again whether BGP based signaling is better than LDP based signaling. We have got to get past this issue once and for all. My personal experience (having implemented BGP based signaling for L2VPN) is that my previous company could not find any customer demand for BGP-based solution (we did not look into Italy though :-) However, there was greater interest in LDP based solution and public forums to test interoperability with. [RS: Carrying out a quick count of the individuals that have expressed support on this mailing list for the two opposing drafts (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for an SP or a vendor the results are (roughly): Draft Vendor Support SP Support BGP 4 19 LDP 7 3 These results would suggest that customers (i.e. SPs) prefer the BGP approach. I am not saying that I agree, far from it, but I don't think that we should rule out protocols at this stage, especially in the inter-AS case. Instead we should be focussing on getting the functional specifications correct.] I think we have learned enough lessons from CR-LDP vs RSVP-TE debacle. Lets not repeat it for L2VPN. ...Richard -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Monday, May 05, 2003 11:21 PM To: 'Alex Zinin'; PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Single vs many solution(s) Alex, I think the ideal goal is to have only one solution, but such ideal usual can be achieved if we are working in a pure theoretical environment, without market considerations. In reality the market is driving in most of the cases, and some assumptions made two years ago are not any more valid - there are categories of SPs that pretty much have disappeared from the map. You stated very clear that a problem space needs to have a single solution. I fully agree with you as a goal, but ut the issue that we face right now is that the problem space is not well concluded and well understood just purely from technical considerations. The L2 VPLS is a complex space with multiple dimensions, and the vendors - in the last two years - have worked from different angles, optimizing one or more dimension(s) of the problem space (probable the downturn in the market it self, was part of the problem). Without to contradict each other, most of the solutions are closed in a specific dimension, based on some objective/subjective parameters or experience and some criteria of optimization. Moving in only one dimension doesn't scale it self. The fact we do have more than one solution, I think is a good thing, and doesn't contradict that we can't move toward one solution, if we are driving diligently, and willing to make compromises. Taken such research value in consideration, would be a positive sign that IETF is looking to create a solution that would be valid for a while. Reading the mailing list, I observed the same wise advise from most of the SPs, and this reflect not a "problem" but a reality. Cheers Vasile -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Monday, May 05, 2003 5:27 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Single vs many solution(s) Yakov, [I took the liberty to change the subject line] >> I believe the goal for the WG should be to work out >> a single solution. > That is certainly not in the charter. In fact the goal > you stated above directly contradicts what is in the charter: > Multiple approaches are being developed as each approach > has particular characteristics and differing scope of > applicability. Thanks for pointing out a possible contradiction. I don't think it exists. My opinion (and I think it would be safe for me to say it is consistent with that of the IESG) is that as long as different solutions are solving different problems (or, as the text of the charter says, have different scopes of applicability), it is fine to have more than one solution. However, for a single problem, we only need a single STD'ized solution. > And if you believe that for VPLS the goal should be a single solution, > then why wouldn't you insist to have the same goal for L3 VPNs ? you forgot to add "and if you wouldn't insist on a single solution for L3 VPNs, then why do you insist on this for L2 VPNs" ;-) The reason is I don't want to restart the L3 VPN work in the IETF and/or revisit the decisions that have been made in the past, while I still see a reasonable opportunity to steer the L2 VPN work. > Also, if you insist on a single solution, wouldn't that > imply a single auto-discovery mechanism for VPLS ? This would definitely be my preference. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 16:03:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06424 for ; Tue, 6 May 2003 16:03:24 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46K5mv28503 for ; Tue, 6 May 2003 16:05:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46K5iG15495 for ; Tue, 6 May 2003 16:05:44 -0400 (EDT) Message-ID: From: "Marco Carugi" To: "'Alex Zinin'" Cc: PPVPN@nortelnetworks.com Subject: RE: Strategy for VPN work in IETF Date: Tue, 6 May 2003 21:55:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31409.71BEF6EC" X-LYRIS-Message-Id: 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_01C31409.71BEF6EC Content-Type: text/plain; charset="iso-8859-1" Alex, I had promised myself to keep quiet for a while on this topic and respectfully listening to the list. Reading some assertions, I cannot anymore. Looking after the best interest of the WG and having worked so hard to create it time ago. Inline, Marco > Alex Zinin wrote : > > > > Let me provide some clarifications wrt the questions raised in this > thread. > > 1. Changes will induce additional delays > > I should have communicated this better, I think. The fact that > we're talking about two separate WGs does NOT mean that work within > PPVPN is stopped. As my message said, the new WGs would be > announced at the same time as the current one would be closed. > Until then, the only discussion happening on the new WG's mailing > lists would be about the charter and the PPVPN would conduct > business as usual. We're closely coordinating with Marco and Rick, We (chairs) have just been requested to provide our advice on WG splitting without having had any way to participate in the discussion on issues. We have explained that, before discussing solutions, the issues should be openly discussed and agreed (I saw this happening for other topics, ex. Sub-IP area future debate in Atlanta). And that, ADs and TA ("you" have been the PPVPN TA until one month ago for a long time) never expressed such concerns in the past (or even, almost never dialogue with us (TA case)) . We have brought a number of reasons on why splitting is not a good idea. I also made a reasonable proposal that you noted (but has not been discussed with the WG). You finally said that you will propose your plan anyway to the WG. Is this "close coordination" ? > so all decisions taken within PPVPN will be effective in the new > WGs. > > So, the changes will not affect how the PPVPN documents are > progressed. > > 2. Not much L3 stuff is left anyway, so putting it in a separate WG > won't help. > > This is, of course, the first thing that was checked before > deciding whether separate WGs are needed or not. The proposed > charter of the L3VPN WG will give a clear view of what's left and > how much time it needs (see also my answer to the next question). You have not discussed the charters topic with us (chairs). We just answered to some milestone questions when looking at current L3 and L2 work items. On the other side, we heared that some concerns "still" exist at IESG level on specific "L3" solution which has been explicitly included in the PPVPN charter at WG creation time: this topic is certainly not in scope here, but may explain some WG issues. I would have expected (and I actually thought) these concerns were over after all this time. > Long story short, it does look like that there's enough work left > to warrant a separate WG. This is questionable. > 3. What are the new charters going to be like and who are the chairs? > > I am in the process of creating the new mailing lists, as soon as > they are ready (shouldn't take the secretariat more than 2 days), I > will inform this list and will post the proposed charters there for > discussion. So, it seems like you will anticipate creation of the lists (as well as charter discussions), without waiting for extensive input on the plan as requested from the list. > > > 5. What to do with "generic" documents like requirements and > terminology? > > For documents that span both WGs, one of the WGs will be made the > host for each them based on the discussion with the > community, authors, > and WG chairs. This shows one of the limits of the plan. Without mentioning other generic documents (topics), like management or security frameworks. > > 6. Let's see who's complaining, what the concerns are, whether they > are valid, etc, etc. > > Management of WGs within areas is part of the AD's > responsibilities. While doing so, we talk to different IETF > participants, document authors, WG chairs, collect opinions, then > compare those with our observations, and apply our judgement to > decide whether something needs to be changed and how. > > Given that these processes happen under the confidentiality > conditions, it would not be productive and/or constructive to do > this in public. This is very easy to say. The fact is that you didn't bring us (Rick and I) very factual elements about these concerns. For our part, we brought a number of counter elements (including past lack of support in our regards, change in L2 solution work direction promoted at the AD level - this last thing not wrong per se IMO (I already said this), but certainly with some WG management inconvenients). Hope this provides some clarification. ------_=_NextPart_001_01C31409.71BEF6EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Strategy for VPN work in IETF

Alex,

I had promised myself to keep quiet for a while on = this topic and respectfully listening to the list. Reading some = assertions, I cannot anymore.

Looking after the best interest of the WG and having = worked so hard to create it time ago.

Inline, Marco


> Alex Zinin wrote :
>
> <snip>
>
> Let me provide some clarifications wrt the = questions raised in this
> thread.
> 
> 1. Changes will induce additional delays
>
>    I should have communicated = this better, I think. The fact that
>    we're talking about two = separate WGs does NOT mean that work within
>    PPVPN is stopped. As my = message said, the new WGs would be
>    announced at the same time as = the current one would be closed.
>    Until then, the only = discussion happening on the new WG's mailing
>    lists would be about the = charter and the PPVPN would conduct
>    business as usual. We're = closely coordinating with Marco and Rick,

We (chairs) have just been requested to provide our = advice on WG splitting without having had any way to participate in the = discussion on issues.

We have explained that, before discussing solutions, = the issues should be openly discussed and agreed (I saw this happening = for other topics, ex. Sub-IP area future debate in Atlanta). And that, = ADs and TA ("you" have been the PPVPN TA until one month ago = for a long time) never expressed such concerns in the past (or even, = almost never dialogue with us

(TA case)) .
We have brought a number of reasons on why splitting = is not a good idea.
I also made a reasonable proposal that you noted = (but has not been discussed with the WG).
You finally said that you will propose your plan = anyway to the WG.

Is this "close coordination" ?


>    so all decisions taken within = PPVPN will be effective in the new
>    WGs.
>
>    So, the changes will not = affect how the PPVPN documents are
>    progressed.
>
> 2. Not much L3 stuff is left anyway, so putting = it in a separate WG
>    won't help.
>
>    This is, of course, the first = thing that was checked before
>    deciding whether separate WGs = are needed or not. The proposed
>    charter of the L3VPN WG will = give a clear view of what's left and
>    how much time it needs (see = also my answer to the next question).

You have not discussed the charters topic with us = (chairs). We just answered to some milestone questions when looking at = current L3 and L2 work items.

On the other side, we heared that some concerns = "still" exist at IESG level on specific "L3" = solution which has been explicitly included in the PPVPN charter at WG = creation time: this topic is certainly not in scope here, but may = explain some WG issues. 

I would have expected (and I actually thought) these = concerns were over after all this time.

>    Long story short, it does look = like that there's enough work left
>    to warrant a separate = WG.

This is questionable.


> 3. What are the new charters going to be like = and who are the chairs?
>
>    I am in the process of = creating the new mailing lists, as soon as
>    they are ready (shouldn't = take the secretariat more than 2 days), I
>    will inform this list and = will post the proposed charters there for
>    discussion.

So, it seems like you will anticipate creation of the = lists (as well as charter discussions), without waiting for extensive = input on the plan as requested from the list.

> <snip>
>
> 5. What to do with "generic" = documents like requirements and
> terminology?
>
>    For documents that span both = WGs, one of the WGs will be made the
>    host for each them based on = the discussion with the
> community, authors,
>    and WG chairs.

This shows one of the limits of the plan.
Without mentioning other generic documents (topics), = like management or security frameworks.

>
> 6. Let's see who's complaining, what the = concerns are, whether they
>    are valid, etc, etc.
>
>    Management of WGs within = areas is part of the AD's
>    responsibilities. While doing = so, we talk to different IETF
>    participants, document = authors, WG chairs, collect opinions, then
>    compare those with our = observations, and apply our judgement to
>    decide whether something = needs to be changed and how.
>
>    Given that these processes = happen under the confidentiality
>    conditions, it would not be = productive and/or constructive to do
>    this in public.

This is very easy to say. The fact is that you didn't = bring us (Rick and I) very factual elements about these concerns. =

For our part, we brought a number of counter elements = (including past lack of support in our regards, change in L2 solution = work direction promoted at the AD level - this last thing not wrong per = se IMO (I already said this), but certainly with some WG management = inconvenients).

Hope this provides some clarification.

------_=_NextPart_001_01C31409.71BEF6EC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 16:15:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06791 for ; Tue, 6 May 2003 16:15:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46KHUv03897 for ; Tue, 6 May 2003 16:17:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46KHQ820512 for ; Tue, 6 May 2003 16:17:27 -0400 (EDT) X-Original-Recipient: hshah@wavesmithnetworks.com Message-ID: <3EB7E637.70502@pi.se> Date: Tue, 06 May 2003 18:43:35 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vkompella@timetra.com CC: richard.spencer@bt.com, hshah@wavesmithnetworks.com, "Vasile Radoaca" , zinin@psg.com, PPVPN@nortelnetworks.com, yakov@juniper.net Subject: Re: Single vs many solution(s) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailc.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: mailc.telia.com [194.22.190.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit All, I technically agree with what Vach says, but ... ... there is a a problem here, within IETF we frequently ask "What does the operators think?" or state "We need more opertor input!" So when some individuals working for operators actually do say what they think, you'll probably will make it harder to have their opinion next time if you don't acknowledge their input this time. Opinions is not limited to the people who were in SF, actually the IETF procedure is to form consensus on the mailing list. I haven't counted the number of operators supporting one side or the other, but still think that the input from operator affiliated individuals are important in this discussion Having said that, I also would like to say that I support one single solution per problem. I would also like to take care that solution we pick for the "current" problem is not insufficient for "tomorrows" problem. /Loa Vach Kompella wrote: > Richard, > > Were you at the IETF in San Francisco? Did you count the > vendor/provider support there? There is an incorrect notion that just > because a number of "individuals who work for providers" have supported > the BGP draft, that there is provider support for it. > > To continue this further: how would you evaluate the "support" an > individual who works for a vendor that does not have a box that even > remotely can perform L2VPN functions? How would you evaluate the > "support" of an individual who works for a provider that is not remotely > connected to the department that would either make the decision to > provide L2VPNs or implement or support L2VPNs? > > Individuals at the IETF cast their support as individuals. If you want > to qualify it as vendor or provider support, then please take the extra > step of figuring out if they really speak for the company. Thanks. > > -Vach > > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Tuesday, May 06, 2003 7:27 AM > To: hshah@wavesmithnetworks.com; Vasile Radoaca; zinin@psg.com; > PPVPN@nortelnetworks.com > Cc: yakov@juniper.net > Subject: RE: Single vs many solution(s) > > Himanshu, > > > I believe that there can exist multiple solutions for different sets > of problems. However, one must not confuse the solution with > signaling. We oughta not have two signaling mechanisms for > two solutions to the same problem. > > [RS: I agree that there should only be one 'functional > specification'. However, I don't think we can rule out the > possibility of having to use more than one protocol for each > function until the functional specifications have been developed.] > > A while back, it was determined that PW setup signaling is not > the charter of PPVPN but of PWE3. Lately, we have been > discussing again whether BGP based signaling is better than LDP > based signaling. We have got to get past this issue once and for > all. My personal experience (having implemented BGP based > signaling for L2VPN) is that my previous company could not find any > customer > demand for BGP-based solution (we did not look into Italy though :-) > However, there was greater interest in LDP based solution and > public forums to test interoperability with. > [RS: Carrying out a quick count of the individuals that have > expressed support on this mailing list for the two opposing drafts > (K.Kompella vs. V.Kompella/Lasserre), based on whether they work for > an SP or a vendor the results are (roughly): > > Draft Vendor Support SP Support > BGP 4 19 > LDP 7 3 > > These results would suggest that customers (i.e. SPs) prefer the BGP > approach. I am not saying that I agree, far from it, but I don't > think that we should rule out protocols at this stage, especially in > the inter-AS case. Instead we should be focussing on getting the > functional specifications correct.] > > I think we have learned enough lessons from CR-LDP vs RSVP-TE > debacle. Lets not repeat it for L2VPN. > > ...Richard > > > > > > -----Original Message----- > From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] > Sent: Monday, May 05, 2003 11:21 PM > To: 'Alex Zinin'; PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: RE: Single vs many solution(s) > > Alex, > > I think the ideal goal is to have only one solution, but > such ideal usual can be achieved if we are working in a pure > theoretical environment, without market considerations. In > reality the market is driving in most of the cases, and some > assumptions made two years ago are not any more valid - > there are categories of SPs that pretty much have > disappeared from the map. > > You stated very clear that a problem space needs to have a > single solution. I fully agree with you as a goal, but ut > the issue that we face right now is that the problem space > is not well concluded and well understood just purely from > technical considerations. > > The L2 VPLS is a complex space with multiple dimensions, > and the vendors - in the last two years - have worked from > different angles, optimizing one or more dimension(s) of the > problem space (probable the downturn in the market it self, > was part of the problem). Without to contradict each other, > most of the solutions are closed in a specific dimension, > based on some objective/subjective parameters or experience > and some criteria of optimization. Moving in only one > dimension doesn't scale it self. > > > The fact we do have more than one solution, I think is a > good thing, and doesn't contradict that we can't move toward > one solution, if we are driving diligently, and willing to > make compromises. Taken such research value in > consideration, would be a positive sign that IETF is looking > to create a solution that would be valid for a while. > Reading the mailing list, I observed the same wise advise > from most of the SPs, and this reflect not a "problem" but a > reality. > > > Cheers > Vasile > > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, May 05, 2003 5:27 PM > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > > > Yakov, > > [I took the liberty to change the subject line] > > >> I believe the goal for the WG should be to work out > >> a single solution. > > > That is certainly not in the charter. In fact the goal > > you stated above directly contradicts what is in the > charter: > > > Multiple approaches are being developed as each approach > > has particular characteristics and differing scope of > > applicability. > > Thanks for pointing out a possible contradiction. I don't > think it exists. > > My opinion (and I think it would be safe for me to say it is > consistent with that of the IESG) is that as long as > different solutions are solving different problems (or, as > the text of the charter says, have different scopes of > applicability), it is fine to have more than one solution. > However, for a single problem, we only need a single > STD'ized solution. > > > And if you believe that for VPLS the goal should be a > single solution, > > then why wouldn't you insist to have the same goal for L3 > VPNs ? > > you forgot to add "and if you wouldn't insist on a single > solution for L3 VPNs, then why do you insist on this for L2 > VPNs" ;-) > > The reason is I don't want to restart the L3 VPN work in the > IETF and/or revisit the decisions that have been made in the > past, while I still see a reasonable opportunity to steer > the L2 VPN work. > > > Also, if you insist on a single solution, wouldn't that > > imply a single auto-discovery mechanism for VPLS ? > > This would definitely be my preference. > > Alex > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 16:19:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06962 for ; Tue, 6 May 2003 16:19:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46KLlv07819 for ; Tue, 6 May 2003 16:21:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46KLg802002 for ; Tue, 6 May 2003 16:21:43 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67E2@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: "Vasile Radoaca" , loa@pi.se Cc: zinin@psg.com, PPVPN@nortelnetworks.com, yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Tue, 6 May 2003 21:14:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3140C.16401E23" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: 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_01C3140C.16401E23 Content-Type: text/plain; charset="iso-8859-1" Agreed Vasile...I see common *server* layer problems (assuming a given server layer technology) being possible, but I see very different *client* layer problems. See my (far) larger posting to Alex for what is in my mind here. regards, Neil -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: 06 May 2003 18:15 To: 'Loa Andersson' Cc: Harrison,N,Neil,IKL2 R; zinin@psg.com; PPVPN@nortelnetworks.com; yakov@juniper.net Subject: RE: Single vs many solution(s) Loa, Did we identify clearly only one problem? I wish to have only one final solution - but what Alex doesn't show us how we can move toward such solution. What are the intermediate points to get to the final destination - and here I think we need to be little bit more inventive. Can we use intermediate "solutions/mechanisms" that are not fundamental in contradiction to converge toward a single solution? Cheers Vasile -----Original Message----- From: Loa Andersson [ mailto:loa@pi.se ] Sent: Tuesday, May 06, 2003 12:48 PM To: Radoaca, Vasile [BL60:X624:EXCH] Cc: 'neil.2.harrison@bt.com'; zinin@psg.com; PPVPN@nortelnetworks.com; yakov@juniper.net Subject: Re: Single vs many solution(s) Vasile, should we read this as you in principle want several solutions for the same problem? /Loa Vasile Radoaca wrote: > Neil/Alex > > You pointed out clearly mw own concern with Alex' model. > What Alex is proposing assumes > that most of work was done, and now we are in the > process of simple selecting a single "solution". > Also, his model assumes that once one solution is chosen > than the work is to perfect the solution - but > what is happen if we need to change something > fundamental - then solution A is still A or would become > B? And if B was part of initial proposals then what > would become B. > > Personal, I believe that talking of only solution at > this point in time is a just misunderstanding of the > current situation. If we want a solution to be chosen > just to proof that a VPLS can be implemented than > I am fine. > > Vasile > > > -----Original Message----- > From: neil.2.harrison@bt.com [ mailto:neil.2.harrison@bt.com ] > Sent: Tuesday, May 06, 2003 11:16 AM > To: Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com; > PPVPN@nortelnetworks.com > Cc: yakov@juniper.net > Subject: RE: Single vs many solution(s) > > Vasile/Alex, > > -----Original Message----- > From: Vasile Radoaca [ mailto:vasile@nortelnetworks.com ] > Sent: 06 May 2003 04:21 > To: 'Alex Zinin'; PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: RE: Single vs many solution(s) > > Alex, > > I think the ideal goal is to have only one solution, but such > ideal usual can be achieved if we are working in a pure > theoretical environment, without market considerations. In > reality the market is driving in most of the cases, > > NH=> Which 'market'? Is this (i) the Internet (big 'I') (ii) the > traditional operator (iii) the ISP (iv) the vendor market or > some other market? Speaking as an operator, we are not driving > this market and neither are our end customers. Our end > customers usually don't care how we implement our WANs....unless > we screw-up through ill-defined solutions. Their main concerns > are cost per bit and reliability/security. And my concerns are > therefore these plus getting architecturally clean solutions > that drive down my capex/opex.....but that might conflict with > the aims of those wanting shift boxes (who are IMO driving the > market) and perhaps some technology religion/dogma that is > creating bad architectures (which at some point will impact my > capex/opex downstream). > > > > and some assumptions made two years ago are not any more valid > - there are categories of SPs that pretty much have disappeared > from the map. > > NH=> Yes indeed. > > You stated very clear that a problem space needs to have a > single solution. I fully agree with you as a goal, but ut the > issue that we face right now is that the problem space is not > well concluded and well understood just purely from technical > considerations. > > NH=> I agree. I have problems with this 'single solution' > view *if* it based on some (G)MPLS/IP unified view of the > networking world. The fact is cnls, co pkt-sw and co cct-sw > modes are *all* needed and they require different functional > solutions.....this is actually at the root of most of the > current day problems/discussions. Ethernet is something else > again.....it simply does not have the right functional > attributes to scale/work in the WAN environment. There are some > things that are common to VPNs, but these relate to the setting > up/mtce of the *server* layer (lets say MPLS.....but it could be > other) and not the *client* layer distribution (of routing, if > appropriate) that lies above this. So IPoverMPLS is different > to arbitrary_L2overMPLS is different to EthernetoverMPLS at the > *client* level.....and these are all different (architecturally) > to X/IP cases of same at the *server* level (and some of which > we would deprecate....but that's our call as an operator on what > we regard as sensible or not client/server layer network > relationships). > > The L2 VPLS is a complex space with multiple dimensions, and > the vendors - in the last two years - have worked from > different angles, optimizing one or more dimension(s) of the > problem space (probable the downturn in the market it self, was > part of the problem). > > NH=> The *server* layer aspects are more simple IMO and these can > be unified (see my related posting). The difficult aspects > relate to client-layer distribution stuff above this . > > Without to contradict each other, most of the solutions are > closed in a specific dimension, based on some > objective/subjective parameters or experience and some criteria > of optimization. Moving in only one dimension doesn't scale it > self. > > > The fact we do have more than one solution, I think is a good > thing, and doesn't contradict that we can't move toward one > solution, if we are driving diligently, and willing to make > compromises. Taken such research value in consideration, would > be a positive sign that IETF is looking to create a solution > that would be valid for a while. Reading the mailing list, I > observed the same wise advise from most of the SPs, and this > reflect not a "problem" but a reality. > > NH=> I saw no good architectural rationale given for a vote from > any SPs........other than to say we have X so want to keep X for > all applications, without arguments to show why X is still > 'right'. The main technical arguments have been provided by > Eric, Yakov, etc who are not SPs....but this is largely at a > protocol level not the wider arch view. I have given some of my > views in the past as a traditional operator, looking to create a > sustainable/logical networking world in which cnls, co pkt-sw > and co cct-sw modes can all harmoniously co-exist. > > > Cheers > Vasile > > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, May 05, 2003 5:27 PM > To: PPVPN@nortelnetworks.com > Cc: Yakov Rekhter > Subject: Single vs many solution(s) > > > Yakov, > > [I took the liberty to change the subject line] > > >> I believe the goal for the WG should be to work out > >> a single solution. > > > That is certainly not in the charter. In fact the goal > > you stated above directly contradicts what is in the > charter: > > > Multiple approaches are being developed as each approach > > has particular characteristics and differing scope of > > applicability. > > Thanks for pointing out a possible contradiction. I don't think > it exists. > > My opinion (and I think it would be safe for me to say it is > consistent with that of the IESG) is that as long as different > solutions are solving different problems (or, as the text of the > charter says, have different scopes of applicability), it is > fine to have more than one solution. However, for a single > problem, we only need a single STD'ized solution. > > > And if you believe that for VPLS the goal should be a single > solution, > > then why wouldn't you insist to have the same goal for L3 > VPNs ? > > you forgot to add "and if you wouldn't insist on a single > solution for L3 VPNs, then why do you insist on this for L2 > VPNs" ;-) > > The reason is I don't want to restart the L3 VPN work in the > IETF and/or revisit the decisions that have been made in the > past, while I still see a reasonable opportunity to steer the L2 > VPN work. > > > Also, if you insist on a single solution, wouldn't that > > imply a single auto-discovery mechanism for VPLS ? > > This would definitely be my preference. > > Alex > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se ------_=_NextPart_001_01C3140C.16401E23 Content-Type: text/html; charset="iso-8859-1" RE: Single vs many solution(s)
Agreed Vasile...I see common *server* layer problems (assuming a given server layer technology) being possible, but I see very different *client* layer problems.  See my (far) larger posting to Alex for what is in my mind here.
 
regards, Neil
-----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: 06 May 2003 18:15
To: 'Loa Andersson'
Cc: Harrison,N,Neil,IKL2 R; zinin@psg.com; PPVPN@nortelnetworks.com; yakov@juniper.net
Subject: RE: Single vs many solution(s)

Loa,

 Did we identify clearly only one problem?
 
 I wish to have only one final solution - but what Alex doesn't show us how we can
 move toward such solution. What are the intermediate points to get to the final
 destination - and here I think we need to be little bit more inventive.
 Can we use intermediate "solutions/mechanisms" that are not fundamental in contradiction to
 converge toward a single solution?
 
 
Cheers
  Vasile

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Tuesday, May 06, 2003 12:48 PM
To: Radoaca, Vasile [BL60:X624:EXCH]
Cc: 'neil.2.harrison@bt.com'; zinin@psg.com; PPVPN@nortelnetworks.com; yakov@juniper.net
Subject: Re: Single vs many solution(s)


Vasile,

should we read this as you in principle want several solutions for the same problem?

/Loa

Vasile Radoaca wrote:
> Neil/Alex
> 
> You pointed out clearly mw own concern with Alex' model.
> What Alex is proposing assumes
> that most of work was done, and now we are in the
> process of simple selecting a single "solution".
> Also, his model assumes that once one solution is chosen
> than the work is to perfect the solution - but
> what is happen if we need to change something
> fundamental - then solution A is still A or would become
> B? And if B was part of initial proposals then what
> would become B.
> 
> Personal, I believe that talking of only solution at
> this point in time is a just misunderstanding of the
> current situation. If we want a solution to be chosen
> just to proof that a VPLS can be implemented than
> I am fine.
> 
>           Vasile   
>            
>
>     -----Original Message-----
>     From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
>     Sent: Tuesday, May 06, 2003 11:16 AM
>     To: Radoaca, Vasile [BL60:X624:EXCH]; zinin@psg.com;
>     PPVPN@nortelnetworks.com
>     Cc: yakov@juniper.net
>     Subject: RE: Single vs many solution(s)
>
>     Vasile/Alex,
>
>         -----Original Message-----
>         From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
>         Sent: 06 May 2003 04:21
>         To: 'Alex Zinin'; PPVPN@nortelnetworks.com
>         Cc: Yakov Rekhter
>         Subject: RE: Single vs many solution(s)
>
>         Alex,
>
>           I think the ideal goal is to have only one solution,  but such
>         ideal usual can be achieved if we are working in a pure
>         theoretical environment, without market considerations. In
>         reality the market is driving in most of the cases,
>
>         NH=>  Which 'market'?  Is this (i) the Internet (big 'I') (ii) the
>         traditional operator (iii) the ISP (iv) the vendor market or
>         some other market?  Speaking as an operator, we are not driving
>         this market and neither are our end customers.  Our end
>         customers usually don't care how we implement our WANs....unless
>         we screw-up through ill-defined solutions.  Their main concerns
>         are cost per bit and reliability/security.  And my concerns are
>         therefore these plus getting architecturally clean solutions
>         that drive down my capex/opex.....but that might conflict with
>         the aims of those wanting shift boxes (who are IMO driving the
>         market) and perhaps some technology religion/dogma that is
>         creating bad architectures (which at some point will impact my
>         capex/opex downstream).
>
>         
>
>           and some assumptions made two years ago are not any more valid
>         - there are categories of SPs that pretty much have disappeared
>         from the map.
>
>         NH=>  Yes indeed.
>
>           You stated very clear that a problem space needs to have a
>         single solution. I fully agree with you as a goal, but ut the
>         issue that we face right now is that the problem space is not
>         well concluded and well understood just purely from technical
>         considerations.
>
>         NH=>  I agree.  I have problems with this 'single solution'
>         view *if* it based on some (G)MPLS/IP unified view of the
>         networking world.  The fact is cnls, co pkt-sw and co cct-sw
>         modes are *all* needed and they require different functional
>         solutions.....this is actually at the root of most of the
>         current day problems/discussions.  Ethernet is something else
>         again.....it simply does not have the right functional
>         attributes to scale/work in the WAN environment.  There are some
>         things that are common to VPNs, but these relate to the setting
>         up/mtce of the *server* layer (lets say MPLS.....but it could be
>         other) and not the *client* layer distribution (of routing, if
>         appropriate) that lies above this.  So IPoverMPLS is different
>         to arbitrary_L2overMPLS is different to EthernetoverMPLS at the
>         *client* level.....and these are all different (architecturally)
>         to X/IP cases of same at the *server* level (and some of which
>         we would deprecate....but that's our call as an operator on what
>         we regard as sensible or not client/server layer network
>         relationships).
>
>          The L2 VPLS is a complex space with multiple dimensions, and
>         the vendors - in the last two years -  have worked from
>         different angles, optimizing one or more dimension(s) of the
>         problem space (probable the downturn in the market it self, was
>         part of the problem).
>
>         NH=>  The *server* layer aspects are more simple IMO and these can
>         be unified (see my related posting).  The difficult aspects
>         relate to client-layer distribution stuff above this .
>
>          Without to contradict each other, most of the solutions are
>         closed in a specific dimension, based on some
>         objective/subjective parameters or experience and some criteria
>         of optimization. Moving in only one dimension doesn't scale it
> self.
>
>
>          The fact we do have more than one solution, I think is a good
>         thing, and doesn't contradict that we can't move toward one
>         solution, if we are driving diligently, and willing to make
>         compromises. Taken such research value in consideration, would
>         be a positive sign that IETF is looking to create a solution
>         that would be valid for a while. Reading the mailing list, I
>         observed the same wise advise from most of the SPs, and this
>         reflect not a "problem" but a reality.
>
>         NH=>  I saw no good architectural rationale given for a vote from
>         any SPs........other than to say we have X so want to keep X for
>         all applications, without arguments to show why X is still
>         'right'.  The main technical arguments have been provided by
>         Eric, Yakov, etc who are not SPs....but this is largely at a
>         protocol level not the wider arch view.  I have given some of my
>         views in the past as a traditional operator, looking to create a
>         sustainable/logical networking world in which cnls, co pkt-sw
>         and co cct-sw modes can all harmoniously co-exist.
>
>
>         Cheers
>            Vasile
>         
>         -----Original Message-----
>         From: Alex Zinin [mailto:zinin@psg.com]
>         Sent: Monday, May 05, 2003 5:27 PM
>         To: PPVPN@nortelnetworks.com
>         Cc: Yakov Rekhter
>         Subject: Single vs many solution(s)
>
>
>         Yakov,
>
>         [I took the liberty to change the subject line]
>
>          >> I believe the goal for the WG should be to work out
>          >> a single solution.
>
>          > That is certainly not in the charter. In fact the goal
>          > you stated above directly contradicts what is in the
> charter:
>
>          >    Multiple approaches are being developed as each approach
>          >    has particular characteristics and differing scope of
>          > applicability.
>
>         Thanks for pointing out a possible contradiction. I don't think
>         it exists.
>
>         My opinion (and I think it would be safe for me to say it is
>         consistent with that of the IESG) is that as long as different
>         solutions are solving different problems (or, as the text of the
>         charter says, have different scopes of applicability), it is
>         fine to have more than one solution. However, for a single
>         problem, we only need a single STD'ized solution.
>
>          > And if you believe that for VPLS the goal should be a single
>         solution,
>          > then why wouldn't you insist to have the same goal for L3
> VPNs ?
>
>         you forgot to add "and if you wouldn't insist on a single
>         solution for L3 VPNs, then why do you insist on this for L2
>         VPNs" ;-)
>
>         The reason is I don't want to restart the L3 VPN work in the
>         IETF and/or revisit the decisions that have been made in the
>         past, while I still see a reasonable opportunity to steer the L2
>         VPN work.
>
>          > Also, if you insist on a single solution, wouldn't that
>          > imply a single auto-discovery mechanism for VPLS ?
>
>         This would definitely be my preference.
>
>         Alex
>
>


--
Loa Andersson

Mobile          +46 739 81 21 64
Email           loa@pi.se


------_=_NextPart_001_01C3140C.16401E23-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 16:32:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07457 for ; Tue, 6 May 2003 16:32:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46KZ3v12972 for ; Tue, 6 May 2003 16:35:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46KYxk17573 for ; Tue, 6 May 2003 16:34:59 -0400 (EDT) Message-ID: From: "Marco Carugi" To: Alex Zinin Cc: PPVPN , "'George Swallow'" Subject: PPVPN meeting time Date: Tue, 6 May 2003 22:26:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3140D.CCD3E9DA" X-LYRIS-Message-Id: 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_01C3140D.CCD3E9DA Content-Type: text/plain; charset="iso-8859-1" Alex, > > Alex Zinin wrote : > > Interesting that you mention this... I actually believe > > that if a WG consistently needs more than one meeting slot, Concerning San Francisco, the PPVPN slot was reduced from 2.5 to 2 hours at the last moment (at least another Sub-IP WG had a 2.5 hour slot with explicitly shorter agenda than the allocated time, but nobody supported my request to swap). > > it is a good sign of it having more on its plate than can efficiently deal with or > > poor management of the meeting time. It may be also sign of other positive factors, such as large interest from the community based on the discussed/progressed topics and documents, a feeling of involvement in the work progress and process by an unsually large and diversified number of people compared to the IETF WG average. > I thought the IESG was concerned about the overall number of > Workgroups. They are much easier to create than to shut down. So if > meeting twice per IETF for a short while until the work settles down > lets you have one less, seems like a good idea. > ...George Agree with George. It is clearly one concrete option for the next IETF meeting, if we would be allowed ... Marco ------_=_NextPart_001_01C3140D.CCD3E9DA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PPVPN meeting time

Alex,


> >  Alex Zinin wrote : 
> >  Interesting that you mention this... = I actually believe
> >  that if a WG consistently needs more = than one meeting slot,

Concerning San Francisco, the PPVPN slot was reduced = from
2.5 to 2 hours at the last moment (at least another = Sub-IP WG
had a 2.5 hour slot with explicitly shorter agenda = than the
allocated time, but nobody supported my request to = swap).

> >  it is a good sign of it having more = on its plate than can efficiently deal with or
> >  poor management of the meeting time. =

It may be also sign of other positive factors, such = as large interest
from the community based on the discussed/progressed = topics and documents,
a feeling of involvement in the work progress and = process by an unsually large and diversified number of people compared = to the IETF WG average.

> I thought the IESG was concerned about the = overall number of
> Workgroups.  They are much easier to = create than to shut down.  So if
> meeting twice per IETF for a short while until = the work settles down
> lets you have one less, seems like a good = idea.
> ...George
 
Agree with George. It is clearly one concrete option = for the next IETF meeting, if we would  be allowed ...

Marco

------_=_NextPart_001_01C3140D.CCD3E9DA-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 17:02:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08891 for ; Tue, 6 May 2003 17:02:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46L4xv12591 for ; Tue, 6 May 2003 17:04:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46L4qi01877 for ; Tue, 6 May 2003 17:04:53 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: "Nagarajan, Ananth [CC]" , Alex Zinin , ppvpn@nortelnetworks.com Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF Date: Tue, 6 May 2003 17:01:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31412.AB7B3A54" X-LYRIS-Message-Id: 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_01C31412.AB7B3A54 Content-Type: text/plain; charset="utf-8" Ananth, >If, in fact, the WG does split, then we also need to think about >what to do with a few documents such as the generic reqts draft, >that will be ready for IESG last call this week, that really is >an umbrella document for both L2 and L3 VPNs. Similarly, I think >we have the terminology draft too that we need to determine what to do with. The bgp auto-discovery draft covers as well both layer-3 and layer-2 vpns. But besides the "what to do with these common drafts question?", we need to ask ourselves why these drafts were created in the first place. For example isn't the generic requirement document covers common requirements for layer-2 and layer3 vpns. The simple existence of these drafts indicate that there is a belief within the wg that layer-2 and layer-3 vpns share something in common such as service attributes, topology, security, etc (documented in this draft). On that topic, if later on there are proposals that apply to both layer-2 and layer-3 vpns, where these proposals need to be captured, on what charter... One way or the other, the 'link', whatever that might be (protocols, service characteristics, etc), between layer-2 and layer-3 work needs to be taken into account and splitting the wg will somehow eliminate the need to explore this side of the vpn problem. Hamid. ------_=_NextPart_001_01C31412.AB7B3A54 Content-Type: text/html; charset="utf-8" RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF

Ananth,

>If, in fact, the WG does split, then we also need to think about
>what to do with a few documents such as the generic reqts draft,
>that will be ready for IESG last call this week, that really is
>an umbrella document for both L2 and L3 VPNs.  Similarly, I think
>we have the terminology draft too that we need to determine what to do with.

The bgp auto-discovery draft covers as well
both layer-3 and layer-2 vpns.

But besides the "what to do with these common drafts
question?", we need to ask ourselves why these drafts
were created in the first place. For example isn't
the generic requirement document covers common
requirements for layer-2 and layer3 vpns. The simple
existence of these drafts indicate that there is
a belief within the wg that layer-2 and layer-3 vpns
share something in common such as service attributes, topology,
security, etc (documented in this draft).

On that topic, if later on there are proposals that
apply to both layer-2 and layer-3 vpns, where these
proposals need to be captured, on what charter...
One way or the other, the 'link', whatever that might be
(protocols, service characteristics, etc), between layer-2
and layer-3 work needs to be taken into account and splitting
the wg will somehow eliminate the need to explore
this side of the vpn problem.

Hamid.

------_=_NextPart_001_01C31412.AB7B3A54-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 17:21:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09612 for ; Tue, 6 May 2003 17:21:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46LNev17346 for ; Tue, 6 May 2003 17:23:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46LNaX09995 for ; Tue, 6 May 2003 17:23:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PPVPN meeting time Date: Tue, 6 May 2003 16:20:54 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A70D9@KCCLUST06EVS1.ugd.att.com> Thread-Topic: PPVPN meeting time Thread-Index: AcMUDsyUYgE8hyj3RauId3kg7QPQQgAAUiKwAAAJjyA= From: "Ash, Gerald R (Jerry), ALABS" To: "Marco Carugi" , "Alex Zinin" , "George Swallow" Cc: "Ash, Gerald R (Jerry), ALABS" , "PPVPN" X-SMTP-HELO: almso2.proxy.att.com X-SMTP-MAIL-FROM: gash@att.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: almso2.att.com [192.128.166.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA09612 Alex> if a WG consistently needs more than one meeting slot, Alex> it is a good sign of it having more on its plate than Alex> can efficiently deal with or poor management of the Alex> meeting time. IMO PPVPN is one of the best-managed WGs, and as such the chairs have been able to manage a large work-load. I agree with Marco that there is a strong interest and much contribution to PPVPN. Finishing up some work (e.g., L3), and converging on other work, should reduce the load. It is not obvious that splitting the WG/load will speed things up, more likely to slow things down. George> meeting twice per IETF for a short while until the work George> settles down lets you have one less [WG], seems like a George> good idea. Marco> Agree with George. It is clearly one concrete option for Marco> the next IETF meeting, if we would be allowed. I also agree with George. There have been several concerns raised about the rather drastic change proposed, and comments re 'let's wait a bit longer'. As with the whole Sub-IP area, that would seem a good option at this point. Jerry From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 18:23:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12227 for ; Tue, 6 May 2003 18:23:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46MPUv07664 for ; Tue, 6 May 2003 18:25:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46MPR423685 for ; Tue, 6 May 2003 18:25:27 -0400 (EDT) Date: Tue, 6 May 2003 15:21:50 -0700 (PDT) Message-Id: <200305062221.h46MLon62163@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Ron Haberman" Cc: Subject: RE: Single vs many solution(s) In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A0DEF88@m-va-bsod03.add0.masergy.com> References: <6B25E083A064374CA3D2FAB305CFAF7A0DEF88@m-va-bsod03.add0.masergy.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ron Haberman writes: > Masergy Communications is an example for a company that actually IS > running all three VPNs. We are running L2 point to point for about > two years, 2547 for more than a year and are actually currently > running (currently as in not planning to, thinking about it, > evaluating) VPLS service for about a month and a half in our > production network. Ron, How would you rate the contribution of the ppvpn WG to the services that you are providing ? Are those solutions based on technology discussed in this WG ? The proposed reoganization is based on: "numerous concerns that the IESG members received from the WG participants about limited and slow progress within the WG despite the efforts of the WG chairs and its members." I assume that those concerns about "limited and slow progress" have been voiced mostly in private. To a more distant observer like myself it isn't easy to understand what those are and what constitutes a messure of "success" or "failure" of the WG efforts. I'm hoping that we can learn from whatever concerns exist with the current group in order for those issues not to reoccur with the new proposed structure. I would hope that people like yourself which are activly engaged in deploying the technology can point out the things this WG did correctly (if any) or wrongly. regards, Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 18:49:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13110 for ; Tue, 6 May 2003 18:49:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46Mq9v11879 for ; Tue, 6 May 2003 18:52:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46Mq6m02382 for ; Tue, 6 May 2003 18:52:07 -0400 (EDT) Message-ID: <3EB83BBD.D1246023@cisco.com> Date: Tue, 06 May 2003 15:48:29 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Muneyoshi Suzuki CC: mark@mseery.com, ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <20030430.184013.130229373.suzuki.muneyoshi@lab.ntt.co.jp> <20030430154647.72161.qmail@web13504.mail.yahoo.com> <20030501.183803.97286099.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, At least on these issues, :) we are in perfect agreement. -- Norm Muneyoshi Suzuki wrote: > > Anyway, in the following, how to process xSTP is discussed because > most interests relate on it. > > (1) The SP must ensure a single tree topology in the SP network. Manual > configuration, provider-STP, and provider-RSTP can support it without > any difficulties. In this process, the SP don't care customer-xSTP, > because it is the SP's responsibility to ensure a tree topology, thus it > is determined under the SP's policy and control. It is a quite unrealistic > scenario that the SP network topology is changed by the customer-xSTP. > > (2) It is customer responsibility to ensure a single tree topology in the > customer network which consists of customer sites interconnected by the > SP network and backdoor links. This is because, the customer can cause > a loop whether the SP forwards customer-xSTP transparently or the SP > provides per-customer xSTP instances. If the customer does no use > xSTP, there is a possibility to cause a loop. > > (3) If the SP forwards customer-xSTP transparently, and if the customer > use customer-xSTP, it can avoid a loop even if it pass through the SP > network. This is because, the SP ensures a single tree topology and a > single customer Bridge that supports customer-xSTP in a loop is sufficient > to detect and cut the loop. > > (4) However, it is highly desired to detect a customer loop in the SP > network. But, (a) detection is not limited xSTP, another technology > can also detect a loop, (b) provider core Bridges don't need to support > per-customer xSTP instances, because Provider Edge Bridges that support > pre-customer xSTP instances are sufficient to detect and cut the loop, > and (c) the full-mesh scheme also has completely the same issues. > > (5) And it is highly desired for the SP network to detect customer network > topology change and clear the cache for the customer, if the customer use > xSTP and is multihomed. In this case, provider Bridges need to snoop > customer-xSTP then forwards it transparently. However, both the xSTP based > SP network and full-mesh scheme have completely the same issues. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 18:52:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13182 for ; Tue, 6 May 2003 18:52:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46MtJv15429 for ; Tue, 6 May 2003 18:55:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46MtGm06418 for ; Tue, 6 May 2003 18:55:16 -0400 (EDT) Message-ID: <3EB83C72.93B5C21E@cisco.com> Date: Tue, 06 May 2003 15:51:30 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Cheng-Yin.Lee@alcatel.com CC: Muneyoshi Suzuki , jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <20030422.095728.07567803.suzuki.muneyoshi@lab.ntt.co.jp> <3EA95F59.AEC52332@cisco.com> <3EAEDA74.470FBB30@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ching-Yin, I have no objection at all to using something less than a full mesh where the topology used is known to match the underlying data flow. At the same time, I don't want to limit the solution offered by L2VPN to those cases. -- Norm Cheng-Yin Lee wrote: > > Norm, Muneyoshi, > Norman Finn wrote: > > > > Muneyoshi, > > > > If you use spanning tree among the pseudowires connecting Islands, > > as in: > > pw A > > island 1 --------------------- island 2 > > \ / > > pw B \_______ _________/ pw C > > \ / > > island 3 > > > > then one of pw A, pw B, or pw C must be blocked. Let's suppose it's > > pw C. Then, all traffic from island 2 to island 3 must be relayed > > by island 1. > > > > In other words, since wires are almost "free" in this space, one > > tends to have a lot of them. It the extreme case that you have a > > full mesh of connections among all the participants in a net, spanning > > tree is a particularly wasteful approach; it guarantees to block all > > but N of the N*(N-1)/2 pseudowires! (: Yes, a bridge-bigot is saying > > that spanning tree is not optimal for all interconnect plans. :) > If in the problem we are trying to solve, the islands are end customers > LAN, and the traffic are mostly flowing to/from one or few hubs to a > larger number of spokes, then there is no need to have a full-mesh of PW > (partial mesh is sufficient), and the case where traffic flow is not > optimal is infrequent then. > I think it's fine to solve 80% of the problem well and optimize for the > remaining 20%. A full-meshed with split-horizon seems to be optimized > for the minority of requirements, but not solving the majority of the > problem well (issues already being discussed and acknowledged on this > list). > > If the problem we are trying to solve is building very large LANs, then > I think it's worth considering Neil Harrison point that "There is a > massive difference in recognising the importance of ethernet as a key > CPE *interface* and then (somehow) making the (wrong) extrapolation that > this means ethernet is a great WAN technology." > > > If you configure a relatively sparse interconnect plan, using just > > a few pseudowires, and if those pseudowires approximate physical > > reality, then spanning tree becomes more viable. The scaling > > problem for 3000 VPLS instances at 10 pseudowires each becomes 3000 > > VPLS instances at 2-3 pseudowires each, reducing the BPDU load from > > 20,000 to 7,500. I would remark that our best bridges top out at > > somewhere on the order of 1,000 - 2,000 BPDUs per second, at this > > time. I need to think a bit more before I agree that this solution > > "simple and robust". > If we keep bridging to the furthest edge possible (e.g. in CLE or MTU if > need be), then the number of VPLS instances is drastically reduced. > > Perhaps until we agree on the problem we are trying to solve, it's hard > to scope VPLS problem space. > > Regards, > Cheng-Yin > > > > > -- Norm > > > > Muneyoshi Suzuki wrote: > > > > > > Joris, > > > > > > > My question is: how do you deal with (portions of) the network, for which a > > > > spanning tree would be a very inefficient forwarding means, because the > > > > physical topology does not approximate a tree? > > > > > > Could you clarify this? What is spanning tree in the above context? > > > 802.1D STP, or STP/RSTP/MSTP? > > > > > > If you are claiming STP topology change time is inefficient, the use of > > > RSTP/MSTP should be considered. > > > > > > If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify > > > the issues? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 18:59:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13343 for ; Tue, 6 May 2003 18:59:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46N1mU03225 for ; Tue, 6 May 2003 19:01:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46N1io17094 for ; Tue, 6 May 2003 19:01:44 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67E6@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: mark@mseery.com Cc: ppvpn@nortelnetworks.com, zinin@psg.com Subject: RE: FW: Single vs many solution(s) Date: Tue, 6 May 2003 23:58:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hi Mark.....in-line please. regards, Neil > Neil, > > >> NH: Operators need *all* 3 mode....<< > > Is there any publicly available information explaining > the rationale for this statement? Not disputing it, > just like to understand the details of the logic. NH=> This is actually an excellent question. My logic is based on what we sell, what customers want, and what makes sense architecturally to cover a diverse set of customer services (noting also the fact that MPLS (and even GMPLS) found it necessary to come into existence even in IETF). I am not aware of any studies supporting this view (or any other view).....just a 'proof by existence'. But I find it hard/impossible to imagine a networking world where all 3 modes would not find a logical application.....just like I find it hard to imagine a people/goods transport solution based only on trains. > > >> NH: Let's consider the VPN problem we are trying to > address using MPLS as the common co pkt-sw core server > layer technology and see if we can identify what is > common and what is not common. << > > When you say "we" I assume you mean BT. NH=> No I didn't here, I meant 'we' in the sense of 'the engineering community at large' > It is not > clear to me that is a generally accepted truth. > Forgetting about the IP option for a second, it would > seem that the very presence of PWE suggests another > server layer (as I think you have essentially stated). NH=> How many PWE3 switches are you aware of? This is a key point....networking entities that only exist at 2 points are more like 'end-end applications or sessions'. To qualify as a layer network implies (amongst other things, esp addressing) that we have nodal switching. PWE3 stuff is more of an adaptation function that has, unfortunately, started to take on the characteristics of a layer network without actually being one.....largely to proxy for missing/poor functional components of technologies that are proper layer networks. > > But more importantly, it is not clear that there is > consenus that LDP provides a co pkt-sw capability, in > fact I've seen many arguments to the contrary, > certainly within the MPLS WG; and I know at some level > you are yourself concerned that it does not, so seems > some consensus on this issue is required if we go down > the road of defining functional requirements. NH=> How much space do I have to answer this?......I will try and be brief. A co pkt-sw forwarding modes uses link-connection identifiers (aka labels, DLCI, VPI/VCI, etc) that only have the requirement of link uniqueness, cue FR, ATM, MPLS. Such link-connection identifiers only have any networking currency when associated with a parent trail entity......this is what connects together 2 disjoint globally addressable access points in a layer network. If the parent trail does not exist then the link-connection identifiers have no network currency....should be obvious I hope. So some form of signalling protocol is required to assign the link-connection inter-nodal identifiers and bind them to their parent trail (when that trail comes into existence, and remove when it is torn down). None of this is required in a cnls mode. Note this has nothing to do with routing protocols......both cnls and co pkt-sw (or even co cct-sw) modes may or may not use distributed routing protocols.....this means absolutely nothing wrt the networking mode, only the forwarding classification dictates the network mode. In terms of functional data-plane behaviour however, this means a cnls traffic pkt must contain both globally significant source and destination addresses (and as an aside it means each/every cnls pkt carries its own CV function). This is not true for a co pkt-sw mode (hopefully obvious)....so one can get defects arising in a co pkt-sw mode that simply cannot exist in a cnls mode, eg swaps, mismerging. Now a cnls mode has no a priori trail connectivity by definition. A co pkt-sw mode does however. If we 'merge' in a cnls mode it is not really merging at all but simply multiplexing as each/every pkt is uniquely identifiable in a 'merged' stream of such pkts by virtue of the SA/DA it carries. If we merge in a co pkt-sw mode then we lose sight of the source....and which is why BTW, in all applications of LDP mp2p there is always some level of LSP above this that identifies the *source* (the mp2p LSPs only identify the *destination*) to allow 'demerging'. So merging in a co pkt-sw mode is a bizarre topological thing to do. The native topologies that make sense (ie preserve source identification) in a co pkt-sw mode are p2p and p2mp. mp2p topologies in a co pkt-sw forwarding mode *demand* higher level demerging p2p constructs above them. However, this does not mitigate against all the problems the mp2p topologies create......such as their fault-management or the perceived need to run some form of ECMP over them if they just track an IGP based on SPF (a sort-of TE function). There are a whole list of problems that mp2p co pkt-sw constructs therefore create. Do you really want me to list them all? I don't see any real issue/argument here. We simply have to accept MPLS uses a co pkt-sw forwarding mode (because its just a fact) and that in such a mode the only topological constructs that make any sense are p2p and p2mp. Sure you can use mp2p.....you just pay for it in other ways. Can we put that one to bed now please? > > >> NH: 5. ethernet/VLANs. The client is ethernet with > or without VLAN identifiers. Client layer address > distribution is done directly in the client's > data-plane based on broadcasting/learning/aging. There > is no *forced* need for an operator to own this > problem.....all the ethernet/VLAN/bridging/etc > functionality can be done in the client layer and all > the operator doing is providing a simple MPLS VPN > (like ATM/FR today). << > > So I think I have argued one way or another that I am > concerned about putting too much Ethernet client stuff > in the network so keep that in mind as I make the > following comments. > > The problem with today's client/server model is that > the server layer is a point-to-point trail, NH=> This is not a 'problem' per se, in a co pkt-sw or a co cct-sw mode this a *fact*. If one wants a any-any cnls behaviour then use the right networking mode for this.....which is cnls/IP, don't fudge the co modes to do something IP does far better and arch correctly. > that means > if the operator wants to offer a switched service > based on the client payload, then the PDU has to be > popped out of the trail and switched by a different > piece of equipment, i.e. there is a difference between > a switched transport infrastructure and a switched > service. NH=> Not exactly sure what you mean here....but it sure read like 'terminate the server layer and switch the (payload) PDU in the right client layer which is appropriate to the mode in question'. > Seems to me that the unspoken aim of VPLS is > to avoid this. NH=> Agreed about the 'unspoken' bit.....so far at least, though we are asking the question 'why' should the SP (WA)network take on this role, in a technology that, although having the hallmarks of cnls (ie each PDU carries SA/DA pairs), does not have the 2 principle functional components to even contemplete WA(network) scaling, ie addresses that carry the semantic of 'where' (as opposed to 'who'...which is a name) and therefore no aggregation capability, and of course no routing capability. Is that not why the 'network layer' was invented in the 1st place? >Now should we intermingle the client > layer switching/briding solution together with the > server layer solution - this is where I see potential > for inter-standards body conflict and architectural > conerns. NH=> And that is precisely why I tried to suggest divorcing them, viz: there is a common (across all VPN types) *server* layer problem of topology discovery/construction, and a secondary problem that is client layer specific wrt 'information' (routing/addressing/reachability...call it what you will) distribution above this. > > Additionally, with point-to-point trails a mesh is > required. NH=> This is a red-herring and a source on continuous misinformation that keeps cropping up. If A wants to talk to B using a co mode then *something* has to be configured p2p between A and B in the *data-plane*.....you simply cannot avoid this. Automating the process is key however. > from the subscriber/access to inside the edge/core > network. This is one incremental step in the right > direction; and maybe an important first step to get to > market etc. NH=> For whom? Don't hear many customers screaming for us to build ethernet WANs....they ask for ethernet CPE interfaces yes. How we deliver across the WAN is not their concern. > Ultimately though, the option of having a > true multipoint server layer might be an interesting > option to pursue - if it can be managed etc. NH=> Not sure what you are looking for here....the right answer to your quest has, I think, already been defined....its a cnls mode called IP and it already does this. Just stop looking for an answer in a co mode....it does not exist. > What some > VPLS solutions are saying is that we have solved the > mesh problem by automating the provisioning - > excellent answer, and important. NH=> Agreed, but this is the automating of the basic VPN (any) *server* layer problem I previously mentioned. > But another way of > solving the problem would be to provide a multipoint > server layer. NH=> Please elborate. AFAIK this problem is solved for scalable WAN solutions...its called IP. > That would leave three options for > service providers to choose from: > > 1. point-to-point transport to a client layer > switching function NH=> We must be able to provide this one as the default. > 2. edge-to-edge mesh that emulates a client layer > switching function NH=> Not clear how this is different to the above case > 3. multi-point server layer NH=> This is cnls IP IMO. > > So then the question I would ask the WG, chairs, and > ADs is it acceptable to solve one problem along three > different (network)architectural paradigms, where you > have one solution per paradigm, or must we select one? > (we are of course looking like getting 1) and 2) > anyway so we will already have more than one); > > Why would we need both 2) and 3) well it may turn out > that solving QoS, traffic engineering, and management > problems are very complex to solve with 3) and > therefore 3) may give some charateristics which are > suitable for some service descriptions/operators but > not others. > > Mark > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 19:02:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13422 for ; Tue, 6 May 2003 19:02:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46N4VU06257 for ; Tue, 6 May 2003 19:04:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46N4Ro24934 for ; Tue, 6 May 2003 19:04:27 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67E5@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: mark@mseery.com Cc: ppvpn@nortelnetworks.com Subject: RE: Plug-and-play components (was FW: Single vs many solution(s)) Date: Tue, 6 May 2003 23:58:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hi Mark, > Neil, > > [clipped] > > >> As an operator I have a requirement to be able to > choose addressing, routing, signalling (for the 2 co > modes), OAM, etc functional components *independently* > (using best-of-breed selection criteria) both per > mode and within each mode.<< > > Not sure how this can be achieved in practice (under > current industry structure/system architectures). NH=> Easy....just find a vendor who recognises it! We did for L1 control-plane signalling and are now happily using PNNI (as we wanted). It a great signalling protocol...better than rsvp-te in our view. I know another large operator who has done exactly the same as we have (even bought from the same vendor) though is still trotting out the GMPLS stuff on the lists....quite bizarre. As I noted in an earlier mail....its not at all clear to me that those vocal on the IETF lists represent an operator's true internal position. > I > doubt it can be achieved by many startups NH=> vendors? operators? The issue here is running with the herd and being too afraid to to say what you really think. I have lots count of the private mails I have had agreeing with the stuff I have posted in the past and yet not feeling able to say so publically. I think there are some massive opportunties (playing to the trad operator markets) for vendors who can spot the key stuff and act on it. And the feedback I get from vendors I deal with is that we are some way ahead in our thinking as to what the real networking issues are and how best to tackle them. MPLS (esp) is a major opportunity waiting to happen. >- actually > any; unless I misunderstand your meaning. Perhaps you > could give some thoughts on how this could be achieved > in practice, but ultimately maybe this group can not > really tackle this issue and the IESG should take it > up in some way. Perhaps this is yet another reason for > an "architecture" function/WG/BOF in the IETF. NH=> I am not so pessimistic about the future. I think there is a great future *iff* we all can shake off our technology religions/prejudices and just accept there is a role for cnls, co pkt-sw and co cct-sw mode to live in harmony. The 'bad' stuff arises from those who don't have such open minds, and assume that stuff like the GMPLS peer-model makes any sense and that MPLS is the same as IP. This is just technology dogma at work. All 3 modes have a required future. > > Mark > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 19:08:58 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13558 for ; Tue, 6 May 2003 19:08:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46NBMU10374 for ; Tue, 6 May 2003 19:11:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46NBGo16576 for ; Tue, 6 May 2003 19:11:16 -0400 (EDT) Date: Tue, 6 May 2003 16:07:40 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@malt To: Pedro Roque Marques Cc: Ron Haberman , PPVPN@nortelnetworks.com Subject: Contribution of the PPVPN WG In-Reply-To: <200305062221.h46MLon62163@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: prattle.redback.com X-SMTP-MAIL-FROM: rahul@redback.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: prattle.redback.com [155.53.12.9] X-LYRIS-Message-Id: Hi Ron and Pedro, [Took the liberty of changing the subject line] Your mails bring out a very key question. The PPVPN WG has been in the business of developing L3 and L2 VPN technology that providers can deploy to offer these services. Do providers feel they are unable to deploy/offer L3 VPN service because of limitations with the WG ? Do providers feel they are unable to deploy/offer L2 VPN service because of limitations with the WG ? If the answer is yes, what are these limitations ? From a distance it seems that the business/economic case is more of a reason, if any, for any seemingly slow deployment. Or do vendors feel they are unable to develop this technology because of limitations with this WG ? My answer to this is no. Regards, rahul On Tue, 6 May 2003, Pedro Roque Marques wrote: > Ron Haberman writes: > > > Masergy Communications is an example for a company that actually IS > > running all three VPNs. We are running L2 point to point for about > > two years, 2547 for more than a year and are actually currently > > running (currently as in not planning to, thinking about it, > > evaluating) VPLS service for about a month and a half in our > > production network. > > Ron, > How would you rate the contribution of the ppvpn WG to the services > that you are providing ? Are those solutions based on technology > discussed in this WG ? > > The proposed reoganization is based on: > "numerous concerns that the IESG members received from the WG > participants about limited and slow progress within the WG despite the > efforts of the WG chairs and its members." > > I assume that those concerns about "limited and slow progress" have > been voiced mostly in private. To a more distant observer like myself > it isn't easy to understand what those are and what constitutes a > messure of "success" or "failure" of the WG efforts. > > I'm hoping that we can learn from whatever concerns exist with the > current group in order for those issues not to reoccur with the new > proposed structure. > > I would hope that people like yourself which are activly engaged in > deploying the technology can point out the things this WG did > correctly (if any) or wrongly. > > regards, > Pedro. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 19:15:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13678 for ; Tue, 6 May 2003 19:15:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h46NHkU15173 for ; Tue, 6 May 2003 19:17:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h46NHg522925 for ; Tue, 6 May 2003 19:17:42 -0400 (EDT) Message-ID: <20030506231426.72945.qmail@web13503.mail.yahoo.com> Date: Tue, 6 May 2003 16:14:26 -0700 (PDT) From: Mark Seery Subject: RE: Plug-and-play components (was FW: Single vs many solution(s)) To: neil.2.harrison@bt.com Cc: ppvpn@nortelnetworks.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D67E5@i2km07-ukbr.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13503.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13503.mail.yahoo.com [216.136.175.82] X-LYRIS-Message-Id: Hi Neil, Didn't mean to bring in to question your logic, just trying to suggest that not every vendor can support every possible combination, and that it may not be possible to create optimized solutions if a vendor indeed tried to. At some point the vendor has to know the specific solution an operator wants, build it, test it, deploy it, and fix it ;-) It could be argued an open systems approach to your desire could help you, where for example you could by the PNNI stack yourself and install it on the system, but no such model exists today, and CW is that such an approach is not practical. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 20:10:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14860 for ; Tue, 6 May 2003 20:10:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h470CxU05607 for ; Tue, 6 May 2003 20:13:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h470Cqv02709 for ; Tue, 6 May 2003 20:12:52 -0400 (EDT) Message-ID: <20030507000852.43735.qmail@web13502.mail.yahoo.com> Date: Tue, 6 May 2003 17:08:52 -0700 (PDT) From: Mark Seery Subject: RE: FW: Single vs many solution(s) To: neil.2.harrison@bt.com Cc: ppvpn@nortelnetworks.com, zinin@psg.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D67E6@i2km07-ukbr.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13502.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13502.mail.yahoo.com [216.136.175.81] X-LYRIS-Message-Id: Thanks Neil, Is MPLS co-pkt-sw or CNLS? ========================== I won't take up space arguing this, my only point was that I had not observed consensus, your good points not withstanding. Perhaps I missed the consensus. Multi-point co-pkt-sw ===================== So I read from your reply that you believe, for reasons stated, that a multipoint co-pkt-sw mode does not exist, and would not be valid to exist. BTW, what is your view on IP multicast. Is this a different mode than normal IP CLNS, or is this the same? P2P as misinformation ===================== So you don't agree that HVPLS et el have moved the mesh from the CPE in to the network? Or just that no subscriber cares? Why do subscribers care? Well I will concede it may be an artifact of business models (per-vc pricing). Though touching each CPE everytime a new site is added does create potential for error, and may actually concern a subscriber - as opposed to an automated model by whatever means. I'll also grant that some operators have automated the process via management plane, but some have not, and may prefer not to. I will also grant that the tradeoff for when to use control plane vs management plane is sometimes viewed in the context of the time the circuit is alive for - but not really wanting to go off on that particular tangent. But the working assumption is that there is a problem to be solved; that much I can observe whether I agree or not. The value of Ethernet WANs ========================== To argue that there is no value in switched Ethernet WAN/MAN services is essentially to argue that this WG has no reason to exist - I think? I'm not sure I want to pursue this line of discussion, on this mailing list ;-) As to whether Ethernet lacks the capability to scale as a WAN technology, this seems also to be an unspoken assumption of this WG. The support for various VPLS proposals would suggest that in the minds of a number of people those problems are being addressed. I agree with you as to the importance of Ethernet as a subscriber interface. I agree Ethernet WAN services can be offered in multiple ways preserving investment in existing technology or leveraging investment in new technology. But at the end of the day, the charter of this particular WG is to solve the problem using a bounded set of technologies - which is why the discussion may be narrower than what you would like; I certainly engage in broader technology discussions when interacting with carriers, as I am sure many do on this list, but do want to respect the mission of this standards group, and this WG. Some other responses to clips below. Thanks again for the substantive responses. Regards, Mark >> NH=> How many PWE3 switches are you aware of? This is a key point....networking entities that only exist at 2 points are more like 'end-end applications or sessions'. << Interesting point, and one well worth thinking about, I would only observe, that VPLS is not an actual switch - it is a distributed, emulated switch, based on p2p connections; which is at some very abstract level, just an explosion of what happens inside many systems (where the "server" layer is managed by a fabric header). >> NH=> Not exactly sure what you mean here....but it sure read like 'terminate the server layer and switch the (payload) PDU in the right client layer which is appropriate to the mode in question'. << Well apart from the value judgement ;-) yes, that is what I said - I only tease here because there is a valid discussion to be had about home many transport layers one network needs - but let's not go there. So popping out to a client layer is a valid way of solving the problem, VPLS is suggesting there is another way; the unspoken assumption that the VPLS way also allows for the delivery of other services on the same "switching" network. Which would naturally lead to a discussion of pros/cons/tradeoffs/economics/feasibility (in the case of Ethernet) that is perhaps beyond the scope of the WG. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 20:15:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15030 for ; Tue, 6 May 2003 20:15:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h470HbU09162 for ; Tue, 6 May 2003 20:17:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h470HYN08065 for ; Tue, 6 May 2003 20:17:34 -0400 (EDT) Message-ID: <3EB84FB5.8630E288@cisco.com> Date: Tue, 06 May 2003 17:13:41 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Muneyoshi Suzuki , Mick Seaman , Tony Jeffree , Les Bell , Paul Congdon , Neil Jarvis CC: ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <3EA08E50.7011B94@cisco.com> <20030421.134800.63057419.suzuki.muneyoshi@lab.ntt.co.jp> <3EA95C0A.3077599@cisco.com> <20030430.171312.41636959.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 6 20:31:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15444 for ; Tue, 6 May 2003 20:31:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h470YFU13209 for ; Tue, 6 May 2003 20:34:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h470YAd19316 for ; Tue, 6 May 2003 20:34:11 -0400 (EDT) Date: Tue, 6 May 2003 17:31:47 -0700 (PDT) Message-Id: <200305070031.h470VlI62530@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: neil.2.harrison@bt.com Cc: ppvpn@nortelnetworks.com Subject: clns vs co as underlying model for VPN services X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Neil, You bring up a set of very interesting questions. I confess i've a fair ammount of dificulty following your terminology so it is likely that i'm misinterpreting what you are saying. If i understand what you are saying, you suggest that one of the first things to keep in mind in designing a VPN service is that it basically consists of a co pkt-sw service. It seems to me that while that is one possible model it is not the only possible model and that a comparisson is worthwhile. So what is the clns model for VPNs ? (I believe most people understand better than myself so the following is mostly to validate my assumptions). Consider a network that contains core only nodes (P-nodes) and edge nodes (PE-nodes). PE-nodes have the capability to allocate a forwarding equivalence class (FEC) indentifier (for lack of better term). This FEC identifies the forwaring nexthop of the traffic on this node. FEC-IDs are the equivalent of 'destination addresses' on IP packets as far as forwarding is concerned. As Neil mentions these are effectivly mp2p identifiers. P-nodes on the other hand do not know anything about this service specific FECs. Their concern is to provide forwarding services to PEs. This services can be p2p, p2mp or mp2p (merging is typically used). So why do this ? It is all the nice properties that Neil dislikes :-) The core network (P-nodes) deals only w/ aggregated flows. This flows can be p2p (eg: rsvp-te), mp2p (via merging either by LDP or inter-as BGP MPLS signaling) and hopefully in the future they will be p2mp also. The idea being that using aggregated flows you can control your traffic as you see fit and then appropriatly map service-FECs to these aggregated flows. So what is the advantage w/ the service FECs being mp2p. When your service definition does not require you to identify the source, using mp2p FEC(labels) allows you to allocate 1 inner label that identifies the forwarding nexthop regardless of the ingress. When your service definition requires you to identify the source, then you must allocate N mp2p labels in order to achieve a 1-to-1 mapping. But using the same architectural pieces you can express both models (source and no source identification). And do so while optimizing it for the worse case in terms of state. Also you can decouple the service-FEC from the PE-PE transit layer. The latter is imho one of the key pieces missing at this point. It would be nice to be able to map N services into M tunnel technologies without using N*M mechanisms. That requires layering and a definition of what your interfaces should be. Note that there are also services which i would classify as L2 which don't require source identification and are effectivly mp2p. The example i have in mind is when a SP provides a carrier-of-carriers service to its customers in which the 'routes' are limited to /32s representing remote attachement points. This can effectivly be used to provide a service that can run on top of any media and that provides an mp2p LSP to any other customer attachement point to the VPN. For people running clns traffic on top, mp2p is a good service model. Maybe the rest of the WG members can correct my misunderstandings and mischaracterizations. And maybe the folks that are more knowledgeble of co mechanisms can explain in what way that model is superior. Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 00:14:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19903 for ; Wed, 7 May 2003 00:14:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h474HNY13351 for ; Wed, 7 May 2003 00:17:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h474HJ924295 for ; Wed, 7 May 2003 00:17:19 -0400 (EDT) Reply-To: From: "Mick Seaman" To: "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" Cc: , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Tue, 6 May 2003 21:15:54 -0700 Message-ID: <006d01c3144f$5e952370$210110ac@corp.telseon.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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3EB84FB5.8630E288@cisco.com> X-SMTP-HELO: pimout1-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout1-ext.prodigy.net [207.115.63.77] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit In as much as I will ever wholly agree with Norm, I do so now. Mick -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, May 06, 2003 5:14 PM To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 00:50:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20507 for ; Wed, 7 May 2003 00:50:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h474r4Y18008 for ; Wed, 7 May 2003 00:53:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h474r1i03427 for ; Wed, 7 May 2003 00:53:01 -0400 (EDT) Date: Wed, 07 May 2003 13:51:34 +0900 (JST) Message-Id: <20030507.135134.59463278.suzuki.muneyoshi@lab.ntt.co.jp> To: nfinn@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <3EB83BBD.D1246023@cisco.com> References: <20030430154647.72161.qmail@web13504.mail.yahoo.com> <20030501.183803.97286099.suzuki.muneyoshi@lab.ntt.co.jp> <3EB83BBD.D1246023@cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Norm, > At least on these issues, :) we are in perfect agreement. Good. :-) BTW, it seems to me, we are leaved behind from the WG. There are little interest in the most important technical issues. ;-) Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 11:52:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06428 for ; Wed, 7 May 2003 11:52:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47FssY21560 for ; Wed, 7 May 2003 11:54:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47FsoJ06214 for ; Wed, 7 May 2003 11:54:50 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Subject: RE: vpls scaling question Date: Wed, 7 May 2003 11:20:59 -0400 Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C3148A.BD2A1540" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp2g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp2g.bellsouth.com [139.76.165.197] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C3148A.BD2A1540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit to clarify the INTRA- AS vpls case I would like to better understand the expected capabilities of INTRA-AS vpls vs a network of Ethernet switches. What is the scaling objective for vpls ? Current generation Ethernet switches have evolved from the 4096 VLAN/network to 4096 VLAN/port. Scale limits on SP Ethernet networks are typically driven by other factors e.g. MAC address table size, issues with multicast etc. Is vpls intended to tackle any of those scale constraints ? or to put it another way... Current Ethernet switch networks can support on the order of 10,000 VLAN service instances. Will vpls enable scaling to the 10,000,000 or so service instances/AS necessary to enable Ethernet as a residential service ? -----Original Message----- From: Steven.Wright [mailto:steven.wright@bellsouth.com] Sent: Wednesday, April 23, 2003 5:04 PM To: Subject: vpls scaling question vpls is proposed as a mechanism to enable large-scale Ethernet networks. Can anyone quantify for me at what stage flat Ethernet networks break and vpls is required ? i.e what should the decision criteria be to convert an Ethernet network to a vpls network ? Steven Wright BellSouth ------=_NextPart_000_0000_01C3148A.BD2A1540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
to=20 clarify the INTRA- AS vpls case
I = would like to=20 better understand the expected capabilities of  INTRA-AS vpls vs a = network=20 of Ethernet switches.
 
What=20 is the scaling objective for vpls ?
Current generation Ethernet switches have evolved from the 4096 = VLAN/network to 4096 VLAN/port. Scale limits on  SP Ethernet = networks are=20 typically driven by other factors e.g. MAC address table size, issues = with=20 multicast etc.
 
Is=20 vpls intended to tackle any of those scale constraints ? or to put it = another=20 way...
Current Ethernet switch networks can support on the order of = 10,000 VLAN=20 service instances.  Will vpls enable scaling to the 10,000,000 or = so=20 service instances/AS necessary to enable Ethernet as a residential = service=20 ?
 
 
 
 
-----Original Message-----
From: Steven.Wright=20 [mailto:steven.wright@bellsouth.com]
Sent: Wednesday, April = 23, 2003=20 5:04 PM
To: Subject: vpls scaling=20 question

vpls = is proposed=20 as a mechanism to enable large-scale Ethernet = networks.
Can = anyone=20 quantify for me at what stage flat Ethernet networks break and vpls is = required ?
i.e = what should=20 the decision criteria be to convert an Ethernet network to a vpls = network=20 ?
Steven=20 Wright
BellSouth
------=_NextPart_000_0000_01C3148A.BD2A1540-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 12:05:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06831 for ; Wed, 7 May 2003 12:05:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47G8MY18932 for ; Wed, 7 May 2003 12:08:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47G8Hb08763 for ; Wed, 7 May 2003 12:08:18 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67E9@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: mark@mseery.com Cc: ppvpn@nortelnetworks.com, zinin@psg.com Subject: RE: FW: Single vs many solution(s) Date: Wed, 7 May 2003 09:00:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hi Mark, please see in-line. regards, Neil BTW - Going to be rather busy now for next week or so.....so if any further questions to me on mail may not get an answer. > > Thanks Neil, > > Is MPLS co-pkt-sw or CNLS? > ========================== > > I won't take up space arguing this, my only point was > that I had not observed consensus, your good points > not withstanding. Perhaps I missed the consensus. NH=> You won't get it.....its not PC to say this here in IETF. It's got nothing to do with the use or not of a distributed routing protocol (atm/pnni can use this, for example), and all to do with the forwarding mode behaviour.....and MPLS (any variety of such) is quite distinct to IP's behaviour here. I've seen/had some minor players try and argue its not true (trying to deflect/defend the problems created by LDP mp2p) but not the major players. Arguing this just wastes time/energy. Maybe the SDH and OTN (GMPLS) data-plane also has cnls forwarding behaviour too ;-). > > Multi-point co-pkt-sw > ===================== > > So I read from your reply that you believe, for > reasons stated, that a multipoint co-pkt-sw mode does > not exist, and would not be valid to exist. NH=> It can exist (and does), but my point is that it creates problems in other dimensions....and in my view the problems outweigh any advantages. If one wants any-any connectivity a cnls mode (ie IP) is the right (WA)networking solution (as this does not have the data-plane problems). Merging using link-connection-only unique identifiers is not a 'good thing' to do from a trite architectural analysis.....you lose sight of the source, so if you use a mp2p mode you are forced to also run something p2p over this to provide the source information. If people started to use the functional models of G.805 this fact would become very obvious. > > BTW, what is your view on IP multicast. Is this a > different mode than normal IP CLNS, or is this the > same? NH=> Don't confuse mp2p *merging* and p2mp broad/multi-cast....these are *not* the same thing architecturally. Note that there is no such thing as mp2p/merging in a cnls mode......this is multiplexing as the source/destination are identifiable in any 'merged' stream of cnls pkts. A p2mp topology is valid in a cnls, co pkt-sw mode and a co cct-sw mode. The source is constant/identifiable in the co modes and the only difference is single vs multiple target locations. Again, modelling using G.805 would reveal the behaviour/validity. > > P2P as misinformation > ===================== > > So you don't agree that HVPLS et el have moved the > mesh from the CPE in to the network? Or just that no > subscriber cares? NH=> I would not say it like this. What is happening is that the bridging functionality is being moved into the WAN, and one is asking/expecting the SP to somehow (yet to be figured) use this functionality (in some shared way) to advantage. We are not, as yet, convinced this is a Good Thing. > > Why do subscribers care? Well I will concede it may be > an artifact of business models (per-vc pricing). NH=> I don't believe customers care how *we* provide their ethernet services.....and esp whether we build based WANs based on ethernet/VLANs. Customers mainly care about $/bit and reliabilty/security.....and they only care about QoS issues when they suffer unacceptable performance (in general they expect things to 'work' at reducing prices). Our job as a SP (and my job specifically) is to make sure we deliver these aspects at min opex/capex cost. They have an ethernet interface on their CPE and want to use it. How we deliver the traffic from customer site A to customer site B is our problem. If it can be shown that building ethernet based WANs and using VLAN technology offers us some advanatges (esp cost) then great....but so far we are not convinced. So I don't believe it is customers who are driving this view but (i) those wishing to sell boxes and (ii) those who 'believe' this is the right solution from some philosophical standpoint. From a pure architectural perspective, ethernet as-is is simply not designed to scale/work in the WAN environment.......that is just a fact. If it can made to work satisfactorily then fine.....but as I say we have yet to be convinced. > Though touching each CPE everytime a new site is added > does create potential for error, and may actually > concern a subscriber - as opposed to an automated > model by whatever means. I'll also grant that some > operators have automated the process via management > plane, but some have not, and may prefer not to. I > will also grant that the tradeoff for when to use > control plane vs management plane is sometimes viewed > in the context of the time the circuit is alive for - > but not really wanting to go off on that particular > tangent. > > But the working assumption is that there is a problem > to be solved; that much I can observe whether I agree > or not. NH=> Its too early to make a call on this in our opinion. In the meantime we will use other means to deliver ethernet *interfaced* services. > > The value of Ethernet WANs > ========================== > > To argue that there is no value in switched Ethernet > WAN/MAN services is essentially to argue that this WG > has no reason to exist - I think? I'm not sure I want > to pursue this line of discussion, on this mailing > list ;-) > > As to whether Ethernet lacks the capability to scale > as a WAN technology, this seems also to be an unspoken > assumption of this WG. The support for various VPLS > proposals would suggest that in the minds of a number > of people those problems are being addressed. NH=> Then let's wait and see what emerges. > > I agree with you as to the importance of Ethernet as a > subscriber interface. I agree Ethernet WAN services > can be offered in multiple ways preserving investment > in existing technology or leveraging investment in new > technology. But at the end of the day, the charter of > this particular WG is to solve the problem using a > bounded set of technologies - which is why the > discussion may be narrower than what you would like; I > certainly engage in broader technology discussions > when interacting with carriers, as I am sure many do > on this list, but do want to respect the mission of > this standards group, and this WG. NH=> That's fine. However, taking such a stance is hardly in the best interests of the customer and the wider operator community....all solutions should be considered without prejudice. > > Some other responses to clips below. > > Thanks again for the substantive responses. > Regards, > Mark > > >> NH=> How many PWE3 switches are you aware of? This > is a key point....networking entities that only exist > at 2 points are more like 'end-end applications or > sessions'. << > > Interesting point, and one well worth thinking about, > I would only observe, that VPLS is not an actual > switch - it is a distributed, emulated switch, based > on p2p connections; which is at some very abstract > level, just an explosion of what happens inside many > systems (where the "server" layer is managed by a > fabric header). NH=> If one started to use G.805 arch models to describe/define the networks being discussed (rather than just lines/boxes) much of the issues would become obvious. BTW I was talking specifically about the PW entities that are being created, not the 'higher' client layer implications that in the VPLS case you raise and are related to ethernet behaviours. > > >> NH=> Not exactly sure what you mean here....but it > sure read like 'terminate the server layer and switch > the (payload) PDU in the right client layer which is > appropriate to the mode in question'. << > > Well apart from the value judgement ;-) yes, that is > what I said - I only tease here because there is a > valid discussion to be had about home many transport > layers one network needs - but let's not go there. NH=> Why not? It's important. I want to see the number of nested network layers we have to manage reduced to a minimum......there are many reasons for this (hopefully most are obvious). However, this statement is *not* the same as saying we can functionally crunch the cnls/co pkt-sw/co cct-sw into some God-Box.....that approach is both technically flawed and commercially flawed. PWE3 is creating more things that can go wrong and need to be managed....much of this is unnecessary, and being done to fix problems created in (MPLS) server layer networks and the irrational view that X/IP must 'be the same' as X/MPLS. > > So popping out to a client layer is a valid way of > solving the problem, VPLS is suggesting there is > another way; the unspoken assumption that the VPLS way > also allows for the delivery of other services on the > same "switching" network. Which would naturally lead > to a discussion of > pros/cons/tradeoffs/economics/feasibility (in the case > of Ethernet) that is perhaps beyond the scope of the > WG. > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 12:19:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07275 for ; Wed, 7 May 2003 12:19:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47GMHY26156 for ; Wed, 7 May 2003 12:22:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47GMCB18327 for ; Wed, 7 May 2003 12:22:13 -0400 (EDT) Reply-To: From: "Steven.Wright" To: , Subject: RE: ppvpn effort support Date: Wed, 7 May 2003 10:54:25 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200304241720.h3OHK9lY012002@rtp-core-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp2g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp2g.bellsouth.com [139.76.165.197] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, April 24, 2003 1:20 PM > To: steven.wright@bellsouth.com > Cc: ppvpn@nortelnetworks.com > Subject: Re: ppvpn effort support > > > > Steven> while the hierarchical concepts of draft lasserre > are important, I > Steven> expect these notions of hierarchy will be > associated with > Steven> administrative boundaries. Administrative > boundaries also imply > Steven> administrative policy and BGP is the accepted > tool for managing > Steven> this. > > I wonder if you could be more specific about this, perhaps > an example of > inter-AS L2VPN service where you want to set up policies > at the inter-AS > border. I'd like to understand better the degree to > which the policy > management is dependent on the underlying signaling protocol. > Consider the security aspects in an inter-AS case. Current administrative policy restricts inter-AS control plane interactions to those between BGP peers. It would take a significant effort to change this security policy to permit signaling (using another protocol no less!) from outside my AS to an arbitrary router within my AS. Service architectures need to fit within the constraints of administrative security policies. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 12:24:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07485 for ; Wed, 7 May 2003 12:24:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47GQiY00087 for ; Wed, 7 May 2003 12:26:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47GQbB00660 for ; Wed, 7 May 2003 12:26:37 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D67E8@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: roque@juniper.net Cc: ppvpn@nortelnetworks.com Subject: RE: clns vs co as underlying model for VPN services Date: Wed, 7 May 2003 09:00:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: > > > Neil, > You bring up a set of very interesting questions. I confess i've a > fair ammount of dificulty following your terminology so it is likely > that i'm misinterpreting what you are saying. NH=> Reading what you wrote I'd say 'yes' we have a communication issue.....so rather than sending lots of mail and going over old ground on this I'll send you my TEl No in a separate mail and we can discuss off-line. regards, Neil From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 12:28:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07547 for ; Wed, 7 May 2003 12:28:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47GV3Y03514 for ; Wed, 7 May 2003 12:31:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47GUx911094 for ; Wed, 7 May 2003 12:31:00 -0400 (EDT) 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: Comments on the L2 VPN framework and solutions documents Date: Wed, 7 May 2003 09:01:13 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB720215005A@WHISTLER.WaveSmithNet.com> Thread-Topic: Comments on the L2 VPN framework and solutions documents Thread-Index: AcMULiEIz6DUmnBrSoKMAwq9R5eHqAAabsXA From: "Himanshu Shah" To: "Norman Finn" , "Muneyoshi Suzuki" , "Mick Seaman" , "Tony Jeffree" , "Les Bell" , "Paul Congdon" , "Neil Jarvis" Cc: , X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07547 Norm, You have to excuse me for jumping in at the tail end and not following the thread. I would like a clarification. Are you implying that 802.1ad is contemplating on running one or more (Provider's) instances of R/M/STP on fully-meshed pseudowires? /himanshu Wavesmith Networks -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, May 06, 2003 8:14 PM To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 12:31:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07644 for ; Wed, 7 May 2003 12:31:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47GXvY06276 for ; Wed, 7 May 2003 12:33:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47GXq914949 for ; Wed, 7 May 2003 12:33:52 -0400 (EDT) Content-Class: urn:content-classes:message Subject: RE: Contribution of the PPVPN WG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 2003 10:11:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A0DEF8A@m-va-bsod03.add0.masergy.com> Thread-Topic: Contribution of the PPVPN WG thread-index: AcMUJEyjcpIv04BDSsGV8ndpvKnQlAAenu5A From: "Ron Haberman" To: "Rahul Aggarwal" , "Pedro Roque Marques" Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: ronh@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07644 Rahul, Inline... > -----Original Message----- > From: Rahul Aggarwal [mailto:rahul@redback.com] > Sent: Tuesday, May 06, 2003 7:08 PM > To: Pedro Roque Marques > Cc: Ron Haberman; PPVPN@nortelnetworks.com > Subject: Contribution of the PPVPN WG > > > > Hi Ron and Pedro, > > [Took the liberty of changing the subject line] > > Your mails bring out a very key question. The PPVPN WG has > been in the business of developing L3 and L2 VPN technology > that providers can deploy to offer these services. > > Do providers feel they are unable to deploy/offer L3 VPN > service because of limitations with the WG ? RH> I don't. I have all the technology pieces that I need at this point to offer the service. Could there be improvements? Yes. Would I feel differently if my company had a policy of not adopting technologies before the standard? Probably yes... (I really hope that other SP have that policy) > > Do providers feel they are unable to deploy/offer L2 VPN > service because of limitations with the WG ? RH> Not at this point. I think the two (LDP, BGP) solutions are available and ready. At least to the point of my own satisfaction with results of testing them in my lab. I have my opinion and was able to convince enough people at my company to choose one. If at any point either I will feel differently (because of the market, improvements to the other solution, etc) I will go through the usual "dealing with the vendor" to accommodate the change. There is no visible difference to my customer, which is the most important thing to me as a SP. That allows me to pick the best solution according to how the it affects my backbone: efficient use of protocols, easy of configuration, easy of change and integration of the new service with companies product line. > > If the answer is yes, what are these limitations ? From a > distance it seems that the business/economic case is more of > a reason, if any, for any seemingly slow deployment. > > Or do vendors feel they are unable to develop this technology > because of limitations with this WG ? > My answer to this is no. > > Regards, > rahul > > > On Tue, 6 May 2003, Pedro Roque Marques wrote: > > > Ron Haberman writes: > > > > > Masergy Communications is an example for a company that > actually IS > > > running all three VPNs. We are running L2 point to point > for about > > > two years, 2547 for more than a year and are actually currently > > > running (currently as in not planning to, thinking about it, > > > evaluating) VPLS service for about a month and a half in our > > > production network. > > > > Ron, > > How would you rate the contribution of the ppvpn WG to the services > > that you are providing ? Are those solutions based on technology > > discussed in this WG ? > > > > The proposed reoganization is based on: > > "numerous concerns that the IESG members received from the WG > > participants about limited and slow progress within the > WG despite the > > efforts of the WG chairs and its members." > > > > I assume that those concerns about "limited and slow progress" have > > been voiced mostly in private. To a more distant observer > like myself > > it isn't easy to understand what those are and what constitutes a > > messure of "success" or "failure" of the WG efforts. > > > > I'm hoping that we can learn from whatever concerns exist with the > > current group in order for those issues not to reoccur with the new > > proposed structure. > > > > I would hope that people like yourself which are activly engaged in > > deploying the technology can point out the things this WG did > > correctly (if any) or wrongly. > > > > regards, > > Pedro. > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 12:41:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07795 for ; Wed, 7 May 2003 12:41:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47GiJY09169 for ; Wed, 7 May 2003 12:44:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47GiF928366 for ; Wed, 7 May 2003 12:44:15 -0400 (EDT) Message-ID: <20030507145134.77802.qmail@web13503.mail.yahoo.com> Date: Wed, 7 May 2003 07:51:34 -0700 (PDT) From: Mark Seery Subject: RE: FW: Single vs many solution(s) To: neil.2.harrison@bt.com Cc: ppvpn@nortelnetworks.com, zinin@psg.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D67E9@i2km07-ukbr.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13503.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13503.mail.yahoo.com [216.136.175.82] X-LYRIS-Message-Id: Neil, >> NH: BTW - Going to be rather busy now for next week or so.....so if any further questions to me on mail may not get an answer. << Understood. You have been generous with your comments already - so good luck with whatever it is that keeps you busy. >> NH: ....you lose sight of the source, so if you use a mp2p mode you are forced to also run something p2p over this.. << Fair enough. I'll do some more thinking about whether I conclude PWE is another connection or just an encapsulation [no need to respond] >> NH=> That's fine. However, taking such a stance is hardly in the best interests of the customer and the wider operator community....all solutions should be considered without prejudice. << I will give your advise some more thought. In response I would simply observe the charter: ".....while using IP-based mechanisms in the provider infrastructure to improve scalability and configurability over traditional L2 networks)." I don't think you can totally avoid being contextual. While you are contributing to a WG you kind of have to have some respect for the rules that have been agreed to. You can always take that hat off, step outside of the WG (as ADs often do) - indeed the IETF (in private emails, of public comments in other forums), and make another set of observations and comments. >> NH=> Why not? It's important. I want to see the number of nested network layers we have to manage reduced to a minimum. << My response was very badly worded. What I meant to communicate is that as a non-operator, you come to see so many different networks, vary amounts of "legacy", organizational structures, strategic initiatives, etc....that at some point you begin to feel that it is really arrogant to say that one approach meets everyones needs - maybe it is just an illusion, but things do seem to be different from operator to operator. As I said in another post, I can see how a selection of p2p, automated mesh, and multipoint (we can argue about which type) server layers might enable a broad range of operators to meet their needs. At the end of the day the pragmatic issues of the boxes people have, the boxes they could have, and how well they work together and cost, tend to have a large influence on decisions. Would it be nice if sometimes we slowed down and considered the long-term implications of what we are doing? You won't get an argument from me - but I also understand that people/cultures will tend to self-optimize for the period of time in which they live - or endure the consequences; life in the jungle 101 ;-) The IETF is becoming, or has become, a big tent. Big tents are tough to manage - no question. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 12:51:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08007 for ; Wed, 7 May 2003 12:51:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47GrSY12009 for ; Wed, 7 May 2003 12:53:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47GrN609329 for ; Wed, 7 May 2003 12:53:23 -0400 (EDT) Message-Id: <200305071525.h47FPq7H017640@rtp-core-1.cisco.com> To: Norman Finn cc: Muneyoshi Suzuki , Mick Seaman , Tony Jeffree , Les Bell , Paul Congdon , Neil Jarvis , ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Tue, 06 May 2003 17:13:41 -0700. <3EB84FB5.8630E288@cisco.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: Wed, 07 May 2003 11:25:52 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Norm> The problem with the model in the L2 FW doc (rev 3) is that it clings Norm> to the idea, discarded by IEEE 802 in 1996, that separate VLANs are Norm> handled by separate, independent, virtual bridges. IEEE 802.1Q chose Norm> a model in which one bridge handles all of the VLANs using individual Norm> physical ports, through which each of the VLANs pass. Well, the model in the FW doc was developed as the result of a very long and iterative conversation in which I was desperately trying to figure out what the IEEE guys were talking about. So if it doesn't match what IEEE might expect, the difference might be substantive, or it might be due to a misunderstanding; the first thing to do is to try to figure out which is the case. Frankly, when I look at the diagram in the FW doc and I look at Norm's doc, I don't see what the substantive difference is. Maybe the problem is that I don't understand the difference between the two models Norm describes above. Can anyone explain, in practical terms, what the difference is? Will bridges built to one model do anything differently than bridges built to another? Or more to the point, is there some issue which prevents bridges built to the IEEE model from correctly implementing the VPLS model which is in the framework document? From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:10:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08689 for ; Wed, 7 May 2003 13:10:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HD2Y22999 for ; Wed, 7 May 2003 13:13:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HCwb25265 for ; Wed, 7 May 2003 13:12:58 -0400 (EDT) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Cc: "Marco Carugi" , "'Rick Wilder'" Subject: PPVPN L3 solution space : TWO-WEEK WG LAST CALL on draft-ietf-ppv pn-vpn-vr-04.txt and related draft-ietf-ppvpn-as-vr-01.txt Date: Wed, 7 May 2003 18:06:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314B2.9308BE06" X-LYRIS-Message-Id: 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_01C314B2.9308BE06 Content-Type: text/plain; charset="iso-8859-1" All, as anticipated in San Francisco, we wish to progress asap some fundamental work in the L3 space. After launch of similar process for the basic 2547bis WG draft and related AS WG draft, we are calling here a TWO-WEEK WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt (to standard track). We associate it with a corresponding two-week WG Last Call on the related Applicability Statement draft-ietf-ppvpn-as-vr-01.txt. Thanks for your comments on the list. The call will end on Wed May 21th. Marco and Rick P.S. Following steps in the L3 space (hopefully soon) will consider the VR and 2547 related MIBs and the complementary 2547-related solution drafts. ------_=_NextPart_001_01C314B2.9308BE06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PPVPN L3 solution space : TWO-WEEK WG LAST CALL on = draft-ietf-ppvpn-vpn-vr-04.txt and related = draft-ietf-ppvpn-as-vr-01.txt

All,
as anticipated in San Francisco, we = wish to progress asap some fundamental work in the L3 space.

After launch of similar process for = the basic 2547bis WG draft and = related AS WG draft,
we are calling here a TWO-WEEK WG LAST CALL on = draft-ietf-ppvpn-vpn-vr-04.txt (to = standard track).
We associate it with a corresponding = two-week WG Last Call on the related Applicability Statement = draft-ietf-ppvpn-as-vr-01.txt.

Thanks for your comments on the list. = The call will end on Wed May 21th.
Marco and Rick

P.S. Following steps in the L3 space = (hopefully soon) will consider the VR and 2547 related MIBs and the = complementary 2547-related solution drafts. 

------_=_NextPart_001_01C314B2.9308BE06-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:13:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08741 for ; Wed, 7 May 2003 13:13:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HGFY25099 for ; Wed, 7 May 2003 13:16:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HG9004869 for ; Wed, 7 May 2003 13:16:09 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , PPVPN@nortelnetworks.com Cc: richard.spencer@bt.com, yakov@juniper.net Subject: RE: Single vs many solution(s) Date: Wed, 7 May 2003 10:53:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314A8.7B3742CA" X-LYRIS-Message-Id: 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_01C314A8.7B3742CA Content-Type: text/plain; charset="iso-8859-1" Alex, [clipped]... > > So, from this perspective, the framework MAY very easily look > like this (mechanism == protocol or protocol extension): > > Data-plane : mechanism A > Intra-domain discovery : mechanism B > Intra-domain signaling : mechanism C > Inter-domain discovery : mechanism D > Inter-domain signaling : mechanism C++ > Your proposal doesn't preclude the case where a given protocol is used to implement mechanisms B, C and D if we assume that mechanism == protocol extension. > Of course there must be some architectural glue that brings all > the pieces together. > > What I would like us to avoid is solution space exploration, where > we have many mechanisms for the same function we need, i.e, I would > be disappointed to see us end up with a framework looking like: > > Data-plane : mechanism A, or B, or C > Intra-domain discovery : mechanism D, or E, or F > Intra-domain signaling : mechanism G, or H, or I > Inter-domain discovery : mechanism J, or K, or L > Inter-domain signaling : mechanism M, or N, or O > > This would, in view, impact interoperability. > That sounds logic, but is it really that simple? Consider this example, a protocol "x" made a choice "a" of a particular extension for solving a given l2vpn problem, and later on it happens that "a" doesn't cover exactly the set of scenarios the wg needs to look at, and another choice "b" is proposed for the same problem and piggybacked on the same protocol "x" ("b" makes the 'architectural glue' mentioned above more likely to happen). In your opinion what should the wg do? Pick only one option (a or b), or incorporate the two options on the same protocol "x"? I hope your answer will not include something like 'it depends...' :-). > We also seem to agree on the point I brought in my message > to Mark: > > > Regarding the considerations you mention above, in my > > opinion it would be wrong for us to start the discussion > > by saying "SPs have X and Y deployed in their networks, > > so we just have to decide whether we piggy-back on X or > > on Y." >Instead I'd like to see a discussion ala "What are > > the functions we need? How can we best implement them? > > Do we have an existing protocol that would be the right > > fit for this functionality or do we need a new one(s)?" > I am afraid what you are proposing (which sounds logic as well) will cause the ppvpn wg to progress very slowly if we assume that this "discussion" includes multiple proposals on existing protocols and multiple proposals on new protocols, particularly if it is not straightforward to answer the question "how can we best implement them?". Besides, I think you missed an important piece which is to make sure that these functions (including the 'architectural glue' mentioned above) needs to meet a set of requirements. Hamid. ------_=_NextPart_001_01C314A8.7B3742CA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Single vs many solution(s)

Alex,

[clipped]...

>
>  So, from this perspective, the framework = MAY very easily look
>  like this (mechanism =3D=3D protocol or = protocol extension):
>
>   = Data-plane          &n= bsp;   : mechanism A
>   Intra-domain discovery  : = mechanism B
>   Intra-domain signaling  : = mechanism C
>   Inter-domain discovery  : = mechanism D
>   Inter-domain signaling  : = mechanism C++
>

Your proposal doesn't preclude the case where
a given protocol is used to implement
mechanisms B, C and D if we assume that
mechanism =3D=3D protocol extension.


>  Of course there must be some architectural = glue that brings all
>  the pieces together.
>  
>  What I would like us to avoid is solution = space exploration, where
>  we have many mechanisms for the same = function we need, i.e, I would
>  be disappointed to see us end up with a = framework looking like:
>
>   = Data-plane          &n= bsp;   : mechanism A, or B, or C
>   Intra-domain discovery  : = mechanism D, or E, or F
>   Intra-domain signaling  : = mechanism G, or H, or I
>   Inter-domain discovery  : = mechanism J, or K, or L
>   Inter-domain signaling  : = mechanism M, or N, or O
>
>  This would, in view, impact = interoperability.
>

That sounds logic, but is it really that simple? =
Consider this example, a protocol "x" made = a choice "a"
of a particular extension for solving a given l2vpn = problem,
and later on it happens that "a" doesn't = cover
exactly the set of scenarios the wg needs to look = at,
and another choice "b" is proposed for the = same problem
and piggybacked on the same protocol "x" = ("b" makes
the 'architectural glue' mentioned above more likely = to happen).

In your opinion what should the wg do? Pick only one =
option (a or b), or incorporate the two = options
on the same protocol "x"?

I hope your answer will not include something
like 'it depends...' :-).

 
>  We also seem to agree on the point I = brought in my message
>  to Mark:
>
> > Regarding the considerations you mention = above, in my
> > opinion it would be wrong for us to start = the discussion
> > by saying "SPs have X and Y deployed = in their networks,
> > so we just have to decide whether we = piggy-back on X or
> > on Y." >Instead I'd like to see a = discussion ala "What are
> > the functions we need? How can we best = implement them?
> > Do we have an existing protocol that would = be the right
> > fit for this functionality or do we need a = new one(s)?"
>

I am afraid what you are proposing (which sounds = logic as well)
will cause the ppvpn wg to progress very slowly if = we assume that
this "discussion" includes multiple = proposals on existing
protocols and multiple proposals on new protocols, = particularly
if it is not straightforward to answer the question =
"how can we best implement them?".

Besides, I think you missed an important piece which = is to
make sure that these functions (including
the 'architectural glue' mentioned above) needs = to
meet a set of requirements.

Hamid.
 
 

------_=_NextPart_001_01C314A8.7B3742CA-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:22:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08960 for ; Wed, 7 May 2003 13:22:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HOmY29704 for ; Wed, 7 May 2003 13:24:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HOj029985 for ; Wed, 7 May 2003 13:24:45 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Rahul Aggarwal , Pedro Roque Marques Cc: PPVPN@nortelnetworks.com Subject: RE: Contribution of the PPVPN WG Date: Wed, 7 May 2003 12:18:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314B4.55144E2E" X-LYRIS-Message-Id: 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_01C314B4.55144E2E Content-Type: text/plain; charset="iso-8859-1" Rahul, > > Do providers feel they are unable to deploy/offer L3 VPN > service because > of limitations with the WG ? > > Do providers feel they are unable to deploy/offer L2 VPN > service because > of limitations with the WG ? > I add to it this question as well: "In general, are the providers/operators deploying layer-3 vpn services across IP/MPLS networks the same ones who will deploy layer-2 vpn services (across the same IP/MPLS network)?" - note that layer 2vpn includes vpws, vpls, like-to-like, any-to-any, etc... Hamid. ------_=_NextPart_001_01C314B4.55144E2E Content-Type: text/html; charset="iso-8859-1" RE: Contribution of the PPVPN WG

Rahul,


>
> Do providers feel they are unable to deploy/offer L3 VPN
> service because
> of limitations with the WG ?
>
> Do providers feel they are unable to deploy/offer L2 VPN
> service because
> of limitations with the WG ?
>

I add to it this question as well:

"In general, are the providers/operators deploying layer-3 vpn
services across IP/MPLS networks the same ones who will
deploy layer-2 vpn services (across the same IP/MPLS
network)?" - note that layer 2vpn includes vpws, vpls, like-to-like,
any-to-any, etc...

Hamid.

------_=_NextPart_001_01C314B4.55144E2E-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:27:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09160 for ; Wed, 7 May 2003 13:27:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HUOY04637 for ; Wed, 7 May 2003 13:30:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HUJG16793 for ; Wed, 7 May 2003 13:30:19 -0400 (EDT) Message-ID: From: "Busschbach, Peter B (Peter)" To: "'steven.wright@BellSouth.com'" , erosen@cisco.com, ppvpn@nortelnetworks.com Subject: RE: ppvpn effort support Date: Wed, 7 May 2003 13:26:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: ihemail1.firewall.lucent.com X-SMTP-MAIL-FROM: busschbach@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ihemail1.lucent.com [192.11.222.161] X-LYRIS-Message-Id: > -----Original Message----- > From: Steven.Wright [mailto:steven.wright@BellSouth.com] > Sent: Wednesday, May 07, 2003 10:54 AM > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Thursday, April 24, 2003 1:20 PM > > Subject: Re: ppvpn effort support > > > > > > > > Steven> while the hierarchical concepts of draft lasserre > > are important, I > > Steven> expect these notions of hierarchy will be > > associated with > > Steven> administrative boundaries. Administrative > > boundaries also imply > > Steven> administrative policy and BGP is the accepted > > tool for managing > > Steven> this. > > > > I wonder if you could be more specific about this, perhaps > > an example of > > inter-AS L2VPN service where you want to set up policies > > at the inter-AS > > border. I'd like to understand better the degree to > > which the policy > > management is dependent on the underlying signaling protocol. > > > Consider the security aspects in an inter-AS case. > Current administrative policy restricts inter-AS control > plane interactions > to those between BGP peers. > It would take a significant effort to change this security > policy to permit > signaling (using another protocol no less!) from outside my AS to an > arbitrary router within my AS. Service architectures need to > fit within the > constraints of administrative security policies. > Steven, In case of PW-over-MPLS, I would think that the setup of an LSP between two PEs needs to comply with the administrative poicies that govern inter-AS traffic. However, once that LSP has been set up and the two PES are essentially peers, do you still need to through BGP routers to exchange PW labels? In case of PW-over-IP the situation is different (which sounds like an echo of Neil Harrison's emails). I would argue that in general all signaling doesn't through BGP peers, e.g. in case of the setup of IPsec tunnels. The bigger question, however, is: do you think that in case of PW-over-IP, use of BGP for signaling solves all security problems? Thanks, Peter > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:31:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09367 for ; Wed, 7 May 2003 13:31:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HYIY06671 for ; Wed, 7 May 2003 13:34:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HYDG24620 for ; Wed, 7 May 2003 13:34:14 -0400 (EDT) Content-Class: urn:content-classes:message Subject: RE: Single vs many solution(s) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 2003 09:44:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A0DEF89@m-va-bsod03.add0.masergy.com> Thread-Topic: Single vs many solution(s) thread-index: AcMUHedVYuZXk6w0SsOIM8pcx/ZG6gAbXf9A From: "Ron Haberman" To: "Pedro Roque Marques" Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: ronh@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09367 Pedro, Inline... > -----Original Message----- > From: Pedro Roque Marques [mailto:roque@juniper.net] > Sent: Tuesday, May 06, 2003 6:22 PM > To: Ron Haberman > Cc: PPVPN@nortelnetworks.com > Subject: RE: Single vs many solution(s) > > > Ron Haberman writes: > > > Masergy Communications is an example for a company that actually IS > > running all three VPNs. We are running L2 point to point > for about two > > years, 2547 for more than a year and are actually currently running > > (currently as in not planning to, thinking about it, > > evaluating) VPLS service for about a month and a half in our > > production network. > > Ron, > How would you rate the contribution of the ppvpn WG to the > services that you are providing ? Are those solutions based > on technology discussed in this WG ? RH> I don't think that I should be grading to the WG :). In general though, Masergy is relatively young company which helps it adopt new technologies fast. I started planning for VPLS over a year ago, waiting for the solutions to be agreed on. Do I think it could/should have been done faster, sure, but that is almost always the case. As to the second part of your question, at this point all of the technology that I am running in the network (for VPNs) came from PPVPN and PWE3, 2575, martini and VPLS using lesserre-vkompella. That wasn't the case in the past, we have adopted Juniper's CCC (before switching to martini) using VLAN stacking (instead of label stacking that wasn't available) to allow for reuse of LSPs. We had a short period of time (never made it to the network) discussing VR based systems (which were available) until 2547 came out. > > The proposed reoganization is based on: > "numerous concerns that the IESG members received from the WG > participants about limited and slow progress within the > WG despite the > efforts of the WG chairs and its members." > > I assume that those concerns about "limited and slow > progress" have been voiced mostly in private. To a more > distant observer like myself it isn't easy to understand what > those are and what constitutes a messure of "success" or > "failure" of the WG efforts. > RH> I was wondering about that myself. I don't understand why would people voice concerns like that in private. From what I have seen, it was possible to move at least one solution forward at the IETF in Atlanta. Weather that would have made the WG more or less "successful" I don't know. I think that in general terms there is a very fine line between success that is based on finding solutions quickly and finding the "best" solution possible. From the WG perspective I would think that success is measured by: 1) Number of implementations of the technology (shows that competing vendors agree on the solution). 2) Adoption of those implementations (shows that SP agree with vendors). 3) The solution/s become standard (provides a stamp of "approval" by a certifying authority). I assume that a lot of people will not agree and might want to rank (3) as (1). I think that if as a SP I can offer a service using multiple vendors and able to connect that service to other SP the technology being certified "standard" is icing on the cake. That being said, I would love for (3) to happen around the same time as (1) but I will not wait. > I'm hoping that we can learn from whatever concerns exist > with the current group in order for those issues not to > reoccur with the new proposed structure. > RH> I am still hopeful that the new structure might not happen all together. I think there is enough difficulty in coordinating efforts between PWE3 and PPVPN. I also think that almost all people interested/contributing to L2VPN will also be involved in L3VPN. > I would hope that people like yourself which are activly > engaged in deploying the technology can point out the things > this WG did correctly (if any) or wrongly. > RH> I don't think it is my place to do that. I am part of the WG and just like anybody else there are things that I personally think were done right and wrong. I think most of the work was done in the "right" way, people coming to agreement on solutions, working together, collaborating, producing results. The only item that I would say was done (and is being done) "wrong" is what appears to me as taking actions based on politics driven by company's interests. Could that be avoided, I doubt it. As much as the ideal of "personal contributions" makes sense I understand it being very hard to follow when your company is in competition with another to provide/sell the solution. As a general improvement item to the IETF I would suggest to clarify the "voting" procedures. At times my recollection of support or lack of was different than the final decision (not just in PPVPN) not to mention that what should the vote be in order to show support is by it self unclear. > regards, > Pedro. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:44:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09763 for ; Wed, 7 May 2003 13:44:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HkRY12971 for ; Wed, 7 May 2003 13:46:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HkMJ07626 for ; Wed, 7 May 2003 13:46:23 -0400 (EDT) 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: Comments on the L2 VPN framework and solutions documents Date: Wed, 7 May 2003 13:29:22 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB720215260A@WHISTLER.WaveSmithNet.com> Thread-Topic: Comments on the L2 VPN framework and solutions documents Thread-Index: AcMUpsAk8/K6HlOsRbGOs+UqeBlDpQABXt0A From: "Himanshu Shah" To: , "Norman Finn" , "Muneyoshi Suzuki" , "Tony Jeffree" , "Les Bell" , "Paul Congdon" , "Neil Jarvis" Cc: , X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09763 This digresses from earlier thinking (at least mine) that P-STP would not span across pseudowires. There are several implications to running STP across PWs that may need to be clarified/worked out. 1) "fully-meshed" attribute of the PWs only applied within a context of a VPLS instance. That is, if PE1 and PE2 participated in VPLS instance 1 than there was no pseudowire to PE3 which did not participate in VPLS instance 1. However, with this scheme, each PE would have pseudowire to every other VPLS capable PE irrespective of its VPLS instance membership 2) Assuming that 1 MSTP instance covers entire provider's network, a backdoor link from ProvBridge1 to ProvBridge2 of VPLS instance 1, may cause 802.1ad's emulated LAN ports to all VPLS instances (i.e. all PWs from that PE are in blocked state irrespective of its VPLS instance membership). Doesn't this block other VPLS instances's traffic across PWs? Perhaps my assumption is wrong and there is in fact P-STP instance for each VPLS instance. However, if that is true, PE would run into BPDU scalability issues. /himanshu -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Wednesday, May 07, 2003 10:42 AM To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents If the fully meshed pseudowires (and the attached equipment/functions at their ends) provide a LAN Service (stictly the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both documents) then RSTP/MSTP will work just fine. To be more specific P802.1ad does specify the operation of a single instance of MSTP within a Provider Network, how that travels over pseduowires is of course how any LAN traffic travels over psedudowires (i.e. the pseudowire protocol looks after making sure the configuration of the pseudo wires correctly provides the fully connected LAN service, that not being either MSTPs design goal or the desire of P802.1ad to specify the simulation of LANs over non-LAN media, particularly where the non-LAN media have native protocols that are to be used as part of the solution - MPLS for example). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 6:01 AM To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Norm, You have to excuse me for jumping in at the tail end and not following the thread. I would like a clarification. Are you implying that 802.1ad is contemplating on running one or more (Provider's) instances of R/M/STP on fully-meshed pseudowires? /himanshu Wavesmith Networks -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, May 06, 2003 8:14 PM To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:47:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09826 for ; Wed, 7 May 2003 13:47:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HnsY15963 for ; Wed, 7 May 2003 13:49:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HnmJ11270 for ; Wed, 7 May 2003 13:49:48 -0400 (EDT) Message-Id: <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> To: Waldemar Augustyn cc: Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: Message from waldemar@nxp.com of "Mon, 05 May 2003 00:33:21 EDT." <3EB5E991.5040604@nxp.com> Date: Wed, 07 May 2003 12:24:18 -0400 From: Thomas Narten X-SMTP-HELO: e4.ny.us.ibm.com X-SMTP-MAIL-FROM: narten@us.ibm.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: e4.ny.us.ibm.com [32.97.182.104] X-LYRIS-Message-Id: Catching up a bit (and summarizing)... Waldemar Augustyn writes: > as the co-originator, with Tissa, of the L2 VPN work within PPVPN, I > would like to say I am glad to see this effort finally recognized as > significant. But the two year delay does not impress me. What is being > proposed should have been done at that time, two years ago. At the very > least, the charter of ppvpn should have been adjusted as it was promised > but never done. As the likely Area Advisor for these WGs, I think it is important to get the charters updated so that the WG and the ADs (and IESG) are in sync. Doing so sooner rather than later tends minimize (later) problems. (Note: this is true in general and if we end up moving these WGs to INT, doing this as part of the move seems logical, which is why I'm now following this all more closely.) > It appears, what we're talking about is playing catch up. The issue is > really the charter which makes no sense, but I do not see the point of > splitting the WG after these years. My understanding after having looked at the work as that there are something like 12-13 IDs on L3 VPNs in the pipeline. That's no small number and suggests that an L3 focused WG still has plenty on its plate. Eric Rosen writes: > 1. Before being comfortable with a reorganization, I'd like to see what the > new charters will be. I'd particularly like to be sure that the L3VPN > charter is not constructed so as to cause a reset. Same with the PWE3 > charter; we don't want to have to refight old wars. Fair enough. I don't think a PWE3 revised charter has even been drafted yet, but for the L2/L3 there are drafts (somewhere). Stay tuned. > 2. From ground level, the most important aspect of a particular WG being in > a particular area is the attitude of that area's ADs towards the work > that the WG is doing. This is an unknown to us. Given that at least one > IESG member (though not one involved in this reorg) has been quoted in > the trade tabloids as saying that this work is all a scam which will > destroy the network, you can see why we might react cautiously to any > proposed change. I don't know that I've been quoted on the press on this topic, so I'll assume the referal is to someone else. :-) Bottom line is that I'm fairly agnostic about the technology. I understand that there is a need for it, folks seem to want to do it, and there is a WG in place that is well on its way towards doing the work. I don't see a need to revisit such basic questions. But I am interested in seeing the WG complete work in a reasonable fashion in a way that when the documents make it to the IESG, there are no suprises and I can make the case that the work is baked/solid and there are no serious issues the WG neglected to consider. More on this over the next few weeks, I expect. As one example, on the topic of "one vs. multiple solutions", I know the IESG will ask, why are we standardizing 3 solutions to the same problem (if that is what the WG thinks it is going to do). The WG will have to be able to answer that sort of question with a credible response (and in some cases, a credible justification is that the solutions are very different and there are different applicabilities to the mechanisms -- but one needs to look at the details on this). If the answer simply is "because we want to and we'll let the market decide", the IESG may well come back and say fine, make them all experimental, none of them on standards track. Revisit when the market has decided. Would that be what the WG wants? Would that be in the best interests of the IETF and Internet community? I wonder. "Hamid Ould-Brahim" writes: > Wouldn't be more appropriate to first discuss what these concerns > are and if they are indeed justified concerns, and solicit feedback > from the wg to discuss options or improvements on how to move the wg > forward and get consensus on that. If I recall, similar open > approach has been taken for sup-ip area in Atlanta meeting. Sometimes, public discussions aren't the best way to deal with issues constructively. This is particularly true when it comes to management questions about WG operations. > After all, the amount of work after the split is exactly > the same as before the split if not bigger (given that > l3vpns work is almost done and the split will > introduce additional administrative overhead). But if there are two WGs, the management load is split across more chairs, so it takes less cycles (e.g., from each chair) to manage each WG. There is a basic tension in the IETF between having WGs that are too large (a similar discussion has been ongoing in places like MobileIP and IPv6 over the last year) and where splitting them up into smaller WGs can help focus them. Indeed, there have been numerious conversations about this on the problem-statement list (with one view being that smaller, focused WGs tending to do a better job of completing their work than larger ones). I tend to share that view (as a general observation), and given that there are some 13 documents in the L3 space alone, I see there being ample work for a standalone WG to take on. Will splitting up the WGs _guarantee_ this? Of course not. Does it solve all possible problems? Of course not. But it can help, and it seems reasonable in my mind to do so in this case. Yakov Rekhter writes: > As was pointed by other folks, there is practically no L3 VPN > related activities now. Practically all the discussion is about L2 > VPN, or to be even more precise, above VPLS. Just count the number > of messages posted to the list over the last 12 months related to > L3 VPNs vs L2 VPNs. The chairs themselves seem to agree that there are some 13 documents on L3 that are not through the system yet. I'm a bit concerned to hear that there has been minimal discussion on L3 topics over the last year, given the number of L3 work items that apparently need to get completed. The above could be read as indicating that the discussion/urgency of the L2 work is pushing out or drowning out discussion on L3 topics. If that is the case, a separate WG, mailing list, etc., may well help. I'm assuming the L3 work is important and should get completed. Thomas From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:51:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10051 for ; Wed, 7 May 2003 13:51:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47HsOY18523 for ; Wed, 7 May 2003 13:54:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47HsHJ16010 for ; Wed, 7 May 2003 13:54:18 -0400 (EDT) Reply-To: From: "Mick Seaman" To: "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" Cc: , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Wed, 7 May 2003 07:41:31 -0700 Message-ID: <007601c314a6$c1f6a7c0$210110ac@corp.telseon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0077_01C3146C.1597CFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB720215005A@WHISTLER.WaveSmithNet.com> X-MS-TNEF-Correlator: 0000000043410BC5A002D6408BB2E6318DA014D28417C700 X-SMTP-HELO: pimout1-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout1-ext.prodigy.net [207.115.63.77] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C3146C.1597CFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit If the fully meshed pseudowires (and the attached equipment/functions at their ends) provide a LAN Service (stictly the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both documents) then RSTP/MSTP will work just fine. To be more specific P802.1ad does specify the operation of a single instance of MSTP within a Provider Network, how that travels over pseduowires is of course how any LAN traffic travels over psedudowires (i.e. the pseudowire protocol looks after making sure the configuration of the pseudo wires correctly provides the fully connected LAN service, that not being either MSTPs design goal or the desire of P802.1ad to specify the simulation of LANs over non-LAN media, particularly where the non-LAN media have native protocols that are to be used as part of the solution - MPLS for example). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 6:01 AM To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Norm, You have to excuse me for jumping in at the tail end and not following the thread. I would like a clarification. Are you implying that 802.1ad is contemplating on running one or more (Provider's) instances of R/M/STP on fully-meshed pseudowires? /himanshu Wavesmith Networks -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, May 06, 2003 8:14 PM To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm ------=_NextPart_000_0077_01C3146C.1597CFC0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiIOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBQAHAAcAKQAAAAMAGQEB A5AGADgaAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAQ29tbWVudHMgb24gdGhlIEwyIFZQTiBmcmFtZXdvcmsgYW5kIHNvbHV0 aW9ucyBkb2N1bWVudHMAAAAAAgFxAAEAAAAWAAAAAcMUpsAk8/K6HlOsRbGOs+UqeBlDpQAAAgEd DAEAAAAaAAAAU01UUDpNSUNLX1NFQU1BTkBJRUVFLk9SRwAAAAsAAQ4AAAAAQAAGDgCmO62mFMMB AgEKDgEAAAAYAAAAAAAAAENBC8WgAtZAi7LmMY2gFNLCgAAAAwAUDgEAAAALAB8OAQAAAAIBCRAB AAAA2xUAANcVAAAnLwAATFpGdXoYj4IDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMC gA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1 ESIMYGMAUPMLCQFkMzYWUAumCuMKgABJZiB0aGUgZmB1bGx5IAeBHZBkxCBwFBB1ZG8D8Bgg3QQg KABwHnAdgmECQADQcR5SZXF1BSAHgAIwL+EdwG5jdGkCIAQgH+DPHXIfACBgH3BzKR6AA2AMdmkB AB/QIExBTssGUiLQYx2gKHMhUCFAex3xHYJJAjAEkQdABgB12QJgYXkSgSOGYQQgAQEHC4AeYQuA IDgwMi7cMUQf0B9xJ1NREiALYEJ1FBAgNi41I/FhsQeAIG51BtASgWMohM8nIQbgHYAmkG9jKZAg 0QcicR2BA6BSU1RQL3sF4CwAIAPwHeAscAWwa9wgaiigBUAmwi4c9Bz0PFRvKoAdoARgGCAgc05w BZAGkA3gIFAnU2FfHnAe0AeRLzQkdG8vQHI/H+AhYTFQHWAjIACQbmf+bCpCJBAAcCPRMgEsNR2A WychIyBQIrQSknQs0iw8IGge4B1xIbIxkHZlnmwEICLAEoEekWR1HuX/BAAx8gWgCHAosTWCAHAe AD8jQjYRASAvkTYfHshpLm8toB1zHpgiknQq8AbwIHkXsG9rIZEBgBKBAMBrvzJhLyAIcB2gHYIF oG4mwP5nCHAxpzu4LHEfEgWhGCD/JEMipQQgHYg+8SbgIUAeYd8jQhQQI6M1YDXDbiqgLqF/PiIi AB2BBcIsACaCAJBn+QOgZ28lMQWxHYJGEi8B3zIBL8c80DCbAJBtHdAxp2cjQTZ1RKBuLSNCB4Bk XwcwNWAKsSQhSZFyHfF3/0VxPpRK6zVwNjEpcDGhTkH/PKZCIiGxCsA+kS6TKKEecFcmcUvSP8Zz BvB1MbMtuQXQUEwF8AIQIiF4KUCpC1BlKS27TQ3gay3Kai1VQk8FEGcLgCUxTbMHkCkwZ2VVQxz0 RgNhmDogSAdwAHFodQYAOxPgKsBbAMADEDzQOmiTHkBYUEB3NjFzbTPhkybgNRNzLgWgbV0c9DcG YAIwV4BXCYAm4HNkiyWgNWBNJaAgMDc1YIkB0DAzKNA6MDEQwLZNLiZXgE4FsAOCRguAjG47BdAh IGV5bx5A8mklUXp1PhBewVRRBlHfKUAAcF7ALoA4wUoBEQnRdV7ATAeRQjZQAnAc9FD/KJADIAhQ MnAe0F6xB8ADEZZKCsAi0HMc9ENjV4DAcHB2cG5ARKAAIBc2UFn6XsBDK6FnLVmlC4AuYbBlQAdA Yx/gbzZQWnJaxSVwakFRV4BS9kVXgAhQbSsjMVADoB2C8kwUQFZQI2ADUClBLNN/H2JRtiaBKvYt yhz0XhIs/S3KWQhgThRIcQ7AKwAosf8pUVKyLSBTID4iNBIhwxz0/wGQAxEiQSezRKICEB3gHuG/ PjEdgh2AGCAwIC27SSzB4x3QHnBsaWsjAinxBoH/DeAxozuQLcoHEB2gXyBYEPsHcAtQeXNkIbEv 1jehPvG/DrBTITGhPjECIBz0ciEgXwMAenMxQT3RLvIoNGYn1yJxMsY3s1IsIC8sQhz0SzHRHcMt Hi9zPy3KL/c0AFfEHPRXWXY05myrVU+/Vl9XYl4ZWHc/EUMAQC9gtQTwb1p/VApQW9k2XJXwODox NC+wXWle71///2EPYhEvsGK6bXVjn2SvZb/3Zs9n3wfwZWkfai9rP2xP/1PHjBZuG4wOLHA8sZYg HPS+PhzlniCeIHUQYzEnIcJjC4AtAHdlJy8BGCBm/wSQBRBzci6QSSMpQgRilND+II3gPsNBM6F0 nkhSsjhz+yqABRBkhWAnESTxANCWsfcz0h2zf2RzNWB7oqW3HoD/EoGXgFKAnkgyxjVgBACdv/+i AkuABPAooACQMdE3oSch5z61DrMyAVdHPSAmcAVAz5SQLKE/1ZdRRlcq0iey/53GNYMukCKhCcEE ERggSaE7HmFRt2Q5QStQO5BTb1E1YEknbaAZRQUQY/988KK8QgEFAS6xq3WuBDuQ/6ICcwihgzfx UyKSgR4AS4D/ASASgQNSssVuFZ4gUbAddP9zFzehqpGFUAnRIMKgtq4E76kCnyIz4ICbTR4AAaB7 IPcFMQBxn8ByV4Ch864FN6H9WbBzMpAwIDJhNWApsJSQ/yojBUC6dpFFpWMdgllgHgC/pFQhkS8B KpQmtR9iYiCQ+1jALbtBRKFFcsKCr2JR4P+8gb6BvYFLgQnAKUA3kjEj/m5McsZCT5MvIDLxW+AL ItsdEqRVQyNRpMNmANBP8/8dhh4UpUSrdSWTtjcc9FkR5xghKoAeAElFz1AnQiez+c9AVEah0XUQ HkB1Qy62b5SQoCFiwSchbULBC2Ft+ak2SXSzEcgfThEEICmw/yuxIqAHkCDRCYBEMS6QW+D/DrDV 089GJ4BuFR9i1LJBQf8iADZAUKE9IVEjPmCR8BfB/y28O8IDYAJgegClVB2CtnSLq3Wt2CgYIHYg M30R/09lM+Ac9CnwMmFCIaDUIuEfS6GqkgsRzu0nITE5Ob+KcTXDFBAKsZShHPRWSkP/T9IT4B9w MpDO8+JmqQEfcL/icCJBINE1YCLQACB1JTH/wsXQUs9RHPQoBRPQjFAjAv/b90ygDeAqwHuipFXj 5CGR/60440Mc9CigcMRLgCLR5kL4cGh5DdHtEhfBplFz4f0IYGcqwOlEjYDpcusvCrD/BBDZ3i8B N6F1kAJAMpHZkPukwXDzcj9AemM2oulE2/W/1NICQASQ0FIc9Mswdi7x/x+E0BK2ZUyhJzUoUFlg syH/PgQz4CaCiDEhYcAxxrF1EP8XsCQQLbWiAqGDplHHZaZR9x9iTuh6Am8lsM7zKAT8BP8roctS cXalEeZJxIRIYVvj/z7yXiGgts9DoYnx04PU3YD/FZAeAHQBUbCW8S6Q8zIxQa/zz7Min/MykHYN sHRewP/TlE/ywZXpU8LK/3Qd8QBk/9CoN9MNwRWBvbAd8i7xg9T/pMPqoCHCXlHA0RQQegDfM/8K 4pbyv2JYoT4idZD6N9pI/8dlwDJzMcAxoHJCJAIo5RL/6TWtIuNE8JJxle5VMjfZkv8TI97xwmGC sqeiy+o1YO7FfngPkXuS8DUlwXxn63Mg/nwoYC0xlmAlySTQMuUa8N5GUsD4IOBwPiJGISVTbP5S IbBFcg1DMZByEYVQWKB/MtGtjd1zNWC3EXACPmBn78MBn0OpNjRnQsLVGNP8Af8vAT31fBCMIVKj 34FHcCkR/wPSlHArcMSSNLG4ltfDMWHvfxMkzyXaxqBy6DD4MCeBc+b196RBRMGWrTHJVml6ej6T bSttQKGtMbRxYr8rEX/AluXnxaGEg9RE4nD//TQ7+cv8fzCmYT/gWJCYMP23IC2xME6h8xBDEYUh wND/XAG0cN6FtuE/cdsR21bd4b8uhkG1RZCkVaGKyFNxiaH/mOPXZT6BTKFFY1LBRKIwF/0sMC02 KXgyuuM/czNkASb/cZUBxvbRmUZ2g/wEt5BEkv8YUjtUJjQssxjUTnBOoQxV/z2tUUWEwKJGQCtP ZQEywJL327M0I1N1KBwgokbPEcPT/8DQ+WNBod+Bx0K6lBb0pFY5PawuKW4qnqJOunw930+fUK9R NoQzhDErTi9PNL9Ou1PfGvCjsR0GVDZ8Ut+/U+9Yb1jDfxAdpNBgK4Qx/1c/ssDQYIyA0GBSoVkf WMK/nGBx8CJRf8BdkRdTMYqw/1jIV3x48HKwWJoaF1nvo7LwQlBEVeqwW5hikdBgfnJXi+8AYaJY uSP0Wc98/1JGhDJgV9BgZNEH9VflaCH/aCRY71n/TrhlCWghgeVX5f9jIWMiXX9tX1Y/bDR4EN9w L1eLW3FK8G4YRe8yIivOIvLybEMaozI2X3JbD/9sUn/A8vBrDqQwbhffgsOA/+BxO5F2IVosF1OK oWA5atH/YcFg7q5QbhgOs9sQmVCfoPFsNW11eFvSbl9uFaQQ/CBnV45oInFUjoDVRZbC/2ghcXHD 0IIhaR9ySHosTrH/ZNFsN6RV2ZJzNHi2gp9uFf1jIWZXj24Pjy+PjWoZb9//kd+T/5WfZOtk0X88 TrVxX/eVr3N/lIdjmG+WX55YGqP4NTg5eG9lNl0xdRyeT/ujL30sM34dW3GJL6TPqG//ln9lGE6x avyZP6l/ru9+O/91wqyvTz+zz1FfUm+2/7f96kGySEKySkO2Z7ZovrKfFbXK6AvABTHfcyJBd1D/ 0oARYXsgIFTDgRtBx9YaFv+2aGfU02GK+uITKHFFMQG1/EwzFvA7sCdgOUUVEUvB78rnOoWyEr0Z Qr3XOwFFlPvEpvTid9UCy7Mc6KD2xRp/z+Hbs4IxhyRe8A2R4hN0/x+gC2DSgOTwyBwjbdNgtmj0 UC0ao3PksLziyuUXUzhWQ0ku4NAjOUUiQ993UO3TxvcGcPnAaEVCtmj/34IyGObi2qPtWy/WFTHk 8P/2UAtyCTMLETvgtmgMuAHE+ziEOUE6TbW6+xwgF+D9oP/GoEOC/IDlAfnw+CLyo/Nzf/nBzERF oe8jyP8v4LZoTfhVU1QBIsyQ/MD4w8Ziv7x4BGDedA2RN/XqsDEnEN8ywyshG9IzwWXpMicQO+Dz 5NY5QShMO1DBIuoxhqF/GQFbwdx6+BN7MPI1R7Vk/7ZoyDq9srx5yuXiS02Xuvv+U0XR0OUzFSsA vUGGoirx/x+goSAngENxG+DedNYXFCP5MlBuJ+gitmiGohqj1mD/DXAK4UthATE08dehGFMV8f8H EPyAO3I3QcNhKXNbwS44/7ZoB7BfUA4DQ1D70BbCNyP/NUH/oEEISkAE8NhC3lEoYP+EEAShSiD/ sTbTDZBI1br7/kZ3cAnCIafo88IUOcL0c/8XYlvBB2bqUmRJ87o3QQvA/eMgbNeRCeEGwDoAMoHQ of9/AIYRNLFGUHswIgAKQDJR/w1wRWUaFsEhAcDIUPdx/Yj/uPHH0CdQ+9NK8IaiRWX21PNfstLh ZmZGMYaCAIFHZH8bJcEhzJELABvg/Ye2Zij95GFJRlBIAC3g+ZMiABZj50WSvRQS1VBF0uTZY/Wn /xb0GcG2ZgwWF+nZkb9UENL/6cB28QTkRZITNxEP6oc20/97MDLHOUDSIYXwJfEPWMNh/yBB1mBI AA9gO2LnsH4BfiDfMsm2Zus2EMFKw25AoDWgX3xzDBbS5BuyOUBP8bBnH/7WMsfwkb9DtmZPKE7u XuYxN/E2kW0PYOMj1fH/13DdsC+i9ZAt0eex3YEiYMojM+BDHucqICKK/Yf+RirQO2LTgBnjSvDH 0NnBzzfx16ChJPqCdXDSogTk//Cw3cDQpCjItmbxYd/SItX/QVNN0UUA8tEzEhs2OvIyUD51NpIz Fc1LEND9h1Nv790y81QLEMbSbgRi/vA1Ub+g4NdwvxAPvUjVtmRGO7HfeCAds0WSHjgBEFDS4AOh 9/nhoSAAgU4PYMbA1mBH8j/fEzaxA5O2ZIdABgBpcOlFEXQt/JAt3bPMgUvB/8eh+hFE8ZxRvlXk Id3xRPPfELHVpR40tmTYcSKK8Ptg/RVhc3dQeQH+8TijOtI24/fH0ApwLOBzR0PcUCJkN8j/G1QD oEjlItK9EACA5kS8FP8A80dj0CHCkT9yBnYwkdW0d0SXtmT8kHU+4sczxqBy/2gQ6MIeRxDCEHA7 JEguIpD/G/g+BziyPpjVodxBezAy4N854NZiB5UYRgVwctyCSLH/Hii2ZDWH8XH64E6BNio+ir/9 EOSx9UFAjCKBNFtX/SH/D4PyQi15NnYgsWRhOGMA8v8bNgOiS592INT/6gHoEdhx/0Iw6cDf0imw eyFbCL8j8bDbBxD+8Cy2ZOoQbTRxFYn/XDX1ETaxN8jMEdUwzRH/wfsPcSqAbL1EtmTZYwVx39L/ 13MasD072GJbCQR4A6EiYP5tQZK2ZBREvxNiMsdC/JB3FUBSGh2zYt5R4yD/kXP+bf7xCmEeNF7F hfDM4hWXf04nSSsVKliHNFsOIeYxRv3MoWsgkjGGyGDksaEAfFH/6BDs1g/7YTi2ZlPRFjHMoPvN AmrTaV9QLOGGUfr1apL/aJVdUSjRgXDh0UMAFWDMEJ8R0QkRNFsxgQOgYWfEQv9fMv9RBELjVnff eOxNscNR/xwQ6oViM3amc0nfwHrR+gD3D3IJhdxxc/0RPuJhG36ZfeejcvGwQ6EPcRmwDQFp/wWB GzXVowOhA6EFQSxQQjD/AIF82LZkePphG3WKNzYUSL/54PHCnFC2ZHLz36J6ZuLPx5j7Yoybyacg ZzFR+2K/NzVnuvSA/HB8+C0wLwJRf6D28tHG0HbT0uRmhucBU3/CcCxQDQH+80d1vYLLsS/7y5Sg 9iL2M98xXinsyDUhn9+WJ3CXJme2l9JMMgDw/6BgA6EQcPugY/JwHdxBx0L/wMR465v0jTMYkeTh hUDT0v/HM/gTjJYUELZmGKCd5eoRx9fg6BCgQ01BQzhQ3eH/yeAUAhigo5JscjLwo9Mgofv7Yhig SPuw9vG2ZqTxCmHLpTTnAEN+oiB505DqAL9IkR4Aivk4MqPl2CNsfTAfbKNWYLZmc1j7pD8gVzEu V01TQTbRnylJU0xPL/gQo7AxNfhhLfYxvyKqhT+c9wnU49XOdntZhPSzYd+RncYUJscGRf4trnAK wa+urMDjctLg9LPny1iXBqygQWPqEN+0wsVfoSjQtPTC0XDllnb+8HX/WXOE8SkC8MOEo9fjx0Kk n//jEmG5dQcQcN3hqMGtYucA/EknM0BiMimgxxEUQQpD//pj6hLlcA7h/RO4y+Vh/7L/obdqkt1Q VkJPAPyRMpONIPv6VJ5bYvuw8SKMEKoV+VK/FYcSuIRgBYKhJzRbQUWo/4yW+ATaZI8Z2DLhggjg n2X/7RMG5uWUsxTsEEOgfTAH8P9+Ut/AczBiMtpgOGBPAIMx/95COpG+QsICX1D0cZOxQc2fYyVi EvlD/IPmcW87SpL/BMCLp82NlxHHs5SiRqPzAb85NrbeE7FscQuhPrFzbJLvL60G+PSzFUBnjfOV uJlvvzzhGpGDkDRbRqL4E1D4Y9ussPd1R2RBXTB38bCKUv9Kos0j12LKOEaAy5g5NSbA/1JhoEP4 GPYx/SL2UDMxfnD/8KP1ckIgJCL6Y4DFmLa2A/85NVw1SqEjMVJgMsAFYYAf/zNBKlD1QcIl+2A6 sV/U+Bb/jDxGYg6AB2Gf0QvQ/5F+cP/1AXyS+eB2sM6xgyIvwTsh//tEfnBicXkxlbYkEROx5rf/ 4lToUTKC6ZVrMFPQ12IywO8awcWTRTA84GSP5f0hEpb/SKG7Ef0TD0ICUfxQEoAcAmcgofKv5WE6 KTRqAUFOF8JhNGoIFH3/YAAeAEIQAQAAAEUAAAA8MDQ5QUFGRUQ5MTg1MTI0NEI5RkY3NEQwRDlE MEVCNzIwMjE1MDA1QUBXSElTVExFUi5XYXZlU21pdGhOZXQuY29tPgAAAAADAAlZAQAAAAsAAIAI IAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAA AAADAAiACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAMAGYAIIAYAAAAAAMAAAAAAAABGAAAA AFKFAAB9bgEAHgAagAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAG4AIIAYA AAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwAfgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAAD ACCACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAIoAIIAYAAAAAAMAAAAAAAABGAAAAABiF AAAAAAAAAgH4DwEAAAAQAAAAQ0ELxaAC1kCLsuYxjaAU0gIB+g8BAAAAEAAAAENBC8WgAtZAi7Lm MY2gFNICAfsPAQAAAJIAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NcbWlja1xMb2NhbCBTZXR0aW5n c1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG1haWxib3gucHN0AAAAAwD+DwUA AAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwNDM0MTBCQzVBMDAyRDY0MDhCQjJFNjMxOERB MDE0RDI4NDE3QzcwMAAAAAADAAYQ0oIX8QMABxBvHgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAA ZQAAAElGVEhFRlVMTFlNRVNIRURQU0VVRE9XSVJFUyhBTkRUSEVBVFRBQ0hFREVRVUlQTUVOVC9G VU5DVElPTlNBVFRIRUlSRU5EUylQUk9WSURFQUxBTlNFUlZJQ0UoU1RJQ1RMWVQAAAAAeKQ= ------=_NextPart_000_0077_01C3146C.1597CFC0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 13:59:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10282 for ; Wed, 7 May 2003 13:59:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47I26Y08990 for ; Wed, 7 May 2003 14:02:06 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47I20E29410 for ; Wed, 7 May 2003 14:02:01 -0400 (EDT) Message-Id: <200305071659.h47Gx37H024423@rtp-core-1.cisco.com> To: Thomas Narten cc: Waldemar Augustyn , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-reply-to: Your message of Wed, 07 May 2003 12:24:18 -0400. <200305071624.h47GOI29002731@rotala.raleigh.ibm.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: Wed, 07 May 2003 12:59:03 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Thomas> I'm a bit concerned to hear that there has been minimal discussion Thomas> on L3 topics over the last year, given the number of L3 work items Thomas> that apparently need to get completed. Well, the issue here is that they were all completed a year ago, and have been held up by some mysterious process. However, I for one would welcome a smaller WG, focused only on L3VPN, which would not get distracted by L2VPN issues. (Though I seem to be the only WG participant to welcome this ;-)) I do anticipate some problems with the IESG (as Marco hints) on L3VPN, but I don't think that those problems will be any less if we keep the topics combined in one WG ;-) Thomas> The above could be read as indicating that the discussion/urgency of Thomas> the L2 work is pushing out or drowning out discussion on L3 topics. Yes, I do think so. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 14:03:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10444 for ; Wed, 7 May 2003 14:03:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47I5pY25552 for ; Wed, 7 May 2003 14:05:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47I5gE09377 for ; Wed, 7 May 2003 14:05:43 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Alex Zinin , ppvpn@nortelnetworks.com Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 12:56:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314B9.978C7218" X-LYRIS-Message-Id: 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_01C314B9.978C7218 Content-Type: text/plain Hi Alex, The proposed split seems to put very little emphasis on the "PP" of PPVPN. The proposed focus on technologies for L2 and L3 is likely to seriously disrupt the focus on the "Provider Provisioned" concept, where much of the value comes from aiming for interoperation across all major VPN technologies. Of course, we could have PPL2VPN and PPL3VPN, but as has been pointed out, we then need to coordinate the "PP" parts across the two WGs. VPN customers want a bundle of VPN services, and don't really care whether it is L2 or L3 (or L1) or some mixture. VPN service providers want an interoperable toolkit which they can use to design services that they can differentiate in various ways to attract VPN customers. PPVPN is providing a forum to define the operation of the VPN tools. Regardless of L2 or L3 technologies, there is a need for simple and interoperable mechanisms for VPN membership and discovery, security considerations, SLA verification, and a host of management areas. These mechanisms are being defined, clarified, and debated in PPVPN mostly without regard to the specific L2 or L3 approaches. They should not be either dropped, or split across two WGs. Yes there is a lot of work in the group, but if it gets fragmented and things slip through the cracks, then we will be forcing the VPN service providers, vendors, and customers to do much more work and spend much more time in the long run. In terms of meeting logistics, we will find that many of the same people will be attending and developing drafts for the proposed L2 and L3 WGs, so we will have to make sure that they don't overlap... Just the same as if we plan extended meeting times for the current PPVPN when it is needed. Finally, I'm closely involved with two areas of work in L3 VPNs in PPVPN, and we are getting to the point where much of the basic work is stable, so the L3VPN may not justify a dedicated WG for much longer, although it does need a WG in which to operate. I would suggest planning for a longer meeting in Vienna (if the agenda justifies it) and bringing this proposal up for discussion there. Regards, Paul > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Sunday, May 04, 2003 3:12 AM > To: ppvpn@nortelnetworks.com > Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten; > Peterson, Jon; Allison Mankin > Subject: IMPORTANT: Strategy for VPN work in IETF > > > Folks, > > Since San Francisco IETF meeting the IESG has been > considering the situation in the SUB-IP area and in the PPVPN > Working Group in particular. > > Such close attention to this WG was triggered by numerous > concerns that the IESG members received from the WG > participants about limited and slow progress within the WG > despite the efforts of the WG chairs and its members. The > IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to > improve WG > focus and productivity and ensure faster progress of the > VPN-related work: > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > The L2 and L3 VPN work spaces are each big enough to > warrant a separate > WG. While concentration of all VPN-related work in a > single forum was > the right thing to do to ensure coordination of efforts > when the PPVPN > WG was created and L2 VPN work came in, such > concentration is causing > scaling problems within the WG at this moment. > > Migration of work into two separate WGs for L2 and L3 VPN > technologies > with more specific WG charters will help to focus > discussions, prevent > staff and meeting time overloading, and will aid faster > progress of > corresponding technologies. > > 2. Migration of the VPN-related work to the Internet area. > > As previously discussed, VPN-related work could be argued > to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where > we believe > the VPN work should go. > > As part of this move, we are also considering moving PWE3 > into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating > in the same > area. > > Based on the above considerations, we are considering the > following steps: > > 1. Two new WGs--L2VPN and L3VPN--will be created in the > Internet area. > The mailing lists will be established and the discussion > of the proposed > charters of the new WGs will be initiated shortly. > > 2. Once the charters of the new WGs are agreed upon and > approved by the IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the > PPVPN WG will be > performed simultaneously. PPVPN WG documents will be > migrated to the > corresponding new WGs. > > It is our intention to complete this process by the Vienna > IETF meeting. > Also, these changes are being made for management reasons and > are not intended > to be a "reset" on WG activities or to halt or interrupt > progress on current > ongoing WG activities. > > We'd like to hear from the WG members if they see any fatal > flaws with the proposed approach. Please send us your > feedback by May 11th. > > Regards, > > -- > Alex Zinin > IETF SUB-IP Area Co-Director > > > ------_=_NextPart_001_01C314B9.978C7218 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IMPORTANT: Strategy for VPN work in IETF

Hi Alex,

The proposed split seems to put very little emphasis = on the "PP" of PPVPN.

The proposed focus on technologies for L2 and L3 is = likely to seriously disrupt the focus on the "Provider = Provisioned" concept, where much of the value comes from aiming = for interoperation across all major VPN technologies.  Of course, = we could have PPL2VPN and PPL3VPN, but as has been pointed out, we then = need to coordinate the "PP" parts across the two WGs.  =

VPN customers want a bundle of VPN services, and = don't really care whether it is L2 or L3 (or L1) or some mixture.  = VPN service providers want an interoperable toolkit which they can use = to design services that they can differentiate in various ways to = attract VPN customers. PPVPN is providing a forum to define the = operation of the VPN tools.  Regardless of L2 or L3 technologies, = there is a need for simple and interoperable mechanisms for VPN = membership and discovery, security considerations, SLA verification, = and a host of management areas.  These mechanisms are being = defined, clarified, and debated in PPVPN mostly without regard to the = specific L2 or L3 approaches.  They should not be either dropped, = or split across two WGs.

Yes there is a lot of work in the group, but if it = gets fragmented and things slip through the cracks, then we will be = forcing the VPN service providers, vendors, and customers to do much = more work and spend much more time in the long run.

In terms of meeting logistics, we will find that many = of the same people will be attending and developing drafts for the = proposed L2 and L3 WGs, so we will have to make sure that they don't = overlap... Just the same as if we plan extended meeting times for the = current PPVPN when it is needed.

Finally, I'm closely involved with two areas of work = in L3 VPNs in PPVPN, and we are getting to the point where much of the = basic work is stable, so the L3VPN may not justify a dedicated WG for = much longer, although it does need a WG in which to operate.

I would suggest planning for a longer meeting in = Vienna (if the agenda justifies it) and bringing this proposal up for = discussion there.

Regards,
Paul

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: Sunday, May 04, 2003 3:12 AM
> To: ppvpn@nortelnetworks.com
> Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas = Narten;
> Peterson, Jon; Allison Mankin
> Subject: IMPORTANT: Strategy for VPN work in = IETF
>
>
> Folks,
>
> Since San Francisco IETF meeting the IESG has = been
> considering the situation in the SUB-IP area = and in the PPVPN
> Working Group in particular.
>
> Such close attention to this WG was triggered = by numerous
> concerns that the IESG members received from = the WG
> participants about limited and slow progress = within the WG
> despite the efforts of the WG chairs and its = members. The
> IESG also used this opportunity to consider the = IETF area
> that the PPVPN work would fit best.
>
> After much deliberation, the involved ADs = (Bert, Thomas, and I) are
> considering the following organizational = changes in order to
> improve WG
> focus and productivity and ensure faster = progress of the
> VPN-related work:
>
>  1. Split of Layer-2 and Layer-3 VPN work = in separate Working Groups.
>
>     The L2 and L3 VPN work = spaces are each big enough to
> warrant a separate
>     WG. While concentration = of all VPN-related work in a
> single forum was
>     the right thing to do = to ensure coordination of efforts
> when the PPVPN
>     WG was created and L2 = VPN work came in, such
> concentration is causing
>     scaling problems within = the WG at this moment.
>
>     Migration of work into = two separate WGs for L2 and L3 VPN
> technologies
>     with more specific WG = charters will help to focus
> discussions, prevent
>     staff and meeting time = overloading, and will aid faster
> progress of
>     corresponding = technologies.
>
>  2. Migration of the VPN-related work to = the Internet area.
>
>     As previously = discussed, VPN-related work could be argued
> to belong
>     to more than one area. = Tunneling mechanisms are the property that
>     gravitates this work to = the Internet area, which is where
> we believe
>     the VPN work should = go.
>
>     As part of this move, = we are also considering moving PWE3
> into INT,
>     so that L2TPEXT, PWE3, = and thew new VPN WGs are operating
> in the same
>     area.
>
> Based on the above considerations, we are = considering the
> following steps:
>
>  1. Two new WGs--L2VPN and L3VPN--will be = created in the
> Internet area.
>     The mailing lists will = be established and the discussion
> of the proposed
>     charters of the new WGs = will be initiated shortly.
>
>  2. Once the charters of the new WGs are = agreed upon and
> approved by the IESG,
>     creation of the L2VPN = and L3VPN WGs and shutdown of the
> PPVPN WG will be
>     performed = simultaneously. PPVPN WG documents will be
> migrated to the
>     corresponding new = WGs.
>
> It is our intention to complete this process by = the Vienna
> IETF meeting.
> Also, these changes are being made for = management reasons and
> are not intended
> to be a "reset" on WG activities or = to halt or interrupt
> progress on current
> ongoing WG activities.
>
> We'd like to hear from the WG members if they = see any fatal
> flaws with the proposed approach. Please send = us your
> feedback by May 11th.
>
> Regards,
>
> --
> Alex Zinin
> IETF SUB-IP Area Co-Director
>
>
>

------_=_NextPart_001_01C314B9.978C7218-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 14:11:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10749 for ; Wed, 7 May 2003 14:11:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47IDTY29991 for ; Wed, 7 May 2003 14:13:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47IDOE01994 for ; Wed, 7 May 2003 14:13:24 -0400 (EDT) Date: Wed, 7 May 2003 13:19:39 -0400 From: Scott W Brim To: Thomas Narten Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Message-ID: <20030507171939.GQ2136@sbrim-w2k> Mail-Followup-To: Scott W Brim , Thomas Narten , ppvpn@nortelnetworks.com, pwe3@ietf.org References: <3EB5E991.5040604@nxp.com> <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4i X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: swb@employees.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: On Wed, May 07, 2003 12:24:18PM -0400, Thomas Narten allegedly wrote: > There is a basic tension in the IETF between having WGs that are > too large (a similar discussion has been ongoing in places like > MobileIP and IPv6 over the last year) and where splitting them up into > smaller WGs can help focus them. Indeed, there have been numerious > conversations about this on the problem-statement list (with one view > being that smaller, focused WGs tending to do a better job of > completing their work than larger ones). I tend to share that view (as > a general observation), and given that there are some 13 documents in > the L3 space alone, I see there being ample work for a standalone WG > to take on. Will splitting up the WGs _guarantee_ this? Of course > not. Does it solve all possible problems? Of course not. But it can > help, and it seems reasonable in my mind to do so in this case. Having related but small, focused WGs is fine as long as communication between them is mandated and kept flowing. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 14:18:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11002 for ; Wed, 7 May 2003 14:18:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47IKlY04441 for ; Wed, 7 May 2003 14:20:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47IKZi22369 for ; Wed, 7 May 2003 14:20:35 -0400 (EDT) Content-Class: urn:content-classes:message Subject: RE: Contribution of the PPVPN WG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 2003 13:40:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A0DEF8C@m-va-bsod03.add0.masergy.com> Thread-Topic: Contribution of the PPVPN WG thread-index: AcMUvVxbCsnyIv+FRXOXMBG2AMWf9QAAJ8JA From: "Ron Haberman" To: "Hamid Ould-Brahim" , "Rahul Aggarwal" , "Pedro Roque Marques" Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: ronh@masergy.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA11002 Hamid, I think it is hard to include to many L2 technologies and expect a yes/no answer. At a minimum there needs to be separation between point-to-point and VPLS. Reason being the type of the SP topologies supporting the customers. A provider may be in a position to provide mainly WAN services, which will allow for easy adoption of PW services (including like-like and any-any) as well as L3 VPNs. Others may have LAN/MAN access to customers which will make it easier to offer VPLS and L3 VPNs as well as PW services but only of the like-like (Ethernet) type. Masergy to answer you specifically, supports L3 VPNs (2547) and L2 VPNs (martini like-like/any-any, VPLS) on the same IP/MPLS network but is using a different set of LSPs for each type of VPN. Ron. -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Wednesday, May 07, 2003 12:19 PM To: Rahul Aggarwal; Pedro Roque Marques Cc: PPVPN@nortelnetworks.com Subject: RE: Contribution of the PPVPN WG Rahul, > > Do providers feel they are unable to deploy/offer L3 VPN > service because > of limitations with the WG ? > > Do providers feel they are unable to deploy/offer L2 VPN > service because > of limitations with the WG ? > I add to it this question as well: "In general, are the providers/operators deploying layer-3 vpn services across IP/MPLS networks the same ones who will deploy layer-2 vpn services (across the same IP/MPLS network)?" - note that layer 2vpn includes vpws, vpls, like-to-like, any-to-any, etc... Hamid. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 14:28:58 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11484 for ; Wed, 7 May 2003 14:28:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47IVOY09240 for ; Wed, 7 May 2003 14:31:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47IVKE21040 for ; Wed, 7 May 2003 14:31:20 -0400 (EDT) Message-Id: <200305071757.h47HvIe7003926@rotala.raleigh.ibm.com> To: Scott W Brim , ppvpn@nortelnetworks.com, pwe3@ietf.org Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: Message from swb@employees.org of "Wed, 07 May 2003 13:19:39 EDT." <20030507171939.GQ2136@sbrim-w2k> Date: Wed, 07 May 2003 13:57:18 -0400 From: Thomas Narten X-SMTP-HELO: e1.ny.us.ibm.com X-SMTP-MAIL-FROM: narten@us.ibm.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: e1.ny.us.ibm.com [32.97.182.101] X-LYRIS-Message-Id: Scott W Brim writes: > Having related but small, focused WGs is fine as long as communication > between them is mandated and kept flowing. Complete agreement, and keeping that communication going is something I will be watching for. That is also an argument for putting pwe3 and the ppvpn groups together (and also l2tpext) in the same area since they all do relate to varying degrees. Thomas From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 14:36:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11828 for ; Wed, 7 May 2003 14:36:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47IcQY14017 for ; Wed, 7 May 2003 14:38:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47IcLE29041 for ; Wed, 7 May 2003 14:38:22 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com, Thomas Narten Cc: Waldemar Augustyn , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: RE: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 14:08:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314C3.B7798FA2" X-LYRIS-Message-Id: 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_01C314C3.B7798FA2 Content-Type: text/plain; charset="iso-8859-1" Thomas, Eric, > > Thomas> The above could be read as indicating that the > discussion/urgency of > Thomas> the L2 work is pushing out or drowning out discussion > on L3 topics. > > Yes, I do think so. To be more precise, the discussions were mostly on vpls service, and since l2vpn includes services other than vpls, this could be read as well that vpls discussion/urgency is pushing out or drowning out discussions on other l2vpn services. In that respect, creating a new l2vpn wg will not make the situation any better. Hamid. ------_=_NextPart_001_01C314C3.B7798FA2 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF

Thomas, Eric,

>
> Thomas> The above could be read as indicating that the
> discussion/urgency of
> Thomas> the L2 work is pushing out or drowning out discussion
> on L3 topics.
>
> Yes, I do think so.

To be more precise, the discussions were mostly on vpls service,
and since l2vpn includes services other than vpls, this could
be read as well that vpls discussion/urgency is pushing out or
drowning out discussions on other l2vpn services. In that
respect, creating a new l2vpn wg will not make the situation any
better.

Hamid.

------_=_NextPart_001_01C314C3.B7798FA2-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 14:50:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12346 for ; Wed, 7 May 2003 14:50:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47IqmY20544 for ; Wed, 7 May 2003 14:52:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47Iqix14818 for ; Wed, 7 May 2003 14:52:44 -0400 (EDT) Date: Wed, 7 May 2003 11:07:09 -0700 (PDT) Message-Id: <200305071807.h47I79Y64346@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , , Subject: RE: Comments on the L2 VPN framework and solutions documents In-Reply-To: <007601c314a6$c1f6a7c0$210110ac@corp.telseon.com> References: <049AAFED91851244B9FF74D0D9D0EB720215005A@WHISTLER.WaveSmithNet.com> <007601c314a6$c1f6a7c0$210110ac@corp.telseon.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mick Seaman writes: > If the fully meshed pseudowires (and the attached > equipment/functions at their ends) provide a LAN Service (stictly > the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause > 6.5 (same number clause in both documents) then RSTP/MSTP will work > just fine. > To be more specific P802.1ad does specify the operation of a single > instance of MSTP within a Provider Network, how that travels over > pseduowires is of course how any LAN traffic travels over > psedudowires (i.e. the pseudowire protocol looks after making sure > the configuration of the pseudo wires correctly provides the fully > connected LAN service, that not being either MSTPs design goal or > the desire of P802.1ad to specify the simulation of LANs over > non-LAN media, particularly where the non-LAN media have native > protocols that are to be used as part of the solution - MPLS for > example). Mick, Running the risk of abusing your patience to explain basic things... Assume i have provider bridges [A-Z]. Bridge A has two VPLSs: - VPLS 1 has attachement points in A B C. - VPLS 2 has attachement points in A C D. I got the impression that the model that Norm Finn is attempting to explain to the WG is one where xSTP actually involves A sending BPDUs to all provider bridges in the domain [A-Z]. At least that was my reading of the fact that in that model 'one VPLS instance exchanges BPDUs for the entire provider bridge'. If this is the case, in steady state and assuming that the root bridges on the custumer domain is attached to A, would this result in A flooding a single xSTP BPDU to [B-Z] w/ information about both VPLSs or one BPDU per VPLS ? thanks, Pedro. P.S.: Any recomended literature on this topic ? From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 14:56:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12466 for ; Wed, 7 May 2003 14:56:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47IweY24134 for ; Wed, 7 May 2003 14:58:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47IwWx20803 for ; Wed, 7 May 2003 14:58:33 -0400 (EDT) Date: Wed, 7 May 2003 11:28:15 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6857870813.20030507112815@psg.com> To: Pedro Roque Marques CC: ppvpn@nortelnetworks.com, idr@merit.edu Subject: Re: On BGP and VPLS In-Reply-To: <200305030805.h4385Kd51107@roque-bsd.juniper.net> References: <51133594448.20030502191439@psg.com> <200305030805.h4385Kd51107@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Pedro, Sorry for the delay. I found your message in my IDR folder just recently. I'll limit my involvement to this message, I think I will have said enough for my opinion to be heard :) > This point seems to be predicated in the statement that "BGP uses the > NLRI field to carry IP reachability"... Yes, plus that "BGP is an IP routing protocol." > It opens up a sort of philosophical discussion on BGP. This is of > course a highly subjective topic which is hard to quantify or to prove > by logical terms. > Allow me to present my personal view. > BGP is a particular implementation of an algorithm that performs non > looping database flooding distribution. That algorithm consists mostly > on the path vector (used both in ebgp and route reflection) plus route > advertisement rules. This is the publicly specified part of the beast. This is where we disagree in the first place. There's a fine line between a database distribution flooding algorithm and a path-vector routing algorithm. BGP is clearly not the former. > However that ends up being about 10% of the database exchange > algorithm. Each implementation uses distinct algorithms to do the real > heavy lifting: the advertisement of database updates to its peers, > given that each peer is allowed to flow control and that the ammount > of information to be distributed is typically non-trivial compared to > the resources of the system. > None of the functions above actually do depend on the format of your > database records. As long as there is a primary key associated with > each record. Modern implementations, given that they are required to > handle 3/4 different types of records w/ different keys (ipv4, ipv6, > 2547, 2547-for-ipv6, etc) will tend to treat these keys just as > database systems do: as a bit string without any semantics associated > w/ it. > Note also that the number of distinct tables exchanged in a 2547 > implementation may be in the thousands. So segregation of which record > belongs to which table is necessarily a solved problem in practice. > There is one part of BGP that however interacts w/ the semantics of > the particular database being exchanged: route selection from the > Loc-RIB. > The Loc-RIB is by definition where BGP interacts w/ remaining users of > the database and it includes rules that are system specific. > As an exercise, if we take the existing spec and do: > s/route/record/g > s/IP prefix/key/g > Do we still have a document that makes sense.. ? I'm not sure :) > Except for the vague bits about aggregation, about which BGP itself > does little about, i would contend that the result would be pretty > much the same. You are forgetting the parts about Loc-RIB, routing and forwarding tables, next-hop, etc. In any case, such a beast would seize to be an IP routing protocol, but would still perform best path selection to an opaque key in the Internet. If you need a database distribution mechanism as you described above, you don't need the path vector behavior, nor per-peer state for each key, nor next-hops. I.e., you don't need what BGP does. > 2547 which you cite is a particular good example, imho. A 2547 NLRI > ends up being used to create IP reachability information, but while it > is a safi 128 record, it is not IP reachability and it is not treated > as such. 2547 augments _IP prefixes_ with route distinguishers only to make sure that the prefix is unique when used as the key in the RIB. The rest of the reachability/prefix semantics are preserved. >> 2. Distribution of information > That is not the case w/ 2547. PE routers typically have interest in > only a subset of the routing information. They tend to do inbound > filtering in current network deployements but one can also do outbound > filtering in the RRs via either extended-community ORF or subsequent > improvements to ORF (draft-marques-ppvpn-rt-contrain). Note that I purposely compared the approach in the document with the base BGP, not 2547. > P routers do not carry 2547 routing information. Unless the SPs want to use the existing RR infrastructure. > RR in VPN deployments are typically not in the topology. My > understanding of the P-router term is that it is a transit node that > does not have VPN information. Agree, they don't have to. The text should have been "More than that, route reflectors (in some cases implemented on P routers) end up..." > Not really... i can advertise the same key from multiple sources in > L2VPNs also. All policy mechanisms do work... igp distance, etc. It is > just the semantics once the path is selected that are different. > As an example think working and protect PE for a given emulated > circuit (or lan). I think you might have missed my point here. Though a BGP speaker will receive the same key from multiple sources, and will select the best path to it, in the VPLS case, it is not interested in the _best_ path, it is interested in only receiving the key, regardless of where it comes from. > I don't know which model you have in mind but in a typical VPN > deployment scenario (l3 or l2/vpls/etc) a PE has 2 peering sessions to > a RR outside of the topology. The second copy of the information is > there for redudancy... > If a full mesh where used, only 1 copy would be present. So RR and eBGP are the examples where a given BGP speaker would receive extra copies of information. As I replied to Mark: Well, in the IP/BGP case, it is not necessarily the same info, as path attributes are likely to be different and the BGP speaker is interested in selecting the best among them while preserving others as the back-up. In the VPLS case, we don't need the best, just one copy is sufficient. This is not necessarily an issue per se, rather an interesting observation exposing the transport nature of this particular proposed application of BGP. We have similar properties (more than one copy received) in the flooding algorithm in IGPs, but we admit that flooding is a transport component very specific to IGPs (where every node needs all info, btw), and we don't keep track of where we receive PDUs from as we do in BGP. >> 3. Aggregation of information for large-scale operation ... > To give you an example, in JunOS aggregation is implemented as a > separate routing protocol... if i'm not mistaken the model is lifted > from 'gated'. Clearly the idea that aggregation may be a distinct > component from BGP has been around for a while. This does not change the fact that information that BGP as an IP routing protocol distributes is aggregateable. Also note that route aggregation rules are part of the routing protocol specification and definitely depend on the protocol behavior (true for BGP, OSPF, and ISIS), so it is not a completely distinct notion, though some implementations decouple the two. > VPLS doesn't really need aggregation although it does use an IGP :-) > PE to PE connectivity is performed indepently from the 'forwarding > distinguisher' advertisement (i.e. the inner label). Any or multiple > routing and singaling protocols may be used for this > functionality. Only the information exterior to the SP network > (service attachements) is carried through BGP. This part should go into the thread on "Info Summarization" where one of the questions is how we can limit the amount of state/information that a given participating node will have to maintain. I'd like to again highlight the difference between aggregateable semantics of NLRI contents in BGP when used as IP routing protocols, and non-aggregateable semantics of it in the proposal, which means that mechanisms different from those existing in current BGP practices would need to be used to limit the amount of maintained info. >> The above gives me a very uncomfortable feeling that the proposal >> is stretching BGP to perform functions it was not designed for. > Any succesful protocol will be used for means other than it was > designed for. That is usually a sign that the designers got something > right. I was being mild. >> 4. Backwards compatibility and SW upgrade requirements > That is not an issue as we've seen above. The deployment model is > different from what you assume. As before, unless the SPs want to use the existing RR infrastructure. >> 5. Coupling of VPLS and BGP SW >> a) Lesser BGP code stability--bugs in the VPLS part of the code > You have no basis to conclude that. I do :) > Any modern BGP implementation worth its salt consists of > AF-independent code + AF-specific code. The fact is that you can > implement VPLS without touching the AF-independent code. The fact is that pieces of code in routing protocol implementations are not only statically related via the function call tree, but also dynamically and indirectly... but I will stop right here, because we'll inevitably get into implementation specifics... >> b) Potential dynamic effects--since with a BGP-based approach, > I'm sorry but this is just FUD. I hope people don't think about potential interference between large distributed systems as FUD. > All router implementations do have some level of resource sharing > between completly unrelated features. In some of them, all > functionality shares all resources. Agreed, though I was talking about tighter coupling when Inet BGP and VPLS BGP are in the same process/thread (which is very likely the case). As I told in my answer to Mark: I tend to look at this more broadly--putting VPLS functionality in BGP increases the chances of interference. Some consider this a strictly implementation-specific issue. I think that whether or not VPLS-specific functionality is sufficiently decoupled from base BGP is an implementation aspect; while increased risk of interference is an architectural one. Again, I'll stop here too. >> My recommendation would be for the WG to consider these points. > The way i see it there is an high likely-hood of this turning into an > "Yes, it is" "No, it isn't" discussion. And I'd really like to avoid > that. Agreed. > A question to you and to the WG(s) in general: > - What are the main concerns that you have w/ the generic database > exchange view of BGP (Lets call it the "Basically General Purpose" > theory). The fact that BGP is not a generic database exchange protocol, and I don't think it should be positioned as such. > - Can we have a reasonable discussion about the best engineering > approach to provide database exchange services for > routing-related-applications without getting into a religious argument > about "2547 is evil" ? i.e. can we try to separate how highly each one > of us rates the actual application from this discussion ? I think we'll have to agree on the definition of "database exchange services" and "routing-related-applications", but generally, yes, sure. > - I believe one of the preconditions for a resonable discussion is to > realise that implementors are the most interested people in not > introducing regressions to shipping code. They actually get to fix it > after being screamed at for a considerable lenght of time. > I'd really like to get past the "you can't implement a feature i don't > want because your are going to break the code" kind of discussion. I think there is a generally good understanding of this. I don't think this is something that is sufficient for the IETF to base technical conclusions on. > - Are we going to have a similiar discussion about LDP ? LDP is not > any less relevant for network stability nor a protocol which is any > simpler than BGP (if anything the level of complexity is higher given > that LDP has all the db exchange problem of BGP + a non trivial > ammount of issues of its own). I have absolutely no problem with this. Thanks for your comments. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 15:37:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14781 for ; Wed, 7 May 2003 15:37:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47JdkY08763 for ; Wed, 7 May 2003 15:39:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47Jdhw14599 for ; Wed, 7 May 2003 15:39:43 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Ron Haberman , Rahul Aggarwal , Pedro Roque Marques Cc: PPVPN@nortelnetworks.com Subject: RE: Contribution of the PPVPN WG Date: Wed, 7 May 2003 15:37:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314D0.11661844" X-LYRIS-Message-Id: 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_01C314D0.11661844 Content-Type: text/plain; charset="iso-8859-1" Ron > > I think it is hard to include to many L2 technologies and expect a > yes/no answer. Sure. In fact I wasn't expecting yes/no but in general situations, whether those who are building IP/MPLS type networks plan to offer both layer-2 and layer-3 vpns (regardless of the debate on protocols, etc). >At a minimum there needs to be separation between > point-to-point and VPLS. Reason being the type of the SP topologies > supporting the customers. A provider may be in a position to provide > mainly WAN services, which will allow for easy adoption of PW services > (including like-like and any-any) as well as L3 VPNs. Others may have > LAN/MAN access to customers which will make it easier to > offer VPLS and > L3 VPNs as well as PW services but only of the like-like (Ethernet) > type. > Masergy to answer you specifically, supports L3 VPNs (2547) > and L2 VPNs > (martini like-like/any-any, VPLS) on the same IP/MPLS network but is > using a different set of LSPs for each type of VPN. > Thanks for sharing that with us. I suppose you mean the PE-PE LSPs. Hamid. ------_=_NextPart_001_01C314D0.11661844 Content-Type: text/html; charset="iso-8859-1" RE: Contribution of the PPVPN WG

Ron

>
> I think it is hard to include to many L2 technologies and expect a
> yes/no answer.

Sure. In fact I wasn't expecting yes/no but in general
situations, whether those who are building IP/MPLS type
networks plan to offer both layer-2 and layer-3 vpns
(regardless of the debate on protocols, etc).

>At a minimum there needs to be separation between
> point-to-point and VPLS. Reason being the type of the SP topologies
> supporting the customers. A provider may be in a position to provide
> mainly WAN services, which will allow for easy adoption of PW services
> (including like-like and any-any) as well as L3 VPNs. Others may have
> LAN/MAN access to customers which will make it easier to
> offer VPLS and
> L3 VPNs as well as PW services but only of the like-like (Ethernet)
> type.

> Masergy to answer you specifically, supports L3 VPNs (2547)
> and L2 VPNs
> (martini like-like/any-any, VPLS) on the same IP/MPLS network but is
> using a different set of LSPs for each type of VPN.
>

Thanks for sharing that with us. I suppose you mean the
PE-PE LSPs.

Hamid.

------_=_NextPart_001_01C314D0.11661844-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 15:41:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15004 for ; Wed, 7 May 2003 15:41:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47JiGY12883 for ; Wed, 7 May 2003 15:44:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47JiBw19570 for ; Wed, 7 May 2003 15:44:12 -0400 (EDT) Content-Class: urn:content-classes:message Subject: RE: Contribution of the PPVPN WG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 2003 15:41:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A044DDA@m-va-bsod03.add0.masergy.com> Thread-Topic: Contribution of the PPVPN WG thread-index: AcMU0BXYYesHKzB9RfOcvkryxI+y5gAAEvmQ From: "Ron Haberman" To: "Hamid Ould-Brahim" , "Rahul Aggarwal" , "Pedro Roque Marques" Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: ronh@masergy.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA15004 Hamid, Inline... -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Wednesday, May 07, 2003 3:37 PM To: Ron Haberman; Rahul Aggarwal; Pedro Roque Marques Cc: PPVPN@nortelnetworks.com Subject: RE: Contribution of the PPVPN WG Ron > > I think it is hard to include to many L2 technologies and expect a > yes/no answer. Sure. In fact I wasn't expecting yes/no but in general situations, whether those who are building IP/MPLS type networks plan to offer both layer-2 and layer-3 vpns (regardless of the debate on protocols, etc). >At a minimum there needs to be separation between > point-to-point and VPLS. Reason being the type of the SP topologies > supporting the customers. A provider may be in a position to provide > mainly WAN services, which will allow for easy adoption of PW services > (including like-like and any-any) as well as L3 VPNs. Others may have > LAN/MAN access to customers which will make it easier to > offer VPLS and > L3 VPNs as well as PW services but only of the like-like (Ethernet) > type. > Masergy to answer you specifically, supports L3 VPNs (2547) > and L2 VPNs > (martini like-like/any-any, VPLS) on the same IP/MPLS network but is > using a different set of LSPs for each type of VPN. > Thanks for sharing that with us. I suppose you mean the PE-PE LSPs. RH> Yes I do. Hamid. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 16:31:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16538 for ; Wed, 7 May 2003 16:31:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47KY2Y13776 for ; Wed, 7 May 2003 16:34:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47KXvB22094 for ; Wed, 7 May 2003 16:33:58 -0400 (EDT) Date: Wed, 7 May 2003 13:30:24 -0700 (PDT) Message-Id: <200305072030.h47KUOC64557@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: ppvpn@nortelnetworks.com, idr@merit.edu Subject: Re: On BGP and VPLS In-Reply-To: <6857870813.20030507112815@psg.com> References: <51133594448.20030502191439@psg.com> <200305030805.h4385Kd51107@roque-bsd.juniper.net> <6857870813.20030507112815@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex Zinin writes: > Pedro, Sorry for the delay. I found your message in my IDR folder > just recently. I'll limit my involvement to this message, I think I > will have said enough for my opinion to be heard :) Alex, >> The way i see it there is an high likely-hood of this turning into >> an "Yes, it is" "No, it isn't" discussion. And I'd really like to >> avoid that. > Agreed. It seems to me that we immediatly got into this dead-lock point. Allow me to make a further attempt to clarify my point of view. >> This point seems to be predicated in the statement that "BGP uses >> the NLRI field to carry IP reachability"... > Yes, plus that "BGP is an IP routing protocol." That is one possible application of BGP. It does not invalidate that possibility of other applications. Let me rephrase my point: It is possible to extract from the BGP specification a common set of functionality that is independent of 'IP routing'. Such common set of functionality consists on the ability to flood databases of information accross multiple domains, in a distributed fashion. Since this problem reoccurs often in networking, several other applications have made use of this commonality to avoid reinventing the wheel. The 'common functionality' in question is not so much what is documented in the BGP specification but the algorithms required to implement it. > This is where we disagree in the first place. > There's a fine line between a database distribution flooding > algorithm and a path-vector routing algorithm. BGP is clearly not > the former. "Yes, it is" :-) Give me an argument and i'll try a more productive response. >> As an exercise, if we take the existing spec and do: >> s/route/record/g s/IP prefix/key/g >> Do we still have a document that makes sense.. ? > I'm not sure :) >> Except for the vague bits about aggregation, about which BGP itself >> does little about, i would contend that the result would be pretty >> much the same. > You are forgetting the parts about Loc-RIB, routing and forwarding > tables, next-hop, etc. In any case, such a beast would seize to be > an IP routing protocol, but would still perform best path selection > to an opaque key in the Internet. If you need a database > distribution mechanism as you described above, you don't need the > path vector behavior, nor per-peer state for each key, nor > next-hops. I.e., you don't need what BGP does. You repeat this argument throughout your e-mail. And i'm completly missing your point: The path-vector algorithm is essential to the flooding of the BGP database information. Without it flooding would eternally loop. path-vector as in: o as-path and cluster-list loop detection o iBGP doesn't advertise iBGP This is what makes BGP flooding work. None of this information is used for Loc-rib purposes. >>> 2. Distribution of information [...] >> P routers do not carry 2547 routing information. > Unless the SPs want to use the existing RR infrastructure. All the SPs i've worked with explicitly do not want to do this. >> Not really... i can advertise the same key from multiple sources in >> L2VPNs also. All policy mechanisms do work... igp distance, etc. It >> is just the semantics once the path is selected that are different. >> As an example think working and protect PE for a given emulated >> circuit (or lan). > I think you might have missed my point here. Though a BGP speaker > will receive the same key from multiple sources, and will select the > best path to it, in the VPLS case, it is not interested in the > _best_ path, it is interested in only receiving the key, regardless > of where it comes from. That is factually incorrect. I gave you an example in the original e-mail to illustrate the point. The same 'key' maybe advertised from more than one source. BGP needs to select the best-path in any such occurence. > So RR and eBGP are the examples where a given BGP speaker would > receive extra copies of information. As I replied to Mark: > Well, in the IP/BGP case, it is not necessarily the same info, > as path attributes are likely to be different and the BGP speaker is > interested in selecting the best among them while preserving others > as the back-up. In the VPLS case, we don't need the best, just one > copy is sufficient. That is incorrect. PE1 advertises 'key' preference 100, label 10000 - this is working circuit. PE2 advertises 'key' preference 200, label 10001 - this is protect circuit. It works just like IP routing. All the preference mechanisms that you use in IP routing can be used here. IGP failure to PE1 for instance, causes a remote system to automatically reroute. > This does not change the fact that information that BGP as an IP > routing protocol distributes is aggregateable. That doesn't mean that BGP does aggregate anything either. BGP doesn't specify any algorithm for aggregation itself. What BGP does address is the interaction between possible aggregation and its loop detection mechanism. > Also note that route > aggregation rules are part of the routing protocol specification and > definitely depend on the protocol behavior (true for BGP, OSPF, and > ISIS), so it is not a completely distinct notion, though some > implementations decouple the two. BGP does not specify any rules for what routes should be aggregated or into what they should be aggregated. It cannot since these are operational decisions. The statement above is false as far as i can understand it. >>> 5. Coupling of VPLS and BGP SW >>> a) Lesser BGP code stability--bugs in the VPLS part of the >>> code >> You have no basis to conclude that. > I do :) Please present a justification then. We are back to "no, it isn't" / "yes, it is" mode. > The fact is that pieces of code in routing protocol implementations > are not only statically related via the function call tree, but also > dynamically and indirectly... but I will stop right here, because > we'll inevitably get into implementation specifics... This is what i call FUD... "Uncertainty" not being backed by any argument. The way i see it this is a central piece of your (IESG) original "concern" statement. >>> b) Potential dynamic effects--since with a BGP-based approach, >> I'm sorry but this is just FUD. > I hope people don't think about potential interference between large > distributed systems as FUD. You are wording it just that way: "potential interference between large distributed systems". No facts, no specific points. Just vague allegations. If the above is "fair game" then i want to ask the IESG to use the same "potential interference" criterium to, say, IPv6... IPv6 not only involves changes to BGP to support this NLRI but changes to all hosts and pretty much all protocols and applications. It can "dynamically and indirectly" cause interference too. Perhaps IPv6 is a treat to the internet stability ? Since i don't intend to run IPv6 in the forseable future it standardization of IPv6 is going cause 'interference' with my workstation software, which i rather not deal with. > I tend to look at this more broadly--putting VPLS functionality > in BGP increases the chances of interference. Some consider this a > strictly implementation-specific issue. I think that whether or not > VPLS-specific functionality is sufficiently decoupled from base BGP > is an implementation aspect; while increased risk of interference is > an architectural one. I believe that this completly confuses architecture with implementation. This is not an architectural consideration. This is a vague aspersion on the competency of BGP implementors. Your argument taken to the extreme would result in forbidding all and any standardization of new software mechanisms. Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 16:59:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17332 for ; Wed, 7 May 2003 16:59:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47L1vY01802 for ; Wed, 7 May 2003 17:01:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47L1oW08822 for ; Wed, 7 May 2003 17:01:50 -0400 (EDT) Date: Wed, 7 May 2003 13:58:58 -0700 (PDT) Message-Id: <200305072058.h47Kww664593@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: ppvpn@nortelnetworks.com, idr@merit.edu Subject: Re: On BGP and VPLS In-Reply-To: <200305072030.h47KUOC64557@roque-bsd.juniper.net> References: <51133594448.20030502191439@psg.com> <200305030805.h4385Kd51107@roque-bsd.juniper.net> <6857870813.20030507112815@psg.com> <200305072030.h47KUOC64557@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Pedro Roque Marques writes: >>> The way i see it there is an high likely-hood of this turning into >>> an "Yes, it is" "No, it isn't" discussion. And I'd really like to >>> avoid that. >> Agreed. Following up on my own e-mail... i don't think it is in any way productive to continue the discussion torwards this path. Lets try to turn the discussion around to the positive side: Ignore VPLS for now. Lets define a problem: 1. A database consisting on entries (key, attr) needs to be propagated accross routers of the same domain and accross different administrative domains. 2. An given key may be originated by more than one of the participating systems. 3. A key advertised via a given member of a domain depends on reachability to that advertiser. Task at hand is to find a solution to the problem above. Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 17:08:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17686 for ; Wed, 7 May 2003 17:08:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47LBGY07312 for ; Wed, 7 May 2003 17:11:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47LBDW03874 for ; Wed, 7 May 2003 17:11:13 -0400 (EDT) Message-Id: <200305072106.RAA19411@workhorse.fictitious.org> To: Pedro Roque Marques cc: Alex Zinin , ppvpn@nortelnetworks.com, idr@merit.edu Reply-To: curtis@fictitious.org Subject: Re: On BGP and VPLS In-reply-to: Your message of "Wed, 07 May 2003 13:30:24 PDT." <200305072030.h47KUOC64557@roque-bsd.juniper.net> Date: Wed, 07 May 2003 17:06:04 -0400 From: Curtis Villamizar X-SMTP-HELO: workhorse.fictitious.org X-SMTP-MAIL-FROM: curtis@workhorse.fictitious.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: workhorse.fictitious.org [209.150.1.230] X-LYRIS-Message-Id: Pedro, This is the BGP4 base spec. The interpretation of the BGP advertisements are IP prefix aka NLRI for which routes are advertised and not general keys mapping to general records. If some extension of BGP4 such as VPN or PW makes some other use of BGP flooding then that's fine but need not be reflected in the base document. The changes that you are only vaguely specifying (s/route/record/g s/IP prefix/key/g) doesn't at all pertain to the use of BGP as defined in the base spec, hasn't been interpreted as being in conflict with any existing document, and I don't think this is a productive discussion during last call of a very key document. Curtis From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 17:15:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17890 for ; Wed, 7 May 2003 17:15:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47LI3Y10383 for ; Wed, 7 May 2003 17:18:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47LHxj07594 for ; Wed, 7 May 2003 17:18:00 -0400 (EDT) Date: Wed, 7 May 2003 14:15:39 -0700 (PDT) Message-Id: <200305072115.h47LFdh64632@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: curtis@fictitious.org Cc: ppvpn@nortelnetworks.com, idr@merit.edu Subject: Re: On BGP and VPLS In-Reply-To: <200305072106.RAA19411@workhorse.fictitious.org> References: <200305072030.h47KUOC64557@roque-bsd.juniper.net> <200305072106.RAA19411@workhorse.fictitious.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Curtis Villamizar writes: > Pedro, > This is the BGP4 base spec. The interpretation of the BGP > advertisements are IP prefix aka NLRI for which routes are > advertised and not general keys mapping to general records. > If some extension of BGP4 such as VPN or PW makes some other use of > BGP flooding then that's fine but need not be reflected in the base > document. > The changes that you are only vaguely specifying (s/route/record/g > s/IP prefix/key/g) doesn't at all pertain to the use of BGP as > defined in the base spec, hasn't been interpreted as being in > conflict with any existing document, and I don't think this is a > productive discussion during last call of a very key document. Curtis, In no way i was suggesting that we change the base spec. My argument is that the flooding algorithm in the BGP spec is applicable to other NLRI-types. And that the document can be, and has been sucesfully used to do so. i.e. it is still a coherent document when you interpret it in the context of a different NLRI-type. regards, Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 17:20:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18259 for ; Wed, 7 May 2003 17:20:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47LN7Y14272 for ; Wed, 7 May 2003 17:23:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47LN4j12236 for ; Wed, 7 May 2003 17:23:04 -0400 (EDT) Message-Id: <200305072120.RAA19579@workhorse.fictitious.org> To: Pedro Roque Marques cc: Alex Zinin , ppvpn@nortelnetworks.com, idr@merit.edu Reply-To: curtis@fictitious.org Subject: Re: On BGP and VPLS In-reply-to: Your message of "Wed, 07 May 2003 13:58:58 PDT." <200305072058.h47Kww664593@roque-bsd.juniper.net> Date: Wed, 07 May 2003 17:20:25 -0400 From: Curtis Villamizar X-SMTP-HELO: workhorse.fictitious.org X-SMTP-MAIL-FROM: curtis@workhorse.fictitious.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: workhorse.fictitious.org [209.150.1.230] X-LYRIS-Message-Id: In message <200305072058.h47Kww664593@roque-bsd.juniper.net>, Pedro Roque Marqu es writes: > Pedro Roque Marques writes: > > >>> The way i see it there is an high likely-hood of this turning into > >>> an "Yes, it is" "No, it isn't" discussion. And I'd really like to > >>> avoid that. > > >> Agreed. > > Following up on my own e-mail... i don't think it is in any way > productive to continue the discussion torwards this path. > > Lets try to turn the discussion around to the positive side: > > Ignore VPLS for now. > > Lets define a problem: > > 1. A database consisting on entries (key, attr) needs to be propagated > accross routers of the same domain and accross different > administrative domains. > > 2. An given key may be originated by more than one of the > participating systems. > > 3. A key advertised via a given member of a domain depends on > reachability to that advertiser. > > Task at hand is to find a solution to the problem above. > > Pedro. Pedro, You are welcome to consider BGP for this key distribution even if the BGP spec does not match the terminology you are looking for. The terminology would not be the deciding factor. If there are technical problems with whatever you propose, that is a separate matter. Now please drop IDR from the Cc and go about doing the ppvpn work, whether it is VPLS or selecting a mechanism for your hypothetical key/attr distribution. Curtis From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 17:46:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18964 for ; Wed, 7 May 2003 17:46:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47LmQY20337 for ; Wed, 7 May 2003 17:48:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47LmM623988 for ; Wed, 7 May 2003 17:48:23 -0400 (EDT) Message-Id: <200305072145.RAA19938@workhorse.fictitious.org> To: Pedro Roque Marques cc: curtis@fictitious.org, ppvpn@nortelnetworks.com, idr@merit.edu Reply-To: curtis@fictitious.org Subject: Re: On BGP and VPLS In-reply-to: Your message of "Wed, 07 May 2003 14:15:39 PDT." <200305072115.h47LFdh64632@roque-bsd.juniper.net> Date: Wed, 07 May 2003 17:45:48 -0400 From: Curtis Villamizar X-SMTP-HELO: workhorse.fictitious.org X-SMTP-MAIL-FROM: curtis@workhorse.fictitious.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: workhorse.fictitious.org [209.150.1.230] X-LYRIS-Message-Id: In message <200305072115.h47LFdh64632@roque-bsd.juniper.net>, Pedro Roque Marqu es writes: > Curtis Villamizar writes: > > > Pedro, > > > This is the BGP4 base spec. The interpretation of the BGP > > advertisements are IP prefix aka NLRI for which routes are > > advertised and not general keys mapping to general records. > > > If some extension of BGP4 such as VPN or PW makes some other use of > > BGP flooding then that's fine but need not be reflected in the base > > document. > > > The changes that you are only vaguely specifying (s/route/record/g > > s/IP prefix/key/g) doesn't at all pertain to the use of BGP as > > defined in the base spec, hasn't been interpreted as being in > > conflict with any existing document, and I don't think this is a > > productive discussion during last call of a very key document. > > Curtis, > In no way i was suggesting that we change the base spec. > > My argument is that the flooding algorithm in the BGP spec is > applicable to other NLRI-types. And that the document can be, and has > been sucesfully used to do so. i.e. it is still a coherent document > when you interpret it in the context of a different NLRI-type. > > regards, > Pedro. So you are not suggesting a change at all to BGP4. If so you don't need to involve the IDR WG in a semantic discussion. If the issue is whether to use BGP4 for distribution of VPLS information and the objection were along the lines of scaling, or some other technical matter then that was not at all clear. Unless I missed something, IDR was added to the Cc mid discussion. If so, maybe you should tell us what draft you are discussing and be clear about what the issue is. Curtis From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 17:49:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19048 for ; Wed, 7 May 2003 17:49:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47LpqY24160 for ; Wed, 7 May 2003 17:51:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47Lpn628364 for ; Wed, 7 May 2003 17:51:49 -0400 (EDT) Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Pedro Roque Marques'" , Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: RE: On BGP and VPLS Date: Wed, 7 May 2003 17:46:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: auemail2.firewall.lucent.com X-SMTP-MAIL-FROM: busschbach@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: auemail2.lucent.com [192.11.223.163] X-LYRIS-Message-Id: > -----Original Message----- > From: Pedro Roque Marques [mailto:roque@juniper.net] > Sent: Wednesday, May 07, 2003 4:59 PM > To: Alex Zinin > Cc: ppvpn@nortelnetworks.com; idr@merit.edu > Subject: Re: On BGP and VPLS > > > Pedro Roque Marques writes: > > >>> The way i see it there is an high likely-hood of this turning into > >>> an "Yes, it is" "No, it isn't" discussion. And I'd really like to > >>> avoid that. > > >> Agreed. > > Following up on my own e-mail... i don't think it is in any way > productive to continue the discussion torwards this path. > > Lets try to turn the discussion around to the positive side: > > Ignore VPLS for now. > > Lets define a problem: > Pedro, It is fine to ignore VPLS and work on some arbitrary problem, but since the discussion takes place on this mailing list, I suspect that in the end, we will somehow circle back to VPLS :-) For VPLS or other L2 VPNs, the primary requirement is that for a given VPN, a PE with an attachment circuit that belongs to that VPN is able to discover the identities of the other PEs with ACs that belong to the same VPN. I don't see what that has to do with the propagation of a database across routers. There is a big difference between L2 VPN autodiscovery and advertizing of routes. L2 VPN parameters are static, provisioned by a service provider and relevant only to the members of the VPN. Route information is dynamic, dependent on the actual network topology and relevant to every node in the network. It seems to me that access to a central database is a much more sensible solution for L2 VPN autodiscovery. Peter > 1. A database consisting on entries (key, attr) needs to be propagated > accross routers of the same domain and accross different > administrative domains. > > 2. An given key may be originated by more than one of the > participating systems. > > 3. A key advertised via a given member of a domain depends on > reachability to that advertiser. > > Task at hand is to find a solution to the problem above. > > Pedro. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 18:50:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21651 for ; Wed, 7 May 2003 18:50:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47MqqY27338 for ; Wed, 7 May 2003 18:52:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47Mqm421922 for ; Wed, 7 May 2003 18:52:48 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6800@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: "Hamid Ould-Brahim" , erosen@cisco.com, narten@us.ibm.com Cc: waldemar@nxp.com, zinin@psg.com, ppvpn@nortelnetworks.com, pwe3@ietf.org, bwijnen@lucent.com, jon.peterson@neustar.biz, mankin@psg.com Subject: RE: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 22:13:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hamid Ould-Brahim wrote 07 May 2003 19:09 Thomas, Eric, > > Thomas> The above could be read as indicating that the > discussion/urgency of > Thomas> the L2 work is pushing out or drowning out discussion > on L3 topics. > > Yes, I do think so. To be more precise, the discussions were mostly on vpls service, and since l2vpn includes services other than vpls, this could be read as well that vpls discussion/urgency is pushing out or drowning out discussions on other l2vpn services. In that respect, creating a new l2vpn wg will not make the situation any better. Hamid. NH=> Excellent observation Hamid. It would seem to me that a L2 VPN service should be nothing more than some form of co pkt-sw managed BW service. This could then be the common *default* VPN solution on which additional *client* layer VPN services (be they IP (rfc2547) or ethernet (VPLS)) can be considered (see my recent posting to Alex which suggested such a view). However, even though I can see logic in grouping together the common server layer aspects and then adding specific client layer aspects as needed, maybe this is not so attractive to some? regards, Neil From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 18:58:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21791 for ; Wed, 7 May 2003 18:58:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47N1JY08600 for ; Wed, 7 May 2003 19:01:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47N1Gh00935 for ; Wed, 7 May 2003 19:01:16 -0400 (EDT) Reply-To: From: "Mick Seaman" To: "'Pedro Roque Marques'" Cc: "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Wed, 7 May 2003 15:59:25 -0700 Message-ID: <000601c314ec$551f2e10$210110ac@corp.telseon.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 CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200305071807.h47I79Y64346@roque-bsd.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SMTP-HELO: pimout4-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout4-ext.prodigy.net [207.115.63.103] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Pedro, For literature see Clause 7 in 802.1s (the MSTP amendment to 802.1Q which will be rolled in to 802.1Q-2003). You can find a copy at: http://www.ieee802.org/1/files/private/s-drafts/d15/802-1s-d15.pdf user: p8021 password: go_wildcats I think this gives a better explanation of how all this layers out in .1Q than the prior version of the document. And I believe I agree with you on what Norm is trying to explain (but he should confirm that himself, as there are many twists possible here). The question about the number of BPDUs per VPLS depends on exactly how you want to do this. I like the single MSTP BPDU answer best. The rest of this answer has to wait until I complete the editing on the soon to be distributed P802.1ad/D1, as I find that the answer is essentially the content I am currently working on. Mick -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Wednesday, May 07, 2003 11:07 AM To: mick_seaman@ieee.org Cc: 'Himanshu Shah'; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'; ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Mick Seaman writes: > If the fully meshed pseudowires (and the attached > equipment/functions at their ends) provide a LAN Service (stictly > the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause > 6.5 (same number clause in both documents) then RSTP/MSTP will work > just fine. > To be more specific P802.1ad does specify the operation of a single > instance of MSTP within a Provider Network, how that travels over > pseduowires is of course how any LAN traffic travels over > psedudowires (i.e. the pseudowire protocol looks after making sure > the configuration of the pseudo wires correctly provides the fully > connected LAN service, that not being either MSTPs design goal or > the desire of P802.1ad to specify the simulation of LANs over > non-LAN media, particularly where the non-LAN media have native > protocols that are to be used as part of the solution - MPLS for > example). Mick, Running the risk of abusing your patience to explain basic things... Assume i have provider bridges [A-Z]. Bridge A has two VPLSs: - VPLS 1 has attachement points in A B C. - VPLS 2 has attachement points in A C D. I got the impression that the model that Norm Finn is attempting to explain to the WG is one where xSTP actually involves A sending BPDUs to all provider bridges in the domain [A-Z]. At least that was my reading of the fact that in that model 'one VPLS instance exchanges BPDUs for the entire provider bridge'. If this is the case, in steady state and assuming that the root bridges on the custumer domain is attached to A, would this result in A flooding a single xSTP BPDU to [B-Z] w/ information about both VPLSs or one BPDU per VPLS ? thanks, Pedro. P.S.: Any recomended literature on this topic ? From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 19:02:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21934 for ; Wed, 7 May 2003 19:02:52 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47N5HY12368 for ; Wed, 7 May 2003 19:05:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47N5Eh12054 for ; Wed, 7 May 2003 19:05:14 -0400 (EDT) Reply-To: From: "Mick Seaman" To: "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" Cc: , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Wed, 7 May 2003 15:42:02 -0700 Message-ID: <000201c314ec$52afb4b0$210110ac@corp.telseon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C314B1.A6526350" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <049AAFED91851244B9FF74D0D9D0EB720215260A@WHISTLER.WaveSmithNet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MS-TNEF-Correlator: 0000000043410BC5A002D6408BB2E6318DA014D26419C700 Importance: Normal X-SMTP-HELO: pimout4-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout4-ext.prodigy.net [207.115.63.103] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C314B1.A6526350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Himanshu, In (1) I think you have your layering a little mixed up. From the point of view of control connectivity the pseudo-wires have to establish a full mesh that is never perceived by layer 2 protocols as being less than complete. STP is running across the service that runs on top of the mechanisms that make the service LAN like. If you wish to provide subset LANs to be configured then of course you can have subsets each of which has full connectivity in itself. Just never try to pretend to layer 2 that two non equal subsets are the same LAN. In (2) I think you are further into the same pit. It is trivial to get into BPDU scaleability issues along the path you suggest. A much more attractive alternative is to maintain a single full mesh for control connectivity which then prunes that mesh per VPLS (each VPLS doesn't have to touch certain mesh nodes) and then uses that pruning to delete VPLS specific pseudowires to the unwanted mesh nodes. Only one instance of the topology determining protocol and the pruning protocol are then required for all VPLSs. The trick here is to put provider provisioning in at the right level in the architecture (i.e. not at the pseudowire level,but higher up so that it can drive the pseudowire level in the context of the actually available resources). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 10:29 AM To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents This digresses from earlier thinking (at least mine) that P-STP would not span across pseudowires. There are several implications to running STP across PWs that may need to be clarified/worked out. 1) "fully-meshed" attribute of the PWs only applied within a context of a VPLS instance. That is, if PE1 and PE2 participated in VPLS instance 1 than there was no pseudowire to PE3 which did not participate in VPLS instance 1. However, with this scheme, each PE would have pseudowire to every other VPLS capable PE irrespective of its VPLS instance membership 2) Assuming that 1 MSTP instance covers entire provider's network, a backdoor link from ProvBridge1 to ProvBridge2 of VPLS instance 1, may cause 802.1ad's emulated LAN ports to all VPLS instances (i.e. all PWs from that PE are in blocked state irrespective of its VPLS instance membership). Doesn't this block other VPLS instances's traffic across PWs? Perhaps my assumption is wrong and there is in fact P-STP instance for each VPLS instance. However, if that is true, PE would run into BPDU scalability issues. /himanshu -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Wednesday, May 07, 2003 10:42 AM To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents If the fully meshed pseudowires (and the attached equipment/functions at their ends) provide a LAN Service (stictly the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both documents) then RSTP/MSTP will work just fine. To be more specific P802.1ad does specify the operation of a single instance of MSTP within a Provider Network, how that travels over pseduowires is of course how any LAN traffic travels over psedudowires (i.e. the pseudowire protocol looks after making sure the configuration of the pseudo wires correctly provides the fully connected LAN service, that not being either MSTPs design goal or the desire of P802.1ad to specify the simulation of LANs over non-LAN media, particularly where the non-LAN media have native protocols that are to be used as part of the solution - MPLS for example). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 6:01 AM To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Norm, You have to excuse me for jumping in at the tail end and not following the thread. I would like a clarification. Are you implying that 802.1ad is contemplating on running one or more (Provider's) instances of R/M/STP on fully-meshed pseudowires? /himanshu Wavesmith Networks -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, May 06, 2003 8:14 PM To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm ------=_NextPart_000_0003_01C314B1.A6526350 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiAWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBQAHAA8AKgAAAAMAIgEB A5AGANAfAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAQ29tbWVudHMgb24gdGhlIEwyIFZQTiBmcmFtZXdvcmsgYW5kIHNvbHV0 aW9ucyBkb2N1bWVudHMAAAAAAgFxAAEAAAAWAAAAAcMU6eCUJdJatS7QTEGwpOoBypo02AAAAgEd DAEAAAAaAAAAU01UUDpNSUNLX1NFQU1BTkBJRUVFLk9SRwAAAAsAAQ4AAAAAQAAGDgAsIt/pFMMB AgEKDgEAAAAYAAAAAAAAAENBC8WgAtZAi7LmMY2gFNLCgAAAAwAUDgEAAAALAB8OAQAAAAIBCRAB AAAAcRsAAG0bAACuPAAATFpGdWmtwRoDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMC gA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1 ESIMYGMAUPMLCQFkMzYWUAumCuMKgMZIB3AAcWh1LBz0HPQCSQOgKDEpIEkgRHRoC4BrIHkIYCC5 E+B2ZR+CBcALYHkGcVBuZyBhIGBpAkBsESAAbWl4CYAgdXA4LiBGA2EfISAAcG/DC4AFQG9mIHYI kAfgvyMhBaACMANgAyAj0W4FkGR0aSNQdHkidBQQdXhkby0D8BggBCAf03R8byAHkAGRISAdoCDx Zrx1bAMgB4EnMB8wYQVAXQQAICSAH/AFwHAEkGO2ZSTAIcFiJQAgcyAUQF5wA2AmgBeRBCBhBCBi fykwINEhYAQRKBEDoAWgbYsLUBQgZSIQU1RQKFLccnUkcCDDBQBvK5MgAP0UEHIjUCkgKAQtIQQg AiB9JnFwIxIiggeAE9EDAHNubSujBUAAwGsusi44TNxBTiERMXAiEEkjMB+SfwPxJ/EmkCpBI1AB AC5AdX5iFBEyUiuhJpArECPCZvxpZwhwIcEigQOgI6MIcHsUEB+DYwORH9M0dAQgZfcA0CcwIyF3 H0A4oRPgBCAfJ3MkWwuAKFA4UGVsZvkiEEp1JsAohSQAJQEz0j0sYW42ISaQKcYoE3R3xSaQbi9x ZXF1B0A391sKwDGFYQeAMlIuHe4y/x78P3IncAAgIpAFwCLhJpD9P7dwITBAfChDJAAkwT7BDSaB ZzSxQzNCUERV/y5AN3AhYAGgAxA6gwQQClD/KsEXsCDRIoMoMCcwH5I0cO5nRiAmwCIQQSGAGtAn MH8EYD+BKDAkAADQJLFKoWz/DrAEoCgwSzJFQiaQAMAi4f8LcSDxAJAg0CFhJ3gCEAXA/yPfJOI5 BDZDKkAtMAeRMQRDJ9Io8SBWUEwF8CjPOINR4yWgB5BuJwVAJjb/JoBKMikgACBM4ifDPlABAP5z HvAAcDYlO4BQ1lCSIMKvJoEBACxSUdRzKPBjBpDfDeAlVSXUQ1UtMHcAcA6wxyHQVMgiEE9ubCUA AiD3TBEAgAGQbi6hL+UvoReh/mclAAEAS5EhkC1TKkZVdv9Wp14YP4QDoBggPqAl4SHQ305SB0AD IFHiWwFUXJIFEM5jH3BC8UwWcHVWkjQT/yjRNAIAkAIgIMJM8j3xIpH5BRBnaAVAIWAf8AMgOsF/ IoIKwBPQITAkkTXxHsBpfi4sgT5QBUBlZVi4ZiQs/mJjoR9AZfASgSHwLkBDYvcoMgVAN3JkRYEx hGjuZob/TpIOwi/lSwE+sVtRH+ALcP8LYAJgZbEHkAhhKSBVUEB71k1ioR3qLXJyT2XRC4D1PsFN K4FhRiBycxz0IjK8OiAdVgYAE+AnMFtMkbFLgG86aB2gdYBAWgA3H/AwwCEwaCSAPhFya3tbACwR XRz0BmACMHSwV2sJgFDBZCCALAXQIIAgDDA3eUAB0DAzIDFQMDoyORDATRz0VHd2ECGBYrBfFBBA AABwQMsIkAngLgWwZzsHsAWw1QOCRguAbnyQTVCxH5AFHaBpBgB1enVraet8kHsQbiUASgERCdEZ MDUdA0wHkUI7IAJwIFD+YSeAEiEg0CWgfVEHwAMRTkoKwGSRHPRDY3SwcPhwdnB78D5QACA7IHcq RXyQQzZRZy1ZC4Au+X/QZUAHQDdwgzF3onf1zTSAaiSRdLBSRXSwCFDebQeAAjAvVCKRTBRAUeD/ MoADUEABd1JVc2rQCkAksOcCIAQgJaBjdYczHep6tX8fQInRNdAl8VYiA1I4cXLvISA78h9CIMIo KDFHMTuRnV2hZR7wHPQoE1AtLLL/PiAngCHQaDJYIAORLaVYuf9Ae2JBSpI/gRQQKLE+wQdw/wtQ DeBL0YmyJoEtJiyxHPT5LaVQVzDnJQAkgDYSNUTnC2AGgQiQZC93UiHBCGDLRDwe4SIncnktJ8IJ gPoiSrNpafFcN5aCAiBvMu+CoI0RCzEdEiCdoAPwHzL/IPFt6SEAUeNbxmIiKDN5QOMGkJ1HUEUx VXOhYCoh/wrAJLBYUEjhIcE6wZ87eiD/K7OdR0LiIABaAChxM9Fo+P8mgaFgehA5BIvwkEOdR6Ip 96LveiAiEEhZACiieUCd0v8fIoH1naEE8CKQB4B5QDiD36Fgj/Uf06XMKKJ5nUcqYP9C8lHjN3AK sG/CrMEl4CXx/1gxSyMjITrxUdOdR1vHB4C3BtAEkH3hcB3qQYFBR+H/XaFIgigxoYAF4CzCW9YF oN8osThhAjBpUmPWJ6tYdyXreUAhAGIA0GsloAWxISCrH2GMk1A0AUIFEGRGIP+kAaaButcOUK7n IzCjLXlAB5cSN3BWESA4MDIu+DFhZLgwJqBKIAtgWjL/MmIiwAAgq1gmgWGWW7cEIP9n1GGSloKM k49UrNA/cbJJ/ymAF7BisCHBJsGo0rDfseTPW7edR7NocJAgRFL1qyL/xRSvWsHnuDlK4QEgWIGW GP4/HeqhMgSQE+AlYCGAb0HvtQIFMGTBKFJ3A2Ag0lWU+2MEOsFmSwGg2I+zW8dOUv9SSJ+IqkcG kCgDskhFUgpQf3lArMctIUZdR1xAexz0L/8fQB102a9yb3N/dINxcgZRf3vCdad7X3xhd+94/3oE NK8UQHqadNt8kCd8uSflkd99juZyfqrmcBz0J3/W5nL3gHrmcoFZJ4IPgx+EL4U//4ZPh1+Ib4l/ 218eNi/0mlP/J7MhwVi6jfBetUrBOJEhwfVg0nDw8i8ncFwQ81RlZPsl4LcxZFVRM/YhADJiBmH9 LoMoJsAN4CFQJQQeoEuT/wMg7/EpxPv2KuEBAY6hotPtvtNEVXO+01ESIAtgvpLYNi41/GFAAm7z 4LORf5fyvpLE8q9h86ge8DZDUr0ssS+186rQJ5Hyg2o7gt//MpIcNUNKc1gnUL7VUtP/WBUlBC+w k7HPw57jTUVbyr8EpZ31usJkExKwuQVoWQA/PbVK8GZRL1EosxQQZHX/WQUoYTaYDfJaEHmAMmLM lr8Oj/c4Z+NsLV4XF7Bvd4D/+4Ab4P4xMVEgwjRwP4U1lv8KFyUoM2El8jbAxhH8szP1/y309jQk Vb/VLlXisCgTaDK/KxTrEELjtfL+8k1AZ54g/GdvPsFhYSKCHoJnoSMh/wg3JoEJGk1Av4MKNTTj DwPdPlEtMmJAEIvwYeKwqET/v5GNAE/CYvJe4iNbU1RLxf8qSGsDP3M1Q1YRCKAq4ahCcy/W8xYg LbXgUfLTY3j/QACUII7AcK/bv9zPc9907491/3cP4Y/inzY6MLXQ/3qafL99zN7Zfo2/8H/m0eT/ gH+Bj+xf7W/uf++P8J/xr6/yv/PPLCflwiwr+llJQf9TZp6gRLC+oQHBYVIFkJQQ/2T7jvVvgfqi ACNoMmFQBRC/WQG1UxcC6IC/ICvrSY/1f9jgmNCeMpgUlFTUwCv6Qe9noebwMICUAnm1RwhGEBH/ nmOUESIh0HHoANHklQZbgvthYQdTKAzWuDCO0MHoEEH6UgSQLwSy0eTP4ZpakVr7zbvazVcx5g1W RRstvy7P3y/S5ckw5xeBlSBACUCr8FpvMu9U2WE0WDZ5xTj4OjE0gGB6qTdfOG85f/+AP0XlPA89 Hz4vPz9AT0FQ/mVBj0KfQ69Evyw35sZGi9dkftAyqNA60eQ+juV2kL92kE2A6pLJ07pBqmAnkxH9 6IBm/XCYMLVSrmAhkwGy/wdQ/xBtQNJAkuEZdnnkdrj/02IQ48owuxPXwpOxGdDQIf9bIhrymqSg gVQSfifAMK+V93a41EagkXN2L3pyi/Cr8D8BEArAz+RJcRclnpZXRz+OII5S2IEfIRhUb8FGV/9x ogAidjYN86Wh0FCME3iBO7+kKidkzKFvINTAU29Z4rBJJ4zAeJhFmDBj/79BezsegZYgm3Co4xhy hnT/oALTQkuWefMZcSuSbSHi8P+DAMzA/jG6c4tERoV2kHEQ//XkS4cQEYMBXcDogW7yeSbfhnSB csmy2PDNu02csXzA1nXPsAAhc6pgci/wemP3hnUQEVsQcyuwvyAdceKw/wIgvnTY8JLXabWq1aUy 4vC/fMT6AdERAwT/JdCiYvkA+zEwK+tBHRGvgpryh9IqUP+xsZbxlfEj8YgwAbDWYwmi/m4k4p6y KAPFkvrAKECHBf18xUMmAX0z0aGuM/X29oT/fbSD5f4DjqfR5DGB6ICc4Xni8ElFp8C+wgAjp7BU /kZ6QU2A2yCtAwcm2IB4kT/qIUlxzzECYVCggaZJdP+/QaCPJoHKIeDgSYAnUBlQ/zOhJkAcoUfw NFDF0K5Dp7b/vwCRFdCirSIZsesQElCcof8VkSmT2VBqYGrRBiwYgtBQf/3wk1B9xBhyjuSD5YZI KPHogHYgM1WBJ9XY8NHk/wJgHXEn0XlEDREkEYMCohHjp11JcTE5OWLhUTMYwPckQW0R0eRWIrMo QlFA+sD/K7CnY7rWgXH6wLrg+rEzoffisOuAJGB1XVGbNajCp8H/0eQAdfiQc7D7crRnJRAIAP8D MFQSfMW8VPoBhai7s9HkHwEQSTSDAA0BvrJwaHl/CsDYgWpQatF+wUxREIBn7wMwwbTTo8OPCiRA iGCyTu/RFNjhGeAU8W/X0Ulj4TD/+QBS4hKywbS0Za1C+GD9cPeowtHk0aB2B2H39KiCjtX/JRH/ pQDAMdCLkRZ02PD+8v9goSpxmKGfIU2AFaALUCvl/5ciefN+wZ/VfsFw0idYUnL+b/4gp2MAdNR0 bBGjwknm/32Bvrmc9EfRNFMXYjaReSb/p7N5+cpD6NS18P1w4vBMcf+RoG9hR/DLogmxzD+Lknhj 9SuwdhEgdGfArARHwpoF/8HDmzrX5Bnx2NSpGBBDC0D/DRKWIPZiB2Ho1H0zGVBJsv82wZlBGMCT ULej41JvYpfS/zERHXJOANKnsrif1ZiiS6H/mKF44hqU2pi9gsGlhZK7tP/JAkoFxsUKp7IC65O3 YZrR31sigBKkWjSAxzV46AFUAs/Ipf4xVNfD4yB8O1AFod9u0P45/UALVfNgRiswMdDboiAdckb5 lSvcUhzgnmL/5bMRsGkxXcAxEAtBhf214+80gI+BSHKx0GebcXezgab9DNdCm0XxQ9RxykEWZQdQ /2SRKxMYcR/gAYHcQmzgVYD/nQJVMZEGsDMJ0Rrz/T/+Sn2fEHLAoNCg//G/ZdAUQU5EmgakgaHG aXoXA23vA90MMaSBjOFiA4GwUG9V98A1efRcRES64NWkFGmkbL+kgH7REFAxAHCgazAtiaD/JxFJ gBuBXZGZQDRxjOC29f+PUSIhs4GzxrZRBvYaJfLw96Klefqgw3FiEXFTr9XKQb8lER3TKzEdEgiH BKAtDpn/UKKTUyIjC9TZlkoF2jbPQf9xtiIj1HSQAB0C8MITxP6k/wUj8UQm4CcR5MUWHSm1XTD/ erYYmyfV2aKZArQjDJMr5f4o9JB6tqeBnEOZQNHTGhE/eWGP0pME72R8xhYcLinnK/p3EicqfD0o DykfKab7XKNcoSsmnyekJyssT/Ng93wh9XYspnwrTyxfMN8xM/cBEPYUqNArXKEvr4swqND/dbCo 0CsRMY8xMmSASmD6wfewUDYB78MxYyAxOC/sUWAfSyAxCvKHMl98IkJQRN5VrUA0CDsBqNByL/tb QO86EjEp/GQyP3wqtlyiOMf/qNA9QeBlMFVAkUCUMV8yb/8nKD15QJFaVTBVO5E7kjXv/0XPLq9E pFCAxqAv+zPhDGDFRohFx6IiKyLu4kSz+fMTMjY34jN/RMKwULZA/0N+fKBGh3lim/C44RQBTpH/ Mpzvw2MROKlDQToxOV6GwD9GiOcjs4AY8HgQRKVtdZ54NEJGz0aFh7AgZy/+/0CSScRm8K21bzJA kUnhjwD/WpFBj0q4UpwnIT1BRKeipb+yAkukUSZbD0aFO5FmL///Rn9nn2f9QolIT2pPbG9uD/89 Wz1BV6wnJUnPbh9L72z3HmNw327PdsjzEzU4OX9Q3z2mNaFNjHa/e59VnDP/Vo0z4WGffT+A327v PYgnIf9DbHGvge+HX1arTjKFHyevX4w/Kc8q349vkG1BirhC/Yq6Q47XjtiXIu4lo1jkMPPdoZqj IkFPwKrw6dGxMP/4xJvx87GgRjsmjthARKvRn2NqoVMA4R2ho/VMM6EA/xQgqVARte2BJDGjVxL1 ioJ9lYlClkfKQR4EnRbNUnf/rXKkI/VYeWadirBBtCNaoe9flDdg5gEf03T4EPSgqvCfvWCgjPvd q9CO2FAt8xMec8kAlVKjVe/DVkNJ5wdQqJMRtSJDT8DGQ59n++SA0jBoHbKO2AiCCoi/Uv+zE8XL CEbtob1g1tDj4uGjf+OBFFCO2OUo2jTCVBGxOv8mJZNr9JDkcNYQpVAb8hRg/71x0mDQkssTy+PS MaS0+PEPx5OhbwhQjthNVVNU/9mSpQDVMNEzntKU6NzQtuT35gEQZc1AMf+ACzMDkfRCewwxPlky /4AUUL1GEbEo/kwTwJmSwqHgERvxNDG06u/Qg+4AyqUgJWSO2KCqliLflOmjVbq7JgeTa1MeQalV /wuFH+CVseASA2H4EHmQ//A/G+H0ULbkrofskwrAbif/wJKO2OAS8xOu0OXg41Ej0f/ZoQ1hsBHw w+5h9NAUYBPi/w+xm9EB4zQxBqiO2P4gN8D/5nMbwNRA7zIPkw2x2BAZeP8isN1gsLK2wQDQXIDd Ed5w39gh73PmAPaFk2tGT+DiMv/6F8FjmoQSMszj79I0Md/Wv8LCPLnMKg+x5DC7kGywAf/iUd8w EnAK8akRV3BegQ0h/x7A7gD6cOKwCsHl4B3VOyb/mZH+IKDAz+HV+JFhoEDioH/UQ06Q2iId1c9E OCKrUWb+Zh6hXvLY8R/U85WZkaUBr+Nw9FDV947WKLzRSR7A/yBwHRDSA/pw7tMIgpWE60X8UEWr VJ/zzhfvZPIxjtb/5IbwWbIBl8TpQsIwT2HdVP8Iguun6X/C9yRjU6ALNxGw/xHhXmD+YefIm9Eb 8a7QIHD/GbAT0rDAVnFWkAs5jtbDpvvpMSMzbhkQDhBU4+SGq1Tr9CIRsE/KIGfXRgs3yQHDl7OO 1k8oTl6+oRBh/Q8BbRmwu5OuYa/gtiAIEl/OAAZBwCG18frQIwxQQ9n3Vyog+vrV90YDQBPS/6vw 8lNOkKBAG/EQYbAQeZT50vJ1cKsS3VTJILYwqRT/ATiO1snRtnL7RdPDJkEdcN+u4QuC86YTYgrA dQ8CC4XnpbvpQNX3U2+1osvE44D9n0Ju3NLXYA3BeVCv4JeA9+gtIUWO1EYUIVCQ9iMYUvv2qMhw UKWQ3BHSUXmQ2PH+ThmwnzCu0CBit4MPIdwDJ47UX7DecGlwZLF0Lf3VAC22I6TxJDGgEdKBGWH/ toGWxbyRtmEZY+khrhX2pLuO1LDhIiSw09Dt0XNPwP9RcddhERMTQg9ToEDi4B0A/nMfs7TA+tQQ OPPE3BAhVf/7Qp8g2PC+tJSE2WMf06iR/5sBF+Le5gkBriQdB47U1QDudRdSm1OlUHJAgMEy9rf/ 6TIMkBOUIJ77APRoFncRIv8XCK4RtLFToAtQElCu0uAF+/C23eBytPIhIfaYjtQN9//J4dNQJvEO mhb61YC9Ic2x9xj8+vEMy1fVkefzyrIF6f8O5vkhPNEQ09li86bcEiQP/06QrW/CccCBsOEaoMIw tnJ/AiBTkTN4l5PKIN+A12As+47UwoBtDOHt+TSlzYEPIX8QOKSBraDI4dgxn+EC8Gz/lbSO1Omz 3eG2cq/j8yAVq9+w0jN53OjcEfrQbRoCjtT/7LSXgzqim2LVAO2wKor2I85itsG7kNgBc23XYeLR //akNzVeYKVS7gcmlyGb7ZqvMPcMy+aRvqFGpRFr+QL/Cfal4L0heXBUwcCAxUboa385qI7WLEHu oaUQpXJDQ2n/N8AFUV7B02VDAkEFNcEBQf9Z4LpBjvAQ8KSA6kHhgQzL8wnx3BBhZ5yyN6LXwdyy /7vGUE9RXCYhm8H0gML1OqP/TxZLubgwU0HScOfi4fW04b5z1YEXUjmLVwnAE3LKIO8cEZ/h8iDl cWnd8fOlrhP/3BHcEd2xBMAaoNjxVUiO1P9RajmLTfoPpuy40lDKMraA947US2O4Eno/UqAI09Jl C/miFyBnCcHT0g+lQCraMPfU4FVoBaAv2sF5Zq7hCpDvT0OrVD72v3FTmuAEwOVxb9djH+WV8qQh L6QEeWYi/86jEPE2mcU4DZG4Bv/gb5bzQCZwQkwy2WB40NwRDJD/1BA8YkiNtLGbYpk0UVt0ZP9l o/EBvVFdsKxCm1PQg2UG/+yAjtbxEHZVwoHTIMCAeLP4TUFD0kC2UaJQ7HLxEH98AkTiC2B8Q/kR 09LxEEh/1CDz0Y7WfWHi0X2kv3BD+VcSIHnUgMJwIQH2cGNp9xCifFWwk2xVoEUT0pCO1iNLyNQU PyBXBsdNU4ZBD0F3mUlTTy/QgMl8IDE10NEtMZeSgvV+P3Vn4kS8RabmMfTNI2HPuAF2NuyWn3ZF LYbg4zH/iB6FMLvipZDNI6PIb3aFEPxBY8KAuCSbNXmYqSSoUuup4L4GdtdgdTHjXWEBcv/JM10T sFObYn0Pu4I6KU13nwyQtlGBMYXSv3BJJwuw/zqiAhCwseyx4rPS08KCveD/51HVg5E7vdHYInon QwK1wH8usidw1QELA2WQ0sR2y2L/1CDJkraAgoXRwu336yhc0Pfd8nmXDMtBHhhlBtB0stT/Z4mw orny4VB31cWD31a+BP+LhMSAHBBVoOBgVsK4MAWw/zqistAQ0CdwW6HUgumxlrL/mnI3wNohbCEa PTuVOoLRs/PU877hbzvzst0wZBel/f9vgaAjbRIfE5JxEaaPTuwh90Th5BEXIXNFAggd32jNI/3t sGdmY24ocd8VUfMBXAB3DMsfEtCDUNDThSDP5Uf7PLE1oHfKIGLClUKlkwTS/6Kov4CkCBGl50Aq 0Xiz0Ij/zqHVks7AC6FW4MkTzeIakP/8ktLTWTVxJo5zEaU0peKx//uhKtALMN3RWI8LsQLAzbH/ mpXT0BMhOETQhmSsHtLm8P/f0XhB5EDYAVbgzXFVAtJQ/08gpyFbkggxE5HTtFbgOuH/UaFuJvyB 7CG/J7rEwMEK8v/CBUOg4WAE0gsw8zGeAx2g/RVQZGhV1ZHrBiERk4HVg//nstrB1MDq8PRy+RHL H73R7DopDNrZsU6a0Qza4IQCfdfQAAAAHgBCEAEAAABFAAAAPDA0OUFBRkVEOTE4NTEyNDRCOUZG NzREMEQ5RDBFQjcyMDIxNTI2MEFAV0hJU1RMRVIuV2F2ZVNtaXRoTmV0LmNvbT4AAAAAAwAJWQEA AAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAA ABCFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAADABmACCAGAAAAAADAAAAA AAAARgAAAABShQAAfW4BAB4AGoAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAAL ABuACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsAH4AIIAYAAAAAAMAAAAAAAABGAAAAAA6F AAAAAAAAAwAggAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADACKACCAGAAAAAADAAAAAAAAA RgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAENBC8WgAtZAi7LmMY2gFNICAfoPAQAAABAAAABDQQvF oALWQIuy5jGNoBTSAgH7DwEAAACSAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAA AAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXG1pY2tcTG9jYWwg U2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xtYWlsYm94LnBzdAAA AAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDQzNDEwQkM1QTAwMkQ2NDA4QkIy RTYzMThEQTAxNEQyNjQxOUM3MDAAAAAAAwAGEPxJfNUDAAcQYygAAAMAEBAAAAAAAwAREAAAAAAe AAgQAQAAAGUAAABISU1BTlNIVSxJTigxKUlUSElOS1lPVUhBVkVZT1VSTEFZRVJJTkdBTElUVExF TUlYRURVUEZST01USEVQT0lOVE9GVklFV09GQ09OVFJPTENPTk5FQ1RJVklUWVRIRVBTRVVEAAAA ADqf ------=_NextPart_000_0003_01C314B1.A6526350-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 19:44:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24224 for ; Wed, 7 May 2003 19:44:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47NkoY18651 for ; Wed, 7 May 2003 19:46:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47Nklw01292 for ; Wed, 7 May 2003 19:46:47 -0400 (EDT) Date: Wed, 7 May 2003 16:40:54 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9876630168.20030507164054@psg.com> To: George Swallow CC: PPVPN , pwe3@ietf.org, =?ISO-8859-15?B?V2lqbmVuLA0KICAgIEJlcnQgKEJlcnQp?= , Thomas Narten , =?ISO-8859-15?B?UGV0ZXJzb24sDQogICAgSm9u?= , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: <200305061442.KAA23011@bifocal.cisco.com> References: <200305061442.KAA23011@bifocal.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit George, > I thought the IESG was concerned about the overall number of > Workgroups. They are much easier to create than to shut down. I think the overall number of the WGs is a lesser concern. > So if meeting twice per IETF for a short while until the work > settles down lets you have one less, seems like a good idea. Agreed, provided that this is not a consistent situation and that the agenda time is not used for slideware, but to discuss real issues the WG is facing, verify consensus on document modifications, etc., i.e., the real stuff. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 19:47:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24297 for ; Wed, 7 May 2003 19:47:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h47NoLY22335 for ; Wed, 7 May 2003 19:50:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h47NoHw05381 for ; Wed, 7 May 2003 19:50:18 -0400 (EDT) Date: Wed, 7 May 2003 16:42:07 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4476702912.20030507164207@psg.com> To: "Marco Carugi" CC: PPVPN@nortelnetworks.com Subject: Re: Strategy for VPN work in IETF In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Marco, I'll take this off the list. -- Alex Tuesday, May 6, 2003, 12:55:29 PM, Marco Carugi wrote: > Alex, > I had promised myself to keep quiet for a while on this topic and > respectfully listening to the list. Reading some assertions, I cannot > anymore. > Looking after the best interest of the WG and having worked so hard to > create it time ago. > Inline, Marco From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 21:48:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26887 for ; Wed, 7 May 2003 21:48:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h481p5J22025 for ; Wed, 7 May 2003 21:51:06 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h481p1Z03752 for ; Wed, 7 May 2003 21:51:02 -0400 (EDT) Date: Wed, 7 May 2003 18:48:44 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@malt To: Ron Haberman Cc: Pedro Roque Marques , PPVPN@nortelnetworks.com Subject: RE: Contribution of the PPVPN WG In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A0DEF8A@m-va-bsod03.add0.masergy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: prattle.redback.com X-SMTP-MAIL-FROM: rahul@redback.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: prattle.redback.com [155.53.12.9] X-LYRIS-Message-Id: Hi Ron, Thanks for your comments. I am not against or for splitting the PPVPN WG into two different WGs. I just feel that its helpful to understand the existing limitations and if they can be addressed by the split. Hence specific feedback like yours is very useful. I do share the concern that several other folks have expressed about how aspects common to L2 and L3 VPN (requirements and solutions) will be handled after the split. Regards, rahul On Wed, 7 May 2003, Ron Haberman wrote: > Rahul, > Inline... > > > -----Original Message----- > > From: Rahul Aggarwal [mailto:rahul@redback.com] > > Sent: Tuesday, May 06, 2003 7:08 PM > > To: Pedro Roque Marques > > Cc: Ron Haberman; PPVPN@nortelnetworks.com > > Subject: Contribution of the PPVPN WG > > > > > > > > Hi Ron and Pedro, > > > > [Took the liberty of changing the subject line] > > > > Your mails bring out a very key question. The PPVPN WG has > > been in the business of developing L3 and L2 VPN technology > > that providers can deploy to offer these services. > > > > Do providers feel they are unable to deploy/offer L3 VPN > > service because of limitations with the WG ? > > RH> I don't. I have all the technology pieces that I need at this point > to offer the service. Could there be improvements? Yes. Would I feel > differently if my company had a policy of not adopting technologies > before the standard? Probably yes... (I really hope that other SP have > that policy) > > > > > Do providers feel they are unable to deploy/offer L2 VPN > > service because of limitations with the WG ? > RH> Not at this point. I think the two (LDP, BGP) solutions are > available and ready. At least to the point of my own satisfaction with > results of testing them in my lab. I have my opinion and was able to > convince enough people at my company to choose one. If at any point > either I will feel differently (because of the market, improvements to > the other solution, etc) I will go through the usual "dealing with the > vendor" to accommodate the change. There is no visible difference to my > customer, which is the most important thing to me as a SP. That allows > me to pick the best solution according to how the it affects my > backbone: efficient use of protocols, easy of configuration, easy of > change and integration of the new service with companies product line. > > > > > If the answer is yes, what are these limitations ? From a > > distance it seems that the business/economic case is more of > > a reason, if any, for any seemingly slow deployment. > > > > Or do vendors feel they are unable to develop this technology > > because of limitations with this WG ? > > My answer to this is no. > > > > Regards, > > rahul > > > > > > On Tue, 6 May 2003, Pedro Roque Marques wrote: > > > > > Ron Haberman writes: > > > > > > > Masergy Communications is an example for a company that > > actually IS > > > > running all three VPNs. We are running L2 point to point > > for about > > > > two years, 2547 for more than a year and are actually currently > > > > running (currently as in not planning to, thinking about it, > > > > evaluating) VPLS service for about a month and a half in our > > > > production network. > > > > > > Ron, > > > How would you rate the contribution of the ppvpn WG to the services > > > that you are providing ? Are those solutions based on technology > > > discussed in this WG ? > > > > > > The proposed reoganization is based on: > > > "numerous concerns that the IESG members received from the WG > > > participants about limited and slow progress within the > > WG despite the > > > efforts of the WG chairs and its members." > > > > > > I assume that those concerns about "limited and slow progress" have > > > been voiced mostly in private. To a more distant observer > > like myself > > > it isn't easy to understand what those are and what constitutes a > > > messure of "success" or "failure" of the WG efforts. > > > > > > I'm hoping that we can learn from whatever concerns exist with the > > > current group in order for those issues not to reoccur with the new > > > proposed structure. > > > > > > I would hope that people like yourself which are activly engaged in > > > deploying the technology can point out the things this WG did > > > correctly (if any) or wrongly. > > > > > > regards, > > > Pedro. > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 21:57:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27061 for ; Wed, 7 May 2003 21:57:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h481xiJ03327 for ; Wed, 7 May 2003 21:59:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h481xdZ13745 for ; Wed, 7 May 2003 21:59:39 -0400 (EDT) Date: Wed, 7 May 2003 18:53:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <17184595822.20030507185340@psg.com> To: PPVPN@nortelnetworks.com Subject: Draft charter for L2VPN MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Proposed L2VPN charter below (draft). -- Alex Layer 2 Virtual Private Networks (l2vpn) Chairs: Area Director(s): Thomas Narten Erik Nordmark Area Advisor: Thomas Narten Technical Advisor: Alex Zinin Description of Working Group: This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned layer-2 virtual private networks (L2VPNs). The WG is responsible for standardization of the following solutions: 1. Virtual Private LAN Service--L2 service that emulates LAN across an IP and an MPLS-enabled IP network. 2. Virtual Private Wire Service--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. The WG will address intra-AS scenarios only at this point (inter-AS considerations will be considered for inclusion in the updated charter when the current one is completed.) As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. As a specific example, this WG will not define new encapsulation mechanism, but will use those defined in the PWE3 WG. The WG will work on the following items, adding new work items will require rechartering: 1. Discovery of PEs participating in L2 service, and topology of required connectivity 2. Signaling of psuedo-wire and service parameters 3. Solution documents (providing the framework for a specific solution, should include info on how discovery, signaling, and encaps work together, include security, AS as a separate document,...) 4. MIBs 5. L2VPN-specific OAM extensions--extensions to existing OAM solutions for VPLS and VPWS. Milestones (optimistic): JUL 2003 Submit L2 requirements to IESG for publication as Informational RFC JUL 2003 Submit L2 framework to IESG for publication as Informational RFC JUL 2003 Identify VPLS and VPWS solutions for the WG AUG 2003 Submit an I-D describing MIB for VPLS AUG 2003 Submit an I-D describing MIB for VPWS AUG 2003 Submit an I-D on OAM for VPLS AUG 2003 Submit an I-D on OAM for VPWS DEC 2003 Submit VPLS solution documents to IESG DEC 2003 Submit VPWS solution documents to IESG JAN 2004 Submit MIB for VPLS to IESG JAN 2004 Submit MIB for VPWS to IESG MAR 2004 Submit OAM for VPLS to IESG MAR 2004 Submit OAM for VPWS to IESG From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 22:05:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27272 for ; Wed, 7 May 2003 22:05:05 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4827VJ11494 for ; Wed, 7 May 2003 22:07:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4827RJ00760 for ; Wed, 7 May 2003 22:07:27 -0400 (EDT) Date: Wed, 7 May 2003 18:51:57 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <184493545.20030507185157@psg.com> To: PPVPN@nortelnetworks.com Subject: Draft charter for L3VPN MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- It is taking longer than I anticipated to set up the mailing lists, so I am sending the proposed WG charters to this list. These are _drafts_, so are likely to need more fine-tuning. Below is the proposed charter for L3VPN. The one on L2VPN is in a separate message. Comments welcome. -- Alex Layer 3 Virtual Private Networks (l3vpn) Chair(s): Area Director(s): Thomas Narten Erik Nordmark Area Advisor: Thomas Narten Technical Advisor: Alex Zinin Description of Working Group: This working group is responsible for defining and specifying a limited number of solutions for supporting Layer-3 (routed) Virtual Private Networks (L3VPNs). The WG is responsible for standardization of the following solutions: 1. BGP/MPLS IP VPNs (based on RFC 2547) 2. IP VPNs using Virtual Routers 3. CE-based VPNs using IPSEC As part of this effort the WG will work on the following tasks (additional work items will require rechartering): 1. Requirements and framework for Layer 3 VPNs 2. Solution documents for each approach listed above (including applicability statements) 3. MIB definitions for each approach 4. Security mechanisms for each approach Multicast support and Inter-AS considerations are excluded from the charter at this time. They may be considered for inclusion in an updated charter at a later time. Future work items may also include OAM support. As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. WG Milestones (optimistic): Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info (completed) Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info (completed) Aug 2003 Submit L3 VPN Security Analysis to IESG for publication as Info (draft-fang-ppvpn-security-framework-00) Aug 2003 Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01) Sep 2003 Submit CE-based specification and AS to IESG for publication as PS (draft-ietf-ppvpn-ce-based-03) Sep 2003 Submit Virtual Router specification and AS to IESG for publication as PS (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) Oct 2003 Submit VPN MIB Textual Conventions to IESG for publication as PS (draft-ietf-ppvpn-tc-mib-02) Oct 2003 Submit MPLS BGP MIB to IESG for publication as PS (draft-ietf-ppvpn-mpls-vpn-mib-05) Oct 2003 Submit VR MIB to IESG for publication as PS (draft-ietf-ppvpn-vr-mib-04) Dec 2003 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-ipsec-2547-03) Jan 2003 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-gre-ip-2547-02) Jan 2003 Submit specification of CE Route Authentication to IESG for publication as PS (draft-ietf-ppvpn-l3vpn-auth-03) From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 7 23:28:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28513 for ; Wed, 7 May 2003 23:28:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h483UVJ22279 for ; Wed, 7 May 2003 23:30:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h483UQO28975 for ; Wed, 7 May 2003 23:30:27 -0400 (EDT) Date: Thu, 08 May 2003 12:28:32 +0900 (JST) Message-Id: <20030508.122832.41628530.suzuki.muneyoshi@lab.ntt.co.jp> To: zinin@psg.com Cc: PPVPN@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Draft charter for L3VPN From: Muneyoshi Suzuki In-Reply-To: <184493545.20030507185157@psg.com> References: <184493545.20030507185157@psg.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex, (1) It seems to me, "provider provisioned" is eliminated from the proposed charter. I think this is important property, because in the current L3 requirements, L3 framework, CE-based solution documents, the scope of the CE-based VPNs is limited to "provider provisioned" thus, customer-managed CE-based VPNs are out scope. If the latter is in scope of the proposed charter, considerable updates are needed to these documents. Therefore, if this is not intended by the IESG, please clearly states that the scope is limited "provider provisioned" in the charter. (2) Interworking discussion between solutions is not clearly stated in the proposed charter. Is it in or out the scope? According to the following statement in the current charter, it may be out of scope. However, based on the WG and DT consensus, it is clearly described in the L3 requirements and framework documents, because we thought it was indispensable. If it is in scope, please clearly states it. > below for specifics). The goal is to foster interoperability among > implementations of a specific approach. Standardization of specific (3) draft-ietf-ppvpn-applicability-guidelines-01.txt and draft-ietf-ppvpn-generic-reqts-02.txt are not addressed in the milestones. I think these are active, so there should be addressed in the L2 or L3 WG charter. (4) In my understanding, the following draft is obsoleted and replaced by draft-declercq-ppvpn-ce-based-sol-00.txt. And I think draft-declercq-ppvpn-ce-based-as-01.txt should also be addressed. >Sep 2003 Submit CE-based specification and AS to IESG for publication as PS > (draft-ietf-ppvpn-ce-based-03) Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 00:17:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29349 for ; Thu, 8 May 2003 00:17:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h484JcW04273 for ; Thu, 8 May 2003 00:19:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h484JZ826755 for ; Thu, 8 May 2003 00:19:36 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.55991.734081.636661@harjus.eng.song.fi> Date: Thu, 8 May 2003 07:19:03 +0300 To: Alex Zinin Cc: PPVPN@nortelnetworks.com Subject: Draft charter for L3VPN In-Reply-To: <184493545.20030507185157@psg.com> References: <184493545.20030507185157@psg.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex Zinin writes: >Inter-AS considerations are excluded from the charter at this time. looks like I in Ietf doesn't mean Internet anymore. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 00:39:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00268 for ; Thu, 8 May 2003 00:39:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h484gEW08971 for ; Thu, 8 May 2003 00:42:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h484gBV03485 for ; Thu, 8 May 2003 00:42:11 -0400 (EDT) Date: Wed, 7 May 2003 21:39:21 -0700 (PDT) Message-Id: <200305080439.h484dLL65952@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: Juha Heinanen , PPVPN@nortelnetworks.com Subject: Draft charter for L3VPN In-Reply-To: <16057.55991.734081.636661@harjus.eng.song.fi> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Juha Heinanen writes: > Alex Zinin writes: > Inter-AS considerations are excluded from the > charter at this time. Alex, A number of SPs that provide L3VPN service use internally more than one AS. I like to suggest that the clause above be changed to "inter-provider considerations are excluded ... at this time". Given that the context is of "Provider Provisioned" VPNs, inter-provider VPNs are not necessarly within scope of the WG. This does not exclude in my view scenarios where a provider buys transit services from another, in order to provide the service to the customer network. This is already contemplated in 2547bis. Inter-AS/single provider is imho a necessary part of the L3VPN solution. > looks like I in Ietf doesn't mean Internet anymore. I'm not sure i understand the comment. The Internet is a public network, a VPN a private one. Do you mean to refer to Internet access from a VPN ? inter-action between the two ? I would believe that to be in scope. Alex, would you please clarify ? regards, Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:09:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00774 for ; Thu, 8 May 2003 01:09:52 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485CHW22730 for ; Thu, 8 May 2003 01:12:17 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485CDi24522 for ; Thu, 8 May 2003 01:12:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.58591.713308.53655@harjus.eng.song.fi> Date: Thu, 8 May 2003 08:02:23 +0300 To: Pedro Roque Marques Cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Draft charter for L3VPN In-Reply-To: <200305080439.h484dLL65952@roque-bsd.juniper.net> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> <200305080439.h484dLL65952@roque-bsd.juniper.net> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Pedro Roque Marques writes: > > looks like I in Ietf doesn't mean Internet anymore. > > I'm not sure i understand the comment. The Internet is a public > network, a VPN a private one. Do you mean to refer to Internet access > from a VPN ? inter-action between the two ? I would believe that to be > in scope. Alex, would you please clarify ? what i meant was that ietf should work on solutions that work across the internet, not just within a single as. if a vpn according to a particular solution cannot span more than one as, the solution is completely useless to us, because in our own network alone there are five-to-six different ases as the result of mergers with and purchases of other providers. also, a regional provider like us needs to have partnerships with other providers that cover other parts of the world. therefore it is almost as important to us that a vpn according to a given solution can span more than one provider. for example, consider the case where we provide a vpn solution for a given customer that initially only has sites within our own network and then suddenly they want to add another site is china, where we do not operate? it would be very unfortunate if we would need at that point to switch from a single provider vpn solution to a multi-provider solution also for the old sites. therefore, i don't see much point in postponing the multi-provider aspects either. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:23:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01015 for ; Thu, 8 May 2003 01:23:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485PWW27110 for ; Thu, 8 May 2003 01:25:32 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485PSA29957 for ; Thu, 8 May 2003 01:25:28 -0400 (EDT) Date: Wed, 7 May 2003 22:19:54 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8996969975.20030507221954@psg.com> To: Muneyoshi Suzuki CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN In-Reply-To: <20030508.122832.41628530.suzuki.muneyoshi@lab.ntt.co.jp> References: <184493545.20030507185157@psg.com> <20030508.122832.41628530.suzuki.muneyoshi@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, Thanks for looking closely at this, my answers inline below. > Alex, > (1) It seems to me, "provider provisioned" is eliminated from the proposed > charter. I think this is important property, because in the current L3 > requirements, L3 framework, CE-based solution documents, the scope of the > CE-based VPNs is limited to "provider provisioned" thus, customer-managed > CE-based VPNs are out scope. If the latter is in scope of the proposed > charter, considerable updates are needed to these documents. Therefore, > if this is not intended by the IESG, please clearly states that the scope is > limited "provider provisioned" in the charter. This is an "oops". Thanks for catching this (note that the L2vpn charter has this part.) How about we change the first para to say: This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs). > (2) Interworking discussion between solutions is not clearly stated in the > proposed charter. Is it in or out the scope? According to the following > statement in the current charter, it may be out of scope. However, based > on the WG and DT consensus, it is clearly described in the L3 requirements > and framework documents, because we thought it was indispensable. If it is > in scope, please clearly states it. If folks believe this is needed, I would suggest we put this in the possible future items. I am not particularly opposed to the WG looking at this, I just want us to get the base specs out before jumping on more advanced things. >> below for specifics). The goal is to foster interoperability among >> implementations of a specific approach. Standardization of specific > (3) draft-ietf-ppvpn-applicability-guidelines-01.txt and > draft-ietf-ppvpn-generic-reqts-02.txt are not addressed in the milestones. > I think these are active, so there should be addressed in the L2 or L3 WG > charter. Agreed. I don't have a particular preference as to which WG these go to, but it seems that L3vpn would be a good fit. I will wait until we hear more comments from people. > (4) In my understanding, the following draft is obsoleted and replaced by > draft-declercq-ppvpn-ce-based-sol-00.txt. And I think > draft-declercq-ppvpn-ce-based-as-01.txt should also be addressed. >>Sep 2003 Submit CE-based specification and AS to IESG for publication as PS >> (draft-ietf-ppvpn-ce-based-03) Noted. Thanks a bunch. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:26:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01123 for ; Thu, 8 May 2003 01:26:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485SrW00682 for ; Thu, 8 May 2003 01:28:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485SmA03894 for ; Thu, 8 May 2003 01:28:49 -0400 (EDT) Reply-To: From: "Mick Seaman" To: "'Pedro Roque Marques'" Cc: "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Wed, 7 May 2003 22:26:38 -0700 Message-ID: <000b01c31522$6794eb30$210110ac@corp.telseon.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 CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200305071807.h47I79Y64346@roque-bsd.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SMTP-HELO: pimout4-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout4-ext.prodigy.net [207.115.63.103] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Pedro, Let me try another shot at this, and at the same time possibly cast some light on Eric's recent question (single bridge model versus multiple virtual bridge model). An IEEE Bridge connects to a LAN, or more properly an instance of the MAC Service. The functionality of multiplexing and demultiplexing VLANs to and from distinguishable packet formats on the LAN is an imbedded function of the Bridge. Further the multiplexing/demultiplexing of certain control protocols to and from the LAN is independent of the VLAN mux/demux. This can be important from the protocol efficiency/scaleability point of view since VLAN mux/demux is limited to associating each whole frames with a given VLAN. Frames that are not VLAN associated can convey information that has been aggregated for a number of VLANs (e.g. GVRP) or information that is the same and applies to all VLANs (is this media working etc. etc.). Since bridging is very susceptible to errors in perceived connectivity [though I am amazed that people are generally so relaxed about burning network bandwidth with routed packets counting out their hop counts during reconfiguration] it is crucially important that (local) connectivity information is bound closely to service support. Accordingly the IEEE Bridge model does not include the possibility of any of the VLANs or the control protocols accessed through a single M-SAP (point of attachment to the MAC Service) being separately supported with methods that can lead to independent/different connectivity/reachability/failure, i.e. data path == control path. So while the decomposition of the services provided by a bridged network into (one version of) a number of VPLS connections appears logically obvious it misses a few things. (1) If the support of each VPLS is understood to be accomplished by a number of 'virtual bridges' the very strong properties of the mux/demux function that ties each of these together at each point of underlying service use need to be explained and not trivialised (equal potential reachability connectivity etc.) and if they cannot be guaranteed overhauled and possibly replicated. (2) Removal of the non VLAN mux/demuxed control traffic not only means that information that can no longer be shared has to be replicated, but that certain items of information (what is the maximum possible extent of this set of VLANs so that I can simply autoconfigure each to the size demanded by external inputs) seems to have disappeared entirely. One excuse for the decomposition of the MAC service into the set of VLAN specific MACs with no other non-VLAN component is that each VPLS will be a 'provisioned service'. At bottom this is simply a claim that the network provider will never ever make a mistake and has a perfectly working service at all times. [If you think that is good enough then you never have to ship BPDUs except when the input conditions change, the far side of each VPLS just manufactures repeat copies at regular intervals]. Being more serious about this the question is what can break or change independently of what else in the provider network. If VPLSes that split out customer data from one site and recombine them at another can only work or break all together then you don't need to track the connectivity of each with a separate BPDU, you could just send one MSTP BPDU with information for all of them on any of them (or on a separate control VPLS though that may be less attractive). If they can all fail independently then you need per VLAN information be carried on each (data path == control path). I sort of anticipate that this discovery may lead to another outbreak of 'bridging doesn't scale' claims. I am afraid here that it is the decomposition into multiple VPLSes and the pseudo-wire models that may be failing the scaling test [good news is that it is entirely possible to get both of these right]. In fact straight bridging with up to 4094 trees per network (region) each supporting up to 4094 independent service instances per link with learning on point to points relegated to the edge ingress/egress ports seems to be doing just fine, so we'll just have to see if we can agree on a VPLS/pseudo-wire model that does at least as well :-) Mick -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Wednesday, May 07, 2003 11:07 AM To: mick_seaman@ieee.org Cc: 'Himanshu Shah'; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'; ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Mick Seaman writes: > If the fully meshed pseudowires (and the attached > equipment/functions at their ends) provide a LAN Service (stictly > the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause > 6.5 (same number clause in both documents) then RSTP/MSTP will work > just fine. > To be more specific P802.1ad does specify the operation of a single > instance of MSTP within a Provider Network, how that travels over > pseduowires is of course how any LAN traffic travels over > psedudowires (i.e. the pseudowire protocol looks after making sure > the configuration of the pseudo wires correctly provides the fully > connected LAN service, that not being either MSTPs design goal or > the desire of P802.1ad to specify the simulation of LANs over > non-LAN media, particularly where the non-LAN media have native > protocols that are to be used as part of the solution - MPLS for > example). Mick, Running the risk of abusing your patience to explain basic things... Assume i have provider bridges [A-Z]. Bridge A has two VPLSs: - VPLS 1 has attachement points in A B C. - VPLS 2 has attachement points in A C D. I got the impression that the model that Norm Finn is attempting to explain to the WG is one where xSTP actually involves A sending BPDUs to all provider bridges in the domain [A-Z]. At least that was my reading of the fact that in that model 'one VPLS instance exchanges BPDUs for the entire provider bridge'. If this is the case, in steady state and assuming that the root bridges on the custumer domain is attached to A, would this result in A flooding a single xSTP BPDU to [B-Z] w/ information about both VPLSs or one BPDU per VPLS ? thanks, Pedro. P.S.: Any recomended literature on this topic ? From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:30:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01245 for ; Thu, 8 May 2003 01:30:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485XGW05147 for ; Thu, 8 May 2003 01:33:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485XBD09071 for ; Thu, 8 May 2003 01:33:12 -0400 (EDT) Date: Wed, 7 May 2003 22:26:56 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5997391982.20030507222656@psg.com> To: Juha Heinanen CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN In-Reply-To: <16057.55991.734081.636661@harjus.eng.song.fi> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Juha, > >Inter-AS considerations are excluded from the charter at this time. > looks like I in Ietf doesn't mean Internet anymore. Note the "at this time" part. The intention is not to preclude the WG from looking at Inter-AS aspects, but rather to make sure we get "simple" things completed first. Same for multicast, as you may have noticed. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:34:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01315 for ; Thu, 8 May 2003 01:34:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485bEW09340 for ; Thu, 8 May 2003 01:37:14 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485bBD13884 for ; Thu, 8 May 2003 01:37:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.60591.41023.900682@harjus.eng.song.fi> Date: Thu, 8 May 2003 08:35:43 +0300 To: Pedro Roque Marques Cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Draft charter for L3VPN In-Reply-To: <200305080525.h485PUi66038@roque-bsd.juniper.net> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> <200305080439.h484dLL65952@roque-bsd.juniper.net> <16057.58591.713308.53655@harjus.eng.song.fi> <200305080525.h485PUi66038@roque-bsd.juniper.net> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Pedro Roque Marques writes: > There is in my mind a fundamental difference between a VPN that can > span more than one provider and a VPN which is "provided" to the > customer network by two different entities. i mean the latter, i.e., the pe in china to which a site is connected to belongs to a provider that operates in china. > One can have a VPN spanning multiple carrier networks by using inter-as > LSPs such what can be provided by carrier-of-carriers or inter-as > RSVP-TE (when avaliable). sorry, but i'm only interested in ip based solutions, not mpls. > I'd be inclined to think that if people come forth and flush out the > multi-provider requirements that the work will be welcomed. But i can > see the attraction in attempting to focus in the single provider case. if you look my radius based proposals, they work equally both in single provider and multi-provider cases. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:36:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01332 for ; Thu, 8 May 2003 01:36:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485cTW10697 for ; Thu, 8 May 2003 01:38:30 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485cQD15406 for ; Thu, 8 May 2003 01:38:26 -0400 (EDT) Date: Wed, 7 May 2003 22:25:30 -0700 (PDT) Message-Id: <200305080525.h485PUi66038@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Juha Heinanen Cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Draft charter for L3VPN In-Reply-To: <16057.58591.713308.53655@harjus.eng.song.fi> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> <200305080439.h484dLL65952@roque-bsd.juniper.net> <16057.58591.713308.53655@harjus.eng.song.fi> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Juha Heinanen writes: > also, a regional provider like us needs to have partnerships with > other providers that cover other parts of the world. therefore it > is almost as important to us that a vpn according to a given > solution can span more than one provider. There is in my mind a fundamental difference between a VPN that can span more than one provider and a VPN which is "provided" to the customer network by two different entities. One can have a VPN spanning multiple carrier networks by using inter-as LSPs such what can be provided by carrier-of-carriers or inter-as RSVP-TE (when avaliable). > for example, consider the case where we provide a vpn solution for a > given customer that initially only has sites within our own network > and then suddenly they want to add another site is china, where we > do not operate? it would be very unfortunate if we would need at > that point to switch from a single provider vpn solution to a > multi-provider solution also for the old sites. > therefore, i don't see much point in postponing the multi-provider > aspects either. My assumption is that if you have two entities "providing" the VPN service you will have to consider additional set of requirements/problems which are distinct from buying a transit LSP from a second provider. I'd be inclined to think that if people come forth and flush out the multi-provider requirements that the work will be welcomed. But i can see the attraction in attempting to focus in the single provider case. regards, Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:41:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01381 for ; Thu, 8 May 2003 01:41:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485hSW14319 for ; Thu, 8 May 2003 01:43:28 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485hND21412 for ; Thu, 8 May 2003 01:43:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.60688.829673.342925@harjus.eng.song.fi> Date: Thu, 8 May 2003 08:37:20 +0300 To: Alex Zinin Cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN In-Reply-To: <5997391982.20030507222656@psg.com> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> <5997391982.20030507222656@psg.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex Zinin writes: > Note the "at this time" part. The intention is not to preclude the WG > from looking at Inter-AS aspects, but rather to make sure we get > "simple" things completed first. see my other email. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:48:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01583 for ; Thu, 8 May 2003 01:48:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485pEW19058 for ; Thu, 8 May 2003 01:51:15 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485pBw26944 for ; Thu, 8 May 2003 01:51:11 -0400 (EDT) Date: Wed, 7 May 2003 22:44:37 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9498453278.20030507224437@psg.com> To: Juha Heinanen CC: Pedro Roque Marques , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: <16057.60591.41023.900682@harjus.eng.song.fi> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> <200305080439.h484dLL65952@roque-bsd.juniper.net> <16057.58591.713308.53655@harjus.eng.song.fi> <200305080525.h485PUi66038@roque-bsd.juniper.net> <16057.60591.41023.900682@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Juha, Pedro- Let's keep to goal of that line in the text in mind--make progress on basic things before going to more complex ones (while still keeping the Internet-wide considerations in mind). Now, looking at the solutions that we have on the plate now-- > 1. BGP/MPLS IP VPNs (based on RFC 2547) > 2. IP VPNs using Virtual Routers > 3. CE-based VPNs using IPSEC --let's answer two questions: 1. Is complexity associated with inter-provider scenarios sufficiently higher than for the single-provider case? 2. Is complexity associated with inter-AS (1 provider) scenarios sufficiently higher than for the single-AS case? Depending on the answers we should be able to draw the line for the first step to include either the single-AS or the single-provider scenarios only. -- Alex Wednesday, May 7, 2003, 10:35:43 PM, Juha Heinanen wrote: > Pedro Roque Marques writes: > > There is in my mind a fundamental difference between a VPN that can > > span more than one provider and a VPN which is "provided" to the > > customer network by two different entities. > i mean the latter, i.e., the pe in china to which a site is connected to > belongs to a provider that operates in china. > > One can have a VPN spanning multiple carrier networks by using inter-as > > LSPs such what can be provided by carrier-of-carriers or inter-as > > RSVP-TE (when avaliable). > sorry, but i'm only interested in ip based solutions, not mpls. > > I'd be inclined to think that if people come forth and flush out the > > multi-provider requirements that the work will be welcomed. But i can > > see the attraction in attempting to focus in the single provider case. > if you look my radius based proposals, they work equally both in single > provider and multi-provider cases. > -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 01:51:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01637 for ; Thu, 8 May 2003 01:51:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h485rcW21606 for ; Thu, 8 May 2003 01:53:38 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h485rXw29730 for ; Thu, 8 May 2003 01:53:33 -0400 (EDT) Date: Thu, 08 May 2003 14:51:59 +0900 (JST) Message-Id: <20030508.145159.78704966.suzuki.muneyoshi@lab.ntt.co.jp> To: zinin@psg.com Cc: PPVPN@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Draft charter for L3VPN From: Muneyoshi Suzuki In-Reply-To: <8996969975.20030507221954@psg.com> References: <184493545.20030507185157@psg.com> <20030508.122832.41628530.suzuki.muneyoshi@lab.ntt.co.jp> <8996969975.20030507221954@psg.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex, > This is an "oops". Thanks for catching this (note that the L2vpn charter has > this part.) How about we change the first para to say: > This working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned > Layer-3 (routed) Virtual Private Networks (L3VPNs). Agreed. > If folks believe this is needed, I would suggest we put this in the > possible future items. I am not particularly opposed to the WG looking > at this, I just want us to get the base specs out before jumping on > more advanced things. Agreed. > Agreed. I don't have a particular preference as to which WG these go > to, but it seems that L3vpn would be a good fit. I will wait until > we hear more comments from people. Agreed. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 02:09:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10926 for ; Thu, 8 May 2003 02:09:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h486BaW29721 for ; Thu, 8 May 2003 02:11:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h486BUp17589 for ; Thu, 8 May 2003 02:11:32 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.62677.21745.888768@harjus.eng.song.fi> Date: Thu, 8 May 2003 09:10:29 +0300 To: Alex Zinin Cc: Pedro Roque Marques , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: <9498453278.20030507224437@psg.com> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> <200305080439.h484dLL65952@roque-bsd.juniper.net> <16057.58591.713308.53655@harjus.eng.song.fi> <200305080525.h485PUi66038@roque-bsd.juniper.net> <16057.60591.41023.900682@harjus.eng.song.fi> <9498453278.20030507224437@psg.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex Zinin writes: > Let's keep to goal of that line in the text in mind--make progress on > basic things before going to more complex ones (while still keeping > the Internet-wide considerations in mind). that would be fine if you can guarantee for me that there exists for each solution a backwards compatible migration path from intra-provider to inter-provider although the details may not have been worked out yet. inter-AS is a MUST from the very beginning. > 1. Is complexity associated with inter-provider scenarios > sufficiently higher than for the single-provider case? no, if your solution is a good one. > 2. Is complexity associated with inter-AS (1 provider) scenarios > sufficiently higher than for the single-AS case? same here. check out my radius drafts. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 02:37:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14067 for ; Thu, 8 May 2003 02:37:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h486dYW04841 for ; Thu, 8 May 2003 02:39:34 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h486dUR26052 for ; Thu, 8 May 2003 02:39:31 -0400 (EDT) Date: Wed, 7 May 2003 23:37:13 -0700 (PDT) Message-Id: <200305080637.h486bDh66163@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: <9498453278.20030507224437@psg.com> References: <184493545.20030507185157@psg.com> <16057.55991.734081.636661@harjus.eng.song.fi> <200305080439.h484dLL65952@roque-bsd.juniper.net> <16057.58591.713308.53655@harjus.eng.song.fi> <200305080525.h485PUi66038@roque-bsd.juniper.net> <16057.60591.41023.900682@harjus.eng.song.fi> <9498453278.20030507224437@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex Zinin writes: >> 1. BGP/MPLS IP VPNs (based on RFC 2547) 2. IP VPNs using Virtual >> Routers 3. CE-based VPNs using IPSEC > --let's answer two questions: > 1. Is complexity associated with inter-provider scenarios > sufficiently higher than for the single-provider case? > 2. Is complexity associated with inter-AS (1 provider) scenarios > sufficiently higher than for the single-AS case? Regarding 2547bis, which is the model i'm familiar with, i believe the current spec already provides enought functionality to allow inter-as/same provider to be used in production environments. The fundamental building blocks apear to be in place. I wouldn't expect additional work in this area to be disjoint from the intra-as scenarios. The additional technology that is applicable in this case besides what is specified in 2547bis is (to my knowledge): RFC 3107, inter-as RSVP-TE (which is being pursued in different WG). I believe it would be useful not to exclude this work from the charter. Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 08:15:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20703 for ; Thu, 8 May 2003 08:15:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48CHvW10695 for ; Thu, 8 May 2003 08:17:58 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48CHrX02806 for ; Thu, 8 May 2003 08:17:54 -0400 (EDT) From: "Jim Guichard" To: "Alex Zinin" , "Juha Heinanen" Cc: "Pedro Roque Marques" , Subject: RE: Draft charter for L3VPN: inter-AS/inter-provider Date: Thu, 8 May 2003 08:10:07 -0400 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) In-Reply-To: <9498453278.20030507224437@psg.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Alex, > >-----Original Message----- > >From: Alex Zinin [mailto:zinin@psg.com] > >Sent: Thursday, May 08, 2003 1:45 AM > >To: Juha Heinanen > >Cc: Pedro Roque Marques; PPVPN@nortelnetworks.com > >Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider > > > > > >Juha, Pedro- > > > > Let's keep to goal of that line in the text in mind--make progress on > > basic things before going to more complex ones (while still keeping > > the Internet-wide considerations in mind). > > > > Now, looking at the solutions that we have on the plate now-- > > > >> 1. BGP/MPLS IP VPNs (based on RFC 2547) > >> 2. IP VPNs using Virtual Routers > >> 3. CE-based VPNs using IPSEC > > > > --let's answer two questions: > > > > 1. Is complexity associated with inter-provider scenarios > > sufficiently higher than for the single-provider case? potentially yes as each independent AS might run differing backbone protocols e.g. 2547oLDP Vs 2547oGRE. An end-to-end LSP must be maintained between ingress/egress PEs so the complexity associated with this operation is imho higher than within a single AS (although even in that case there may be different "islands" that need to interop). > > > > 2. Is complexity associated with inter-AS (1 provider) scenarios > > sufficiently higher than for the single-AS case? potentially yes for the same reasons as (1). Jim > > > > Depending on the answers we should be able to draw the line for the > > first step to include either the single-AS or the single-provider > > scenarios only. > > > >-- > >Alex > > > >Wednesday, May 7, 2003, 10:35:43 PM, Juha Heinanen wrote: > >> Pedro Roque Marques writes: > > > >> > There is in my mind a fundamental difference between a VPN that can > >> > span more than one provider and a VPN which is "provided" to the > >> > customer network by two different entities. > > > >> i mean the latter, i.e., the pe in china to which a site is > >connected to > >> belongs to a provider that operates in china. > > > >> > One can have a VPN spanning multiple carrier networks by > >using inter-as > >> > LSPs such what can be provided by carrier-of-carriers or inter-as > >> > RSVP-TE (when avaliable). > > > >> sorry, but i'm only interested in ip based solutions, not mpls. > > > >> > I'd be inclined to think that if people come forth and flush out the > >> > multi-provider requirements that the work will be welcomed. > >But i can > >> > see the attraction in attempting to focus in the single > >provider case. > > > >> if you look my radius based proposals, they work equally both in single > >> provider and multi-provider cases. > > > >> -- juha > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 10:06:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23326 for ; Thu, 8 May 2003 10:06:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48E8lW26604 for ; Thu, 8 May 2003 10:08:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48E8gT00732 for ; Thu, 8 May 2003 10:08:43 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "Paul Knight" , "'Alex Zinin'" , Cc: , "'Wijnen, Bert \(Bert\)'" , "'Thomas Narten'" , "'Peterson, Jon'" , "'Allison Mankin'" Subject: RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF Date: Thu, 8 May 2003 09:54:30 -0400 Organization: Cisco Systems, Inc. Message-ID: <00dc01c31569$5c4c75d0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01C31547.D53AD5D0" 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: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_00DD_01C31547.D53AD5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 You raise a good point. Is there going to be any discussion of actual provisioning of VPNs? =20 --Tom =20 -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Paul Knight Sent: Wednesday, May 07, 2003 12:56 PM To: Alex Zinin; ppvpn@nortelnetworks.com Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten; Peterson, Jon; Allison Mankin Subject: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF Hi Alex,=20 The proposed split seems to put very little emphasis on the "PP" of = PPVPN.=20 The proposed focus on technologies for L2 and L3 is likely to seriously disrupt the focus on the "Provider Provisioned" concept, where much of = the value comes from aiming for interoperation across all major VPN technologies. Of course, we could have PPL2VPN and PPL3VPN, but as has = been pointed out, we then need to coordinate the "PP" parts across the two = WGs. =20 VPN customers want a bundle of VPN services, and don't really care = whether it is L2 or L3 (or L1) or some mixture. VPN service providers want an interoperable toolkit which they can use to design services that they = can differentiate in various ways to attract VPN customers. PPVPN is = providing a forum to define the operation of the VPN tools. Regardless of L2 or L3 technologies, there is a need for simple and interoperable mechanisms = for VPN membership and discovery, security considerations, SLA verification, = and a host of management areas. These mechanisms are being defined, = clarified, and debated in PPVPN mostly without regard to the specific L2 or L3 approaches. They should not be either dropped, or split across two WGs. Yes there is a lot of work in the group, but if it gets fragmented and things slip through the cracks, then we will be forcing the VPN service providers, vendors, and customers to do much more work and spend much = more time in the long run. In terms of meeting logistics, we will find that many of the same people will be attending and developing drafts for the proposed L2 and L3 WGs, = so we will have to make sure that they don't overlap... Just the same as if = we plan extended meeting times for the current PPVPN when it is needed. Finally, I'm closely involved with two areas of work in L3 VPNs in = PPVPN, and we are getting to the point where much of the basic work is stable, = so the L3VPN may not justify a dedicated WG for much longer, although it = does need a WG in which to operate. I would suggest planning for a longer meeting in Vienna (if the agenda justifies it) and bringing this proposal up for discussion there. Regards,=20 Paul=20 > -----Original Message-----=20 > From: Alex Zinin [mailto:zinin@psg.com]=20 > Sent: Sunday, May 04, 2003 3:12 AM=20 > To: ppvpn@nortelnetworks.com=20 > Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten;=20 > Peterson, Jon; Allison Mankin=20 > Subject: IMPORTANT: Strategy for VPN work in IETF=20 >=20 >=20 > Folks,=20 >=20 > Since San Francisco IETF meeting the IESG has been=20 > considering the situation in the SUB-IP area and in the PPVPN=20 > Working Group in particular.=20 >=20 > Such close attention to this WG was triggered by numerous=20 > concerns that the IESG members received from the WG=20 > participants about limited and slow progress within the WG=20 > despite the efforts of the WG chairs and its members. The=20 > IESG also used this opportunity to consider the IETF area=20 > that the PPVPN work would fit best.=20 >=20 > After much deliberation, the involved ADs (Bert, Thomas, and I) are=20 > considering the following organizational changes in order to=20 > improve WG=20 > focus and productivity and ensure faster progress of the=20 > VPN-related work:=20 >=20 > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups.=20 >=20 > The L2 and L3 VPN work spaces are each big enough to=20 > warrant a separate=20 > WG. While concentration of all VPN-related work in a=20 > single forum was=20 > the right thing to do to ensure coordination of efforts=20 > when the PPVPN=20 > WG was created and L2 VPN work came in, such=20 > concentration is causing=20 > scaling problems within the WG at this moment.=20 >=20 > Migration of work into two separate WGs for L2 and L3 VPN=20 > technologies=20 > with more specific WG charters will help to focus=20 > discussions, prevent=20 > staff and meeting time overloading, and will aid faster=20 > progress of=20 > corresponding technologies.=20 >=20 > 2. Migration of the VPN-related work to the Internet area.=20 >=20 > As previously discussed, VPN-related work could be argued=20 > to belong=20 > to more than one area. Tunneling mechanisms are the property that=20 > gravitates this work to the Internet area, which is where=20 > we believe=20 > the VPN work should go.=20 >=20 > As part of this move, we are also considering moving PWE3=20 > into INT,=20 > so that L2TPEXT, PWE3, and thew new VPN WGs are operating=20 > in the same=20 > area.=20 >=20 > Based on the above considerations, we are considering the=20 > following steps:=20 >=20 > 1. Two new WGs--L2VPN and L3VPN--will be created in the=20 > Internet area.=20 > The mailing lists will be established and the discussion=20 > of the proposed=20 > charters of the new WGs will be initiated shortly.=20 >=20 > 2. Once the charters of the new WGs are agreed upon and=20 > approved by the IESG,=20 > creation of the L2VPN and L3VPN WGs and shutdown of the=20 > PPVPN WG will be=20 > performed simultaneously. PPVPN WG documents will be=20 > migrated to the=20 > corresponding new WGs.=20 >=20 > It is our intention to complete this process by the Vienna=20 > IETF meeting.=20 > Also, these changes are being made for management reasons and=20 > are not intended=20 > to be a "reset" on WG activities or to halt or interrupt=20 > progress on current=20 > ongoing WG activities.=20 >=20 > We'd like to hear from the WG members if they see any fatal=20 > flaws with the proposed approach. Please send us your=20 > feedback by May 11th.=20 >=20 > Regards,=20 >=20 > --=20 > Alex Zinin=20 > IETF SUB-IP Area Co-Director=20 >=20 >=20 >=20 ------=_NextPart_000_00DD_01C31547.D53AD5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
    You raise a good point. Is there going to be = any=20 discussion of
actual=20 provisioning of VPNs?
 
    --Tom
 
-----Original Message-----
From:=20 pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of = Paul=20 Knight
Sent: Wednesday, May 07, 2003 12:56 PM
To: = Alex=20 Zinin; ppvpn@nortelnetworks.com
Cc: pwe3@ietf.org; Wijnen, = Bert=20 (Bert); Thomas Narten; Peterson, Jon; Allison = Mankin
Subject: [PWE3]=20 RE: IMPORTANT: Strategy for VPN work in IETF

Hi Alex,

The proposed split seems to put very little emphasis = on the=20 "PP" of PPVPN.

The proposed focus on technologies for L2 and L3 is = likely to=20 seriously disrupt the focus on the "Provider Provisioned" concept, = where much=20 of the value comes from aiming for interoperation across all major VPN = technologies.  Of course, we could have PPL2VPN and PPL3VPN, but = as has=20 been pointed out, we then need to coordinate the "PP" parts across the = two=20 WGs. 

VPN customers want a bundle of VPN services, and = don't really=20 care whether it is L2 or L3 (or L1) or some mixture.  VPN service = providers want an interoperable toolkit which they can use to design = services=20 that they can differentiate in various ways to attract VPN customers. = PPVPN is=20 providing a forum to define the operation of the VPN tools.  = Regardless=20 of L2 or L3 technologies, there is a need for simple and interoperable = mechanisms for VPN membership and discovery, security considerations, = SLA=20 verification, and a host of management areas.  These mechanisms = are being=20 defined, clarified, and debated in PPVPN mostly without regard to the = specific=20 L2 or L3 approaches.  They should not be either dropped, or split = across=20 two WGs.

Yes there is a lot of work in the group, but if it = gets=20 fragmented and things slip through the cracks, then we will be forcing = the VPN=20 service providers, vendors, and customers to do much more work and = spend much=20 more time in the long run.

In terms of meeting logistics, we will find that = many of the=20 same people will be attending and developing drafts for the proposed = L2 and L3=20 WGs, so we will have to make sure that they don't overlap... Just the = same as=20 if we plan extended meeting times for the current PPVPN when it is=20 needed.

Finally, I'm closely involved with two areas of work = in L3=20 VPNs in PPVPN, and we are getting to the point where much of the basic = work is=20 stable, so the L3VPN may not justify a dedicated WG for much longer, = although=20 it does need a WG in which to operate.

I would suggest planning for a longer meeting in = Vienna (if=20 the agenda justifies it) and bringing this proposal up for discussion=20 there.

Regards,
Paul

> -----Original Message-----
>=20 From: Alex Zinin [mailto:zinin@psg.com]=20
> Sent: Sunday, May 04, 2003 3:12 = AM=20
> To: ppvpn@nortelnetworks.com
> Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten;=20
> Peterson, Jon; Allison Mankin =
> Subject: IMPORTANT: Strategy for VPN work in IETF =
>
>
>=20 Folks,
>
> = Since San=20 Francisco IETF meeting the IESG has been
>=20 considering the situation in the SUB-IP area and in the PPVPN =
> Working Group in particular.
>=20
> Such close attention to this WG was = triggered by=20 numerous
> concerns that the IESG members = received=20 from the WG
> participants about limited = and slow=20 progress within the WG
> despite the = efforts of the=20 WG chairs and its members. The
> IESG = also used=20 this opportunity to consider the IETF area
> that=20 the PPVPN work would fit best.
> =
> After much deliberation, the involved ADs (Bert, Thomas, = and I)=20 are
> considering the following = organizational=20 changes in order to
> improve WG =
> focus and productivity and ensure faster progress of the =
> VPN-related work:
>=20
>  1. Split of Layer-2 and Layer-3 = VPN work in=20 separate Working Groups.
> =
>     The L2 and L3 VPN work spaces = are each big=20 enough to
> warrant a separate =
>     WG. While concentration of all = VPN-related=20 work in a
> single forum was =
>     the right thing to do to ensure=20 coordination of efforts
> when the PPVPN=20
>     WG was created = and L2 VPN=20 work came in, such
> concentration is=20 causing
>     scaling = problems=20 within the WG at this moment.
> =
>     Migration of work into two = separate WGs=20 for L2 and L3 VPN
> technologies =
>     with more specific WG charters = will help=20 to focus
> discussions, prevent =
>     staff and meeting time = overloading, and=20 will aid faster
> progress of =
>     corresponding = technologies.=20
>
>  2. = Migration of the=20 VPN-related work to the Internet area.
>=20
>     As previously = discussed,=20 VPN-related work could be argued
> to = belong=20
>     to more than one area. = Tunneling=20 mechanisms are the property that
>     gravitates this work to the = Internet area,=20 which is where
> we believe =
>     the VPN work should go. =
>
>     = As part of=20 this move, we are also considering moving PWE3
>=20 into INT,
>     so = that=20 L2TPEXT, PWE3, and thew new VPN WGs are operating
>=20 in the same
>     = area.=20
>
> Based on the = above=20 considerations, we are considering the
> = following=20 steps:
>
>  1. Two=20 new WGs--L2VPN and L3VPN--will be created in the
>=20 Internet area.
>     = The=20 mailing lists will be established and the discussion
> of the proposed
>     charters of the new WGs will be = initiated=20 shortly.
>
>  2.=20 Once the charters of the new WGs are agreed upon and
> approved by the IESG,
>     creation of the L2VPN and L3VPN = WGs and=20 shutdown of the
> PPVPN WG will be =
>     performed simultaneously. PPVPN = WG=20 documents will be
> migrated to the=20
>     corresponding = new=20 WGs.
>
> It = is our=20 intention to complete this process by the Vienna
>=20 IETF meeting.
> Also, these changes are = being made=20 for management reasons and
> are not = intended=20
> to be a "reset" on WG activities or to = halt or=20 interrupt
> progress on current =
> ongoing WG activities.
>=20
> We'd like to hear from the WG members = if they see=20 any fatal
> flaws with the proposed = approach.=20 Please send us your
> feedback by May = 11th.=20
>
> Regards, =
>
> --
> Alex=20 Zinin
> IETF SUB-IP Area = Co-Director=20
>
> =
>

------=_NextPart_000_00DD_01C31547.D53AD5D0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 10:23:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24813 for ; Thu, 8 May 2003 10:23:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48EQDW02339 for ; Thu, 8 May 2003 10:26:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48EQ9d21158 for ; Thu, 8 May 2003 10:26:09 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16058.26748.862246.81098@harjus.eng.song.fi> Date: Thu, 8 May 2003 17:23:56 +0300 To: Cc: "Paul Knight" , "'Alex Zinin'" , , , "'Wijnen, Bert \(Bert\)'" , "'Thomas Narten'" , "'Peterson, Jon'" , "'Allison Mankin'" Subject: RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: <00dc01c31569$5c4c75d0$6401a8c0@amer.cisco.com> References: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> <00dc01c31569$5c4c75d0$6401a8c0@amer.cisco.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Thomas D. Nadeau writes: > You raise a good point. Is there going to be any discussion of > actual provisioning of VPNs? provisioning is indeed an important issue. i have been told that commercial provisioning systems for bgp/mpls vpns are very expensive. may be that is because provisioning of them is difficult to do. a good solution is such for which writing automatic provisioning tools is very easy. this is true for radius based solutions, where the provisioning system needs little interaction with the actual pes. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 13:49:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01523 for ; Thu, 8 May 2003 13:49:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48Hq2W01453 for ; Thu, 8 May 2003 13:52:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48Hpwt07195 for ; Thu, 8 May 2003 13:51:58 -0400 (EDT) Date: Thu, 8 May 2003 10:48:24 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@u43 To: Alex Zinin Cc: Juha Heinanen , Pedro Roque Marques , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: <9498453278.20030507224437@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: prattle.redback.com X-SMTP-MAIL-FROM: rahul@redback.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: prattle.redback.com [155.53.12.9] X-LYRIS-Message-Id: Alex, On Wed, 7 May 2003, Alex Zinin wrote: > Juha, Pedro- > > Let's keep to goal of that line in the text in mind--make progress on > basic things before going to more complex ones (while still keeping > the Internet-wide considerations in mind). > > Now, looking at the solutions that we have on the plate now-- > > > 1. BGP/MPLS IP VPNs (based on RFC 2547) > > 2. IP VPNs using Virtual Routers > > 3. CE-based VPNs using IPSEC > > --let's answer two questions: > > 1. Is complexity associated with inter-provider scenarios > sufficiently higher than for the single-provider case? > > 2. Is complexity associated with inter-AS (1 provider) scenarios > sufficiently higher than for the single-AS case? > > Depending on the answers we should be able to draw the line for the > first step to include either the single-AS or the single-provider > scenarios only. > I will restrict my response to 2547. For 2547 inter-as/singe-provider solutions exist and are hashed out. Deploying them may be more complicated than a single-AS, but certainly doesn't validate precluding them from the charter. Hence we should keep them in the charter. Inter-provider solutions can be a future work item. Regards, rahul > -- > Alex > > Wednesday, May 7, 2003, 10:35:43 PM, Juha Heinanen wrote: > > Pedro Roque Marques writes: > > > > There is in my mind a fundamental difference between a VPN that can > > > span more than one provider and a VPN which is "provided" to the > > > customer network by two different entities. > > > i mean the latter, i.e., the pe in china to which a site is connected to > > belongs to a provider that operates in china. > > > > One can have a VPN spanning multiple carrier networks by using inter-as > > > LSPs such what can be provided by carrier-of-carriers or inter-as > > > RSVP-TE (when avaliable). > > > sorry, but i'm only interested in ip based solutions, not mpls. > > > > I'd be inclined to think that if people come forth and flush out the > > > multi-provider requirements that the work will be welcomed. But i can > > > see the attraction in attempting to focus in the single provider case. > > > if you look my radius based proposals, they work equally both in single > > provider and multi-provider cases. > > > -- juha > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 14:12:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02229 for ; Thu, 8 May 2003 14:12:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48IEsW29418 for ; Thu, 8 May 2003 14:14:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48IEn906291 for ; Thu, 8 May 2003 14:14:50 -0400 (EDT) Message-ID: <3EBA9CB1.99B911B1@cisco.com> Date: Thu, 08 May 2003 20:06:41 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN References: <184493545.20030507185157@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Alex, Just two small comments: > Multicast support and Inter-AS considerations are excluded from the charter > at this time. This is very bad thing as each extension or proposed solution has to work both intra and inter domain. There are production deployments already inter-as and any solution which one would come up and which would be limited to intra-as would a bad one. Besides while a number of solutions can be easy to solve intra-domin going out of AS those may no longer work. So my vote is to delete this line. The Inter-AS border on L3VPNs is crossed long time ago ;). > As a general rule, the WG will not create new protocols, but will provide > functional requirements for extensions of the existing protocols that will > be discussed in the protocol-specific WGs. That is even biggest evil making essentially as ppvpn this new WG useless :).Without at least ability to propose extensions to protocols submitting any serious draft is pointless. If I have to write requirements for myself and submit a solution in IDR I would just go for the latter immediately. Also note that this line is outside of reality of work done in vast majority of all drafts in ppvpn WG. I do hope that this line will also be removed therefor making the ppvnp split really useful in practice Cheers, R. Alex Zinin wrote: > > Folks- > > It is taking longer than I anticipated to set up the mailing lists, so > I am sending the proposed WG charters to this list. These are > _drafts_, so are likely to need more fine-tuning. Below is the > proposed charter for L3VPN. The one on L2VPN is in a separate message. > Comments welcome. > > -- > Alex > > Layer 3 Virtual Private Networks (l3vpn) > > Chair(s): > > Area Director(s): > Thomas Narten > Erik Nordmark > > Area Advisor: > Thomas Narten > > Technical Advisor: > Alex Zinin > > Description of Working Group: > > This working group is responsible for defining and specifying a > limited number of solutions for supporting Layer-3 (routed) > Virtual Private Networks (L3VPNs). > > The WG is responsible for standardization of the following solutions: > > 1. BGP/MPLS IP VPNs (based on RFC 2547) > 2. IP VPNs using Virtual Routers > 3. CE-based VPNs using IPSEC > > As part of this effort the WG will work on the following tasks > (additional work items will require rechartering): > > 1. Requirements and framework for Layer 3 VPNs > 2. Solution documents for each approach listed above (including > applicability statements) > 3. MIB definitions for each approach > 4. Security mechanisms for each approach > > Multicast support and Inter-AS considerations are excluded from the charter > at this time. They may be considered for inclusion in an updated charter > at a later time. Future work items may also include OAM support. > > As a general rule, the WG will not create new protocols, but will provide > functional requirements for extensions of the existing protocols that will > be discussed in the protocol-specific WGs. > > WG Milestones (optimistic): > > Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info > (completed) > Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info > (completed) > Aug 2003 Submit L3 VPN Security Analysis to IESG for publication as Info > (draft-fang-ppvpn-security-framework-00) > Aug 2003 Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS > (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01) > > Sep 2003 Submit CE-based specification and AS to IESG for publication as PS > (draft-ietf-ppvpn-ce-based-03) > Sep 2003 Submit Virtual Router specification and AS to IESG for publication as PS > (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) > Oct 2003 Submit VPN MIB Textual Conventions to IESG for publication as PS > (draft-ietf-ppvpn-tc-mib-02) > Oct 2003 Submit MPLS BGP MIB to IESG for publication as PS > (draft-ietf-ppvpn-mpls-vpn-mib-05) > Oct 2003 Submit VR MIB to IESG for publication as PS > (draft-ietf-ppvpn-vr-mib-04) > > Dec 2003 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG > for publication as PS > (draft-ietf-ppvpn-ipsec-2547-03) > Jan 2003 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG > for publication as PS > (draft-ietf-ppvpn-gre-ip-2547-02) > > Jan 2003 Submit specification of CE Route Authentication to IESG for publication as PS > (draft-ietf-ppvpn-l3vpn-auth-03) From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 14:30:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02663 for ; Thu, 8 May 2003 14:30:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48IWTW07569 for ; Thu, 8 May 2003 14:32:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48IWNg23994 for ; Thu, 8 May 2003 14:32:24 -0400 (EDT) Date: Thu, 8 May 2003 11:27:19 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@u43 To: Robert Raszuk Cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN In-Reply-To: <3EBA9CB1.99B911B1@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: prattle.redback.com X-SMTP-MAIL-FROM: rahul@redback.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: prattle.redback.com [155.53.12.9] X-LYRIS-Message-Id: [clipped] > > As a general rule, the WG will not create new protocols, but will provide > > functional requirements for extensions of the existing protocols that will > > be discussed in the protocol-specific WGs. > > That is even biggest evil making essentially as ppvpn this new WG > useless :).Without at least ability to propose extensions to protocols > submitting any serious draft is pointless. If I have to write > requirements for myself and submit a solution in IDR I would just go for > the latter immediately. Also note that this line is outside of reality > of work done in vast majority of all drafts in ppvpn WG. I do hope that > this line will also be removed therefor making the ppvnp split really > useful in practice > I very strongly second Robert's opinion. Time and again the procedure of defining protocol extensions in PPVPN comes up. And every time the reality is ignored. How about the following: "The WG may propose extensions to existing protocols and such extensions will be discussed and reviewed by the protocol-specific WG." The question than is: Should a document submitted to the current PPVPN WG (or the new groups if the split happens) be accepted as a WG doc before the protocol specific WG reviews protocol extensions (if any) ? I think we need more discussion on this. There are cases where it makes sense to have such a review before accepting the doc as a WG doc and there are cases where it doesn't. Regards, rahul > Cheers, > R. > > > > Alex Zinin wrote: > > > > Folks- > > > > It is taking longer than I anticipated to set up the mailing lists, so > > I am sending the proposed WG charters to this list. These are > > _drafts_, so are likely to need more fine-tuning. Below is the > > proposed charter for L3VPN. The one on L2VPN is in a separate message. > > Comments welcome. > > > > -- > > Alex > > > > Layer 3 Virtual Private Networks (l3vpn) > > > > Chair(s): > > > > Area Director(s): > > Thomas Narten > > Erik Nordmark > > > > Area Advisor: > > Thomas Narten > > > > Technical Advisor: > > Alex Zinin > > > > Description of Working Group: > > > > This working group is responsible for defining and specifying a > > limited number of solutions for supporting Layer-3 (routed) > > Virtual Private Networks (L3VPNs). > > > > The WG is responsible for standardization of the following solutions: > > > > 1. BGP/MPLS IP VPNs (based on RFC 2547) > > 2. IP VPNs using Virtual Routers > > 3. CE-based VPNs using IPSEC > > > > As part of this effort the WG will work on the following tasks > > (additional work items will require rechartering): > > > > 1. Requirements and framework for Layer 3 VPNs > > 2. Solution documents for each approach listed above (including > > applicability statements) > > 3. MIB definitions for each approach > > 4. Security mechanisms for each approach > > > > Multicast support and Inter-AS considerations are excluded from the charter > > at this time. They may be considered for inclusion in an updated charter > > at a later time. Future work items may also include OAM support. > > > > As a general rule, the WG will not create new protocols, but will provide > > functional requirements for extensions of the existing protocols that will > > be discussed in the protocol-specific WGs. > > > > WG Milestones (optimistic): > > > > Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info > > (completed) > > Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info > > (completed) > > Aug 2003 Submit L3 VPN Security Analysis to IESG for publication as Info > > (draft-fang-ppvpn-security-framework-00) > > Aug 2003 Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS > > (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01) > > > > Sep 2003 Submit CE-based specification and AS to IESG for publication as PS > > (draft-ietf-ppvpn-ce-based-03) > > Sep 2003 Submit Virtual Router specification and AS to IESG for publication as PS > > (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) > > Oct 2003 Submit VPN MIB Textual Conventions to IESG for publication as PS > > (draft-ietf-ppvpn-tc-mib-02) > > Oct 2003 Submit MPLS BGP MIB to IESG for publication as PS > > (draft-ietf-ppvpn-mpls-vpn-mib-05) > > Oct 2003 Submit VR MIB to IESG for publication as PS > > (draft-ietf-ppvpn-vr-mib-04) > > > > Dec 2003 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG > > for publication as PS > > (draft-ietf-ppvpn-ipsec-2547-03) > > Jan 2003 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG > > for publication as PS > > (draft-ietf-ppvpn-gre-ip-2547-02) > > > > Jan 2003 Submit specification of CE Route Authentication to IESG for publication as PS > > (draft-ietf-ppvpn-l3vpn-auth-03) > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 14:44:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03189 for ; Thu, 8 May 2003 14:44:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48IlCW15299 for ; Thu, 8 May 2003 14:47:12 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48Il7E06385 for ; Thu, 8 May 2003 14:47:07 -0400 (EDT) Message-Id: <200305081844.h48Ii2AD025062@rtp-core-1.cisco.com> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN In-reply-to: Your message of Wed, 07 May 2003 18:51:57 -0700. <184493545.20030507185157@psg.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: Thu, 08 May 2003 14:44:02 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: > Inter-AS considerations are excluded from the charter at this time. As many have pointed out, this doesn't make much sense, as multi-AS and even multi-provider capability must be present in order to make the solution useful. However, in the case of 2547bis, the "multiple providers" are expected to be a small number of closely cooperating service providers. There really isn't much provision for running the VPNs over the public Internet. It might be good to have this "public Internet transparency" excluded from the charter. Presumably, that would prevent the IESG from later rejecting the specs on the grounds that they don't provide public Internet transparency. With regard to the specific list of documents, a notable omission is the specification for doing 2547bis when OSPF is the PE/CE protocol. Now that a proper division of responsibilities has been agreed with the OSPF WG, I'd like to see this document added to the list. > As a general rule, the WG will not create new protocols, but will provide > functional requirements for extensions of the existing protocols that will > be discussed in the protocol-specific WGs. I happen to like this sort of restriction, because it helps to prevent a situation in which every proposal includes an extension that is entirely optimized for that proposal. One more comment: I believe that the month following Dec 2003 is Jan 2004. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 15:17:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05346 for ; Thu, 8 May 2003 15:17:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48JJdW25105 for ; Thu, 8 May 2003 15:19:40 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48JJZM22731 for ; Thu, 8 May 2003 15:19:35 -0400 (EDT) Message-Id: <200305081915.h48JFoAD004347@rtp-core-1.cisco.com> To: mick_seaman@ieee.org cc: "'Pedro Roque Marques'" , "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Wed, 07 May 2003 22:26:38 -0700. <000b01c31522$6794eb30$210110ac@corp.telseon.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: Thu, 08 May 2003 15:15:50 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: I think I see what you're saying -- the FW model provides one emulated LAN per VPLS instance, and only bridges which support that VPLS instances need attach to that emulated LAN. In the IEEE model, all the provider bridges attach to a single emulated LAN, and the VPLS instances would be treated as VLANs of that emulated LAN. Since a VPLS would have sites all around the world presumably, attaching to multiple provider networks, why doesn't this imply that every provider bridge in the world needs to be on the same emulated LAN? You're correct that that does not seem scalable to me. Mick> (1) If the support of each VPLS is understood to be accomplished by a Mick> number of 'virtual bridges' the very strong properties of the Mick> mux/demux function that ties each of these together at each point of Mick> underlying service use need to be explained and not trivialised (equal Mick> potential reachability connectivity etc.) and if they cannot be Mick> guaranteed overhauled and possibly replicated. That doesn't seem like a fatal objection, especially given the alternative. Mick> (2) Removal of the non VLAN mux/demuxed control traffic not only means Mick> that information that can no longer be shared has to be replicated, That certainly seems like the lesser of the evils. Mick> but that certain items of information (what is the maximum possible Mick> extent of this set of VLANs so that I can simply autoconfigure each to Mick> the size demanded by external inputs) seems to have disappeared Mick> entirely. Yes, that would need to be provisioned. Mick> One excuse for the decomposition of the MAC service into the set of Mick> VLAN specific MACs with no other non-VLAN component is that each VPLS Mick> will be a 'provisioned service'. Yes. Mick> At bottom this is simply a claim that the network provider will never Mick> ever make a mistake and has a perfectly working service at all times. No, but it does mean that the OAM model is different, from layer 3 rather than from layer 2. The provider will manage his network as a layer 3 network, not as a layer 2 network. Mick> If you think that is good enough then you never have to ship BPDUs Mick> except when the input conditions change, the far side of each VPLS Mick> just manufactures repeat copies at regular intervals Actually, I like the idea of having the BPDUs spoofed locally, driven perhaps by changes that are learned via network mechanisms. This might help with the "bridges are very susceptible to errors in perceived connectivity" issue. It seems to me that you've pointed to some issues which need to be worked, but if there's a fatal flaw, I don't see what it is. But perhaps there are still some layer 2 issues that I just don't appreciate. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 16:19:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09200 for ; Thu, 8 May 2003 16:19:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48KLmW09083 for ; Thu, 8 May 2003 16:21:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48KLik05697 for ; Thu, 8 May 2003 16:21:44 -0400 (EDT) Reply-To: From: "Mick Seaman" To: Cc: "'Pedro Roque Marques'" , "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Thu, 8 May 2003 13:18:59 -0700 Message-ID: <000501c3159f$122c1c90$210110ac@corp.telseon.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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200305081915.h48JFoAD004347@rtp-core-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SMTP-HELO: pimout3-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout3-ext.prodigy.net [207.115.63.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit The first thing is to appreciate the difference in the models, the second is to work out what information needs to go where and why. It seems that we have spent too long in the 'VPLS works like this, so what do I have to send on each VPLS' mode, and need to get up above that perspective. Of course the IEEE model doesn't require all provider bridges to be on the same emulated LAN, only all those that are optimising their control traffic by sharing its results between them - i.e. just like ordinary LAN. So VPLS's that are on the *same* underlying connectivity can share that knowledge and don't have to suffer BPDU sending inefficiency. Having just written this I now see that it is crucially important to distinguish between "an emulated LAN" and "a subset of an emulated LAN such that control connectivity can be shared amongst the VLANs using it", of course the subset is an emulated LAN in its own right. We don't have this descriptive problem in the IEEE model (yet) because the name for the subset with identical control connectivity is "a LAN", a real one with a single MAC and no bridges inside it. This has probably got to be developed along the lines of investigating how good an emulation any given emulation is, the past descriptions of "looks like" i.e. "looks like a LAN", "no, looks like a bridge", "no, looks like a bridge with LANs around it", "no, looks like a LAN with bridges around it with LANs around them" doesn't get us very far. I had started some work on various good wasy to spoof and otherwise optimise control flows over shaky media, hopefully some time I'll get back to it. And no I don't think there is a fatal flaw either, just some problems to be overscoem. -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Thursday, May 08, 2003 12:16 PM To: mick_seaman@ieee.org Cc: 'Pedro Roque Marques'; 'Himanshu Shah'; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'; ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents I think I see what you're saying -- the FW model provides one emulated LAN per VPLS instance, and only bridges which support that VPLS instances need attach to that emulated LAN. In the IEEE model, all the provider bridges attach to a single emulated LAN, and the VPLS instances would be treated as VLANs of that emulated LAN. Since a VPLS would have sites all around the world presumably, attaching to multiple provider networks, why doesn't this imply that every provider bridge in the world needs to be on the same emulated LAN? You're correct that that does not seem scalable to me. Mick> (1) If the support of each VPLS is understood to be accomplished by a Mick> number of 'virtual bridges' the very strong properties of the Mick> mux/demux function that ties each of these together at each point of Mick> underlying service use need to be explained and not trivialised (equal Mick> potential reachability connectivity etc.) and if they cannot be Mick> guaranteed overhauled and possibly replicated. That doesn't seem like a fatal objection, especially given the alternative. Mick> (2) Removal of the non VLAN mux/demuxed control traffic not only means Mick> that information that can no longer be shared has to be replicated, That certainly seems like the lesser of the evils. Mick> but that certain items of information (what is the maximum possible Mick> extent of this set of VLANs so that I can simply autoconfigure each to Mick> the size demanded by external inputs) seems to have disappeared Mick> entirely. Yes, that would need to be provisioned. Mick> One excuse for the decomposition of the MAC service into the set of Mick> VLAN specific MACs with no other non-VLAN component is that each VPLS Mick> will be a 'provisioned service'. Yes. Mick> At bottom this is simply a claim that the network provider will never Mick> ever make a mistake and has a perfectly working service at all times. No, but it does mean that the OAM model is different, from layer 3 rather than from layer 2. The provider will manage his network as a layer 3 network, not as a layer 2 network. Mick> If you think that is good enough then you never have to ship BPDUs Mick> except when the input conditions change, the far side of each VPLS Mick> just manufactures repeat copies at regular intervals Actually, I like the idea of having the BPDUs spoofed locally, driven perhaps by changes that are learned via network mechanisms. This might help with the "bridges are very susceptible to errors in perceived connectivity" issue. It seems to me that you've pointed to some issues which need to be worked, but if there's a fatal flaw, I don't see what it is. But perhaps there are still some layer 2 issues that I just don't appreciate. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 17:49:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12612 for ; Thu, 8 May 2003 17:49:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48LpYW21826 for ; Thu, 8 May 2003 17:51:34 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48LpUS15076 for ; Thu, 8 May 2003 17:51:31 -0400 (EDT) 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: Comments on the L2 VPN framework and solutions documents Date: Thu, 8 May 2003 17:46:55 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB720215260C@WHISTLER.WaveSmithNet.com> Thread-Topic: Comments on the L2 VPN framework and solutions documents Thread-Index: AcMU6eCUJdJatS7QTEGwpOoBypo02AAuMcQw From: "Himanshu Shah" To: , "Norman Finn" , "Muneyoshi Suzuki" , "Tony Jeffree" , "Les Bell" , "Paul Congdon" , "Neil Jarvis" Cc: , X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12612 I understand this approach. Its a simple approach. And if you want to run M-STP (1 instance) across PWs you may want to use this approach. However, the VPLS drafts in IETF explicitly talks about not having to run the P-STP across PWs. Dual-homing/external loop in Provider's network is handled without using P-STP. There seems to be some disconnect in understanding between these two groups that needs to be worked out. /himanshu -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Wednesday, May 07, 2003 6:42 PM To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Himanshu, In (1) I think you have your layering a little mixed up. From the point of view of control connectivity the pseudo-wires have to establish a full mesh that is never perceived by layer 2 protocols as being less than complete. STP is running across the service that runs on top of the mechanisms that make the service LAN like. If you wish to provide subset LANs to be configured then of course you can have subsets each of which has full connectivity in itself. Just never try to pretend to layer 2 that two non equal subsets are the same LAN. In (2) I think you are further into the same pit. It is trivial to get into BPDU scaleability issues along the path you suggest. A much more attractive alternative is to maintain a single full mesh for control connectivity which then prunes that mesh per VPLS (each VPLS doesn't have to touch certain mesh nodes) and then uses that pruning to delete VPLS specific pseudowires to the unwanted mesh nodes. Only one instance of the topology determining protocol and the pruning protocol are then required for all VPLSs. The trick here is to put provider provisioning in at the right level in the architecture (i.e. not at the pseudowire level,but higher up so that it can drive the pseudowire level in the context of the actually available resources). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 10:29 AM To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents This digresses from earlier thinking (at least mine) that P-STP would not span across pseudowires. There are several implications to running STP across PWs that may need to be clarified/worked out. 1) "fully-meshed" attribute of the PWs only applied within a context of a VPLS instance. That is, if PE1 and PE2 participated in VPLS instance 1 than there was no pseudowire to PE3 which did not participate in VPLS instance 1. However, with this scheme, each PE would have pseudowire to every other VPLS capable PE irrespective of its VPLS instance membership 2) Assuming that 1 MSTP instance covers entire provider's network, a backdoor link from ProvBridge1 to ProvBridge2 of VPLS instance 1, may cause 802.1ad's emulated LAN ports to all VPLS instances (i.e. all PWs from that PE are in blocked state irrespective of its VPLS instance membership). Doesn't this block other VPLS instances's traffic across PWs? Perhaps my assumption is wrong and there is in fact P-STP instance for each VPLS instance. However, if that is true, PE would run into BPDU scalability issues. /himanshu -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Wednesday, May 07, 2003 10:42 AM To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents If the fully meshed pseudowires (and the attached equipment/functions at their ends) provide a LAN Service (stictly the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both documents) then RSTP/MSTP will work just fine. To be more specific P802.1ad does specify the operation of a single instance of MSTP within a Provider Network, how that travels over pseduowires is of course how any LAN traffic travels over psedudowires (i.e. the pseudowire protocol looks after making sure the configuration of the pseudo wires correctly provides the fully connected LAN service, that not being either MSTPs design goal or the desire of P802.1ad to specify the simulation of LANs over non-LAN media, particularly where the non-LAN media have native protocols that are to be used as part of the solution - MPLS for example). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 6:01 AM To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Norm, You have to excuse me for jumping in at the tail end and not following the thread. I would like a clarification. Are you implying that 802.1ad is contemplating on running one or more (Provider's) instances of R/M/STP on fully-meshed pseudowires? /himanshu Wavesmith Networks -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, May 06, 2003 8:14 PM To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 18:31:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15134 for ; Thu, 8 May 2003 18:31:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48MYDW18412 for ; Thu, 8 May 2003 18:34:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48MY8X26220 for ; Thu, 8 May 2003 18:34:09 -0400 (EDT) Reply-To: From: "Mick Seaman" To: "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" Cc: , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Thu, 8 May 2003 15:32:17 -0700 Message-ID: <000b01c315b1$afb14190$210110ac@corp.telseon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01C31577.03526990" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB720215260C@WHISTLER.WaveSmithNet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MS-TNEF-Correlator: 0000000043410BC5A002D6408BB2E6318DA014D20422C700 X-SMTP-HELO: pimout3-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout3-ext.prodigy.net [207.115.63.102] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C31577.03526990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Himanshu, If the VPLS drafts have not changed significantly in their intent (I don't think they have) there is not a disconnect here. There is a difference between running spanning tree to cut PWs and reduce their topology to that of a spanning tree (which is what the VPLS folks were correctly rejecting) and conveying spanning tree BPDUs across the emulated LAN formed by PWs so that bridge ports attaching to that emulate LAN service can have the right state, including the 'LAN' or not in the active topology/topologies for VLANs. Again it is neccessary to get the layering straight, focusing on which wire a BPDU goes down before the layering is straight really doesn't help. Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Thursday, May 08, 2003 2:47 PM To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents I understand this approach. Its a simple approach. And if you want to run M-STP (1 instance) across PWs you may want to use this approach. However, the VPLS drafts in IETF explicitly talks about not having to run the P-STP across PWs. Dual-homing/external loop in Provider's network is handled without using P-STP. There seems to be some disconnect in understanding between these two groups that needs to be worked out. /himanshu -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Wednesday, May 07, 2003 6:42 PM To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Himanshu, In (1) I think you have your layering a little mixed up. From the point of view of control connectivity the pseudo-wires have to establish a full mesh that is never perceived by layer 2 protocols as being less than complete. STP is running across the service that runs on top of the mechanisms that make the service LAN like. If you wish to provide subset LANs to be configured then of course you can have subsets each of which has full connectivity in itself. Just never try to pretend to layer 2 that two non equal subsets are the same LAN. In (2) I think you are further into the same pit. It is trivial to get into BPDU scaleability issues along the path you suggest. A much more attractive alternative is to maintain a single full mesh for control connectivity which then prunes that mesh per VPLS (each VPLS doesn't have to touch certain mesh nodes) and then uses that pruning to delete VPLS specific pseudowires to the unwanted mesh nodes. Only one instance of the topology determining protocol and the pruning protocol are then required for all VPLSs. The trick here is to put provider provisioning in at the right level in the architecture (i.e. not at the pseudowire level,but higher up so that it can drive the pseudowire level in the context of the actually available resources). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 10:29 AM To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents This digresses from earlier thinking (at least mine) that P-STP would not span across pseudowires. There are several implications to running STP across PWs that may need to be clarified/worked out. 1) "fully-meshed" attribute of the PWs only applied within a context of a VPLS instance. That is, if PE1 and PE2 participated in VPLS instance 1 than there was no pseudowire to PE3 which did not participate in VPLS instance 1. However, with this scheme, each PE would have pseudowire to every other VPLS capable PE irrespective of its VPLS instance membership 2) Assuming that 1 MSTP instance covers entire provider's network, a backdoor link from ProvBridge1 to ProvBridge2 of VPLS instance 1, may cause 802.1ad's emulated LAN ports to all VPLS instances (i.e. all PWs from that PE are in blocked state irrespective of its VPLS instance membership). Doesn't this block other VPLS instances's traffic across PWs? Perhaps my assumption is wrong and there is in fact P-STP instance for each VPLS instance. However, if that is true, PE would run into BPDU scalability issues. /himanshu -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Wednesday, May 07, 2003 10:42 AM To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents If the fully meshed pseudowires (and the attached equipment/functions at their ends) provide a LAN Service (stictly the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both documents) then RSTP/MSTP will work just fine. To be more specific P802.1ad does specify the operation of a single instance of MSTP within a Provider Network, how that travels over pseduowires is of course how any LAN traffic travels over psedudowires (i.e. the pseudowire protocol looks after making sure the configuration of the pseudo wires correctly provides the fully connected LAN service, that not being either MSTPs design goal or the desire of P802.1ad to specify the simulation of LANs over non-LAN media, particularly where the non-LAN media have native protocols that are to be used as part of the solution - MPLS for example). Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Wednesday, May 07, 2003 6:01 AM To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Norm, You have to excuse me for jumping in at the tail end and not following the thread. I would like a clarification. Are you implying that 802.1ad is contemplating on running one or more (Provider's) instances of R/M/STP on fully-meshed pseudowires? /himanshu Wavesmith Networks -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, May 06, 2003 8:14 PM To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents Muneyoshi, Muneyoshi Suzuki wrote: > > > I don't think we're referring to the same model. The correct model > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > instance, is: > > The discussion is in the context of WG last call of the L2 FW doc and > how to progress related solution drafts. So, I'm referring Eric's model > describe in the FW doc. The following model completely differ from Eric's, > so the following is disagreement to the FW doc, isn't it? My abrupt answer: The FW doc is misleading, because it disagrees with the way bridges are both defined and built. Another way to put it: My diagram is the only way that a standard bridge CAN interface to the full meshes within the layering model shared by IEEE 802 and IETF. I should be more careful in my claims: It's the only way that has been presented, to date, to IEEE 802.1, and has received a lot of support. The problem with the model in the L2 FW doc (rev 3) is that it clings to the idea, discarded by IEEE 802 in 1996, that separate VLANs are handled by separate, independent, virtual bridges. IEEE 802.1Q chose a model in which one bridge handles all of the VLANs using individual physical ports, through which each of the VLANs pass. There is little point in arguing over which model is better. I favored the IETF model when 802.1Q was making its decision, but I lost. The models, diagrams, and protocols employed by 802.1Q, and hence the actual bridges built today, conform to the IEEE model. There is every reason to argue over which model is more relevant; the one to which bridges are actually built should be of considerably more interest than it seems to be on this mailing list. The diagram, below, brings the IEEE model, in which all VLANs pass through a single port, in line with VPLS full meshes, which exist one per (Provider VLAN | Customer Service Instance | Forwarding Function). Rather than rail against the L2 FW doc rev 3, let me suggest this: Provider Bridges exist, are making money for their (several) builders, and hopefully, are making money for their purchasers. IEEE 802.1AD will standardize them. IEEE 802.1AD will be based on the 802.1Q model. Deployed pseudowire full meshes will, of market-driven necessity, be compatible with this 802.1AD provider bridge model. The only questions are whether or not the 802.1AD-compatible implementations will conform to the IETF documentation, and if not, whether their will exist naive implementations of the incorrect IETF documents that confuse the market. (Incorrect by definition, if they disagree with bridge implementations.) > > |===========================================--------+ > > | | | forwarding | | > > | | | function +--- | > > E i --+ | untagged + VPLS 100 | | > > t n | Provider | | for BPDUs +--- | P r > > h t | Bridge | |------------| | s o > > e e | | | +--- | e u > > r r --+ | | forwarding | | u t > > n f | Each "+" in | VLAN 26 + function +--- | d i > > e a | the border of | | VPLS 200 | | o n > > t c | this block | mux- | +--- | w g > > e --+ represents one + demux |------------| | i > > s | bridge port | function | +--- | r f > > | | | | | e u > > | | | +--- | s n > > --+ | | forwarding | | c > > | | VLAN 589 + function +--- | i t > > | | | VPLS 300 | | n i > > | | | +--- | o > > --+ | | | | n > > |===========================================--------+ > > A B C > > > > The single interface above the "A" label at the bottom is the Provider > > Bridge's bridge port that opens to the L3 world. The three interfaces > > above the "B" label are the interfaces between the forwarding functions > > and the mux-demux unit that translates between the Provider Bridge's > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > the pseudowires. The physical ports on the routed side are of no > > interest to the bridge. :) > > > > In my last note, I was pointing out that the each forwarding function > > MUST control its "B" interface so that it provides 1) full service, or > > 2) no service. (Let's be honest -- my last note was a little confused > > between the "A" interface and the "B" interfaces.) > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > needs to examine this situation, and figure out how to deal with it. > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > is absolutely required to prevent a meltdown of the Provider's network. > > A failure of one of the other VPLSs affects only that customer's traffic. > > (1) It seems to me, in the above model, PEs are interconnected with per > customer meshes, where the PEs attached to the customer are interconnected > with a full mesh. Therefore, in the worst case, there 2000 full meshes > between PEs, if number of customers are 2000. Originally, full mesh has the > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > Furthermore, if fast protection is supported to avoid the protection > racing problem and partial mesh, there are double meshes between the PEs. > So, I don't feel any reality from the above model. For N PEs, the number of LSPs is exactly N, because each LSP is a multipiont-to-point tree terminating at the destination PE. The number of "branches" on all LSP trees is far less than O(N^2), because there is (probably) no single VPLS that spans all of the PEs. The VPLS that touches the largest number of PEs determines the largest n^2 full mesh of LSP "branches". In a typical network with a very large number of PEs, the actual number of LSP "branches" will be far less than N^2. Within that partial mesh of LSPs, for each VPLS, there is a full mesh of pseudowires. The cost of setting up a pseudowire is trivial, compared to the cost of an LSP, because it does not involve the intervening routers. The number of pseudowires required is O(m^2), where m is not the total number of PEs, but some smaller number, related to the typical number of PEs attached to each VPLS. > (2) Frankly, I don't well understand the above model, because it > illustrates some implementation, but is not a protocol architecture. I disagree completely that it is not a protocol architecture. I would not implement the above diagram in one of my switches, because it would be horribly inefficient, there. This is precisely a protocol architecture, because it illustrates exactly where the existing standardized interfaces and standardized functions go, and exactly where new protocol and/or functional elements are required. Specifically, the "mux/demux function", which is trivial, and the "Forwarding Function", which L2VPN is defining. > In the Bridge architecture defined in a series of the IEEE standards, > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > layer entity. Could you clarify where these entities are located in > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? > What is VLAN mux-demux function? According to the standards, the VLAN ID > value is effective only inside the MAC relay entity, so it does not > identify MSAP. I'm not sure whether this conforms with the standards or not, > but I think to realize this architecture big changes are needed to the > current standards. All of the standard IEEE bridge functions are contained in the "Provider Bridge" block. I did not break it out into its components, because there is no need to do so; their existing functions are unchanged. The VLAN mux-demux function merely translates between the Provider's VLAN tags and the Forwarding Function world. The IEEE P802.1 Working Group writes the bridging standards. All of the members of IEEE 802.1, with whom I have discussed this diagram, and that is most of them, believe the above diagram to be conformant to the IEEE 802 standards. It's a shame I cannot explain it better, and I invite those members of 802.1 who read this mailing list to respond, and either argue with me, or hopefully, explain it better. :) -- Norm ------=_NextPart_000_000C_01C31577.03526990 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhMWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBQAIAA8AIAAAAAQAGgEB A5AGAJAiAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAQ29tbWVudHMgb24gdGhlIEwyIFZQTiBmcmFtZXdvcmsgYW5kIHNvbHV0 aW9ucyBkb2N1bWVudHMAAAAAAgFxAAEAAAAWAAAAAcMVsa50P41NVCAVT+eZnm+qtxnjTQAAAgEd DAEAAAAaAAAAU01UUDpNSUNLX1NFQU1BTkBJRUVFLk9SRwAAAAsAAQ4AAAAAQAAGDgAw66OxFcMB AgEKDgEAAAAYAAAAAAAAAENBC8WgAtZAi7LmMY2gFNLCgAAAAwAUDgEAAAALAB8OAQAAAAIBCRAB AAAAMx4AAC8eAACaRAAATFpGdRlcfWMDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMC gA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1 ESIMYGMAUDMLCQFkMzYWUAumIEjjB3AAcWh1LAqiCoQKgABJZiB0aGUgVsRQTAXwZHJhAYAEIGUT 4HYekG5vBUAT0W6qZwmAIACQZwMAZg3gYQBwdGx5IAuAHmJpjwXAC4AOsAIwIChJHvDdAiAnBUAe cAuAax5iIUB9H3IpHmIYICFQBCAfwmHnHvAEAAWgbm4FkAVAJBJ4LiBUJBYk0gEgJCFuKmMekGIU IHcJ4SBydnUlQAuAZyBwCrAoBHQrCdEeYG8f8HUFQFBX/SZxbiBgGCEa0CkhIaMpQLpwF6FnIUAp QR5wYQVAzm8eUCTQKGwodyMAE9CfJFItUCvhHncCEGxrLcG/JCIFoRggJXAhMRggaiVhXyghI+Ap 8iUhH5B5KC8gsEJQRFUmcQUAbwQRcR5yZW11C2AOsCBgTLRBTi6xcgeAIGBiIUBVKbJzK6ViBRBk IEAg/ysgACAmcQJAANAjASjRK6XnM5U0ExQQcnYN4C9RA5GnH3MecgUQZ2gFQHMBkPUOsCwhUWMK QCTwKMIegfonNCEnLAAFwB/CIWQy0fcwYDlSKxUvKwUIkAQgNGHLHqA0IXMl4EFnC3EhUP88ISRx BZAnMAQQCsArcyBA+y4UC2B5BnExcijwC3A54f86cAIQKXAAkDFxAiAt0S1y3wPwJDEk0DKCQKBv B5EikP53A6AnYDRhOWRBNyRhQcZ/KiEHQCExIpAHkCKyHoBsVHAuHYpNDeBrHYot/UniTznBC4AH QAXQQBIgQOtJ4x2ERgNhOhznBgAT4J0tkFsAwAMQKUA6aB1ASUzwQHcfgXNtP3BoLyVQJ4AFsC7w LgWgbV0/HYQGYAIwTCAmAAhwc2SLQUA6cE1BQCAwODpwiQHQMDNRMDo0Nymgak0dhFRNgCBOUEkA X7UUEGEDgUAIkAngLgWwXGc7B7A0cQORRguAbn1T4E0n8CNwMxAjAAYAdbB6dWtpU+BSYG4hQF5K AREJ0RkwHZNMB5FC90fgAnApoGEzsBIhIDAikbdT4SGwAyBKCsA4oHMdhIRDY0wgcHB2cFNA3x/A ACBH4E6aU+BDHoAgMJQtWQuALlcgZUAHQM8g8FqBTxJPZXViMDJMIOxSRUwgCFBtB4ACMAQg+0Lx HnJMFEAesDRBHxAHgP9OwinjNUAKQDBgAiBEcilw916DHYod5SAn8ASBOiEqAb8i8SZxWfADYDbB JeBJNmK9IHFtC1A8kWQmHYRBKgH9BpAgVRBMsE4AIjEpQSfhoQXQLVNUUCJQMSFR/2NiJzAwoTL0 KbEdhGbiAMC/IUBnJkKQKoJj6h2KSESgOmUfkHI6cB5+IWFJRfRURjOAeAtQDeA/cCEw/x2EAZAu 4gGgCGAFQB/CH3F3NvVnoh5yUGfzaRhIFUSydQdALWgDcDFhLw7B3wSRSpEXsCsQIVJQA2A4oH0E gSc/sk6zHYQkYSARZP9lUCBgA/AecHCCQpRyI0gb/yYEFBAzkDMxKVAnYDUxB4D/JOohYWMYMWId hCdmHnFrIudOwECgA2B1cDMyK+ElUH8JgHo2TsIJgB2EcIFIGy//IwAdFEkvSj9LTkjiBlFTEu9N F1KvU7FPW1cJgCVQUGn6N1ElNlGgFEBR6kxLU+D6J1QJJ4vhVN6MwlX6jMB/HYQ7cFc1jMJXyozC WKkn/1lfWm9bf1yPXZ9er1+/YM//Yd9shh0PHhIDoGhAI+AicP8i9GbiH3Nm4QXAQTck0G8w9wJA ZVFOUHggUX5wJeBL4v9tcysgIfEsAjigB9EsESUh/yjwBvAw8iVSPOA/cCtxoVLzFBA60G8tQ4If VSlBB5DvAZFvMJxgJMFmM7ADIAeB/y2QK8M/o20xNiAEkCcwPOH/NLNBM1EwNiADYClAF5Emcf8E ICdgMWJlUDMjA5FPIWVB/w6wJeBoAiRhJ+Yy6Th2K8P/J+GXhHUBLBEecgeAIAIEAP96IivSAMB/ 8KzLNCJvMH/w/2SRZsWl0ilBZDF1kiBwllDfFBE0Eno2JSEg0GcIcCBR/x5xA6CiY1BBnsM46LM0 BCD/RvAtgSwRLVQT4D5BpkKjG9M/QxQQbGYl4EpCkH7i/6dyKPArc2QwqyFjkilQqIbPK8N+Ah/A A6BlcXOhtre/CsCwRZihNBJIG51iMp28f74ypjAAICQRIeIror6VcP8/cL88P4Mo8KOBg4FAhcHz 70PzBPAHQEbwYgMQuUMEEP8KUCZxF7A7BQqwHnBm07Mw/mcgQDogPvFSkBrQLZAEYP9DogJAHxA8 xAdAdHM808QC/ylQTTECMD8yZPIgMGVRpjj/PmKin6OiLVS1A2QwVOGvpvemkqexHqQot0MetEdm pQX/KUDI8icwACA/MqaDH8ABAP5zMKS1A2sRfpXPUjb1AQD/qxIepChgBZAgwqQVpJTCFZ8n8Gci IFHTiCXgT24hMf8CICRBaIWulisHAQB0cXQB/zFiqQbUNtVn3NhFJCfBvVH/Q5EgYD5iRwEeoz7h JgHEIv+FUSQWsoIpgbK1p5F1cgCQ/wIgRePLwS4UOcRlUB+QAyB/PEan0CMADrAlcLSxIlBpPi4l 0SSTLhTXeOTkLGL/KYEjADngEoF+cDU3P3E48v8fADzj53/lKM1SDsKupTyx/3OhITEfgE1BpaE5 oQeQCGH9QAEpSB+CH4MvS09MX01vB05/h++I/zEwOjI5/xDAUf9TD1QfVS9WP1dPWF//ki+TP5RP lV+Wb5d/mI+Zn/+bDyYAJGEk8BhxqlA+MqECvUbwcm8wurIjAjFiKCvh/8XxulF0ASPRb6Ur0nIk 9hD/M7AgYB/CKGIy1td5eM/lov950m0x8eFlIiDhCFRndKwT/2gBjyRpGK+2+EB/ArPmN+D36pAg 0BlgL3/ELACAnZ2hsiKmMnktzMKAACLJc/5p6LHa9ymyMRDt8gFgC9H9gBUgHGB3ksuz7Kkk0G3D L2h2JeKm8zpxZhwHUEX/aFAp8iAgqOHlwDBgb1DHof+00XuxHfv44KpzHAfBon+h/6mhcMDrGilB ICD40C1UewD/DwMcByDpIa/44ObQbPd3kv9jsxwHeyBtkL7QOnC3QyAg/w61tnMkjG0ib5UcYXDQ wbL/bcPF0Meg7oIrgUOQpLHW8X8806JhubFtsxwH2oe+0G23tCBjUMCgcJyqwEFBxqH3dALVFGhQ Tatz2pa1gG0x/7chxTBDkuKWdeAcB/XlOnD1phBi0RBr/8A+cW8wwMHrC1N1YkLqkGTIYCLBJUH9 OZcyLZjtMCHtbWBqUsXQAWsSODAyLjFhZP914XoQK9AhY7Ei26DBkCoY/9Xx4FZoZ2TQ5pTgUhsC C1P/DhQrkMExMQmoQMcQ8FC00f9jYSeSL58wpGhnHAcyKO9Q/CBE0bVjw0PjLhpApzb578mhjrDX QRTYP5yqH/J0gNu4IH6BbRtxM8JwCFKror53cqCfktRU4cR7sWbtkf8fmGfz2ofgEtEIHkhs92ax /9UiMQjEEsbAbWArh2eixSz/xhzva4EvYf7xP/JPhP+GD/+HH/cf+C6KIflaix+ML40//45Pj1+Q b5F/AT8CTwNfBG//BX8GjwefCK9zH7HB7VIZE/+mc7TR13oMsN11yYHREbTR9d+ScG+yL7hg2tBy FOc0/+uQNfF/MBjgsramELEiXeD9rTQoRGDXQKAQo8SdYMpT/91AbrGohHq2qaHWIBcQuODbIZM9 k0Rxgz2TUf9w7mCxPVI2LjV7Ib7CbnKg/zJRFrI9UkOyLiFyaBjgtQN6UjTBLzSzpJDgYXFDar+6 Qn3yENy0A8kz1udQPZX/0ZPW1aPE25AScU6DHaPMBX/aioNlHLU5guLTABA3xWh/KRC8dRKA5RFv 8adzveBk/nXXxauxtViMstjQ+ECxIn9LVo1Pdfjmo+rt3NfHEG/7bECmAGbcMbACNAKzML5F/7RW iNej6LIhpLK1gETRe3P/srWstHT0uLU+la0VKXDVI38PIqnUadDBozSyfbLMAGf5y8Bnb1vh4CHt Up1C5mH/omGG91axh9rMAD5DiPWzo7uNw70RLbEivtAKsGEpcP8nBD5RC8DOguGy7VKiG7Zk/8qF qQjVI74ztAPU0XGwqaHnJwKulnHWIC1hgCHyUiP+ePqAEuANgO9vWn9bj/KfH/Ov9L/1z2BPYV82 OjD/IsD5Wvt//Ixdmf1NPrD+pv9nlP8/AE9rH2wvbT9uT29fX3BvcX9yj6rnZIIsqrpZ/8gB0ibs 4MNwPWGAgeAShFD/EtDjuw217kF5YsJjDyLgEH/gYNfBNBPfEmdAPeCqq0n/K6UbwBeQHPIW1BMU 5tCqut5B5mFlsK9AEsJ5NAeHBv/h8R0jEtGlsTQRZsBnlBPG99pC4CGGEyiLljbwGOBAqPWPAVKD UC80wmeUTqEZGvcQGkx7WY1XsKaMFsPbrH+/rY+ukmSJr6eWQRPgQIgAtSqwb7GvVFghsxg2+IXw ODoxNBrwYtm2H7cv/7g//v/EpbrPu9+8773/vw/9wBBlwE/BX8Jvw3+q9+NGr8VL4z5O8ieQOmeU Pg2lf/VQ9VDMQGlSSJM5AVPAJ/sR0WdAZjXA28A0Ei0goFP/gHKGEIvg7ABRABGhmDb4pP/1eFIi j6NI8DnTVoIScb/g/07h2eKZshlkH0HS0vzn6RDvLlX1eFMGH1Fz9O/5Mgqwfyqwf9CJgE6kyDGV 5R1WV35HDOANEldBneF0lO6BRv5X8GLvgvT2jLMkYUvwCtN390E+ZKjnZEth7eCSwFOybylwSSc5 YPdYRdvA/mM+Afn7nUFL4BowJ6N20v8FNB7CUgLKVvizNYGqUumx/2GwAcBnIC5ROTMKBMVF9VD/ qOB0pMpHVTEBwdyAZ0Htsr/35gU0ADJIctngTHtNG3Gt+4B1TnDvgXNTwHKusO/5IwU1VTGw4HOJ wD3gNAH/KXCF4D002eARl+h1KZUj8n9hsPuEeMFP0YHEfeXvkmL3d8Cv8KqrQSZBLkIZsgaS/6kQ MHEVsRSxorEG8F4AVSP9iGJuo6IdcqbDRFLvoKcA+wXF+4VDpMH781BhLPN0tv91RPx0AqV8ww1n Z5SwQWdA8xuhYbBJRSaAPYLvgyZw/FRG+QHMQFngK8OF5i7Qf/dRaOHIMU3xgSHPYABmSf50PgEf T6VBSOFnUMhAphD/mBCyYbLAm2HGsLMQRJAtA/8mdj3AD9XvkivimHFp0MZw/xthlFGoU1gQ6SDp kYTsl0L/S/BJABIQ/IR20g2kAqUFCOIoZ0B2IDPUQaaV2eD/Z5SBIM+xVUH4BIvRotEBwscg0SYd yDExOTnhoc/z75eAqsEHgWeUVqFzpwLQAP/voInAJiM5lgAx76A5oHlx77JhADB64KMgddwRGfUn gv8mgWeUfzV3UPJwejIzJ6PQ/4bAUpDS0vuFOxR4wQRoOnM/Z5R/0Mf0AcCZET1ycGj+eYmAV0Hp EOmR/YHLEcxw3mdSkEB0UmNCTwqqwNxg3zEOT9RXoZigl1FvVpHII/9f8HfA0aKRckB0MyUsAncg 73rAJ4JnlFBgdoYhdrQnQv8NlaPRfmV/gLCQClGVNNng/32y32GpMRdhHeHMQJRge0D/qqX5Mviz /YEelf2B75KmGP3RMm984CYjfzRTNILRIoL/yKb8QT15G7TGkbMTliK1Uf/35iZz+LlJA2eUNLB6 wGGw/8sxqODuIcawSmKIcUr/ClLr9yOJwHaP4HTmgCrExoL/GMVAgxn6VqSYsVeUJ9iPA//UcIvS FOB1IoYhZ5T785gQ/8hytYEYAZeAEhA2Y2IS7iL/FpKv0c+yzMBRZzF4HpUXYv/KYRdh96KZVFlY PEJAZQRS/zp0R8LIxUWFiWcwwmpTNiG/GZHZ4v7SIxoAMEX1eGbBn9LCR2X+odOXQqMgfLoQv4Rh 7ZB8+XwAihVyIEap8LewkCDgz7JGeFWqnFLIYP8dImRz7wDn8dyAr9DUcQS93zSjADAOQccyMJBn GjH2c/sAZouXQhoFcANTMUkBlSX/hhDyQanTleGeoIBBWwLroP/UQBvCi+EPxi7ziJGZs3v/+30K HdByP2BPYH6xPiVO1JxBRBjGI0Eghml6lcPebYKdl9EjQWIRYoJB77Dv7hU+9fi02wREOaBUZJMp fyMs/hD9kZcQr8DvYOnwLf8IYKXRyECaQQcRGACzMWIQ/zW1DhGlsTJBMobQwYW2mOXv/rD7hfi6 H4Nx4NHwEy6Vf0kBTpGck6nxm9KHR4NgLf+NWc9iEhOWo4qUWFbIxVj2/04B8HbNs1M0zXCbwm+C koT/fWSD43AE3ACl0WOFlN2odf/b8Pl2l1umlVhiF8Iy44tT/aqlKHNQ+XYmQRsDGABQk3+Y0QLR DpIRxG4k+4aU3C7OKaq69dKl6nw9ps+n3/eoZttj22ErpV+mZKXrqw/vciD64XQ2q2Z8qg+rH6+f 76/zf9B01CeQK9thrm8J8P8nkOOwJ5Cp0bBPr/LjQMkg73mB77C0wW6DMeHgr/iurD8gQMngr8px R7Ef+uJCULxEVSwAssi5wSeQcq6739oAuNKv6XsksP98qXbbYv+3hyeQvAFfJa8Vv1G/VLAf/7Ev pei8Ob9R2RWvFbpRulL/tK/Ej61vw2TPQALArruyoYuiIMVIRUZiIisiOKLzw3Nx0zI2tqKyP8OC 77D//6DCPvtgxUcC0hqwN6GSwf/NUbFcboPh0bdpwgG48bgefwWAxUhl4zJA8IDkgMNlbTx1eLMC xY/FRQZwIGf/rr6/UsiE5bAsde3yv1HIof9xkNlRwE/JeNFcpeG8AcNnf/uFMMLKZM/m2c/FRbpR Zv+uv8U/5l/mvcFJxw/pD+sv/+zPvBu8AdZspeXIj+zfyq8967dj75/tj/WIcdM1OP45z5+8ZrRh zEz1f/pf1Fz+M9VNsqHgX/v//5/tr7xI/6XhwizwbwCvBh/Va8zyA9+/pm8K/6iPqZ8OLw8tQQl4 +kIJekMNlw2YFeJs5SIY52LwXGEi0yJBzoAkkGiR/y/wd4QasXJxHwa55g2YvwQ/KpHiKiATf6Gc YSK1TDP/biCS4H6QkHVsQaLxIheRtfsJQhRJQhUHSQGcxBvWTBL+dywyIuN0GPgmHEovATLj39lh 3lS2IGTBnpN0UvCcYD8psDwgH0x6nSqQDZhQLT1x03N1YBQSIhVug1ZDzkmGECdTkHUiQ86ARQP3 HidjQFDwaJxyDZg2solI/z4SMdNEi4cGbGE8IE2AYqL/YGNiQZMQDZhj6Fj0j7SQcf46pOUSK3NQ kBBU0B3QmrL/U7A8MVEgT1JJ00qjUPEjdB9n0UZTIC+HEA2YTVVT/lRYUiPAU/BP8x2SE6hbkO81 pGTBjyVMADF+QInzglH3cwKK8b0ZMn5AkxA8BpBx/ChMkoAYUkFh3dFkQbLx3zOqT0NswEllnuVk DZgfar8U4hOpIhU5e6THEitTnQH/KBWKRZ6gFHHd0oIhUvD4UH9y4JqhcxA1pC1Ha1OJgG7+Jz9S DZjd0nHTLZBkoGIR/6KRYnGMIS7Rb4NtIXOQU7D/dkKOcRqRgKOy8YVoDZh84P+2gGUzmoBTAG3y jlOMcVbQ/5g4oXBcIC9yNYF/kNtAW9G/cZBW4W4zZMB1RRIrRs6g/2DyeNdAIxlEkPJLo26SsvF/ XpZBgrt5SuqOcWLwOlBs/y7BYRFd8JEwibEn0dYw3UH/i+GhAGzAeTBhcImBZKCclf+55hhRfOAf gE6hVLgQIR8A/2FgUwPNUN3SnJVOBLbiKhH8ZmadYd2yV7GelHJVGFFfI8FiMHMQVLcNlig7kUn/ oQCfMJvQUMN5MG2TnMIURPlqBVBFKhQes0zXbiRw8f8NlmNGbxkwwRaEaAJA8M4h/1wUnMJqZ2g/ QbejI9Jgiff/kHCQod0gfSFmiBqRd3EtkP+fMHjQkpIUINUx1VCJ+Q2W90JmZ/Gh826X0IzQ06Nj RtcqFHLikHBPSOBnVgaJ94dHwRZzDZZPKE5ePWH7jyGUgW2K8DpTLSEuoDTgv4bSTMCFAT7hNLF5 kCOLELJDdhcqIHm6VLdGggD/kpIqsHETzVAfADDxjyEu0PP4VFGydXAp0lwUR+A08P8n1H/4DZZI kfNyegVSg5HRv5wwLaGKQnJmkiKJgHWUgs+KRSR7aABUt1NvNGJKhPtiQB4CbluSViCMgTaALqDv FkBm7aAFDZRGkuHPUHTj95zCdWhHMFAkUFrRURH4UP1XsU48gB3wLZCfIjZDjeFPWsMNlN5wXTBp cONxdPotU8AtNOMjsaLxHtFRQf+cIfOBFYU7UTUhnCNn4SzVd3VkDZQvoSLiIFKQbJFz/86A0DFW IY/TkgKOEx8ATkD9hBBznnMzgHmUjvhyhFrQ/6AVegId4FewPXQTRFgjnpP/J1EZwZaiXaaHwSzk m8cNlN1TwHWWEh5jHdByv0A/8v91d2fy04CSVJ9eecBzKJU3/4/ilcgs0TNx0mCKEJEQLZL3XsVv dlygcjOyn+F1WA2U/4y3SKFSEKWxjVqVuiyAO+HvTHGXvHmxi4tXVFFms0ly/4SpjaZ34buRj5NY InJmWtL/os/NUCwvQTE/QS+hmWBA8P/zcoDg0lGyOBZTSOA8QFYg9iwNlEFAbZBxbLmzZUxB/43h jvgjQSxgR6FW8R6hgbD+bBR0DZRoc1yh83Iuo3Hgv5RrL5KyOVuoWtF5kG2Ywv8NlGt0FkO5Yh5y U8BscKlKnXTjYjWBOlBWwXNtViH/TjF1ZLX13SAkEmzHpVegW19sWq+3i4tlUT1hRiPRa/93woi2 JKA74fgw04E/QEQG/2cruGgNlqsBbWEj0CQywgP+abaAhBHdgVIlwcK/xbSB/4AB2KA5AQ2wNmAj QGkBYEHni4uIsVrQYWcbcrZiVoH/W3I6hs8P0Byk4RqBc0BBtf+5Y83Wynk28NIBUTBmomC1fTOh c1RBlhK4S9XJPtNy30jgmtEeoXDgZDFpXLFyZf8s01rRWtFccYOAmWBXsdQI/w2U0Cq4S8y6jmZr eFEQSPLv84ANlMojNtJ6vhIeyFKS8+PLINcgZ4iBUpKOZb7q70uwU6DUKIRgL1mB+CYtod+JUM4D KhS9tj4xUxmgg4DfZDFWI56lFLIi4S8ixPgm/iJNYzZhtVlD+IxRNsZ+oOfuVr7m7wJMMlgg95Ba 0f9eYFLQuyLHTTNxHnIX9NAb//Mk5GNvwTwR3HArAh5jT0P/48ZrQA2Wb9D1FUFBUeA/QPH3c01B Q1EANREhEGsy/2/Q+sLDooog+wN30VKSb9D+SFLgTiENlvwhTjH8ZD4w8kPV0iB5KsBBMJ/BdTDv 4imPYvsVL1Ns1GDD01FQRw2WyohS1D8gV4WHTQxTQY4B9llJU08vk09A+uAxNU+RLTEWUv0BtT/0 J2EEOwUlprC0S+OeYTbB9PZrVh42RS0FoP9h8QbeA/A6oiRQS+MiiO42+QPQQWNBQDbkGfX4WCfk 1ycSKKA8xnZWIHWwo9wh/4AyR/Pb0y8THnL7zzpCuOk/zDdeYDUR//EEkj4wSSf/inC5YoDQL3Fr cWFzUZNBQv88oGYRVEMP+zyRVuL458HC/zSArXKmMFPBicPkUFGE9Yv+YlLgSFLjQAFFUIJst2no 79uQXLL4V4uLQZzY48ZPNP8xlOZJL2I4smAQ9pVEQ14W/zzECkRDQIZA1GBfINWCNvD/ymC5YjGQ j5CmMNphNXJocf8VchkytoBLoerhmP26VblC51BzU7M9oW87ocJb8OLX/yS97kEe4+vSndMRMZBm Dg7vauHDoWLRleFzw8KG3V4o+0vjbHBn5SPs6PCflBFxwe/awIuLndJPQ1BPkwPgTqX2R7txtGB3 SODhgqHSJFP/g5IhaD5AIsiQZWYAqZH3c/9PSE1hVFJNgIph1aBH00yi/5lQe1JRk9f17+YNM5Bl s2X/odF6YamQifBckddPinGBgP9McRlVUpCR4bcET0bjbJ2S/2WwXpH3AWMAVsHVoEwx08L/URDN 4CXh2lKG8ZJRUnTVoP+5odBh7OZ7QWrhPec5hD+B/4myQMXCYGAgg5KJ8HHxHMP7nGCUEGTnFVRR acaf0RJB/1RDZnJZgVOAabBzMnfRSd/ZPJE6KYuaWHFOGZGLmgVfRH1WkAAeAEIQAQAAAEUAAAA8 MDQ5QUFGRUQ5MTg1MTI0NEI5RkY3NEQwRDlEMEVCNzIwMjE1MjYwQ0BXSElTVExFUi5XYXZlU21p dGhOZXQuY29tPgAAAAADAAlZAQAAAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAC gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAiACCAGAAAAAADAAAAAAAAARgAAAAABhQAA AAAAAAMAGYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgAagAggBgAAAAAAwAAAAAAAAEYA AAAAVIUAAAEAAAAEAAAAOS4wAAsAG4AIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwAfgAgg BgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADACCACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAA AAMAIoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAAQ0ELxaAC1kCLsuYx jaAU0gIB+g8BAAAAEAAAAENBC8WgAtZAi7LmMY2gFNICAfsPAQAAAJIAAAAAAAAAOKG7EAXlEBqh uwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQg U2V0dGluZ3NcbWlja1xMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxP dXRsb29rXG1haWxib3gucHN0AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAw NDM0MTBCQzVBMDAyRDY0MDhCQjJFNjMxOERBMDE0RDIwNDIyQzcwMAAAAAADAAYQgzv+oQMABxBH LgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEhJTUFOU0hVLElGVEhFVlBMU0RSQUZUU0hB VkVOT1RDSEFOR0VEU0lHTklGSUNBTlRMWUlOVEhFSVJJTlRFTlQoSURPTlRUSElOS1RIRVlIQVZF KVRIRVJFSVNOT1RBRElTQ08AAAAAyLU= ------=_NextPart_000_000C_01C31577.03526990-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 18:41:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15441 for ; Thu, 8 May 2003 18:41:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48MhWW23555 for ; Thu, 8 May 2003 18:43:32 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48MhSX01391 for ; Thu, 8 May 2003 18:43:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20030508152250.01bf1008@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 May 2003 15:40:19 -0700 To: erosen@cisco.com, Norman Finn From: Ali Sajassi Subject: Re: Comments on the L2 VPN framework and solutions documents Cc: Muneyoshi Suzuki , Mick Seaman , Tony Jeffree , Les Bell , Paul Congdon , Neil Jarvis , ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com In-Reply-To: <200305071525.h47FPq7H017640@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: At 11:25 AM 5/7/2003 -0400, Eric Rosen wrote: >Norm> The problem with the model in the L2 FW doc (rev 3) is that it clings >Norm> to the idea, discarded by IEEE 802 in 1996, that separate VLANs are >Norm> handled by separate, independent, virtual bridges. IEEE 802.1Q chose >Norm> a model in which one bridge handles all of the VLANs using individual >Norm> physical ports, through which each of the VLANs pass. > >Well, the model in the FW doc was developed as the result of a very long >and iterative conversation in which I was desperately trying to figure out >what the IEEE guys were talking about. So if it doesn't match what IEEE >might expect, the difference might be substantive, or it might be due to a >misunderstanding; the first thing to do is to try to figure out which is the >case. With a slight modification of figure 3 in L2 FW, we can make it consistent with IEEE spec. Basically, we need to show multiple instances of VPLS forwarder along with its PWs - one such set for each VPLS instance and one such set corresponding to an Emulated VLAN wrt PE bridge module. All these emulated VLANs feed into a single bridge module and thus the text should be modified accordingly. If more details are needed, then one can expand the figure 3 to the one that Norm included in his earlier email. -Ali >Frankly, when I look at the diagram in the FW doc and I look at Norm's doc, >I don't see what the substantive difference is. Maybe the problem is that I >don't understand the difference between the two models Norm describes >above. > >Can anyone explain, in practical terms, what the difference is? Will >bridges built to one model do anything differently than bridges built to >another? Or more to the point, is there some issue which prevents bridges >built to the IEEE model from correctly implementing the VPLS model which is >in the framework document? From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 18:52:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15799 for ; Thu, 8 May 2003 18:52:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48Mt3W27796 for ; Thu, 8 May 2003 18:55:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48MsxR06664 for ; Thu, 8 May 2003 18:54:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20030508151731.01d596f0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 May 2003 15:51:46 -0700 To: erosen@cisco.com, mick_seaman@ieee.org From: Ali Sajassi Subject: Re: Comments on the L2 VPN framework and solutions documents Cc: "'Pedro Roque Marques'" , "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com In-Reply-To: <200305081915.h48JFoAD004347@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 03:15 PM 5/8/2003 -0400, Eric Rosen wrote: >I think I see what you're saying -- the FW model provides one emulated LAN >per VPLS instance, and only bridges which support that VPLS instances need >attach to that emulated LAN. In the IEEE model, all the provider bridges >attach to a single emulated LAN, and the VPLS instances would be treated as >VLANs of that emulated LAN. That's why we sometimes refer to it during our DT discussion as "emulated VLAN" since with respect to the bridge module, the full-mesh of PWs along with its VPLS forwarder looks like a VLAN to the bridge module. >Since a VPLS would have sites all around the world presumably, attaching to >multiple provider networks, why doesn't this imply that every provider >bridge in the world needs to be on the same emulated LAN? You're correct >that that does not seem scalable to me. I think "emulated LAN" is just a matter of perspective. If we look at the set of VPLS forwarder along with its associated PWs for a given VPLS instance, then that set by itself can be called an "emulated LAN". However, if you look at this set with respect to the bridge module, it is just an "emulated VLAN". >It seems to me that you've pointed to some issues which need to be worked, >but if there's a fatal flaw, I don't see what it is. But perhaps there are >still some layer 2 issues that I just don't appreciate. I think as long as we update the figure 3 and its corresponding text to show that an emulated LAN (emulated VLAN) corresponds to a single VPLS instance and there can be many of them for the single bridge module of the PE, then we should hopefully be all set. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 8 19:05:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16054 for ; Thu, 8 May 2003 19:05:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h48N8EW22858 for ; Thu, 8 May 2003 19:08:14 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h48N89905577 for ; Thu, 8 May 2003 19:08:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20030508155215.01dc0ed8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 May 2003 16:02:38 -0700 To: "Himanshu Shah" , , "Norman Finn" , "Muneyoshi Suzuki" , "Tony Jeffree" , "Les Bell" , "Paul Congdon" , "Neil Jarvis" From: Ali Sajassi Subject: RE: Comments on the L2 VPN framework and solutions documents Cc: , In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB720215260C@WHISTLER.WaveSmit hNet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: At 05:46 PM 5/8/2003 -0400, Himanshu Shah wrote: >I understand this approach. Its a simple approach. >And if you want to run M-STP (1 instance) across PWs >you may want to use this approach. > >However, the VPLS drafts in IETF explicitly >talks about not having to run the P-STP across PWs. >Dual-homing/external loop in Provider's network >is handled without using P-STP. > >There seems to be some disconnect in understanding >between these two groups that needs to be worked >out. I don't think there is a disconnect. When you talk about P-STP, you need to consider both intra-island and inter-island. P-STP is NOT used for inter-island - for that we use full-mesh with split horizon. However, for intra-island where you can have an arbitrary topology of bridges within an access domain, then P-STP is the only viable solution (refer to section 11.2 of draft-lasserre-vkompella). Also keep in mind that P-STP is suggested for Ethernet access domain and not MPLS access domain. -Ali >/himanshu > >-----Original Message----- >From: Mick Seaman [mailto:mick_seaman@ieee.org] >Sent: Wednesday, May 07, 2003 6:42 PM >To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; >'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > >Himanshu, > >In (1) I think you have your layering a little mixed up. From the point of >view of control connectivity the pseudo-wires have to establish a full >mesh that is never perceived by layer 2 protocols as being less than >complete. STP is running across the service that runs on top of the >mechanisms that make the service LAN like. If you wish to provide subset >LANs to be configured then of course you can have subsets each of which >has full connectivity in itself. Just never try to pretend to layer 2 that >two non equal subsets are the same LAN. > >In (2) I think you are further into the same pit. > >It is trivial to get into BPDU scaleability issues along the path you >suggest. A much more attractive alternative is to maintain a single full >mesh for control connectivity which then prunes that mesh per VPLS (each >VPLS doesn't have to touch certain mesh nodes) and then uses that pruning >to delete VPLS specific pseudowires to the unwanted mesh nodes. Only one >instance of the topology determining protocol and the pruning protocol are >then required for all VPLSs. The trick here is to put provider >provisioning in at the right level in the architecture (i.e. not at the >pseudowire level,but higher up so that it can drive the pseudowire level >in the context of the actually available resources). > >Mick > >-----Original Message----- >From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] >Sent: Wednesday, May 07, 2003 10:29 AM >To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; >Les Bell; Paul Congdon; Neil Jarvis >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > >This digresses from earlier thinking (at least mine) >that P-STP would not span across pseudowires. > >There are several implications to running STP >across PWs that may need to be clarified/worked out. > >1) "fully-meshed" attribute of the PWs only applied > within a context of a VPLS instance. That is, if > PE1 and PE2 participated in VPLS instance 1 than > there was no pseudowire to PE3 which did not > participate in VPLS instance 1. However, with this > scheme, each PE would have pseudowire to every > other VPLS capable PE irrespective of its VPLS > instance membership > >2) Assuming that 1 MSTP instance covers entire provider's > network, a backdoor link from ProvBridge1 to ProvBridge2 > of VPLS instance 1, may cause 802.1ad's emulated LAN ports > to all VPLS instances (i.e. all PWs from that PE are > in blocked state irrespective of its VPLS instance > membership). Doesn't this block other VPLS instances's > traffic across PWs? > > Perhaps my assumption is wrong and there is in fact > P-STP instance for each VPLS instance. However, if that > is true, PE would run into BPDU scalability issues. > > >/himanshu > > >-----Original Message----- >From: Mick Seaman [mailto:mick_seaman@ieee.org] >Sent: Wednesday, May 07, 2003 10:42 AM >To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; >'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > >If the fully meshed pseudowires (and the attached equipment/functions at >their ends) provide a LAN Service (stictly the Internal Sublayer Service >as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both >documents) then RSTP/MSTP will work just fine. > >To be more specific P802.1ad does specify the operation of a single >instance of MSTP within a Provider Network, how that travels over >pseduowires is of course how any LAN traffic travels over psedudowires >(i.e. the pseudowire protocol looks after making sure the configuration of >the pseudo wires correctly provides the fully connected LAN service, that >not being either MSTPs design goal or the desire of P802.1ad to specify >the simulation of LANs over non-LAN media, particularly where the non-LAN >media have native protocols that are to be used as part of the solution - >MPLS for example). > >Mick > >-----Original Message----- >From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] >Sent: Wednesday, May 07, 2003 6:01 AM >To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; >Paul Congdon; Neil Jarvis >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > >Norm, > >You have to excuse me for jumping in at the >tail end and not following the thread. > >I would like a clarification. > >Are you implying that 802.1ad is contemplating on >running one or more (Provider's) instances of R/M/STP >on fully-meshed pseudowires? > >/himanshu >Wavesmith Networks > >-----Original Message----- >From: Norman Finn [mailto:nfinn@cisco.com] >Sent: Tuesday, May 06, 2003 8:14 PM >To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; >Neil Jarvis >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: Re: Comments on the L2 VPN framework and solutions documents > > >Muneyoshi, > >Muneyoshi Suzuki wrote: > > > > > I don't think we're referring to the same model. The correct model > > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > > instance, is: > > > > The discussion is in the context of WG last call of the L2 FW doc and > > how to progress related solution drafts. So, I'm referring Eric's model > > describe in the FW doc. The following model completely differ from Eric's, > > so the following is disagreement to the FW doc, isn't it? > >My abrupt answer: The FW doc is misleading, because it disagrees >with the way bridges are both defined and built. > >Another way to put it: My diagram is the only way that a standard >bridge CAN interface to the full meshes within the layering model >shared by IEEE 802 and IETF. I should be more careful in my claims: >It's the only way that has been presented, to date, to IEEE 802.1, >and has received a lot of support. > >The problem with the model in the L2 FW doc (rev 3) is that it >clings to the idea, discarded by IEEE 802 in 1996, that separate >VLANs are handled by separate, independent, virtual bridges. IEEE >802.1Q chose a model in which one bridge handles all of the VLANs >using individual physical ports, through which each of the VLANs >pass. > >There is little point in arguing over which model is better. I >favored the IETF model when 802.1Q was making its decision, but I lost. >The models, diagrams, and protocols employed by 802.1Q, and hence the >actual bridges built today, conform to the IEEE model. There is >every reason to argue over which model is more relevant; the one to >which bridges are actually built should be of considerably more >interest than it seems to be on this mailing list. > >The diagram, below, brings the IEEE model, in which all VLANs pass >through a single port, in line with VPLS full meshes, which exist one >per (Provider VLAN | Customer Service Instance | Forwarding Function). > >Rather than rail against the L2 FW doc rev 3, let me suggest this: >Provider Bridges exist, are making money for their (several) builders, >and hopefully, are making money for their purchasers. IEEE 802.1AD >will standardize them. IEEE 802.1AD will be based on the 802.1Q model. >Deployed pseudowire full meshes will, of market-driven necessity, be >compatible with this 802.1AD provider bridge model. The only questions >are whether or not the 802.1AD-compatible implementations will conform >to the IETF documentation, and if not, whether their will exist naive >implementations of the incorrect IETF documents that confuse the market. >(Incorrect by definition, if they disagree with bridge implementations.) > > > > |===========================================--------+ > > > | | | forwarding | | > > > | | | function +--- | > > > E i --+ | untagged + VPLS 100 | | > > > t n | Provider | | for BPDUs +--- | P r > > > h t | Bridge | |------------| | s o > > > e e | | | +--- | e u > > > r r --+ | | forwarding | | u t > > > n f | Each "+" in | VLAN 26 + function +--- | d i > > > e a | the border of | | VPLS 200 | | o n > > > t c | this block | mux- | +--- | w g > > > e --+ represents one + demux |------------| | i > > > s | bridge port | function | +--- | r f > > > | | | | | e u > > > | | | +--- | s n > > > --+ | | forwarding | | c > > > | | VLAN 589 + function +--- | i t > > > | | | VPLS 300 | | n i > > > | | | +--- | o > > > --+ | | | | n > > > |===========================================--------+ > > > A B C > > > > > > The single interface above the "A" label at the bottom is the Provider > > > Bridge's bridge port that opens to the L3 world. The three interfaces > > > above the "B" label are the interfaces between the forwarding functions > > > and the mux-demux unit that translates between the Provider Bridge's > > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > > > the pseudowires. The physical ports on the routed side are of no > > > interest to the bridge. :) > > > > > > In my last note, I was pointing out that the each forwarding function > > > MUST control its "B" interface so that it provides 1) full service, or > > > 2) no service. (Let's be honest -- my last note was a little confused > > > between the "A" interface and the "B" interfaces.) > > > > > > Since VPLS meshes have one characteristic that physical LANs don't -- > > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > > needs to examine this situation, and figure out how to deal with it. > > > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > > is absolutely required to prevent a meltdown of the Provider's network. > > > A failure of one of the other VPLSs affects only that customer's traffic. > > > > (1) It seems to me, in the above model, PEs are interconnected with per > > customer meshes, where the PEs attached to the customer are interconnected > > with a full mesh. Therefore, in the worst case, there 2000 full meshes > > between PEs, if number of customers are 2000. Originally, full mesh has the > > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > > Furthermore, if fast protection is supported to avoid the protection > > racing problem and partial mesh, there are double meshes between the PEs. > > So, I don't feel any reality from the above model. > >For N PEs, the number of LSPs is exactly N, because each LSP is a >multipiont-to-point tree terminating at the destination PE. The number >of "branches" on all LSP trees is far less than O(N^2), because there is >(probably) no single VPLS that spans all of the PEs. The VPLS that >touches the largest number of PEs determines the largest n^2 full mesh >of LSP "branches". In a typical network with a very large number of >PEs, the actual number of LSP "branches" will be far less than N^2. > >Within that partial mesh of LSPs, for each VPLS, there is a full mesh >of pseudowires. The cost of setting up a pseudowire is trivial, >compared to the cost of an LSP, because it does not involve the >intervening routers. The number of pseudowires required is O(m^2), >where m is not the total number of PEs, but some smaller number, >related to the typical number of PEs attached to each VPLS. > > > (2) Frankly, I don't well understand the above model, because it > > illustrates some implementation, but is not a protocol architecture. > >I disagree completely that it is not a protocol architecture. I would >not implement the above diagram in one of my switches, because it would >be horribly inefficient, there. This is precisely a protocol >architecture, because it illustrates exactly where the existing >standardized interfaces and standardized functions go, and exactly >where new protocol and/or functional elements are required. Specifically, >the "mux/demux function", which is trivial, and the "Forwarding Function", >which L2VPN is defining. > > > In the Bridge architecture defined in a series of the IEEE standards, > > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > > layer entity. Could you clarify where these entities are located in > > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? > > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs > located? > > What is VLAN mux-demux function? According to the standards, the VLAN ID > > value is effective only inside the MAC relay entity, so it does not > > identify MSAP. I'm not sure whether this conforms with the standards or > not, > > but I think to realize this architecture big changes are needed to the > > current standards. > >All of the standard IEEE bridge functions are contained in the "Provider >Bridge" block. I did not break it out into its components, because there >is no need to do so; their existing functions are unchanged. The VLAN >mux-demux function merely translates between the Provider's VLAN tags and >the Forwarding Function world. > >The IEEE P802.1 Working Group writes the bridging standards. All of the >members of IEEE 802.1, with whom I have discussed this diagram, and that is >most of them, believe the above diagram to be conformant to the IEEE 802 >standards. It's a shame I cannot explain it better, and I invite >those members of 802.1 who read this mailing list to respond, and either >argue with me, or hopefully, explain it better. :) > >-- Norm From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 02:08:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03061 for ; Fri, 9 May 2003 02:08:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h496AxB15995 for ; Fri, 9 May 2003 02:11:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h496Aul29619 for ; Fri, 9 May 2003 02:10:56 -0400 (EDT) From: "Mark Seery" To: Cc: Subject: RE: Plug-and-play components (was FW: Single vs many solution(s)) Date: Thu, 8 May 2003 23:07:46 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D67E5@i2km07-ukbr.domain1.systemhost.net> Importance: Normal X-SMTP-HELO: smtp013.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp013.mail.yahoo.com [216.136.173.57] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ok, so now I get it. Its all about the architectural ability to use different components -I didn't get that originally. More offline. Mark -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Tuesday, May 06, 2003 3:58 PM To: mark@mseery.com Cc: ppvpn@nortelnetworks.com Subject: RE: Plug-and-play components (was FW: Single vs many solution(s)) Hi Mark, > Neil, > > [clipped] > > >> As an operator I have a requirement to be able to > choose addressing, routing, signalling (for the 2 co > modes), OAM, etc functional components *independently* > (using best-of-breed selection criteria) both per > mode and within each mode.<< > > Not sure how this can be achieved in practice (under > current industry structure/system architectures). NH=> Easy....just find a vendor who recognises it! We did for L1 control-plane signalling and are now happily using PNNI (as we wanted). It a great signalling protocol...better than rsvp-te in our view. I know another large operator who has done exactly the same as we have (even bought from the same vendor) though is still trotting out the GMPLS stuff on the lists....quite bizarre. As I noted in an earlier mail....its not at all clear to me that those vocal on the IETF lists represent an operator's true internal position. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 05:03:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09899 for ; Fri, 9 May 2003 05:03:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4995nB14732 for ; Fri, 9 May 2003 05:05:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4995ih27414 for ; Fri, 9 May 2003 05:05:45 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A146497014949BC@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'Ali Sajassi'" Cc: ppvpn@nortelnetworks.com, "'mick_seaman@ieee.org'" Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Fri, 9 May 2003 11:03:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31609.CE987300" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: 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_01C31609.CE987300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ali, Enabling P-STP on a intra-island afraid me a little bit :-) (a LER is not a ethernet switch, a LSR should never directly interact = in a STP process) A short example here: What will happen during a LSP failure in the backbone? Will P-STP instance on the affected PE will wait for the reconstruction = of this LSP (rsvp fast-reroute for example)=20 or Will this PE deducted that the Ethernet switches loop is broken and = will change the status of his acces port (or on the remote PEs) from = Blocking to Forwarding? The difficulty here will be to synchronise all P-STP process in the = backbone with MPLS signaling if you don't want that a STP message become quicly useless. Have you an idea of the P-STP convergence (what you want to do and what = you can)? I would like to be optimist on this topic but i can't, look like a hard issue here. Mourad -----Message d'origine----- De : Ali Sajassi [mailto:sajassi@cisco.com] Envoy=E9 : vendredi 9 mai 2003 01:03 =C0 : Himanshu Shah; mick_seaman@ieee.org; Norman Finn; Muneyoshi = Suzuki; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc : ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Objet : RE: Comments on the L2 VPN framework and solutions documents At 05:46 PM 5/8/2003 -0400, Himanshu Shah wrote: >I understand this approach. Its a simple approach. >And if you want to run M-STP (1 instance) across PWs >you may want to use this approach. > >However, the VPLS drafts in IETF explicitly >talks about not having to run the P-STP across PWs. >Dual-homing/external loop in Provider's network >is handled without using P-STP. > >There seems to be some disconnect in understanding >between these two groups that needs to be worked >out. I don't think there is a disconnect. When you talk about P-STP, you = need to=20 consider both intra-island and inter-island. P-STP is NOT used for=20 inter-island - for that we use full-mesh with split horizon. However, = for=20 intra-island where you can have an arbitrary topology of bridges within = an=20 access domain, then P-STP is the only viable solution (refer to section = 11.2 of draft-lasserre-vkompella). Also keep in mind that P-STP is=20 suggested for Ethernet access domain and not MPLS access domain. -Ali >/himanshu > >-----Original Message----- >From: Mick Seaman [mailto:mick_seaman@ieee.org] >Sent: Wednesday, May 07, 2003 6:42 PM >To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; >'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > >Himanshu, > >In (1) I think you have your layering a little mixed up. From the = point of=20 >view of control connectivity the pseudo-wires have to establish a full = >mesh that is never perceived by layer 2 protocols as being less than=20 >complete. STP is running across the service that runs on top of the=20 >mechanisms that make the service LAN like. If you wish to provide = subset=20 >LANs to be configured then of course you can have subsets each of = which=20 >has full connectivity in itself. Just never try to pretend to layer 2 = that=20 >two non equal subsets are the same LAN. > >In (2) I think you are further into the same pit. > >It is trivial to get into BPDU scaleability issues along the path you=20 >suggest. A much more attractive alternative is to maintain a single = full=20 >mesh for control connectivity which then prunes that mesh per VPLS = (each=20 >VPLS doesn't have to touch certain mesh nodes) and then uses that = pruning=20 >to delete VPLS specific pseudowires to the unwanted mesh nodes. Only = one=20 >instance of the topology determining protocol and the pruning protocol = are=20 >then required for all VPLSs. The trick here is to put provider=20 >provisioning in at the right level in the architecture (i.e. not at = the=20 >pseudowire level,but higher up so that it can drive the pseudowire = level=20 >in the context of the actually available resources). > >Mick > >-----Original Message----- >From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] >Sent: Wednesday, May 07, 2003 10:29 AM >To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; >Les Bell; Paul Congdon; Neil Jarvis >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > >This digresses from earlier thinking (at least mine) >that P-STP would not span across pseudowires. > >There are several implications to running STP >across PWs that may need to be clarified/worked out. > >1) "fully-meshed" attribute of the PWs only applied > within a context of a VPLS instance. That is, if > PE1 and PE2 participated in VPLS instance 1 than > there was no pseudowire to PE3 which did not > participate in VPLS instance 1. However, with this > scheme, each PE would have pseudowire to every > other VPLS capable PE irrespective of its VPLS > instance membership > >2) Assuming that 1 MSTP instance covers entire provider's > network, a backdoor link from ProvBridge1 to ProvBridge2 > of VPLS instance 1, may cause 802.1ad's emulated LAN ports > to all VPLS instances (i.e. all PWs from that PE are > in blocked state irrespective of its VPLS instance > membership). Doesn't this block other VPLS instances's > traffic across PWs? > > Perhaps my assumption is wrong and there is in fact > P-STP instance for each VPLS instance. However, if that > is true, PE would run into BPDU scalability issues. > > >/himanshu > > >-----Original Message----- >From: Mick Seaman [mailto:mick_seaman@ieee.org] >Sent: Wednesday, May 07, 2003 10:42 AM >To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; >'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > >If the fully meshed pseudowires (and the attached equipment/functions = at=20 >their ends) provide a LAN Service (stictly the Internal Sublayer = Service=20 >as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both = >documents) then RSTP/MSTP will work just fine. > >To be more specific P802.1ad does specify the operation of a single=20 >instance of MSTP within a Provider Network, how that travels over=20 >pseduowires is of course how any LAN traffic travels over psedudowires = >(i.e. the pseudowire protocol looks after making sure the = configuration of=20 >the pseudo wires correctly provides the fully connected LAN service, = that=20 >not being either MSTPs design goal or the desire of P802.1ad to = specify=20 >the simulation of LANs over non-LAN media, particularly where the = non-LAN=20 >media have native protocols that are to be used as part of the = solution -=20 >MPLS for example). > >Mick > >-----Original Message----- >From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] >Sent: Wednesday, May 07, 2003 6:01 AM >To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les = Bell; >Paul Congdon; Neil Jarvis >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > >Norm, > >You have to excuse me for jumping in at the >tail end and not following the thread. > >I would like a clarification. > >Are you implying that 802.1ad is contemplating on >running one or more (Provider's) instances of R/M/STP >on fully-meshed pseudowires? > >/himanshu >Wavesmith Networks > >-----Original Message----- >From: Norman Finn [mailto:nfinn@cisco.com] >Sent: Tuesday, May 06, 2003 8:14 PM >To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul = Congdon; >Neil Jarvis >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: Re: Comments on the L2 VPN framework and solutions documents > > >Muneyoshi, > >Muneyoshi Suzuki wrote: > > > > > I don't think we're referring to the same model. The correct = model > > > for how a bridge interacts with full-meshes, one full-mesh per = VPLS > > > instance, is: > > > > The discussion is in the context of WG last call of the L2 FW doc = and > > how to progress related solution drafts. So, I'm referring Eric's = model > > describe in the FW doc. The following model completely differ from Eric's, > > so the following is disagreement to the FW doc, isn't it? > >My abrupt answer: The FW doc is misleading, because it disagrees >with the way bridges are both defined and built. > >Another way to put it: My diagram is the only way that a standard >bridge CAN interface to the full meshes within the layering model >shared by IEEE 802 and IETF. I should be more careful in my claims: >It's the only way that has been presented, to date, to IEEE 802.1, >and has received a lot of support. > >The problem with the model in the L2 FW doc (rev 3) is that it >clings to the idea, discarded by IEEE 802 in 1996, that separate >VLANs are handled by separate, independent, virtual bridges. IEEE >802.1Q chose a model in which one bridge handles all of the VLANs >using individual physical ports, through which each of the VLANs >pass. > >There is little point in arguing over which model is better. I >favored the IETF model when 802.1Q was making its decision, but I = lost. >The models, diagrams, and protocols employed by 802.1Q, and hence the >actual bridges built today, conform to the IEEE model. There is >every reason to argue over which model is more relevant; the one to >which bridges are actually built should be of considerably more >interest than it seems to be on this mailing list. > >The diagram, below, brings the IEEE model, in which all VLANs pass >through a single port, in line with VPLS full meshes, which exist one >per (Provider VLAN | Customer Service Instance | Forwarding Function). > >Rather than rail against the L2 FW doc rev 3, let me suggest this: >Provider Bridges exist, are making money for their (several) builders, >and hopefully, are making money for their purchasers. IEEE 802.1AD >will standardize them. IEEE 802.1AD will be based on the 802.1Q = model. >Deployed pseudowire full meshes will, of market-driven necessity, be >compatible with this 802.1AD provider bridge model. The only = questions >are whether or not the 802.1AD-compatible implementations will conform >to the IETF documentation, and if not, whether their will exist naive >implementations of the incorrect IETF documents that confuse the = market. >(Incorrect by definition, if they disagree with bridge = implementations.) > > > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--------+ > > > | | | forwarding | | > > > | | | function +--- | > > > E i --+ | untagged + VPLS 100 | | > > > t n | Provider | | for BPDUs +--- | = P r > > > h t | Bridge | |------------| | = s o > > > e e | | | +--- | = e u > > > r r --+ | | forwarding | | = u t > > > n f | Each "+" in | VLAN 26 + function +--- | = d i > > > e a | the border of | | VPLS 200 | | = o n > > > t c | this block | mux- | +--- | = w g > > > e --+ represents one + demux |------------| | = i > > > s | bridge port | function | +--- | = r f > > > | | | | | = e u > > > | | | +--- | = s n > > > --+ | | forwarding | | c > > > | | VLAN 589 + function +--- | = i t > > > | | | VPLS 300 | | = n i > > > | | | +--- | o > > > --+ | | | | n > > > = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--------+ > > > A B C > > > > > > The single interface above the "A" label at the bottom is the = Provider > > > Bridge's bridge port that opens to the L3 world. The three = interfaces > > > above the "B" label are the interfaces between the forwarding functions > > > and the mux-demux unit that translates between the Provider = Bridge's > > > P-VLAN space and the VPLS VCID space. The "C" ports are the = mouths of > > > the pseudowires. The physical ports on the routed side are of no > > > interest to the bridge. :) > > > > > > In my last note, I was pointing out that the each forwarding = function > > > MUST control its "B" interface so that it provides 1) full = service, or > > > 2) no service. (Let's be honest -- my last note was a little = confused > > > between the "A" interface and the "B" interfaces.) > > > > > > Since VPLS meshes have one characteristic that physical LANs = don't -- > > > one VLAN can be disconnected, while another is working -- IEEE = 802.1 > > > needs to examine this situation, and figure out how to deal with = it. > > > > > > Finally, let me note that only one VPLS -- the one used for BPDUs = -- > > > is absolutely required to prevent a meltdown of the Provider's network. > > > A failure of one of the other VPLSs affects only that customer's traffic. > > > > (1) It seems to me, in the above model, PEs are interconnected with = per > > customer meshes, where the PEs attached to the customer are interconnected > > with a full mesh. Therefore, in the worst case, there 2000 full = meshes > > between PEs, if number of customers are 2000. Originally, full mesh = has the > > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. > > Furthermore, if fast protection is supported to avoid the = protection > > racing problem and partial mesh, there are double meshes between = the PEs. > > So, I don't feel any reality from the above model. > >For N PEs, the number of LSPs is exactly N, because each LSP is a >multipiont-to-point tree terminating at the destination PE. The = number >of "branches" on all LSP trees is far less than O(N^2), because there = is >(probably) no single VPLS that spans all of the PEs. The VPLS that >touches the largest number of PEs determines the largest n^2 full mesh >of LSP "branches". In a typical network with a very large number of >PEs, the actual number of LSP "branches" will be far less than N^2. > >Within that partial mesh of LSPs, for each VPLS, there is a full mesh >of pseudowires. The cost of setting up a pseudowire is trivial, >compared to the cost of an LSP, because it does not involve the >intervening routers. The number of pseudowires required is O(m^2), >where m is not the total number of PEs, but some smaller number, >related to the typical number of PEs attached to each VPLS. > > > (2) Frankly, I don't well understand the above model, because it > > illustrates some implementation, but is not a protocol = architecture. > >I disagree completely that it is not a protocol architecture. I would >not implement the above diagram in one of my switches, because it = would >be horribly inefficient, there. This is precisely a protocol >architecture, because it illustrates exactly where the existing >standardized interfaces and standardized functions go, and exactly >where new protocol and/or functional elements are required. = Specifically, >the "mux/demux function", which is trivial, and the "Forwarding = Function", >which L2VPN is defining. > > > In the Bridge architecture defined in a series of the IEEE = standards, > > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > > layer entity. Could you clarify where these entities are located in > > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is = located? > > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs = > located? > > What is VLAN mux-demux function? According to the standards, the = VLAN ID > > value is effective only inside the MAC relay entity, so it does not > > identify MSAP. I'm not sure whether this conforms with the = standards or=20 > not, > > but I think to realize this architecture big changes are needed to = the > > current standards. > >All of the standard IEEE bridge functions are contained in the = "Provider >Bridge" block. I did not break it out into its components, because = there >is no need to do so; their existing functions are unchanged. The VLAN >mux-demux function merely translates between the Provider's VLAN tags = and >the Forwarding Function world. > >The IEEE P802.1 Working Group writes the bridging standards. All of = the >members of IEEE 802.1, with whom I have discussed this diagram, and = that is >most of them, believe the above diagram to be conformant to the IEEE = 802 >standards. It's a shame I cannot explain it better, and I invite >those members of 802.1 who read this mailing list to respond, and = either >argue with me, or hopefully, explain it better. :) > >-- Norm ------_=_NextPart_001_01C31609.CE987300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments on the L2 VPN framework and solutions = documents

Ali,

Enabling P-STP on a intra-island afraid me a little = bit :-)
(a LER is not a ethernet switch, a LSR should never = directly interact in a STP process)

A short example here:
What will happen during a LSP failure in the = backbone?

Will P-STP instance on the affected PE will wait for = the reconstruction of this LSP (rsvp fast-reroute for example)

or

Will this PE deducted that the Ethernet switches loop = is broken and will change the status of his acces port (or on the = remote PEs) from Blocking to Forwarding?

The difficulty here will be to synchronise all P-STP = process in the backbone with MPLS signaling if you don't want that a = STP message become quicly useless.

Have you an idea of the P-STP convergence (what you = want to do and what you can)?

I would like to be optimist on this topic but i = can't, look like a hard issue here.

Mourad

-----Message d'origine-----
De : Ali Sajassi [mailto:sajassi@cisco.com]
Envoy=E9 : vendredi 9 mai 2003 01:03
=C0 : Himanshu Shah; mick_seaman@ieee.org; Norman = Finn; Muneyoshi Suzuki;
Tony Jeffree; Les Bell; Paul Congdon; Neil = Jarvis
Cc : ppvpn@nortelnetworks.com; = Cheng-Yin.Lee@alcatel.com
Objet : RE: Comments on the L2 VPN framework and = solutions documents




At 05:46 PM 5/8/2003 -0400, Himanshu Shah = wrote:
>I understand this approach. Its a simple = approach.
>And if you want to run M-STP (1 instance) across = PWs
>you may want to use this approach.
>
>However, the VPLS drafts in IETF = explicitly
>talks about not having to run the P-STP across = PWs.
>Dual-homing/external loop in Provider's = network
>is handled without using P-STP.
>
>There seems to be some disconnect in = understanding
>between these two groups that needs to be = worked
>out.

I don't think there is a disconnect. When you talk = about P-STP, you need to
consider both intra-island and inter-island. P-STP = is NOT used for
inter-island - for that we use full-mesh with split = horizon. However, for
intra-island where you can have an arbitrary = topology of bridges within an
access domain, then P-STP is the only viable = solution (refer to section
11.2 of draft-lasserre-vkompella). Also keep in mind = that P-STP is
suggested for Ethernet access domain and not MPLS = access domain.

-Ali


>/himanshu
>
>-----Original Message-----
>From: Mick Seaman [mailto:mick_seaman@ieee.org]
>Sent: Wednesday, May 07, 2003 6:42 PM
>To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi = Suzuki'; 'Tony Jeffree';
>'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'
>Cc: ppvpn@nortelnetworks.com; = Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework = and solutions documents
>
>
>
>Himanshu,
>
>In (1) I think you have your layering a little = mixed up. From the point of
>view of control connectivity the pseudo-wires = have to establish a full
>mesh that is never perceived by layer 2 = protocols as being less than
>complete. STP is running across the service that = runs on top of the
>mechanisms that make the service LAN like. If = you wish to provide subset
>LANs to be configured then of course you can = have subsets each of which
>has full connectivity in itself. Just never try = to pretend to layer 2 that
>two non equal subsets are the same LAN.
>
>In (2) I think you are further into the same = pit.
>
>It is trivial to get into BPDU scaleability = issues along the path you
>suggest. A much more attractive alternative is = to maintain a single full
>mesh for control connectivity which then prunes = that mesh per VPLS (each
>VPLS doesn't have to touch certain mesh nodes) = and then uses that pruning
>to delete VPLS specific pseudowires to the = unwanted mesh nodes. Only one
>instance of the topology determining protocol = and the pruning protocol are
>then required for all VPLSs. The trick here is = to put provider
>provisioning in at the right level in the = architecture (i.e. not at the
>pseudowire level,but higher up so that it can = drive the pseudowire level
>in the context of the actually available = resources).
>
>Mick
>
>-----Original Message-----
>From: Himanshu Shah [mailto:hshah@wavesmithnetwor= ks.com]
>Sent: Wednesday, May 07, 2003 10:29 AM
>To: mick_seaman@ieee.org; Norman Finn; Muneyoshi = Suzuki; Tony Jeffree;
>Les Bell; Paul Congdon; Neil Jarvis
>Cc: ppvpn@nortelnetworks.com; = Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework = and solutions documents
>
>
>This digresses from earlier thinking (at least = mine)
>that P-STP would not span across = pseudowires.
>
>There are several implications to running = STP
>across PWs that may need to be clarified/worked = out.
>
>1) "fully-meshed" attribute of the PWs = only applied
>    within a context of a VPLS = instance. That is, if
>    PE1 and PE2 participated in = VPLS instance 1 than
>    there was no pseudowire to = PE3 which did not
>    participate in VPLS instance = 1. However, with this
>    scheme, each PE would have = pseudowire to every
>    other VPLS capable PE = irrespective of its VPLS
>    instance membership
>
>2) Assuming that 1 MSTP instance covers entire = provider's
>    network, a backdoor link from = ProvBridge1 to ProvBridge2
>    of VPLS instance 1, may cause = 802.1ad's emulated LAN ports
>    to all VPLS instances (i.e. = all PWs from that PE are
>    in blocked state irrespective = of its VPLS instance
>    membership). Doesn't this = block other VPLS instances's
>    traffic across PWs?
>
>    Perhaps my assumption is = wrong and there is in fact
>    P-STP instance for each VPLS = instance. However, if that
>    is true, PE would run into = BPDU scalability issues.
>
>
>/himanshu
>
>
>-----Original Message-----
>From: Mick Seaman [mailto:mick_seaman@ieee.org]
>Sent: Wednesday, May 07, 2003 10:42 AM
>To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi = Suzuki'; 'Tony Jeffree';
>'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'
>Cc: ppvpn@nortelnetworks.com; = Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework = and solutions documents
>
>
>
>If the fully meshed pseudowires (and the = attached equipment/functions at
>their ends) provide a LAN Service (stictly the = Internal Sublayer Service
>as defined in 802.1D and 802.1Q Clause 6.5 (same = number clause in both
>documents) then RSTP/MSTP will work just = fine.
>
>To be more specific P802.1ad does specify the = operation of a single
>instance of MSTP within a Provider Network, how = that travels over
>pseduowires is of course how any LAN traffic = travels over psedudowires
>(i.e. the pseudowire protocol looks after making = sure the configuration of
>the pseudo wires correctly provides the fully = connected LAN service, that
>not being either MSTPs design goal or the desire = of P802.1ad to specify
>the simulation of LANs over non-LAN media, = particularly where the non-LAN
>media have native protocols that are to be used = as part of the solution -
>MPLS for example).
>
>Mick
>
>-----Original Message-----
>From: Himanshu Shah [mailto:hshah@wavesmithnetwor= ks.com]
>Sent: Wednesday, May 07, 2003 6:01 AM
>To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; = Tony Jeffree; Les Bell;
>Paul Congdon; Neil Jarvis
>Cc: ppvpn@nortelnetworks.com; = Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework = and solutions documents
>
>
>Norm,
>
>You have to excuse me for jumping in at = the
>tail end and not following the thread.
>
>I would like a clarification.
>
>Are you implying that 802.1ad is contemplating = on
>running one or more (Provider's) instances of = R/M/STP
>on fully-meshed pseudowires?
>
>/himanshu
>Wavesmith Networks
>
>-----Original Message-----
>From: Norman Finn [mailto:nfinn@cisco.com]
>Sent: Tuesday, May 06, 2003 8:14 PM
>To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; = Les Bell; Paul Congdon;
>Neil Jarvis
>Cc: ppvpn@nortelnetworks.com; = Cheng-Yin.Lee@alcatel.com
>Subject: Re: Comments on the L2 VPN framework = and solutions documents
>
>
>Muneyoshi,
>
>Muneyoshi Suzuki wrote:
> >
> > > I don't think we're referring to the = same model.  The correct model
> > > for how a bridge interacts with = full-meshes, one full-mesh per VPLS
> > > instance, is:
> >
> > The discussion is in the context of WG = last call of the L2 FW doc and
> > how to progress related solution drafts. = So, I'm referring Eric's model
> > describe in the FW doc. The following = model completely differ from Eric's,
> > so the following is disagreement to the FW = doc, isn't it?
>
>My abrupt answer:  The FW doc is = misleading, because it disagrees
>with the way bridges are both defined and = built.
>
>Another way to put it:  My diagram is the = only way that a standard
>bridge CAN interface to the full meshes within = the layering model
>shared by IEEE 802 and IETF.  I should be = more careful in my claims:
>It's the only way that has been presented, to = date, to IEEE 802.1,
>and has received a lot of support.
>
>The problem with the model in the L2 FW doc (rev = 3) is that it
>clings to the idea, discarded by IEEE 802 in = 1996, that separate
>VLANs are handled by separate, independent, = virtual bridges.  IEEE
>802.1Q chose a model in which one bridge handles = all of the VLANs
>using individual physical ports, through which = each of the VLANs
>pass.
>
>There is little point in arguing over which = model is better.  I
>favored the IETF model when 802.1Q was making = its decision, but I lost.
>The models, diagrams, and protocols employed by = 802.1Q, and hence the
>actual bridges built today, conform to the IEEE = model.  There is
>every reason to argue over which model is more = relevant; the one to
>which bridges are actually built should be of = considerably more
>interest than it seems to be on this mailing = list.
>
>The diagram, below, brings the IEEE model, in = which all VLANs pass
>through a single port, in line with VPLS full = meshes, which exist one
>per (Provider VLAN | Customer Service Instance | = Forwarding Function).
>
>Rather than rail against the L2 FW doc rev 3, = let me suggest this:
>Provider Bridges exist, are making money for = their (several) builders,
>and hopefully, are making money for their = purchasers.  IEEE 802.1AD
>will standardize them.  IEEE 802.1AD will = be based on the 802.1Q model.
>Deployed pseudowire full meshes will, of = market-driven necessity, be
>compatible with this 802.1AD provider bridge = model.  The only questions
>are whether or not the 802.1AD-compatible = implementations will conform
>to the IETF documentation, and if not, whether = their will exist naive
>implementations of the incorrect IETF documents = that confuse the market.
>(Incorrect by definition, if they disagree with = bridge implementations.)
>
> > = >           &n= bsp; = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--------+
> > = >           &n= bsp; = |            = ;       = |          | forwarding = |       |
> > = >           &n= bsp; = |            = ;       = |          |  = function  +---    |
> > >    E  = i   = --+           &nb= sp;       | untagged +  VPLS = 100  |       |
> > >    t  = n     |      = Provider     = |          | for = BPDUs  +---    |  P  r
> > >    h  = t     |       = Bridge      = |          = |------------|       |  s  = o
> > >    e  = e     = |            = ;       = |          = |            = +---    |  e  u
> > >    r  = r   = --+           &nb= sp;       = |          | forwarding = |       |  u  t
> > >    n  = f     |     Each "+" = in   |  VLAN 26 +  function  = +---    |  d  i
> > >    e  = a     |    the border of  = |          |  VPLS = 200  |       |  o  = n
> > >    t  = c     |     this = block    |   mux-   = |            = +---    |  w  g
> > >       = e   --+   represents one  +  = demux   |------------|       = |  i
> > >       = s     |     bridge = port   | function = |            = +---    |  r  f
> > = >           &n= bsp; = |            = ;       = |          = |            = |       |  e  u
> > = >           &n= bsp; = |            = ;       = |          = |            = +---    |  s  n
> > = >           = --+           &nb= sp;       = |          | forwarding = |       |     = c
> > = >           &n= bsp; = |            = ;       | VLAN 589 +  function  = +---    |  i  t
> > = >           &n= bsp; = |            = ;       = |          |  VPLS = 300  |       |  n  = i
> > = >           &n= bsp; = |            = ;       = |          = |            = +---    |     o
> > = >           = --+           &nb= sp;       = |          = |            = |       |     = n
> > = >           &n= bsp; = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--------+
> > = >           &n= bsp;           &n= bsp;         = A          = B            = C
> > >
> > > The single interface above the = "A" label at the bottom is the Provider
> > > Bridge's bridge port that opens to = the L3 world.  The three interfaces
> > > above the "B" label are the = interfaces between the forwarding functions
> > > and the mux-demux unit that = translates between the Provider Bridge's
> > > P-VLAN space and the VPLS VCID = space.  The "C" ports are the mouths of
> > > the pseudowires.  The physical = ports on the routed side are of no
> > > interest to the bridge.  = :)
> > >
> > > In my last note, I was pointing out = that the each forwarding function
> > > MUST control its "B" = interface so that it provides 1) full service, or
> > > 2) no service.  (Let's be honest = -- my last note was a little confused
> > > between the "A" interface = and the "B" interfaces.)
> > >
> > > Since VPLS meshes have one = characteristic that physical LANs don't --
> > > one VLAN can be disconnected, while = another is working -- IEEE 802.1
> > > needs to examine this situation, and = figure out how to deal with it.
> > >
> > > Finally, let me note that only one = VPLS -- the one used for BPDUs --
> > > is absolutely required to prevent a = meltdown of the Provider's network.
> > > A failure of one of the other VPLSs = affects only that customer's traffic.
> >
> > (1) It seems to me, in the above model, = PEs are interconnected with per
> > customer meshes, where the PEs attached to = the customer are interconnected
> > with a full mesh. Therefore, in the worst = case, there 2000 full meshes
> > between PEs, if number of customers are = 2000. Originally, full mesh has the
> > O(N^2) problem, so the proposed scheme has = O(#ofCustomers * N^2) problem.
> > Furthermore, if fast protection is = supported to avoid the protection
> > racing problem and partial mesh, there are = double meshes between the PEs.
> > So, I don't feel any reality from the = above model.
>
>For N PEs, the number of LSPs is exactly N, = because each LSP is a
>multipiont-to-point tree terminating at the = destination PE.  The number
>of "branches" on all LSP trees is far = less than O(N^2), because there is
>(probably) no single VPLS that spans all of the = PEs.  The VPLS that
>touches the largest number of PEs determines the = largest n^2 full mesh
>of LSP "branches".  In a typical = network with a very large number of
>PEs, the actual number of LSP = "branches" will be far less than N^2.
>
>Within that partial mesh of LSPs, for each VPLS, = there is a full mesh
>of pseudowires.  The cost of setting up a = pseudowire is trivial,
>compared to the cost of an LSP, because it does = not involve the
>intervening routers.  The number of = pseudowires required is O(m^2),
>where m is not the total number of PEs, but some = smaller number,
>related to the typical number of PEs attached to = each VPLS.
>
> > (2) Frankly, I don't well understand the = above model, because it
> > illustrates some implementation, but is = not a protocol architecture.
>
>I disagree completely that it is not a protocol = architecture.  I would
>not implement the above diagram in one of my = switches, because it would
>be horribly inefficient, there.  This is = precisely a protocol
>architecture, because it illustrates exactly = where the existing
>standardized interfaces and standardized = functions go, and exactly
>where new protocol and/or functional elements = are required.  Specifically,
>the "mux/demux function", which is = trivial, and the "Forwarding Function",
>which L2VPN is defining.
>
> > In the Bridge architecture defined in a = series of the IEEE standards,
> > a Bridge consists of MAC entities, a MAC = relay entity, and a Higher
> > layer entity. Could you clarify where = these entities are located in
> > the above figure? Where are MSAPs defined = in ISO/IEC 15802-1 is located?
> > If the provider Bridge is a VLAN aware = Bridge, where are the E-ISSs
> located?
> > What is VLAN mux-demux function? According = to the standards, the VLAN ID
> > value is effective only inside the MAC = relay entity, so it does not
> > identify MSAP. I'm not sure whether this = conforms with the standards or
> not,
> > but I think to realize this architecture = big changes are needed to the
> > current standards.
>
>All of the standard IEEE bridge functions are = contained in the "Provider
>Bridge" block.  I did not break it out = into its components, because there
>is no need to do so; their existing functions = are unchanged.  The VLAN
>mux-demux function merely translates between the = Provider's VLAN tags and
>the Forwarding Function world.
>
>The IEEE P802.1 Working Group writes the = bridging standards.  All of the
>members of IEEE 802.1, with whom I have = discussed this diagram, and that is
>most of them, believe the above diagram to be = conformant to the IEEE 802
>standards.  It's a shame I cannot explain = it better, and I invite
>those members of 802.1 who read this mailing = list to respond, and either
>argue with me, or hopefully, explain it = better.  :)
>
>-- Norm


------_=_NextPart_001_01C31609.CE987300-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 08:29:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13882 for ; Fri, 9 May 2003 08:29:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49CW8B24256 for ; Fri, 9 May 2003 08:32:08 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49CW4v24085 for ; Fri, 9 May 2003 08:32:04 -0400 (EDT) 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: Comments on the L2 VPN framework and solutions documents Date: Fri, 9 May 2003 08:29:14 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB720215260D@WHISTLER.WaveSmithNet.com> Thread-Topic: Comments on the L2 VPN framework and solutions documents Thread-Index: AcMVthfutE5yawDaTwuoe8N0bgvl5QAaEywA From: "Himanshu Shah" To: "Ali Sajassi" , , "Norman Finn" , "Muneyoshi Suzuki" , "Tony Jeffree" , "Les Bell" , "Paul Congdon" , "Neil Jarvis" Cc: , X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13882 May be an example will clear up some confusion... :-) Lets suppose there is PE-x which is connected to island A and island B. There is PE-y that is connected to island A and island C. and there is PE-z that is connected to island B and island C. Based on what I understand from Mick's explanation is that there is 1. (using your terminology) network-facing (i.e. PW based) emulated Vlan ports (one for each island) and 1 emulated LAN port (for P-STP, 1 instance MSTP) in each PE. 2. There is P-STP BPDUs generation/propagation on emulated LAN port to determine its forwarding state. 3. The state of the emulated LAN port also determines the state of each emulated VLAN port in a PE. Please let me know if above understanding is correct. Now further suppose, 1. there is 10GB backdoor connection between island A (behind PE-x and PE-y). 2. Emulated LAN port in PE-x blocks thus causing emulated VLAN port blocking for island A and island B. How does the traffic from island B behind PE-z reaches to island B behind PE-x? Now let me guess to what you and/or Mick are saying, 1. 802.1ad does not participate in P-STP. It simply takes a received P-BPDU from island facing port and forwards it out to respective emulated VLAN port (something like what you are suggesting in your response but not the impression I got from Mick's explanation) or 1a. 802.1ad does not participate in P-STP. It drops any P-BPDU received from its island facing port. or 2. 802.1ad does participate in P-STP but only on island/access facing ports. P-BPDU received from island facing ports is processed for that port state and forwarded to respective emulated VLAN port. or 3. 802.1ad participates in P-STP on emulated LAN port to determine the states of all emulated VLAN ports (my impression from Mick's explanation) or 4. Each PW is treated as separate emulated port (I don't think anybody is saying this, including me. This is what old bridges used to do for WAN ports but does not make sense for VPLS model at all) I think option 1 or 1a makes sense but has implications of how STP is built and where the root gets selected (possibility of having traffic passing through cloud twice). /himanshu -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com] Sent: Thursday, May 08, 2003 7:03 PM To: Himanshu Shah; mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents At 05:46 PM 5/8/2003 -0400, Himanshu Shah wrote: >I understand this approach. Its a simple approach. >And if you want to run M-STP (1 instance) across PWs >you may want to use this approach. > >However, the VPLS drafts in IETF explicitly >talks about not having to run the P-STP across PWs. >Dual-homing/external loop in Provider's network >is handled without using P-STP. > >There seems to be some disconnect in understanding >between these two groups that needs to be worked >out. I don't think there is a disconnect. When you talk about P-STP, you need to consider both intra-island and inter-island. P-STP is NOT used for inter-island - for that we use full-mesh with split horizon. However, for intra-island where you can have an arbitrary topology of bridges within an access domain, then P-STP is the only viable solution (refer to section 11.2 of draft-lasserre-vkompella). Also keep in mind that P-STP is suggested for Ethernet access domain and not MPLS access domain. -Ali >/himanshu > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 10:58:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19118 for ; Fri, 9 May 2003 10:58:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49F0uB23653 for ; Fri, 9 May 2003 11:00:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49F0p619334 for ; Fri, 9 May 2003 11:00:52 -0400 (EDT) Message-ID: <3EBBC117.D5730B6C@alcatel.be> Date: Fri, 09 May 2003 16:54:15 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten Cc: Alex Zinin , ppvpn@nortelnetworks.com Subject: Re: IMPORTANT: Strategy for VPN work in IETF X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/09/2003 16:54:17, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/09/2003 16:54:18, Serialize complete at 05/09/2003 16:54:18 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-SMTP-HELO: relay4.alcatel.be X-SMTP-MAIL-FROM: jeremy.de_clercq@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc245.alcatel.be [195.207.101.245] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Thomas, all, > The chairs themselves seem to agree that there are some 13 documents > on L3 that are not through the system yet. I'm a bit concerned to hear > that there has been minimal discussion on L3 topics over the last > year, given the number of L3 work items that apparently need to get > completed. > > The above could be read as indicating that the discussion/urgency of > the L2 work is pushing out or drowning out discussion on L3 topics. If > that is the case, a separate WG, mailing list, etc., may well help. > I'm assuming the L3 work is important and should get completed. I believe that it can also be read as indicating that many feel that most of the (current) L3VPN work is stable and agreed upon, and doesn't need more discussion within the WG. As was already hinted previously, the progress of the L3VPN work has been delayed (for a long time) because the framework and requirements documents needed to be accepted first. I do believe however that several proposed new working items (QoS, security, management, multicast, etc.) have received little attention from the WG because of the current L2VPN (VPLS) discussions/urgency. But as many of these are aimed at both L2 and L3VPNs, and as I don't find reference to these items in the proposed charters, I understand that the goal of the proposed split is not to accomodate these. On one hand, I believe that the idea of two separate WGs is a good one, but on the other hand, I'm not sure how much it will help now, so far in the process. I also personally believe that the PPVPN WG has produced valuable results, and is making progress on complex topics every day (look at the current IEEE vs VPLS discussions on this list). And this despite the fact that the 'market' is not waiting and despite the fact that the number of interested individuals (from different backgrounds: SPs, vendors, academic and other standard bodies) is very large. Jeremy. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 11:02:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19278 for ; Fri, 9 May 2003 11:02:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49F4fB29628 for ; Fri, 9 May 2003 11:04:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49F4Z600827 for ; Fri, 9 May 2003 11:04:36 -0400 (EDT) Message-Id: <200305091459.h49ExKZC001931@rtp-core-1.cisco.com> To: mick_seaman@ieee.org cc: "'Pedro Roque Marques'" , "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Thu, 08 May 2003 13:18:59 -0700. <000501c3159f$122c1c90$210110ac@corp.telseon.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, 09 May 2003 10:59:20 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Mick> Of course the IEEE model doesn't require all provider bridges to be on Mick> the same emulated LAN, only all those that are optimising their Mick> control traffic by sharing its results between them - i.e. just like Mick> ordinary LAN. So VPLS's that are on the *same* underlying connectivity Mick> can share that knowledge and don't have to suffer BPDU sending Mick> inefficiency. So the difference between the IEEE model and the FW model is that the IEEE model allows this optimization. But I don't quite understand how to benefit from this optimization in the VPLS environment. A particular set of VPLSes could only be considered to have the same "underlying connectivity" if it is known that they are supported by the same set of PEs, both now and in the future. I'm not sure whether this is a common enough case to worry about, and I'm also not sure how one would get this information from the auto-discovery provisioning model. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 11:26:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20071 for ; Fri, 9 May 2003 11:26:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49FSkP07529 for ; Fri, 9 May 2003 11:28:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49FSde23812 for ; Fri, 9 May 2003 11:28:41 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF05AF8B23@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Thomas Narten Cc: Alex Zinin , ppvpn@nortelnetworks.com, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: L3 VPN Work Item List ?? Date: Fri, 9 May 2003 11:22:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3163E.BF7E6642" X-LYRIS-Message-Id: 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_01C3163E.BF7E6642 Content-Type: text/plain Hi Thomas, Alex and all, I'm still concerned about splitting off L3 work when it already is mostly winding down. Being involved as editor or co-author of drafts in two of the three L3VPN types (VR and CE-based) as well as the security framework draft, I don't see any indication that the work is getting squeezed out of the WG meetings, only that it is proceeding at the pace of the authors' level of input. And it is proceeding well, if we look at the specifics. On Wednesday, Thomas Narten said: "My understanding after having looked at the work as that there are something like 12-13 IDs on L3 VPNs in the pipeline. That's no small number and suggests that an L3 focused WG still has plenty on its plate." (And this was repeated twice more in the message under the thread "RE: IMPORTANT: Strategy for VPN work in IETF".) However, when I look at the work for the proposed L3VPN WG, it seems that there are four main areas: - 2547bis (5 drafts at least) - Virtual Router (VR) (3 drafts) - CE-based IPsec (1 now, will be 3, with A.S. and MIB) - CE route authentication (1 draft) Of the four main areas, two are well advanced: - 2547bis and its applicability statement have already moved to last call (2 drafts) - VR and its applicability statement have moved to last call. (2 drafts) The MIBs for each of these are basically stable and are typically not controversial (2 more drafts), and I think also the drafts defining IPsec and GRE for PE-PE encapsulation in 2547bis are pretty much done, so they should follow like dominos. (2 more drafts) Some items are listed in the L3VPN draft charter which really cover both L2 and L3, as far as I can see: - Security Framework - Textual Conventions (TC) MIB. - Also, (but not on the draft charter) Juha's RADIUS-based PE Discovery seems to apply well to both L2 and L3, and Hamid's BGP Autodiscovery is applicable to both L2 and L3. That really only leaves the CE-based IPsec (which will have a MIB and app statement drafts) and CE route authentication as identified work items which apply only to L3. The CE-based IPsec has a strong start and could become a WG draft in a short time. The related Applicability Statement is also on the way and will follow. So I count about four out of the thirteen drafts with some work. This hardly seems like enough work for a full fledged work group. As Yakov and others have pointed out, there has been little L3 discussion on the list... Not because it is being squeezed out, but because it is pretty stable and has essentially been in the queue waiting for the L3 requirements and L3 framework documents as stable references. I'm probably missing something in my quick count here, but it looks really sparse. Paul Knight "The world is a jungle in general, and the networking game contributes many animals." - RFC 826 ------_=_NextPart_001_01C3163E.BF7E6642 Content-Type: text/html Content-Transfer-Encoding: quoted-printable L3 VPN Work Item List ??

Hi Thomas, Alex and all,

I'm still concerned about splitting off L3 work when = it already is mostly winding down.
Being involved as editor or co-author of drafts in = two of the three L3VPN types (VR and CE-based) as well as the security = framework draft, I don't see any indication that the work is getting = squeezed out of the WG meetings, only that it is proceeding at the pace = of the authors' level of input.  And it is proceeding  well, = if we look at the specifics.

On Wednesday, Thomas Narten said:  "My = understanding after having looked at the work as that there are = something like 12-13 IDs on L3 VPNs in the pipeline. That's no small = number and suggests that an L3 focused WG still has plenty on its = plate."  (And this was repeated twice more in the message = under the thread "RE: IMPORTANT: Strategy for VPN work in = IETF".)

However, when I look at the work for the proposed = L3VPN WG, it seems that there are four main areas:
- 2547bis   (5 drafts at least)
- Virtual Router (VR)  (3 drafts)
- CE-based IPsec  (1 now, will be 3, with A.S. = and MIB)
- CE route authentication (1 draft)

Of the four main areas, two are well advanced: =
- 2547bis and its applicability statement have = already moved to last call  (2 drafts)
- VR and its applicability statement have moved to = last call.  (2 drafts)

The MIBs for each of these are basically stable and = are typically not controversial (2 more drafts), and I think also the = drafts defining IPsec and GRE for PE-PE encapsulation in 2547bis are = pretty much done, so they should follow like dominos. (2 more = drafts)

Some items are listed in the L3VPN draft charter = which really cover both L2 and L3, as far as I can see:
- Security Framework
- Textual Conventions (TC) MIB.
- Also, (but not on the draft charter) Juha's = RADIUS-based PE Discovery seems to apply well to both L2 and L3, and = Hamid's BGP Autodiscovery is applicable to both L2 and L3.

That really only leaves the CE-based IPsec (which = will have a MIB and app statement drafts) and CE route authentication = as identified work items which apply only to L3.  The CE-based = IPsec has a strong start and could become a WG draft in a short time. = The related Applicability Statement is also on the way and will = follow.  So I count about four out of the thirteen drafts with = some work. 

This hardly seems like enough work for a full fledged = work group.  As Yakov and others have pointed out, there has been = little L3 discussion on the list... Not because it is being squeezed = out, but because it is pretty stable and has essentially been in the = queue waiting for the L3 requirements and L3 framework documents as = stable references.

I'm probably missing something in my quick count = here, but it looks really sparse.

Paul Knight

"The world is a jungle in general, and the = networking game contributes many animals."  - RFC 826

------_=_NextPart_001_01C3163E.BF7E6642-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 11:47:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20783 for ; Fri, 9 May 2003 11:47:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49FnVP13484 for ; Fri, 9 May 2003 11:49:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49FnRZ04609 for ; Fri, 9 May 2003 11:49:27 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF05AF8BDA@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Thomas Narten Cc: Alex Zinin , ppvpn@nortelnetworks.com, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: RE: L3 VPN Work Item List ?? Date: Fri, 9 May 2003 11:46:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31642.23CD93D6" X-LYRIS-Message-Id: 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_01C31642.23CD93D6 Content-Type: text/plain Just realized I did not explicitly include Eric's work on 2547bis with OSPF as the PE/CE protocol, but with his usual careful work already proceeding on it, it should not add a lot to the proposed WG load. - Paul -----Original Message----- From: Knight, Paul [BL60:1A00:EXCH] Sent: Friday, May 09, 2003 11:22 AM To: Thomas Narten Cc: Alex Zinin; ppvpn@nortelnetworks.com; Wijnen, Bert (Bert); Peterson, Jon; Allison Mankin Subject: L3 VPN Work Item List ?? Hi Thomas, Alex and all, I'm still concerned about splitting off L3 work when it already is mostly winding down. Being involved as editor or co-author of drafts in two of the three L3VPN types (VR and CE-based) as well as the security framework draft, I don't see any indication that the work is getting squeezed out of the WG meetings, only that it is proceeding at the pace of the authors' level of input. And it is proceeding well, if we look at the specifics. On Wednesday, Thomas Narten said: "My understanding after having looked at the work as that there are something like 12-13 IDs on L3 VPNs in the pipeline. That's no small number and suggests that an L3 focused WG still has plenty on its plate." (And this was repeated twice more in the message under the thread "RE: IMPORTANT: Strategy for VPN work in IETF".) However, when I look at the work for the proposed L3VPN WG, it seems that there are four main areas: - 2547bis (5 drafts at least) - Virtual Router (VR) (3 drafts) - CE-based IPsec (1 now, will be 3, with A.S. and MIB) - CE route authentication (1 draft) Of the four main areas, two are well advanced: - 2547bis and its applicability statement have already moved to last call (2 drafts) - VR and its applicability statement have moved to last call. (2 drafts) The MIBs for each of these are basically stable and are typically not controversial (2 more drafts), and I think also the drafts defining IPsec and GRE for PE-PE encapsulation in 2547bis are pretty much done, so they should follow like dominos. (2 more drafts) Some items are listed in the L3VPN draft charter which really cover both L2 and L3, as far as I can see: - Security Framework - Textual Conventions (TC) MIB. - Also, (but not on the draft charter) Juha's RADIUS-based PE Discovery seems to apply well to both L2 and L3, and Hamid's BGP Autodiscovery is applicable to both L2 and L3. That really only leaves the CE-based IPsec (which will have a MIB and app statement drafts) and CE route authentication as identified work items which apply only to L3. The CE-based IPsec has a strong start and could become a WG draft in a short time. The related Applicability Statement is also on the way and will follow. So I count about four out of the thirteen drafts with some work. This hardly seems like enough work for a full fledged work group. As Yakov and others have pointed out, there has been little L3 discussion on the list... Not because it is being squeezed out, but because it is pretty stable and has essentially been in the queue waiting for the L3 requirements and L3 framework documents as stable references. I'm probably missing something in my quick count here, but it looks really sparse. Paul Knight "The world is a jungle in general, and the networking game contributes many animals." - RFC 826 ------_=_NextPart_001_01C31642.23CD93D6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: L3 VPN Work Item List ??

Just realized I did not explicitly include Eric's = work on 2547bis with OSPF as the  PE/CE protocol, but with his = usual careful work already proceeding on it, it should not add a lot to = the proposed WG load.

- Paul
-----Original Message-----
From: Knight, Paul [BL60:1A00:EXCH]
Sent: Friday, May 09, 2003 11:22 AM
To: Thomas Narten
Cc: Alex Zinin; ppvpn@nortelnetworks.com; Wijnen, = Bert (Bert); Peterson, Jon; Allison Mankin
Subject: L3 VPN Work Item List ??


Hi Thomas, Alex and all,

I'm still concerned about splitting off L3 work when = it already is mostly winding down.

Being involved as editor or co-author of drafts in = two of the three L3VPN types (VR and CE-based) as well as the security = framework draft, I don't see any indication that the work is getting = squeezed out of the WG meetings, only that it is proceeding at the pace = of the authors' level of input.  And it is proceeding  well, = if we look at the specifics.

On Wednesday, Thomas Narten said:  "My = understanding after having looked at the work as that there are = something like 12-13 IDs on L3 VPNs in the pipeline. That's no small = number and suggests that an L3 focused WG still has plenty on its = plate."  (And this was repeated twice more in the message = under the thread "RE: IMPORTANT: Strategy for VPN work in = IETF".)

However, when I look at the work for the proposed = L3VPN WG, it seems that there are four main areas:
- 2547bis   (5 drafts at least)
- Virtual Router (VR)  (3 drafts)
- CE-based IPsec  (1 now, will be 3, with A.S. = and MIB)
- CE route authentication (1 draft)

Of the four main areas, two are well advanced: =
- 2547bis and its applicability statement have = already moved to last call  (2 drafts)
- VR and its applicability statement have moved to = last call.  (2 drafts)

The MIBs for each of these are basically stable and = are typically not controversial (2 more drafts), and I think also the = drafts defining IPsec and GRE for PE-PE encapsulation in 2547bis are = pretty much done, so they should follow like dominos. (2 more = drafts)

Some items are listed in the L3VPN draft charter = which really cover both L2 and L3, as far as I can see:
- Security Framework
- Textual Conventions (TC) MIB.
- Also, (but not on the draft charter) Juha's = RADIUS-based PE Discovery seems to apply well to both L2 and L3, and = Hamid's BGP Autodiscovery is applicable to both L2 and L3.

That really only leaves the CE-based IPsec (which = will have a MIB and app statement drafts) and CE route authentication = as identified work items which apply only to L3.  The CE-based = IPsec has a strong start and could become a WG draft in a short time. = The related Applicability Statement is also on the way and will = follow.  So I count about four out of the thirteen drafts with = some work. 

This hardly seems like enough work for a full fledged = work group.  As Yakov and others have pointed out, there has been = little L3 discussion on the list... Not because it is being squeezed = out, but because it is pretty stable and has essentially been in the = queue waiting for the L3 requirements and L3 framework documents as = stable references.

I'm probably missing something in my quick count = here, but it looks really sparse.

Paul Knight
"The world is a jungle in general, and the = networking game contributes many animals."  - RFC 826

------_=_NextPart_001_01C31642.23CD93D6-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 11:52:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20961 for ; Fri, 9 May 2003 11:52:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49Ft2P17621 for ; Fri, 9 May 2003 11:55:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49FswZ11347 for ; Fri, 9 May 2003 11:54:58 -0400 (EDT) From: "Jim Guichard" To: "Paul Knight" , "Thomas Narten" Cc: "Alex Zinin" , , "Wijnen, Bert \(Bert\)" , "Peterson, Jon" , "Allison Mankin" Subject: RE: L3 VPN Work Item List ?? Date: Fri, 9 May 2003 11:44:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C31620.5D735570" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF05AF8B23@zbl6c004.corpeast.baynetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C31620.5D735570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit L3 VPN Work Item List ??Paul, However, when I look at the work for the proposed L3VPN WG, it seems that there are four main areas: - 2547bis (5 drafts at least) - Virtual Router (VR) (3 drafts) - CE-based IPsec (1 now, will be 3, with A.S. and MIB) also add: http://www.ietf.org/internet-drafts/draft-guichard-ce-ce-ipsec-00.txt - CE route authentication (1 draft) and : http://www.ietf.org/internet-drafts/draft-behringer-mpls-vpn-auth-02.txt Jim ------=_NextPart_000_0039_01C31620.5D735570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable L3 VPN Work Item List ??
Paul,
 =20  

However, when I look at the work for the proposed = L3VPN WG, it=20 seems that there are four main areas:
-=20 2547bis   (5 drafts at least)
- = Virtual=20 Router (VR)  (3 drafts)
- CE-based = IPsec  (1=20 now, will be 3, with A.S. and MIB)  

also=20 add:

http://www.ietf.org/internet-drafts/draft-guichard-ce-ce-ipsec-00.t= xt

 
- CE route=20 authentication (1 draft)  

and=20 :

http://www.ietf.org/internet-drafts/draft-behringer-mpls-vpn-aut= h-02.txt 

Jim 

------=_NextPart_000_0039_01C31620.5D735570-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 11:57:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21112 for ; Fri, 9 May 2003 11:57:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49FxmP25701 for ; Fri, 9 May 2003 11:59:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49FxhZ18319 for ; Fri, 9 May 2003 11:59:44 -0400 (EDT) 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_01C31642.EB4FBE78" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Fri, 9 May 2003 10:51:56 -0500 Message-ID: <1DA3AEE851515549A5D2C5BD7F8FB2471FF2C6@PKDWB06C.ad.sprint.com> Thread-Topic: IMPORTANT: Strategy for VPN work in IETF Thread-Index: AcMWO4QmGcZ799BeRYSYQwo9xFCSPwABrZdw From: "Nagarajan, Ananth [NTWK SVCS]" To: , "Thomas Narten" Cc: "Alex Zinin" , X-OriginalArrivalTime: 09 May 2003 15:51:57.0385 (UTC) FILETIME=[EBA88B90:01C31642] X-SMTP-HELO: smtpgw5.sprintspectrum.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpgw5.sprintspectrum.com [207.40.188.13] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C31642.EB4FBE78 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think I agree with Jeremy here. After thinking about the proposed = split for some time, I realized that (as I said earlier) it would have = made more sense if this was done as soon as L2VPN/PWE3-related stuff was = brought into the WG. I also feel that there are several "generic" = documents, in addition to the ones I brought up on this thread some time = ago, and it will become increasingly complex to decide where those kind = of documents would fit. My preference is to schedule two sessions at Vienna, and spend some time = discussing this, before any decision is made. =20 PS: Another potential problem that would happen is having to subscribe = to both the l2 and l3 vpn mailing lists and getting duplicate emails = everytime a generic issue is discussed. Ananth > -----Original Message----- > From: jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > Sent: Friday, May 09, 2003 9:54 AM > To: Thomas Narten > Cc: Alex Zinin; ppvpn@nortelnetworks.com > Subject: Re: IMPORTANT: Strategy for VPN work in IETF >=20 >=20 > Hi Thomas, all, >=20 > > The chairs themselves seem to agree that there are some 13 documents > > on L3 that are not through the system yet. I'm a bit=20 > concerned to hear > > that there has been minimal discussion on L3 topics over the last > > year, given the number of L3 work items that apparently need to get > > completed. > >=20 > > The above could be read as indicating that the discussion/urgency of > > the L2 work is pushing out or drowning out discussion on L3=20 > topics. If > > that is the case, a separate WG, mailing list, etc., may well help. > > I'm assuming the L3 work is important and should get completed. >=20 > I believe that it can also be read as indicating that many feel that > most of the (current) L3VPN work is stable and agreed upon,=20 > and doesn't > need more discussion within the WG. As was already hinted previously, > the progress of the L3VPN work has been delayed (for a long time) > because the framework and requirements documents needed to be accepted > first. >=20 > I do believe however that several proposed new working items (QoS, > security, management, multicast, etc.) have received little attention > from the WG because of the current L2VPN (VPLS)=20 > discussions/urgency. But > as many of these are aimed at both L2 and L3VPNs, and as I don't find > reference to these items in the proposed charters, I=20 > understand that the > goal of the proposed split is not to accomodate these. >=20 > On one hand, I believe that the idea of two separate WGs is a=20 > good one, > but on the other hand, I'm not sure how much it will help=20 > now, so far in > the process. >=20 > I also personally believe that the PPVPN WG has produced valuable > results, and is making progress on complex topics every day=20 > (look at the > current IEEE vs VPLS discussions on this list). And this despite the > fact that the 'market' is not waiting and despite the fact that the > number of interested individuals (from different backgrounds: SPs, > vendors, academic and other standard bodies) is very large. >=20 > Jeremy. >=20 >=20 >=20 ------_=_NextPart_001_01C31642.EB4FBE78 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IMPORTANT: Strategy for VPN work in IETF

I think I agree with Jeremy here.  After thinking = about the proposed split for some time, I realized that (as I said = earlier) it would have made more sense if this was done as soon as = L2VPN/PWE3-related stuff was brought into the WG.  I also feel that = there are several "generic" documents, in addition to the ones = I brought up on this thread some time ago, and it will become = increasingly complex to decide where those kind of documents would = fit.

My preference is to schedule two sessions at Vienna, = and spend some time discussing this, before any decision is made.  =

PS: Another potential problem that would happen is = having to subscribe to both the l2 and l3 vpn mailing lists and getting = duplicate emails everytime a generic issue is discussed.

Ananth

> -----Original Message-----
> From: jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcat= el.be]
> Sent: Friday, May 09, 2003 9:54 AM
> To: Thomas Narten
> Cc: Alex Zinin; ppvpn@nortelnetworks.com
> Subject: Re: IMPORTANT: Strategy for VPN work in = IETF
>
>
> Hi Thomas, all,
>
> > The chairs themselves seem to agree that = there are some 13 documents
> > on L3 that are not through the system yet. = I'm a bit
> concerned to hear
> > that there has been minimal discussion on = L3 topics over the last
> > year, given the number of L3 work items = that apparently need to get
> > completed.
> >
> > The above could be read as indicating that = the discussion/urgency of
> > the L2 work is pushing out or drowning out = discussion on L3
> topics. If
> > that is the case, a separate WG, mailing = list, etc., may well help.
> > I'm assuming the L3 work is important and = should get completed.
>
> I believe that it can also be read as indicating = that many feel that
> most of the (current) L3VPN work is stable and = agreed upon,
> and doesn't
> need more discussion within the WG. As was = already hinted previously,
> the progress of the L3VPN work has been delayed = (for a long time)
> because the framework and requirements documents = needed to be accepted
> first.
>
> I do believe however that several proposed new = working items (QoS,
> security, management, multicast, etc.) have = received little attention
> from the WG because of the current L2VPN (VPLS) =
> discussions/urgency. But
> as many of these are aimed at both L2 and = L3VPNs, and as I don't find
> reference to these items in the proposed = charters, I
> understand that the
> goal of the proposed split is not to accomodate = these.
>
> On one hand, I believe that the idea of two = separate WGs is a
> good one,
> but on the other hand, I'm not sure how much it = will help
> now, so far in
> the process.
>
> I also personally believe that the PPVPN WG has = produced valuable
> results, and is making progress on complex = topics every day
> (look at the
> current IEEE vs VPLS discussions on this list). = And this despite the
> fact that the 'market' is not waiting and = despite the fact that the
> number of interested individuals (from different = backgrounds: SPs,
> vendors, academic and other standard bodies) is = very large.
>
> Jeremy.
>
>
>

------_=_NextPart_001_01C31642.EB4FBE78-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 12:48:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22651 for ; Fri, 9 May 2003 12:48:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49GpNP25454 for ; Fri, 9 May 2003 12:51:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49GpIv07044 for ; Fri, 9 May 2003 12:51:19 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6065C68A8@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Alex Zinin'" , "'PPVPN@nortelnetworks.com'" Subject: RE: Draft charter for L3VPN Date: Fri, 9 May 2003 12:48:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3164A.DC6A4E72" X-LYRIS-Message-Id: 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_01C3164A.DC6A4E72 Content-Type: text/plain Alex, Now we are really playing games! In your previous email, you mentioned that there has not been any decision to split the PPVPN WG - but now you are sending charters. In my view, this is an irresponsible handling of the proposal as the community has not generally endorsed the proposed split of the WG. I interpret this as a disregard to the PPVPN WG wishes and a misuse/abuse of you AD position. Bilel. -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, May 07, 2003 9:52 PM To: PPVPN@nortelnetworks.com Subject: Draft charter for L3VPN Folks- It is taking longer than I anticipated to set up the mailing lists, so I am sending the proposed WG charters to this list. These are _drafts_, so are likely to need more fine-tuning. Below is the proposed charter for L3VPN. The one on L2VPN is in a separate message. Comments welcome. -- Alex Layer 3 Virtual Private Networks (l3vpn) Chair(s): Area Director(s): Thomas Narten Erik Nordmark Area Advisor: Thomas Narten Technical Advisor: Alex Zinin Description of Working Group: This working group is responsible for defining and specifying a limited number of solutions for supporting Layer-3 (routed) Virtual Private Networks (L3VPNs). The WG is responsible for standardization of the following solutions: 1. BGP/MPLS IP VPNs (based on RFC 2547) 2. IP VPNs using Virtual Routers 3. CE-based VPNs using IPSEC As part of this effort the WG will work on the following tasks (additional work items will require rechartering): 1. Requirements and framework for Layer 3 VPNs 2. Solution documents for each approach listed above (including applicability statements) 3. MIB definitions for each approach 4. Security mechanisms for each approach Multicast support and Inter-AS considerations are excluded from the charter at this time. They may be considered for inclusion in an updated charter at a later time. Future work items may also include OAM support. As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. WG Milestones (optimistic): Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info (completed) Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info (completed) Aug 2003 Submit L3 VPN Security Analysis to IESG for publication as Info (draft-fang-ppvpn-security-framework-00) Aug 2003 Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01) Sep 2003 Submit CE-based specification and AS to IESG for publication as PS (draft-ietf-ppvpn-ce-based-03) Sep 2003 Submit Virtual Router specification and AS to IESG for publication as PS (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) Oct 2003 Submit VPN MIB Textual Conventions to IESG for publication as PS (draft-ietf-ppvpn-tc-mib-02) Oct 2003 Submit MPLS BGP MIB to IESG for publication as PS (draft-ietf-ppvpn-mpls-vpn-mib-05) Oct 2003 Submit VR MIB to IESG for publication as PS (draft-ietf-ppvpn-vr-mib-04) Dec 2003 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-ipsec-2547-03) Jan 2003 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-gre-ip-2547-02) Jan 2003 Submit specification of CE Route Authentication to IESG for publication as PS (draft-ietf-ppvpn-l3vpn-auth-03) ------_=_NextPart_001_01C3164A.DC6A4E72 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft charter for L3VPN

Alex,

Now we are really playing games! In your previous = email, you mentioned that there has not been any decision to split the = PPVPN WG - but now you are sending charters. In my view, this is an = irresponsible handling of the proposal as the community has not = generally endorsed the proposed split of the WG. I interpret this as a = disregard to the PPVPN WG wishes and a misuse/abuse of you AD = position.

Bilel.



-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Wednesday, May 07, 2003 9:52 PM
To: PPVPN@nortelnetworks.com
Subject: Draft charter for L3VPN


Folks-

It is taking longer than I anticipated to set up the = mailing lists, so I am sending the proposed WG charters to this list. = These are _drafts_, so are likely to need more fine-tuning. Below is = the proposed charter for L3VPN. The one on L2VPN is in a separate = message. Comments welcome.

--
Alex

Layer 3 Virtual Private Networks (l3vpn)

Chair(s): <under discussion>

Area Director(s):
   Thomas Narten = <narten@us.ibm.com>
   Erik Nordmark = <nordmark@sun.com>

Area Advisor:
   Thomas Narten = <narten@us.ibm.com>

Technical Advisor:
   Alex Zinin <zinin@psg.com>

Description of Working Group:

This working group is responsible for defining and = specifying a limited number of solutions for supporting Layer-3 = (routed) Virtual Private Networks (L3VPNs).

The WG is responsible for standardization of the = following solutions:

   1. BGP/MPLS IP VPNs (based on RFC = 2547)
   2. IP VPNs using Virtual Routers
   3. CE-based VPNs using IPSEC

As part of this effort the WG will work on the = following tasks (additional work items will require = rechartering):

   1. Requirements and framework for Layer = 3 VPNs
   2. Solution documents for each approach = listed above (including
      applicability = statements)
   3. MIB definitions for each = approach
   4. Security mechanisms for each = approach

Multicast support and Inter-AS considerations are = excluded from the charter
at this time. They may be considered for inclusion = in an updated charter
at a later time. Future work items may also include = OAM support.

As a general rule, the WG will not create new = protocols, but will provide
functional requirements for extensions of the = existing protocols that will
be discussed in the protocol-specific WGs.

WG Milestones (optimistic):

Dec 2002 Submit L3 VPN Requirements Document to IESG = for publication as Info
         = (completed)
Dec 2002 Submit L3 VPN Framework Document to IESG = for publication as Info
         = (completed)
Aug 2003 Submit L3 VPN Security Analysis to IESG for = publication as Info
         = (draft-fang-ppvpn-security-framework-00)
Aug 2003 Submit BGP/MPLS VPNs specification and AS = to IESG for publication as PS
         = (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)

Sep 2003 Submit CE-based specification and AS to IESG = for publication as PS
         = (draft-ietf-ppvpn-ce-based-03)
Sep 2003 Submit Virtual Router specification and AS = to IESG for publication as PS
         = (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) Oct 2003 Submit = VPN MIB Textual Conventions to IESG for publication as PS

         = (draft-ietf-ppvpn-tc-mib-02)
Oct 2003 Submit MPLS BGP MIB to IESG for publication = as PS
         = (draft-ietf-ppvpn-mpls-vpn-mib-05)
Oct 2003 Submit VR MIB to IESG for publication as = PS
         = (draft-ietf-ppvpn-vr-mib-04)

Dec 2003 Submit specification of using IPSEC for = PE-PE encapsulation in BGP/MPLS VPNs to IESG
         for = publication as PS
         = (draft-ietf-ppvpn-ipsec-2547-03)
Jan 2003 Submit specification of using GRE for PE-PE = encapsulation in BGP/MPLS VPNs to IESG
         for = publication as PS
         = (draft-ietf-ppvpn-gre-ip-2547-02)

Jan 2003 Submit specification of CE Route = Authentication to IESG for publication as PS
         = (draft-ietf-ppvpn-l3vpn-auth-03)


------_=_NextPart_001_01C3164A.DC6A4E72-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 13:01:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23212 for ; Fri, 9 May 2003 13:01:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49H3sP11135 for ; Fri, 9 May 2003 13:03:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49H3oL05740 for ; Fri, 9 May 2003 13:03:50 -0400 (EDT) Date: Fri, 9 May 2003 09:58:12 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <126225268148.20030509095812@psg.com> To: "Bilel Jamoussi" CC: "'PPVPN@nortelnetworks.com'" Subject: Re: Draft charter for L3VPN In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6065C68A8@zcard0ke.ca.nortel.com> References: <0D7FC1D8D861D511AEA70002A52CE5E6065C68A8@zcard0ke.ca.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: jamoussi@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bilel, Try to not think that conspiracy is everywhere, for a change, please. I promised to send proposed charters from the very beginning, plus several people asked for them explicitly. One needs to see the proposed charters to decide if the split makes sense. -- Alex http://www.psg.com/~zinin/ Friday, May 9, 2003, 9:48:48 AM, Bilel Jamoussi wrote: > Alex, > Now we are really playing games! In your previous email, you mentioned that > there has not been any decision to split the PPVPN WG - but now you are > sending charters. In my view, this is an irresponsible handling of the > proposal as the community has not generally endorsed the proposed split of > the WG. I interpret this as a disregard to the PPVPN WG wishes and a > misuse/abuse of you AD position. > Bilel. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 13:07:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23445 for ; Fri, 9 May 2003 13:07:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49HA1P15537 for ; Fri, 9 May 2003 13:10:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49H9tL27409 for ; Fri, 9 May 2003 13:09:56 -0400 (EDT) Date: Fri, 9 May 2003 10:04:49 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <150225665609.20030509100449@psg.com> To: "Hamid Ould-Brahim" CC: PPVPN@nortelnetworks.com, richard.spencer@bt.com, yakov@juniper.net Subject: Re: Single vs many solution(s) In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hamid, >> So, from this perspective, the framework MAY very easily look >> like this (mechanism == protocol or protocol extension): >> >> Data-plane : mechanism A >> Intra-domain discovery : mechanism B >> Intra-domain signaling : mechanism C >> Inter-domain discovery : mechanism D >> Inter-domain signaling : mechanism C++ > Your proposal doesn't preclude the case where > a given protocol is used to implement > mechanisms B, C and D if we assume that > mechanism == protocol extension. Well, this is not really a proposal, just an example of how the framework MAY look, so don't read too much into what it precludes or does not preclude. >> Data-plane : mechanism A, or B, or C >> Intra-domain discovery : mechanism D, or E, or F >> Intra-domain signaling : mechanism G, or H, or I >> Inter-domain discovery : mechanism J, or K, or L >> Inter-domain signaling : mechanism M, or N, or O >> >> This would, in view, impact interoperability. > That sounds logic, but is it really that simple? Consider this > example, a protocol "x" made a choice "a" of a particular extension > for solving a given l2vpn problem, and later on it happens that "a" > doesn't cover exactly the set of scenarios the wg needs to look at, > and another choice "b" is proposed for the same problem and > piggybacked on the same protocol "x" ("b" makes the 'architectural > glue' mentioned above more likely to happen). > In your opinion what should the wg do? Pick only one option (a or > b), or incorporate the two options on the same protocol "x"? > I hope your answer will not include something like 'it depends...' > :-). I am afraid it will be :) It's just too abstract to give any reasonable answer. To clarify my point above again, I'll give you an example--I think that we don't need more than one Standard discovery mechanism for the intra-domain scenario. That's the only meaning behind comparing things like "B" vs "D || E || F". Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 13:30:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24034 for ; Fri, 9 May 2003 13:30:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49HWmP22782 for ; Fri, 9 May 2003 13:32:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49HWhs25159 for ; Fri, 9 May 2003 13:32:43 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6065C6938@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Alex Zinin'" Cc: "'PPVPN@nortelnetworks.com'" Subject: RE: Draft charter for L3VPN Date: Fri, 9 May 2003 13:30:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31650.AF89866A" X-LYRIS-Message-Id: 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_01C31650.AF89866A Content-Type: text/plain Alex, "conspiracy" is your word not mine. I used mismanagement and causing trouble to a WG by its AD without articulating the problem statement or following any rules. Bilel. -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Friday, May 09, 2003 12:58 PM To: Jamoussi, Bilel [BL60:1A00:EXCH] Cc: 'PPVPN@nortelnetworks.com' Subject: Re: Draft charter for L3VPN Bilel, Try to not think that conspiracy is everywhere, for a change, please. I promised to send proposed charters from the very beginning, plus several people asked for them explicitly. One needs to see the proposed charters to decide if the split makes sense. -- Alex http://www.psg.com/~zinin/ Friday, May 9, 2003, 9:48:48 AM, Bilel Jamoussi wrote: > Alex, > Now we are really playing games! In your previous email, you mentioned > that there has not been any decision to split the PPVPN WG - but now > you are sending charters. In my view, this is an irresponsible > handling of the proposal as the community has not generally endorsed > the proposed split of the WG. I interpret this as a disregard to the > PPVPN WG wishes and a misuse/abuse of you AD position. > Bilel. ------_=_NextPart_001_01C31650.AF89866A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft charter for L3VPN

Alex, "conspiracy" is your word not mine. I = used mismanagement and causing trouble to a WG by its AD without = articulating the problem statement or following any rules.

Bilel.

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Friday, May 09, 2003 12:58 PM
To: Jamoussi, Bilel [BL60:1A00:EXCH]
Cc: 'PPVPN@nortelnetworks.com'
Subject: Re: Draft charter for L3VPN


Bilel,

 Try to not think that conspiracy is everywhere, = for a change, please.

 I promised to send proposed charters from the = very beginning, plus  several people asked for them explicitly. = One needs to see the  proposed charters to decide if the split = makes sense.

--
Alex
http://www.psg.com/~zinin/

Friday, May 9, 2003, 9:48:48 AM, Bilel Jamoussi = wrote:
> Alex,

> Now we are really playing games! In your = previous email, you mentioned
> that there has not been any decision to split = the PPVPN WG - but now
> you are sending charters. In my view, this is = an irresponsible
> handling of the proposal as the community has = not generally endorsed
> the proposed split of the WG. I interpret this = as a disregard to the
> PPVPN WG wishes and a misuse/abuse of you AD = position.

> Bilel.

------_=_NextPart_001_01C31650.AF89866A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 13:36:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24243 for ; Fri, 9 May 2003 13:36:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49HcYP27351 for ; Fri, 9 May 2003 13:38:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49HcUs02314 for ; Fri, 9 May 2003 13:38:31 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6065C6948@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Alex Zinin'" , "Marco Carugi" Cc: "'PPVPN@nortelnetworks.com'" Subject: RE: Strategy for VPN work in IETF Date: Fri, 9 May 2003 13:34:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31651.300822EC" X-LYRIS-Message-Id: 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_01C31651.300822EC Content-Type: text/plain Alex, Marco brought up several troublesome points on how this is being handled that should be addressed in the open. If you prefer to resolve them one on one - we need to know the outcome - How is this discussion progressing? Bilel. -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, May 07, 2003 7:42 PM To: Carugi, Marco [CTF:0000:EXCH] Cc: PPVPN@nortelnetworks.com Subject: Re: Strategy for VPN work in IETF Marco, I'll take this off the list. -- Alex Tuesday, May 6, 2003, 12:55:29 PM, Marco Carugi wrote: > Alex, > I had promised myself to keep quiet for a while on this topic and > respectfully listening to the list. Reading some assertions, I cannot > anymore. > Looking after the best interest of the WG and having worked so hard to > create it time ago. > Inline, Marco ------_=_NextPart_001_01C31651.300822EC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strategy for VPN work in IETF

Alex,

Marco brought up several troublesome points on how = this is being handled that should be addressed in the open. If you = prefer to resolve them one on one - we need to know the outcome - How = is this discussion progressing?

Bilel.

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Wednesday, May 07, 2003 7:42 PM
To: Carugi, Marco [CTF:0000:EXCH]
Cc: PPVPN@nortelnetworks.com
Subject: Re: Strategy for VPN work in IETF


Marco,

 I'll take this off the list.

--
Alex

Tuesday, May 6, 2003, 12:55:29 PM, Marco Carugi = wrote:
> Alex,

> I had promised myself to keep quiet for a while = on this topic and
> respectfully listening to the list. Reading = some assertions, I cannot
> anymore.

> Looking after the best interest of the WG and = having worked so hard to
> create it time ago.

> Inline, Marco


------_=_NextPart_001_01C31651.300822EC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 13:40:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24346 for ; Fri, 9 May 2003 13:40:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49HgTP01285 for ; Fri, 9 May 2003 13:42:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49HgOs07165 for ; Fri, 9 May 2003 13:42:24 -0400 (EDT) Date: Fri, 9 May 2003 10:35:19 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <35227495461.20030509103519@psg.com> To: "Paul Knight" CC: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin Subject: Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> References: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi, Paul, > The proposed split seems to put very little emphasis on the "PP" of PPVPN. > The proposed focus on technologies for L2 and L3 is likely to seriously > disrupt the focus on the "Provider Provisioned" concept, where much of the > value comes from aiming for interoperation across all major VPN > technologies. Of course, we could have PPL2VPN and PPL3VPN, but as has been > pointed out, we then need to coordinate the "PP" parts across the two WGs. I think before we go and talk about interoperation across all major VPN technologies, we should first make visible progress on those technologies, which focused technology specific WGs are aimed to help. Regarding coordination--totally agree, we will indeed need to coordinate, we actually have an idea for this--create a PPVPN directorate that will ensure such close coordination. > VPN customers want a bundle of VPN services, and don't really care whether > it is L2 or L3 (or L1) or some mixture. VPN service providers want an > interoperable toolkit which they can use to design services that they can > differentiate in various ways to attract VPN customers. PPVPN is providing a > forum to define the operation of the VPN tools. Regardless of L2 or L3 > technologies, there is a need for simple and interoperable mechanisms for > VPN membership and discovery, security considerations, SLA verification, and > a host of management areas. These mechanisms are being defined, clarified, > and debated in PPVPN mostly without regard to the specific L2 or L3 > approaches. They should not be either dropped, or split across two WGs. I don't think anyone suggests to drop those. First, we are not splitting the community, only the WGs as organizational entities to help scaling the management part of the process. People should still talk to each other and discuss those. If folks believe something common for both WGs needs to be worked on, we'll put it in one of the WGs and will inform the other. Occasionally we can even have joint meetings, which happens in the IETF. It seems to me that at this moment, technology-specific work items should be high priority. Most of those pieces are not through the system yet. > Yes there is a lot of work in the group, but if it gets fragmented and > things slip through the cracks, then we will be forcing the VPN service > providers, vendors, and customers to do much more work and spend much more > time in the long run. > In terms of meeting logistics, we will find that many of the same people > will be attending and developing drafts for the proposed L2 and L3 WGs, so > we will have to make sure that they don't overlap... Just the same as if we > plan extended meeting times for the current PPVPN when it is needed. Same people attending different WGs is perfectly fine, this is a normal situation in the IETF (examples: RTG WGs, CCAMP and MPLS). Scheduling-wise, +1 WG is not going to make a big difference. > Finally, I'm closely involved with two areas of work in L3 VPNs in PPVPN, > and we are getting to the point where much of the basic work is stable, so > the L3VPN may not justify a dedicated WG for much longer, although it does > need a WG in which to operate. Lack of "heated" discussions does not mean everything is done. There are items that just need consistent attention and concentration of the participants to be finished, such as security or MIBs. There is also more stuff coming in the L3 space. > I would suggest planning for a longer meeting in Vienna (if the agenda > justifies it) and bringing this proposal up for discussion there. Noted. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 14:09:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25281 for ; Fri, 9 May 2003 14:09:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49IBlP03410 for ; Fri, 9 May 2003 14:11:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49IBhN08630 for ; Fri, 9 May 2003 14:11:44 -0400 (EDT) Date: Fri, 9 May 2003 11:01:25 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <85229060892.20030509110125@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- Regarding inter-AS and inter-provide. Small clarification: the proposal is not to move it outside the charter completely, but to clarify what the WG would be doing first and what next, i.e., make visible progress on basic things and then move to more complex scenarios. Now, having read postings from everyone, it seems that the agreement is (correct me if I'm mistaken) that inter-provider is better put as a future item for now. Regarding inter-AS single provider, I have a couple of questions: 1. Jim Guichard said: > 2. Is complexity associated with inter-AS (1 provider) scenarios > sufficiently higher than for the single-AS case? potentially yes for the same reasons as (1). Jim Two reasons have been brought in (1): a) different encaps for 2547 (MPLS/GRE) b) provisioning end-to-end LSP is more complex in the multi-AS case It seems that this may indeed complicate the mechanisms. I'd love to see a little more discussion on this. 2. Are we going to need additional documents compared to what we already have in order to describe inter-AS scenarios appropriately? If yes, I'd rather say one-AS first, then multi-AS single provider, and then multi-provider. Regards. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 14:47:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26897 for ; Fri, 9 May 2003 14:47:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49InbP14045 for ; Fri, 9 May 2003 14:49:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49InYl14800 for ; Fri, 9 May 2003 14:49:34 -0400 (EDT) Date: Fri, 9 May 2003 11:43:00 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <164231555899.20030509114300@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: protocol-specific work In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On the following part of the proposed charter: > As a general rule, the WG will not create new protocols, but will provide > functional requirements for extensions of the existing protocols that will > be discussed in the protocol-specific WGs. we had the following: Robert wrote: > That is even biggest evil making essentially as ppvpn this new WG > useless :).Without at least ability to propose extensions to protocols > submitting any serious draft is pointless. If I have to write > requirements for myself and submit a solution in IDR I would just go for > the latter immediately. Also note that this line is outside of reality > of work done in vast majority of all drafts in ppvpn WG. I do hope that > this line will also be removed therefor making the ppvnp split really > useful in practice Rahul wrote: > I very strongly second Robert's opinion. Time and again the procedure of > defining protocol extensions in PPVPN comes up. And every time the reality > is ignored. How about the following: > "The WG may propose extensions to existing protocols and such > extensions will be discussed and reviewed by the protocol-specific WG." > > The question than is: Should a document submitted to the current PPVPN WG > (or the new groups if the split happens) be accepted as a WG doc before > the protocol specific WG reviews protocol extensions (if any) ? I think we > need more discussion on this. There are cases where it makes sense to have > such a review before accepting the doc as a WG doc and there are cases > where it doesn't. Eric wrote: > I happen to like this sort of restriction, because it helps to prevent a > situation in which every proposal includes an extension that is entirely > optimized for that proposal. Here's my take on this: 1. I think I (and the IESG in this case too) would not be comfortable with a general approach of extensions to protocols that have corresponding WGs not owned by those WGs. Clearly, the expertise and the bigger picture of the development of a particular protocol is there. So, I think allowing the VPN WGs (or PPVPN) to develop and standardize protocol-specific extensions would not be realistic or fair to the protocol-specific WGs. 2. The text in the charter actually describes an existing situation--we do this in CCAMP--for instance, we have a generic routing document describing information that needs to be distributed and then we have protocol-specific documents that define encoding in that particular protocol. Not extremely effective from the CCAMP perspective, but quite fair if we take other WGs in consideration. 3. In reality, what we want to achieve is the VPN community being able to propose and document extensions to existing protocols that would help VPN technology development. Also, before a given mechanism goes forward, we need to make sure that: a. The VPN community believes that it serves the purpose and the right way forward AND b. The protocol-specific community believes that using the protocol is a good idea and the way this is done is correct. Given that finally the extension specs have to live in the protocol-specific WGs, ow about we use the following process (draft): 1. VPN folks who believe that a given protocol extension is needed, come up with an individual draft describing the details. 2. The draft is brought to the appropriate VPN WG. A discussion on the mailing list AND in the room is held on the subject of why this is needed and whether this is a good idea VPN-wise. If there is no agreement on this--the draft does not go any further. Otherwise: 3. The draft is taken to the protocol-specific WG. The WG discusses if it is happy with it as a general approach, if so takes it as a WG item. Otherwise, the WG chairs summarize the discussion and send the summary to the VPN WG. 4. If the draft is accepted by the protocol-specific WG, the appropriate VPN framework document is updated to describe it and refer to the doc. 5. The WG chairs coordinate timing for the draft. When ready to go to IESG, the draft is LC'ed in both WGs. Comments? Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 15:15:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28901 for ; Fri, 9 May 2003 15:15:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49JIOP05895 for ; Fri, 9 May 2003 15:18:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49JIKA11568 for ; Fri, 9 May 2003 15:18:21 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF05AF916C@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Jim Guichard Cc: ppvpn@nortelnetworks.com Subject: RE: L3 VPN Work Item List ?? Date: Fri, 9 May 2003 15:15:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3165F.64ADFB76" X-LYRIS-Message-Id: 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_01C3165F.64ADFB76 Content-Type: text/plain Jim, Thanks for helping complete the list. And my apologies for not including them... Regards, Paul -----Original Message----- From: Jim Guichard [mailto:jguichar@cisco.com] Sent: Friday, May 09, 2003 11:45 AM To: Knight, Paul [BL60:1A00:EXCH]; Thomas Narten Cc: Alex Zinin; ppvpn@nortelnetworks.com; Wijnen, Bert (Bert); Peterson, Jon; Allison Mankin Subject: RE: L3 VPN Work Item List ?? Paul, However, when I look at the work for the proposed L3VPN WG, it seems that there are four main areas: - 2547bis (5 drafts at least) - Virtual Router (VR) (3 drafts) - CE-based IPsec (1 now, will be 3, with A.S. and MIB) also add: http://www.ietf.org/internet-drafts/draft-guichard-ce-ce-ipsec-00.txt - CE route authentication (1 draft) and : http://www.ietf.org/internet-drafts/draft-behringer-mpls-vpn-auth-02.txt Jim ------_=_NextPart_001_01C3165F.64ADFB76 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: L3 VPN Work Item List ??

Jim,

Thanks for helping complete the list.  And my = apologies for not including them...

Regards,
Paul


-----Original Message-----
From: Jim Guichard [mailto:jguichar@cisco.com] =
Sent: Friday, May 09, 2003 11:45 AM
To: Knight, Paul [BL60:1A00:EXCH]; Thomas = Narten
Cc: Alex Zinin; ppvpn@nortelnetworks.com; Wijnen, = Bert (Bert); Peterson, Jon; Allison Mankin
Subject: RE: L3 VPN Work Item List ??


Paul,
  
However, when I look at the work for the proposed = L3VPN WG, it seems that there are four main areas:
- 2547bis   (5 drafts at least)
- Virtual Router (VR)  (3 drafts)
- CE-based IPsec  (1 now, will be 3, with A.S. = and MIB) 
also add:
http://www.ietf.org/internet-drafts/draft-guichard-ce-= ce-ipsec-00.txt

- CE route authentication (1 draft) 
and :
http://www.ietf.org/internet-drafts/draft-behringer-mp= ls-vpn-auth-02.txt
Jim

------_=_NextPart_001_01C3165F.64ADFB76-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 15:19:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29015 for ; Fri, 9 May 2003 15:19:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49JLrP09902 for ; Fri, 9 May 2003 15:21:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49JLnA16081 for ; Fri, 9 May 2003 15:21:49 -0400 (EDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 9 May 2003 12:18:20 -0700 (PDT) From: Kireeti Kompella To: Alex Zinin cc: ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: <51133594448.20030502191439@psg.com> Message-ID: <20030509114322.R57166@kummer.juniper.net> References: <51133594448.20030502191439@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hi Alex, On Fri, 2 May 2003, Alex Zinin wrote: > More specifically, below I tried to put together a list of concerns > I have about the approach described in draft-kompella-ppvpn-vpls, > that I would like the WG to consider. > > 1. Use of the NLRI field > > As an IP routing protocol, BGP uses the NLRI field to carry IP > reachability information in the form of IP prefixes. As an IP routing protocol, sure. But nowhere in RFC 2858 does it say that BGP has to only be an IP routing protocol. Furthermore, if BGP is used for L2 autodiscovery (which is by the way a PPVPN *Working Group* document), the exact same issue applies. > 2. Distribution of information > > When used as an IP routing protocol, BGP distributes routes among > all participating routers. For 2547, you have the same issue: BGP distributes routes among *all* participating routers, whereas only a few are really interested in them. So why is this an issue for VPLS but not for 2547? The distribution mechanisms are identical. > 3. Aggregation of information for large-scale operation Nowhere does 2858 talk about aggregation; in fact, the notion of aggregation is not even mentioned. -------------- On the issues of BGP for VPLS and also of single solution vs. multiple, there seems to me (I'm not a PPVPN WG chair!) good consensus that the WG wants a BGP solution, and also that they want multiple solutions. Are you, Alex, proposing to override that consensus? The call for consensus to make the various VPLS drafts WG documents was made over 3 weeks ago, and the call was supposed to last one week. We are thus two weeks overdue. I would like the WG chairs to declare what consensus they see, keeping in mind the email that Bert Wijnen (who is a seasoned Area Director) sent to the TE WG just today, saying: || But it is WG chair(s) who decide on how to gauge WG conensus. Or, from RFC 2418: 3.3. Session management Working groups make decisions through a "rough consensus" process. .... It is up to the Chair to determine if rough consensus has been reached. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 15:49:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29917 for ; Fri, 9 May 2003 15:49:09 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49JpZP18505 for ; Fri, 9 May 2003 15:51:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49JpWL07993 for ; Fri, 9 May 2003 15:51:33 -0400 (EDT) Date: Fri, 9 May 2003 12:45:41 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@u43 To: Alex Zinin Cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: <85229060892.20030509110125@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: prattle.redback.com X-SMTP-MAIL-FROM: rahul@redback.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: prattle.redback.com [155.53.12.9] X-LYRIS-Message-Id: Alex, Comments inline: On Fri, 9 May 2003, Alex Zinin wrote: > Folks- > > Regarding inter-AS and inter-provide. Small clarification: the > proposal is not to move it outside the charter completely, but > to clarify what the WG would be doing first and what next, i.e., > make visible progress on basic things and then move to more complex > scenarios. > > Now, having read postings from everyone, it seems that the agreement > is (correct me if I'm mistaken) that inter-provider is better > put as a future item for now. > > Regarding inter-AS single provider, I have a couple of questions: > > 1. Jim Guichard said: > > > 2. Is complexity associated with inter-AS (1 provider) scenarios > > sufficiently higher than for the single-AS case? > > potentially yes for the same reasons as (1). Jim > > Two reasons have been brought in (1): > > a) different encaps for 2547 (MPLS/GRE) There is no fundamental difference with regards to supporting different encaps in the single AS and inter-AS case. > b) provisioning end-to-end LSP is more complex in the multi-AS > case > > It seems that this may indeed complicate the mechanisms. > I'd love to see a little more discussion on this. 2547 describes the mechansims for inter-AS. IMHO they are well understood. Set up of a RSVP-TE inter-AS LSP is work in progress. However 2547 does not need any additional mechanisms for using a RSVP-TE inter-AS LSP between the end PEs. > > 2. Are we going to need additional documents compared to what we > already have in order to describe inter-AS scenarios > appropriately? Base mechanisms for implementing and deploying inter-AS are in place and are described in 2547. If yes, I'd rather say one-AS first, then multi-AS > single provider, and then multi-provider. > I would still say one-AS and multi-AS to begin with. Regards, rahul > Regards. > > Alex > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 15:56:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00124 for ; Fri, 9 May 2003 15:56:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49Jx7P24201 for ; Fri, 9 May 2003 15:59:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49Jx2L17300 for ; Fri, 9 May 2003 15:59:03 -0400 (EDT) Message-ID: <3EBC06ED.4060700@lucent.com> Date: Fri, 09 May 2003 15:52:13 -0400 From: Fabio Chiussi Organization: Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ppvpn@nortelnetworks.com Subject: Re: Draft charter for L3VPN: protocol-specific work Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: auemail2.firewall.lucent.com X-SMTP-MAIL-FROM: fabio@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: auemail2.lucent.com [192.11.223.163] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I am quite confused about the process that is being followed to deal with the issue of splitting the WG, so I would be grateful if somebody can clarify. First of all, it seems to me that a number of people have expressed some very valid concerns on the wisdom/need of a L2/L3 WG split. As far as I can tell (and I just spent a couple of hours re-reading the mailing list archive, to make sure that I had not missed some key messages), these concerns have not been addressed. Also, no strong rationale in support of the split has been presented. Indeed, on the mailing list, I was not able to find any indication of consensus being reached on the split and on the best way to split. It appears, therefore, that no decision has been reached. At this point, we could argue that it is even unclear what we are trying to fix and whether the proposed solution has a chance of fixing it. All this indicates that the issue of splitting the WG and how to split it (I am among those many people that just fail to see any strong reason in support of an L2/L3 split) needs, at a minimum, further and more formal discussion on the mailing list first, and then in person in Vienna. Instead of such a continuing debate, now we are already seeing charters for the new WGs, and discussions on the details of those charters. Given the implications of the decision to split (this is more than a WG recharter, since it also changes the organization of existing and future work), why is this handled this way, by de-facto implying decisions that have not been reached through consensus? Fabio Chiussi From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 16:55:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01932 for ; Fri, 9 May 2003 16:55:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49KvYP27422 for ; Fri, 9 May 2003 16:57:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49KvUT26739 for ; Fri, 9 May 2003 16:57:31 -0400 (EDT) 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="us-ascii" Subject: RE: On BGP and VPLS Date: Fri, 9 May 2003 16:55:08 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C46D@m-va-bsod03.add0.masergy.com> Thread-Topic: On BGP and VPLS thread-index: AcMWYBgPkPajETDERSqmp6CY5JcvwwADHR5Q From: "Rick Wilder" To: "Kireeti Kompella" , "Alex Zinin" Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA01932 Kireeti, Regarding the last part of your message, the working group chairs have been asked to hold off of declarations of consensus on drafts in the wake of discussions of re-organizing (ie. splitting) of the group. Rick -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, May 09, 2003 3:18 PM To: Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS Hi Alex, On Fri, 2 May 2003, Alex Zinin wrote: > More specifically, below I tried to put together a list of concerns > I have about the approach described in draft-kompella-ppvpn-vpls, > that I would like the WG to consider. > > 1. Use of the NLRI field > > As an IP routing protocol, BGP uses the NLRI field to carry IP > reachability information in the form of IP prefixes. As an IP routing protocol, sure. But nowhere in RFC 2858 does it say that BGP has to only be an IP routing protocol. Furthermore, if BGP is used for L2 autodiscovery (which is by the way a PPVPN *Working Group* document), the exact same issue applies. > 2. Distribution of information > > When used as an IP routing protocol, BGP distributes routes among > all participating routers. For 2547, you have the same issue: BGP distributes routes among *all* participating routers, whereas only a few are really interested in them. So why is this an issue for VPLS but not for 2547? The distribution mechanisms are identical. > 3. Aggregation of information for large-scale operation Nowhere does 2858 talk about aggregation; in fact, the notion of aggregation is not even mentioned. -------------- On the issues of BGP for VPLS and also of single solution vs. multiple, there seems to me (I'm not a PPVPN WG chair!) good consensus that the WG wants a BGP solution, and also that they want multiple solutions. Are you, Alex, proposing to override that consensus? The call for consensus to make the various VPLS drafts WG documents was made over 3 weeks ago, and the call was supposed to last one week. We are thus two weeks overdue. I would like the WG chairs to declare what consensus they see, keeping in mind the email that Bert Wijnen (who is a seasoned Area Director) sent to the TE WG just today, saying: || But it is WG chair(s) who decide on how to gauge WG conensus. Or, from RFC 2418: 3.3. Session management Working groups make decisions through a "rough consensus" process. .... It is up to the Chair to determine if rough consensus has been reached. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 17:34:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03177 for ; Fri, 9 May 2003 17:34:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49LbEP17832 for ; Fri, 9 May 2003 17:37:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49Lb9K05505 for ; Fri, 9 May 2003 17:37:10 -0400 (EDT) Date: Fri, 9 May 2003 14:25:34 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <61241310626.20030509142534@psg.com> To: Fabio Chiussi CC: ppvpn@nortelnetworks.com Subject: WG split: why and how? In-Reply-To: <3EBC06ED.4060700@lucent.com> References: <3EBC06ED.4060700@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Fabio, /* Please, don't confuse the subject lines--this does not help * discussion management. I changed it accordingly. */ Seems that indeed some clarifications might be useful. I will get back to the list with a message on this today. Cheers. -- Alex http://www.psg.com/~zinin/ Friday, May 9, 2003, 12:52:13 PM, Fabio Chiussi wrote: > I am quite confused about the process that is being followed to deal > with the issue of splitting the WG, so I would be grateful if somebody > can clarify. > First of all, it seems to me that a number of people have expressed some > very valid concerns on the wisdom/need of a L2/L3 WG split. As far as I > can tell (and I just spent a couple of hours re-reading the mailing list > archive, to make sure that I had not missed some key messages), these > concerns have not been addressed. Also, no strong rationale in support > of the split has been presented. > Indeed, on the mailing list, I was not able to find any indication of > consensus being reached on the split and on the best way to split. It > appears, therefore, that no decision has been reached. At this point, we > could argue that it is even unclear what we are trying to fix and > whether the proposed solution has a chance of fixing it. > All this indicates that the issue of splitting the WG and how to split > it (I am among those many people that just fail to see any strong reason > in support of an L2/L3 split) needs, at a minimum, further and more > formal discussion on the mailing list first, and then in person in Vienna. > Instead of such a continuing debate, now we are already seeing charters > for the new WGs, and discussions on the details of those charters. Given > the implications of the decision to split (this is more than a WG > recharter, since it also changes the organization of existing and future > work), why is this handled this way, by de-facto implying decisions that > have not been reached through consensus? > Fabio Chiussi From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 17:37:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03277 for ; Fri, 9 May 2003 17:37:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49LdrP20774 for ; Fri, 9 May 2003 17:39:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49LdoK08811 for ; Fri, 9 May 2003 17:39:51 -0400 (EDT) Date: Fri, 9 May 2003 14:36:57 -0700 (PDT) From: Kireeti Kompella Message-Id: <200305092136.h49Lav758256@kummer.juniper.net> To: kireeti@juniper.net, rwilder@masergy.com, zinin@psg.com Subject: RE: On BGP and VPLS Cc: ppvpn@nortelnetworks.com In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C46D@m-va-bsod03.add0.masergy.com> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hi Rick, > Regarding the last part of your message, the working group chairs have > been asked to hold off of declarations of consensus on drafts in the > wake of discussions of re-organizing (ie. splitting) of the group. What's the rationale for holding off declarations of consensus? This decision is two weeks overdue, and the split (if it happens) could take several more weeks. It would be a complete travesty if a simple consensus call took weeks but a major decision like a split of the WG was completed in a hurry -- for one, it would suggest that the split was preordained, and not a joint WG decision, a point that Bilel was seeking clarification on. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 17:48:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03793 for ; Fri, 9 May 2003 17:48:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49LoSP25292 for ; Fri, 9 May 2003 17:50:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49LoNK17702 for ; Fri, 9 May 2003 17:50:24 -0400 (EDT) Date: Fri, 9 May 2003 14:45:34 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <84242510191.20030509144534@psg.com> To: Kireeti Kompella CC: rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: <200305092136.h49Lav758256@kummer.juniper.net> References: <200305092136.h49Lav758256@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Kireeti, The two things (declaration of consensus and split-related discussions) are not related. I asked the chairs to hold this off until we chat about it over the phone to make sure we are in sync. Seems that we should be able to come back on Monday. -- Alex Friday, May 9, 2003, 2:36:57 PM, Kireeti Kompella wrote: > Hi Rick, >> Regarding the last part of your message, the working group chairs have >> been asked to hold off of declarations of consensus on drafts in the >> wake of discussions of re-organizing (ie. splitting) of the group. > What's the rationale for holding off declarations of consensus? This > decision is two weeks overdue, and the split (if it happens) could take > several more weeks. > It would be a complete travesty if a simple consensus call took weeks > but a major decision like a split of the WG was completed in a hurry -- > for one, it would suggest that the split was preordained, and not a > joint WG decision, a point that Bilel was seeking clarification on. > Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 17:52:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03952 for ; Fri, 9 May 2003 17:52:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49LsiP29150 for ; Fri, 9 May 2003 17:54:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49LseK23080 for ; Fri, 9 May 2003 17:54:40 -0400 (EDT) Date: Fri, 9 May 2003 14:48:51 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <38242706773.20030509144851@psg.com> To: Kireeti Kompella CC: ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: <20030509114322.R57166@kummer.juniper.net> References: <51133594448.20030502191439@psg.com> <20030509114322.R57166@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Kireeti! [2858 related discussion] I'll leave it to the WG participants to discuss this issue further. My goal was to bring my concerns and attract attention to them. Just one point for this discussion: 2858 says: > This document defines extensions to BGP-4 to > enable it to carry routing information for multiple Network Layer > protocols (e.g., IPv6, IPX, etc...) Note the "Network Layer" part. The contents of the doc is also in terms of Network Layer addresses and routes. In no place does it imply that NLRI can be used to distribute arbitrary information. > On the issues of BGP for VPLS and also of single solution vs. multiple, > there seems to me (I'm not a PPVPN WG chair!) good consensus that the > WG wants a BGP solution, and also that they want multiple solutions. > Are you, Alex, proposing to override that consensus? First, as you correctly said, consensus is to be determined by the WG chairs, so leave it to them, please. Second, I do not believe that any initiation of or participation in a discussion by ADs should be considered as overriding any consensus. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 18:11:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05235 for ; Fri, 9 May 2003 18:11:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49MDYP22520 for ; Fri, 9 May 2003 18:13:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49MDUq05021 for ; Fri, 9 May 2003 18:13:30 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF05AF945C@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Alex Zinin , PPVPN@nortelnetworks.com Subject: RE: Draft charter for L3VPN: protocol-specific work Date: Fri, 9 May 2003 18:10:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31677.D8577D3C" X-LYRIS-Message-Id: 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_01C31677.D8577D3C Content-Type: text/plain Hi Alex, To go into the weekend on a positive note, this looks like a pretty reasonable approach for protocol extensions (whether or not there is a WG split). However, in the interest of saving time in the meetings, perhaps there should be some provision for allowing consensus on a proposed protocol extension to be reached just on the mailing list, so we don't require a presentation and discussion of each one in the meeting. Maybe there could be a slide with a list of the "pre-approved" extensions in the meeting, so any last-minute objections from people not following the mailing list can be heard. Also, are there gray areas in the definition of "protocol extensions" ? I'm assuming that this procedure would apply to: - New attributes - New message types, payload types, type codes - New enumerated values in existing attributes or protocol messages - ? Regards, Paul > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Friday, May 09, 2003 2:43 PM > To: PPVPN@nortelnetworks.com > Subject: Re: Draft charter for L3VPN: protocol-specific work > > > > On the following part of the proposed charter: > > > As a general rule, the WG will not create new protocols, but will > > provide functional requirements for extensions of the existing > > protocols that will be discussed in the protocol-specific WGs. > > we had the following: > > Robert wrote: > > That is even biggest evil making essentially as ppvpn this new WG > > useless :).Without at least ability to propose > extensions to protocols > > submitting any serious draft is pointless. If I have to write > > requirements for myself and submit a solution in IDR I > would just go for > > the latter immediately. Also note that this line is > outside of reality > > of work done in vast majority of all drafts in ppvpn WG. > I do hope that > > this line will also be removed therefor making the ppvnp > split really > > useful in practice > > Rahul wrote: > > I very strongly second Robert's opinion. Time and again > the procedure of > > defining protocol extensions in PPVPN comes up. And > every time the reality > > is ignored. How about the following: > > "The WG may propose extensions to existing protocols and such > > extensions will be discussed and reviewed by the > protocol-specific WG." > > > > The question than is: Should a document submitted to the > current PPVPN WG > > (or the new groups if the split happens) be accepted as > a WG doc before > > the protocol specific WG reviews protocol extensions (if > any) ? I think we > > need more discussion on this. There are cases where it > makes sense to have > > such a review before accepting the doc as a WG doc and > there are cases > > where it doesn't. > > Eric wrote: > > I happen to like this sort of restriction, because it > helps to prevent a > > situation in which every proposal includes an > extension that is entirely > > optimized for that proposal. > > Here's my take on this: > > 1. I think I (and the IESG in this case too) would not be comfortable > with a general approach of extensions to protocols that have > corresponding WGs not owned by those WGs. Clearly, the > expertise and > the bigger picture of the development of a particular protocol is > there. So, I think allowing the VPN WGs (or PPVPN) to develop and > standardize protocol-specific extensions would not be realistic or > fair to the protocol-specific WGs. > > 2. The text in the charter actually describes an existing > situation--we do this in CCAMP--for instance, we have a generic > routing document describing information that needs to be > distributed and then we have protocol-specific documents that > define encoding in that particular protocol. Not extremely > effective from the CCAMP perspective, but quite fair if we take > other WGs in consideration. > > 3. In reality, what we want to achieve is the VPN community being > able to propose and document extensions to existing protocols > that would help VPN technology development. Also, before a given > mechanism goes forward, we need to make sure that: > > a. The VPN community believes that it serves the purpose > and the right way forward > > AND > > b. The protocol-specific community believes that using > the protocol is a good idea and the way this is done > is correct. > > Given that finally the extension specs have to live in the > protocol-specific WGs, ow about we use the following process > (draft): > > 1. VPN folks who believe that a given protocol extension > is needed, come up with an individual draft describing > the details. > > 2. The draft is brought to the appropriate VPN WG. A discussion > on the mailing list AND in the room is held on the subject of > why this is needed and whether this is a good idea VPN-wise. > If there is no agreement on this--the draft does not go > any further. Otherwise: > > 3. The draft is taken to the protocol-specific WG. The WG > discusses if it is happy with it as a general approach, if > so takes it as a WG item. Otherwise, the WG chairs summarize > the discussion and send the summary to the VPN WG. > > 4. If the draft is accepted by the protocol-specific WG, > the appropriate VPN framework document is updated to describe > it and refer to the doc. > > 5. The WG chairs coordinate timing for the draft. > When ready to go to IESG, the draft is LC'ed in both WGs. > > Comments? > > Alex > > > ------_=_NextPart_001_01C31677.D8577D3C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft charter for L3VPN: protocol-specific work

Hi Alex,

To go into the weekend on a positive note, this looks = like a pretty reasonable approach for protocol extensions (whether or = not there is a WG split).

However, in the interest of saving time in the = meetings, perhaps there should be some provision for allowing consensus = on a proposed protocol extension to be reached just on the mailing = list, so we don't require a presentation and discussion of each one in = the meeting.  Maybe there could be a slide with a list of the = "pre-approved" extensions in the meeting, so any last-minute = objections from people not following the mailing list can be = heard.

Also, are there gray areas in the definition of = "protocol extensions" ?

I'm assuming that this procedure would apply = to:
- New attributes
- New message types, payload types, type = codes
- New enumerated values in existing attributes or = protocol messages
- ?

Regards,
Paul

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: Friday, May 09, 2003 2:43 PM
> To: PPVPN@nortelnetworks.com
> Subject: Re: Draft charter for L3VPN: = protocol-specific work
>
>
>
> On the following part of the proposed = charter:
>
> > As a general rule, the WG will not create = new protocols, but will
> > provide functional requirements for = extensions of the existing
> > protocols that will be discussed in the = protocol-specific WGs.
>
> we had the following:
>
>    Robert wrote:
>    > That is even biggest = evil making essentially as ppvpn this new WG
>    > useless :).Without at = least ability to propose
> extensions to protocols
>    > submitting any serious = draft is pointless. If I have to write
>    > requirements for myself = and submit a solution in IDR I
> would just go for
>    > the latter immediately. = Also note that this line is
> outside of reality
>    > of work done in vast = majority of all drafts in ppvpn WG.
> I do hope that
>    > this line will also be = removed therefor making the ppvnp
> split really
>    > useful in = practice
>
>    Rahul wrote:
>    > I very strongly second = Robert's opinion. Time and again
> the procedure of
>    > defining protocol = extensions in PPVPN comes up. And
> every time the reality
>    > is ignored. How about = the following:
>    >    = "The WG may propose extensions to existing protocols and = such
>    > extensions will be = discussed and reviewed by the
> protocol-specific WG."
>    >
>    > The question than is: = Should a document submitted to the
> current PPVPN WG
>    > (or the new groups if = the split happens) be accepted as
> a WG doc before
>    > the protocol specific WG = reviews protocol extensions (if
> any) ? I think we
>    > need more discussion on = this. There are cases where it
> makes sense to have
>    > such a review before = accepting the doc as a WG doc and
> there are cases
>    > where it doesn't.
>
>    Eric wrote:
>    > I happen  to like = this  sort of restriction,  because it
> helps to  prevent a
>    > situation in  which = every  proposal includes an 
> extension that  is entirely
>    > optimized for that = proposal.
>
> Here's my take on this:
>
> 1. I think I (and the IESG in this case too) = would not be comfortable
>    with a general approach of = extensions to protocols that have
>    corresponding WGs not owned = by those WGs. Clearly, the
> expertise and
>    the bigger picture of the = development of a particular protocol is
>    there. So, I think allowing = the VPN WGs (or PPVPN) to develop and
>    standardize protocol-specific = extensions would not be realistic or
>    fair to the protocol-specific = WGs.
>
> 2. The text in the charter actually describes = an existing
>    situation--we do this in = CCAMP--for instance, we have a generic
>    routing document describing = information that needs to be
>    distributed and then we have = protocol-specific documents that
>    define encoding in that = particular protocol. Not extremely
>    effective from the CCAMP = perspective, but quite fair if we take
>    other WGs in = consideration.
>
> 3. In reality, what we want to achieve is the = VPN community being
>    able to propose and document = extensions to existing protocols
>    that would help VPN = technology development. Also, before a given
>    mechanism goes forward, we = need to make sure that:
>
>      a. The VPN = community believes that it serves the purpose
>         = and the right way forward
>     
>    AND
>   
>      b. The = protocol-specific community believes that using
>         = the protocol is a good idea and the way this is done
>         = is correct.
>
>    Given that finally the = extension specs have to live in the
>    protocol-specific WGs, ow = about we use the following process
>    (draft):
>
>      1. VPN folks who = believe that a given protocol extension
>         = is needed, come up with an individual draft describing
>         = the details.
>
>      2. The draft is = brought to the appropriate VPN WG. A discussion
>         = on the mailing list AND in the room is held on the subject of
>         = why this is needed and whether this is a good idea VPN-wise.
>         = If there is no agreement on this--the draft does not go
>         = any further. Otherwise:
>
>      3. The draft is = taken to the protocol-specific WG. The WG
>         = discusses if it is happy with it as a general approach, if
>         = so takes it as a WG item. Otherwise, the WG chairs summarize
>         = the discussion and send the summary to the VPN WG.
>
>      4. If the draft = is accepted by the protocol-specific WG,
>         = the appropriate VPN framework document is updated to describe
>         = it and refer to the doc.
>
>      5. The WG chairs = coordinate timing for the draft.
>         = When ready to go to IESG, the draft is LC'ed in both WGs.
>
>    Comments?
>
> Alex
>
>
>

------_=_NextPart_001_01C31677.D8577D3C-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 18:15:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05686 for ; Fri, 9 May 2003 18:15:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49MHbP26241 for ; Fri, 9 May 2003 18:17:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49MHWo09054 for ; Fri, 9 May 2003 18:17:32 -0400 (EDT) Date: Fri, 9 May 2003 15:10:06 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <60243982388.20030509151006@psg.com> To: Eric Rosen CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: Internet transparency In-Reply-To: <200305081844.h48Ii2AD025062@rtp-core-1.cisco.com> References: <200305081844.h48Ii2AD025062@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, > However, in the case of 2547bis, the "multiple providers" are expected to be > a small number of closely cooperating service providers. There really isn't > much provision for running the VPNs over the public Internet. It might be > good to have this "public Internet transparency" excluded from the charter. > Presumably, that would prevent the IESG from later rejecting the specs on > the grounds that they don't provide public Internet transparency. Is this specific to the case of 2547 only or generic to all L3 mechanisms? If the former, I would rather not like the charter to say so. As for rejecting the 2547-related specs, I think it would be very useful if the applicability statement highlighted the detail about cooperating SPs and state that Internet transparency is a non-goal. > With regard to the specific list of documents, a notable omission is the > specification for doing 2547bis when OSPF is the PE/CE protocol. Now that > a proper division of responsibilities has been agreed with the OSPF WG, I'd > like to see this document added to the list. Noted. > One more comment: I believe that the month following Dec 2003 is Jan 2004. We definitely need a consensus on this. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 18:22:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05943 for ; Fri, 9 May 2003 18:22:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49MPEP00718 for ; Fri, 9 May 2003 18:25:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49MPBo16770 for ; Fri, 9 May 2003 18:25:11 -0400 (EDT) Date: Fri, 9 May 2003 15:18:35 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18244491099.20030509151835@psg.com> To: "Paul Knight" CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: protocol-specific work In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF05AF945C@zbl6c004.corpeast.baynetworks.com> References: <6204FDDE129D364D8040A98BCCB290EF05AF945C@zbl6c004.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Paul, > To go into the weekend on a positive note, this looks like a pretty > reasonable approach for protocol extensions (whether or not there is a WG > split). Thanks, we need some positive notes this week ;) > However, in the interest of saving time in the meetings, perhaps there > should be some provision for allowing consensus on a proposed protocol > extension to be reached just on the mailing list, so we don't require a > presentation and discussion of each one in the meeting. Maybe there could > be a slide with a list of the "pre-approved" extensions in the meeting, so > any last-minute objections from people not following the mailing list can be > heard. I think this goes to the area of 'how do we gauge consensus?' It would probably be too much for this list to take this topic now :) However, generally, I think that just a discussion on the mailing list or just a discussion at a face-to-face meeting are not enough, we need both. > Also, are there gray areas in the definition of "protocol extensions" ? Most probably, but I think it would probably be hard to come up with a universal definition, so maybe we should leave this to the judgement of WG chairs and ADs. To answer your particular questions: > I'm assuming that this procedure would apply to: > - New attributes I'd say yes > - New message types, payload types, type codes I'd say yes > - New enumerated values in existing attributes or protocol messages I'd say no, provided that the semantics of the fields are not changed, but this may very well depend on each particular case. Thanks. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 18:52:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06416 for ; Fri, 9 May 2003 18:52:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49Mt2P05891 for ; Fri, 9 May 2003 18:55:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49MswA27783 for ; Fri, 9 May 2003 18:54:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Fri, 9 May 2003 17:52:39 -0500 Message-ID: Thread-Topic: RE: IMPORTANT: Strategy for VPN work in IETF Thread-Index: AcMWfXOBb49hZ4IpEdejAADAT2jDug== From: "Fang, Luyuan, ALABS" To: "Nagarajan, Ananth [NTWK SVCS]" , , "Thomas Narten" Cc: "Alex Zinin" , X-SMTP-HELO: almso2.proxy.att.com X-SMTP-MAIL-FROM: luyuanfang@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: almso2.att.com [192.128.166.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA06416 I agree with Jeremy and Ananth. Luyuan -----Original Message----- From: Nagarajan, Ananth [NTWK SVCS] [mailto:ananth.nagarajan@mail.sprint.com] Sent: Friday, May 09, 2003 11:52 AM To: jeremy.de_clercq@alcatel.be; Thomas Narten Cc: Alex Zinin; ppvpn@nortelnetworks.com Subject: RE: IMPORTANT: Strategy for VPN work in IETF I think I agree with Jeremy here. After thinking about the proposed split for some time, I realized that (as I said earlier) it would have made more sense if this was done as soon as L2VPN/PWE3-related stuff was brought into the WG. I also feel that there are several "generic" documents, in addition to the ones I brought up on this thread some time ago, and it will become increasingly complex to decide where those kind of documents would fit. My preference is to schedule two sessions at Vienna, and spend some time discussing this, before any decision is made. PS: Another potential problem that would happen is having to subscribe to both the l2 and l3 vpn mailing lists and getting duplicate emails everytime a generic issue is discussed. Ananth > -----Original Message----- > From: jeremy.de_clercq@alcatel.be [] > Sent: Friday, May 09, 2003 9:54 AM > To: Thomas Narten > Cc: Alex Zinin; ppvpn@nortelnetworks.com > Subject: Re: IMPORTANT: Strategy for VPN work in IETF > > > Hi Thomas, all, > > > The chairs themselves seem to agree that there are some 13 documents > > on L3 that are not through the system yet. I'm a bit > concerned to hear > > that there has been minimal discussion on L3 topics over the last > > year, given the number of L3 work items that apparently need to get > > completed. > > > > The above could be read as indicating that the discussion/urgency of > > the L2 work is pushing out or drowning out discussion on L3 > topics. If > > that is the case, a separate WG, mailing list, etc., may well help. > > I'm assuming the L3 work is important and should get completed. > > I believe that it can also be read as indicating that many feel that > most of the (current) L3VPN work is stable and agreed upon, > and doesn't > need more discussion within the WG. As was already hinted previously, > the progress of the L3VPN work has been delayed (for a long time) > because the framework and requirements documents needed to be accepted > first. > > I do believe however that several proposed new working items (QoS, > security, management, multicast, etc.) have received little attention > from the WG because of the current L2VPN (VPLS) > discussions/urgency. But > as many of these are aimed at both L2 and L3VPNs, and as I don't find > reference to these items in the proposed charters, I > understand that the > goal of the proposed split is not to accomodate these. > > On one hand, I believe that the idea of two separate WGs is a > good one, > but on the other hand, I'm not sure how much it will help > now, so far in > the process. > > I also personally believe that the PPVPN WG has produced valuable > results, and is making progress on complex topics every day > (look at the > current IEEE vs VPLS discussions on this list). And this despite the > fact that the 'market' is not waiting and despite the fact that the > number of interested individuals (from different backgrounds: SPs, > vendors, academic and other standard bodies) is very large. > > Jeremy. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 19:04:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06705 for ; Fri, 9 May 2003 19:04:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49N6bP28037 for ; Fri, 9 May 2003 19:06:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49N6Xg08922 for ; Fri, 9 May 2003 19:06:34 -0400 (EDT) Date: Fri, 9 May 2003 16:00:24 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <190247000317.20030509160024@psg.com> To: jeremy.de_clercq@alcatel.be CC: Thomas Narten , ppvpn@nortelnetworks.com Subject: Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: <3EBBC117.D5730B6C@alcatel.be> References: <3EBBC117.D5730B6C@alcatel.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Jeremy, Thanks for your message, please see my comments inline below. > I believe that it can also be read as indicating that many feel that > most of the (current) L3VPN work is stable and agreed upon, and doesn't > need more discussion within the WG. I'd like to make a particular comment on those documents considered "stable" and "done". Very often it seems that once the active discussion in the WG is settled, this is it, the document is ready to fly and not much attention is needed. My experience as an AD and an IESG member is quite different. Quite often considerable issues are found during the AD-review and IESG-review processes. I am not talking about fundamental disagreements like whether MPLS is good or evil, but about plain technical issues, security aspects, etc. These are parts of the path of a document through the IETF process and often require the same level of attention and focus of the WG as during the first (intra-WG) phase of it. So, my point here is that we should not underestimate the amount of work that is left for the existing L3 documents. > As was already hinted previously, the progress of the L3VPN work has > been delayed (for a long time) because the framework and > requirements documents needed to be accepted first. This sounds like the delays for those docs have been primarily on the IESG side. I think it would be interesting to take a look at the logs in the ID tracker to see where exactly the delays were. As a data point, I can tell you that the way of a document within the IESG is time-bound, because of the way the IESG as a body operates. Most of the delays I see in reality are during either the AD-review process, or when input from the IESG needs to be addressed. > I do believe however that several proposed new working items (QoS, > security, management, multicast, etc.) have received little attention > from the WG because of the current L2VPN (VPLS) discussions/urgency. But > as many of these are aimed at both L2 and L3VPNs, and as I don't find > reference to these items in the proposed charters, I understand that the > goal of the proposed split is not to accomodate these. Could you send the draft names, pls? > On one hand, I believe that the idea of two separate WGs is a good one, > but on the other hand, I'm not sure how much it will help now, so far in > the process. > I also personally believe that the PPVPN WG has produced valuable > results, and is making progress on complex topics every day (look at the > current IEEE vs VPLS discussions on this list). And this despite the > fact that the 'market' is not waiting and despite the fact that the > number of interested individuals (from different backgrounds: SPs, > vendors, academic and other standard bodies) is very large. Noted. Thanks. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 19:08:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06814 for ; Fri, 9 May 2003 19:08:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h49NAtP00570 for ; Fri, 9 May 2003 19:10:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h49NApg15223 for ; Fri, 9 May 2003 19:10:52 -0400 (EDT) Date: Fri, 9 May 2003 16:05:48 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <175247323722.20030509160548@psg.com> To: "Nagarajan, Ananth [NTWK SVCS]" CC: jeremy.de_clercq@alcatel.be, "Thomas Narten" , ppvpn@nortelnetworks.com Subject: Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: <1DA3AEE851515549A5D2C5BD7F8FB2471FF2C6@PKDWB06C.ad.sprint.com> References: <1DA3AEE851515549A5D2C5BD7F8FB2471FF2C6@PKDWB06C.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ananth, Friday, May 9, 2003, 8:51:56 AM, Nagarajan, Ananth [NTWK SVCS] wrote: > I think I agree with Jeremy here. After thinking about the proposed > split for some time, I realized that (as I said earlier) it would > have made more sense if this was done as soon as L2VPN/PWE3-related > stuff was brought into the WG. Isn't later better than never? > I also feel that there are several "generic" documents, in addition > to the ones I brought up on this thread some time ago, and it will > become increasingly complex to decide where those kind of documents > would fit. Please list those documents. > My preference is to schedule two sessions at Vienna, and spend some > time discussing this, before any decision is made. I'll address this in my answer to Fabio. > PS: Another potential problem that would happen is having to > subscribe to both the l2 and l3 vpn mailing lists and getting > duplicate emails everytime a generic issue is discussed. I was under impression that modern e-mail clients had tools to deal with this :) Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 20:47:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08522 for ; Fri, 9 May 2003 20:47:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4A0nbP21667 for ; Fri, 9 May 2003 20:49:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4A0nYJ21850 for ; Fri, 9 May 2003 20:49:34 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6065C6CE9@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Rick Wilder'" , "'Kireeti Kompella'" , "'Alex Zinin'" Cc: "'ppvpn@nortelnetworks.com'" Subject: RE: On BGP and VPLS Date: Fri, 9 May 2003 20:47:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3168D.BA4BA3E8" X-LYRIS-Message-Id: 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_01C3168D.BA4BA3E8 Content-Type: text/plain As mentioned in my initial email on the thread "Re: IMPORTANT: Strategy for VPN work in IETF" - this re-organization is not needed and is slowing down progress of the PPVPN WG - The chairs should be in a position to progress the work of their WG sine the WG is still chartered. Bilel. -----Original Message----- From: Rick Wilder [mailto:rwilder@masergy.com] Sent: Friday, May 09, 2003 4:55 PM To: Kireeti Kompella; Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: RE: On BGP and VPLS Kireeti, Regarding the last part of your message, the working group chairs have been asked to hold off of declarations of consensus on drafts in the wake of discussions of re-organizing (ie. splitting) of the group. Rick -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, May 09, 2003 3:18 PM To: Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS Hi Alex, On Fri, 2 May 2003, Alex Zinin wrote: > More specifically, below I tried to put together a list of concerns > I have about the approach described in draft-kompella-ppvpn-vpls, > that I would like the WG to consider. > > 1. Use of the NLRI field > > As an IP routing protocol, BGP uses the NLRI field to carry IP > reachability information in the form of IP prefixes. As an IP routing protocol, sure. But nowhere in RFC 2858 does it say that BGP has to only be an IP routing protocol. Furthermore, if BGP is used for L2 autodiscovery (which is by the way a PPVPN *Working Group* document), the exact same issue applies. > 2. Distribution of information > > When used as an IP routing protocol, BGP distributes routes among > all participating routers. For 2547, you have the same issue: BGP distributes routes among *all* participating routers, whereas only a few are really interested in them. So why is this an issue for VPLS but not for 2547? The distribution mechanisms are identical. > 3. Aggregation of information for large-scale operation Nowhere does 2858 talk about aggregation; in fact, the notion of aggregation is not even mentioned. -------------- On the issues of BGP for VPLS and also of single solution vs. multiple, there seems to me (I'm not a PPVPN WG chair!) good consensus that the WG wants a BGP solution, and also that they want multiple solutions. Are you, Alex, proposing to override that consensus? The call for consensus to make the various VPLS drafts WG documents was made over 3 weeks ago, and the call was supposed to last one week. We are thus two weeks overdue. I would like the WG chairs to declare what consensus they see, keeping in mind the email that Bert Wijnen (who is a seasoned Area Director) sent to the TE WG just today, saying: || But it is WG chair(s) who decide on how to gauge WG conensus. Or, from RFC 2418: 3.3. Session management Working groups make decisions through a "rough consensus" process. .... It is up to the Chair to determine if rough consensus has been reached. Kireeti. ------_=_NextPart_001_01C3168D.BA4BA3E8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: On BGP and VPLS

As mentioned in my initial email on the thread = "Re: IMPORTANT: Strategy for VPN work in IETF"  - this = re-organization is not needed and is slowing down progress of the PPVPN = WG - The chairs should be in a position to progress the work of their = WG sine the WG is still chartered.

Bilel.

-----Original Message-----
From: Rick Wilder [mailto:rwilder@masergy.com] =
Sent: Friday, May 09, 2003 4:55 PM
To: Kireeti Kompella; Alex Zinin
Cc: ppvpn@nortelnetworks.com
Subject: RE: On BGP and VPLS



Kireeti,

Regarding the last part of your message, the working = group chairs have been asked to hold off of declarations of consensus = on drafts in the wake of discussions of re-organizing (ie. splitting) = of the group.

Rick

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net] =
Sent: Friday, May 09, 2003 3:18 PM
To: Alex Zinin
Cc: ppvpn@nortelnetworks.com
Subject: Re: On BGP and VPLS

Hi Alex,

On Fri, 2 May 2003, Alex Zinin wrote:

>  More specifically, below I tried to put = together a list of concerns 
> I have about the approach described in = draft-kompella-ppvpn-vpls, 
> that I would like the WG to consider.
>
>  1. Use of the NLRI field
>
>    As an IP routing protocol, = BGP uses the NLRI field to carry IP
>    reachability information in = the form of IP prefixes.

As an IP routing protocol, sure.  But nowhere in = RFC 2858 does it say that BGP has to only be an IP routing = protocol.

Furthermore, if BGP is used for L2 autodiscovery = (which is by the way a PPVPN *Working Group* document), the exact same = issue applies.

>  2. Distribution of information
>
>    When used as an IP routing = protocol, BGP distributes routes among
>    all participating = routers.

For 2547, you have the same issue: BGP distributes = routes among *all* participating routers, whereas only a few are really = interested in them. So why is this an issue for VPLS but not for = 2547?  The distribution mechanisms are identical.

>  3. Aggregation of information for = large-scale operation

Nowhere does 2858 talk about aggregation; in fact, = the notion of aggregation is not even mentioned.

--------------

On the issues of BGP for VPLS and also of single = solution vs. multiple, there seems to me (I'm not a PPVPN WG chair!) = good consensus that the WG wants a BGP solution, and also that they = want multiple solutions. Are you, Alex, proposing to override that = consensus?

The call for consensus to make the various VPLS = drafts WG documents was made over 3 weeks ago, and the call was = supposed to last one week. We are thus two weeks overdue.  I would = like the WG chairs to declare what consensus they see, keeping in mind = the email that Bert Wijnen (who is a seasoned Area Director) sent to = the TE WG just today, saying:

|| But it is WG chair(s) who decide on how to gauge = WG conensus.

Or, from RFC 2418:

3.3. Session management

   Working groups make decisions through a = "rough consensus" process. ....
          &nb= sp;           &nb= sp;  It is up to the Chair to determine if rough
   consensus has been reached.

Kireeti.



------_=_NextPart_001_01C3168D.BA4BA3E8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 21:07:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08831 for ; Fri, 9 May 2003 21:07:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4A1A8P04218 for ; Fri, 9 May 2003 21:10:08 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4A1A4507753 for ; Fri, 9 May 2003 21:10:05 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , PPVPN@nortelnetworks.com Subject: RE: Draft charter for L3VPN: protocol-specific work Date: Fri, 9 May 2003 21:06:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31690.6DAE75BC" X-LYRIS-Message-Id: 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_01C31690.6DAE75BC Content-Type: text/plain; charset="iso-8859-1" Alex, > > a. The VPN community believes that it serves the purpose > and the right way forward > > AND > > b. The protocol-specific community believes that using > the protocol is a good idea and the way this is done > is correct. > > Given that finally the extension specs have to live in the > protocol-specific WGs, ow about we use the following process > (draft): > > 1. VPN folks who believe that a given protocol extension > is needed, come up with an individual draft describing > the details. > > 2. The draft is brought to the appropriate VPN WG. A discussion > on the mailing list AND in the room is held on the subject of > why this is needed and whether this is a good idea VPN-wise. > If there is no agreement on this--the draft does not go > any further. Otherwise: > > 3. The draft is taken to the protocol-specific WG. The WG > discusses if it is happy with it as a general approach, if > so takes it as a WG item. Otherwise, the WG chairs summarize > the discussion and send the summary to the VPN WG. > > 4. If the draft is accepted by the protocol-specific WG, > the appropriate VPN framework document is updated to describe > it and refer to the doc. > > 5. The WG chairs coordinate timing for the draft. > When ready to go to IESG, the draft is LC'ed in both WGs. > If I take the example of LDP extensions proposals in l2vpn space. Should both MPLS and PPVPN WGs agree to the changes before accepting the drafts? or should MPLS, PWE3, and PPVPN WGs all agree to the changes (for example if the changes modify PWE3 protocols/mechanisms and they add as well new TLVs to LDP (not related to PWE3's work/charter))? Wouldn't that cause more delays for most l2vpn work? The other question I have is if after the draft was accepted in all the appropriate WGs, and later on additional extensions are proposed. Should we redo the same process and go to all related protocol-specific WGs to get a new approval? Hamid. ------_=_NextPart_001_01C31690.6DAE75BC Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L3VPN: protocol-specific work

Alex,

>
>      a. The VPN community believes that it serves the purpose
>         and the right way forward
>     
>    AND
>   
>      b. The protocol-specific community believes that using
>         the protocol is a good idea and the way this is done
>         is correct.
>
>    Given that finally the extension specs have to live in the
>    protocol-specific WGs, ow about we use the following process
>    (draft):
>
>      1. VPN folks who believe that a given protocol extension
>         is needed, come up with an individual draft describing
>         the details.
>
>      2. The draft is brought to the appropriate VPN WG. A discussion
>         on the mailing list AND in the room is held on the subject of
>         why this is needed and whether this is a good idea VPN-wise.
>         If there is no agreement on this--the draft does not go
>         any further. Otherwise:
>
>      3. The draft is taken to the protocol-specific WG. The WG
>         discusses if it is happy with it as a general approach, if
>         so takes it as a WG item. Otherwise, the WG chairs summarize
>         the discussion and send the summary to the VPN WG.
>
>      4. If the draft is accepted by the protocol-specific WG,
>         the appropriate VPN framework document is updated to describe
>         it and refer to the doc.
>
>      5. The WG chairs coordinate timing for the draft.
>         When ready to go to IESG, the draft is LC'ed in both WGs.
>

If I take the example of LDP extensions proposals in l2vpn
space. Should both MPLS and PPVPN WGs agree to the changes before
accepting the drafts? or should MPLS, PWE3, and PPVPN WGs all
agree to the changes (for example if the changes modify PWE3
protocols/mechanisms and they add as well new TLVs to LDP
(not related to PWE3's work/charter))?

Wouldn't that cause more delays for most l2vpn work?

The other question I have is if  after the draft was accepted
in all the appropriate WGs, and later on additional extensions
are proposed. Should we redo the same process and go to all
related protocol-specific WGs to get a new approval?

Hamid.

 

------_=_NextPart_001_01C31690.6DAE75BC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 22:11:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09738 for ; Fri, 9 May 2003 22:11:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4A2E2P17611 for ; Fri, 9 May 2003 22:14:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4A2DwP28694 for ; Fri, 9 May 2003 22:13:58 -0400 (EDT) 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: Strategy for VPN work in IETF Date: Fri, 9 May 2003 19:10:27 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E01461EDE@TNEXVS02.tahoenetworks.com> Thread-Topic: IMPORTANT: Strategy for VPN work in IETF Thread-Index: AcMWgAsotVk1nqrtRlmnmRX2D1IoAAAFY/1A From: "Bryan Gleeson" To: "Alex Zinin" , "Thomas Narten" Cc: X-OriginalArrivalTime: 10 May 2003 02:10:27.0725 (UTC) FILETIME=[53250BD0:01C31699] X-SMTP-HELO: TNEXVS01.tahoenetworks.com X-SMTP-MAIL-FROM: bryan@tahoenetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: nat-63-99-114-4.tahoenetworks.com [63.99.114.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA09738 Alex et al, Having observed the discussion this week, I certainly agree with the many others who are concerned about the justification for the WG split and the manner in which the restructuring is being proposed. Many issues are being mixed together, including ways to speed up the work, rechartering, moving the work out of the sub-ip area, and the WG split itself. Splitting the group is not a pre-requisite for addressing the first three issues, and I agree with those who argue that a convincing case has yet to be made that having a single WG is a real problem. The proposed charters seem to me to be a step backwards since they have removed any reference to common components and mechanisms which was a goal of the current charter. Issues like VPN discovery, membership and topology are very similar whether data-plane forwarding takes place at layer-2 or layer-3, and I think that development of common mechanisms is something to be encouraged. For example, as was pointed out before, Juha's VPN discovery draft using Radius, and Hamid's VPN discovery draft using BGP, seem equally applicable to layers 2 and 3, and splitting the group would make the development of common solutions more cumbersome, and less likely. As regards speeding up the work, ideas such as a second session at IETF meetings, interim meetings, forcing resolution of some controversial issues, etc, all warrant examination, and I'm sure that those more closely involved in the work have more ideas on this topic; however I doubt whether splitting the group will by itself make much difference. A rechartering exercise may be useful at this time if it ensures that later progression of documents through the IESG will be not be subject to undue delay (for example if the charter calls for standardizing multiple solutions, then the fact that multiple solutions were produced is not a valid objection to progressing those solutions). Also I've never viewed a PPVPN as a sub-ip phenomenon, so moving the work to the Internet area makes sense to me. Lastly I think the new procedure for extending protocols is still too complex (e.g. I find the proposal that the VPN framework document be updated for every extension very odd). Most protocols these days are designed to be easily extensible. There is merit to having wide review of new solutions, however having a formal process that requires the AAA WG to approve of and do a synchronized last call for something as simple as a Radius extension, for example, is very cumbersome, and will certainly slow things down. Regards, Bryan From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 22:42:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10112 for ; Fri, 9 May 2003 22:42:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4A2ieP21264 for ; Fri, 9 May 2003 22:44:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4A2ibQ06858 for ; Fri, 9 May 2003 22:44:37 -0400 (EDT) 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="utf-8" Subject: RE: On BGP and VPLS Date: Fri, 9 May 2003 22:42:09 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C46F@m-va-bsod03.add0.masergy.com> Thread-Topic: On BGP and VPLS thread-index: AcMWcyLcR/nSRKdWTHutM4sqagr4lQAKZ+Ti From: "Rick Wilder" To: "Kireeti Kompella" , , Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA10112 Kireeti, Apparently my previous message was in error in linking the planning to spllit the group with the delay in deciding on working group status of documents. We have planned a conference on Monday which may resolve other WG issues independent of reorganization plans. Rick -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Fri 5/9/2003 5:36 PM To: kireeti@juniper.net; Rick Wilder; zinin@psg.com Cc: ppvpn@nortelnetworks.com Subject: RE: On BGP and VPLS Hi Rick, > Regarding the last part of your message, the working group chairs have > been asked to hold off of declarations of consensus on drafts in the > wake of discussions of re-organizing (ie. splitting) of the group. What's the rationale for holding off declarations of consensus? This decision is two weeks overdue, and the split (if it happens) could take several more weeks. It would be a complete travesty if a simple consensus call took weeks but a major decision like a split of the WG was completed in a hurry -- for one, it would suggest that the split was preordained, and not a joint WG decision, a point that Bilel was seeking clarification on. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 9 22:55:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10327 for ; Fri, 9 May 2003 22:55:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4A2vuP25246 for ; Fri, 9 May 2003 22:57:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4A2vqY11734 for ; Fri, 9 May 2003 22:57:52 -0400 (EDT) Date: Fri, 9 May 2003 19:55:38 -0700 (PDT) From: Kireeti Kompella Message-Id: <200305100255.h4A2tce59221@kummer.juniper.net> To: kireeti@juniper.net, rwilder@masergy.com, zinin@psg.com Subject: RE: On BGP and VPLS Cc: ppvpn@nortelnetworks.com In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C46F@m-va-bsod03.add0.masergy.com> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: > Apparently my previous message was in error No problem. Things change so fast that I can't wait to read my email to see what's new :-) Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 10 13:09:57 2003 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02136 for ; Sat, 10 May 2003 13:09:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4AF49M17039 for ; Sat, 10 May 2003 11:04:09 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4AF46725749 for ; Sat, 10 May 2003 11:04:07 -0400 (EDT) Date: Fri, 9 May 2003 23:46:39 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <162274975293.20030509234639@psg.com> To: ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? In-Reply-To: <61241310626.20030509142534@psg.com> References: <3EBC06ED.4060700@lucent.com> <61241310626.20030509142534@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- As promised (though 11:40-ish my time), I tried to quickly bring together information that would clarify some confusion I noticed during the discussion about the work split. I also tried to come up with answers to questions that I thought might be interesting. Hope this is helpful. Regards. Alex 1. Procedural background: 1.1 Relevant quotes from RFC 2418: Section 2: a) "...A working group may be established at the initiative of an Area Director or it may be initiated by an individual or group of individuals." b) "Working groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.). Working groups are generally expected to be short-lived in nature." c) "Upon completion of its goals and achievement of its objectives, the working group is terminated. A working group may also be terminated for other reasons (see section 4)." Section 4: "If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, or if the assumptions which that work was based have been modified in discussion or by experience, the Area Director, in consultation with the working group can either: 1. Recharter to refocus its tasks, 2. Choose new Chair(s), or 3. Disband. If the working group disagrees with the Area Director's choice, it may appeal to the IESG (see section 3.4)." d) "The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director(s), although final approval is made by the IESG with advice from the Internet Architecture Board (IAB). A charter is a contract between a working group and the IETF to perform a set of tasks." 1.2. WG split is not covered in 2418 From the process perspective, splitting of PPVPN work is considered as 1) termination of the existing WG, 2) formation of the new WGs, and 3) relocation of the WG documents to the new WGs. 2. Data about PPVPN WG: BOF'ed : Pittsburgh, Aug 03, 2000 (NBVPN BOF) 1st meeting : San Diego , Dec 14, 2000 (PPVPN BOF/WG) WG drafts : 17 (as of May 09, 2003) Submitted to IESG : 3 (L3 framework, L3 reqs, generic reqs) Approved, in RFC-ed queue : None (as of May 09, 2003) RFCs published : None (as of May 09, 2003) 3. Problem statement. As seen by ADs: slow progress on L3 and L2 VPN work (see section 2 above) caused by comparatively wide problem space with unusually big number of correlated technologies (L2, bridging, tunneling, routing, signalling, etc.) that in turn results in a big number of tasks and documents within the WG. Overloading of the WG resources (management cycles, mailing list, and face-to-face meeting time) causes slow progress on the existing WG documents that (because of the number of incomplete items) keeps continuing VPN technology developments outside the WG and makes the process within the WG and its results less relevant to the community and the industry. Unless addressed, the situation is expected to get only worse. 4. Summary of the solution under consideration 1. Put L3 and L2 work in separate WGs Analysis of the L3 and L2 remaining and potential future work items has shown that there is a sufficient amount of work in each area to warrant a separate WG. Smaller and more focused WGs tend to be more efficient in terms of achieving consensus and completing their tasks. 2. Focus the charters to ensure progress on items already in the pipe; expand the charters and add more work items as things progress 5. Goal of the discussion on the list Collect community feedback on the solution and the charters of the proposed new WGs. 6. FAQ 6.1 How is relocating the work to the Internet area related to the described problem and the proposed split? It is not. Relocation of the VPN work to the Internet area is an independent action. However, since the question of reorganizing the work is being considered, it is logical to do the move at the same time. 6.2 Does the IETF process require consensus within the WG on the problem statement and/or the proposed solution? Formally, the ADs or the IESG do not need to obtain WG consensus on forming, disbanding, splitting a WG, or any other WG management actions. However, it is normal for the ADs and the IESG to consult the community before making the decisions. This is what happened before the discussion was started and essentially what is happening on the list now. 6.3 Have you made the decision already or are you still open to feedback from the community? We came to the WG with a strong opinion that a split is needed, however, the decision has not been made yet and we are open to all opinions. 6.4 If the decision has not been made yet, why did you start the discussion on the charters of proposed new WGs? This was done to make sure the community has enough information to understand what the results of the split would be, and to collect feedback on the charters themselves. 6.5 What would happen to the documents that span both L2 and L3 VPN areas? They would be put in one of the new WGs. 6.6 How would you ensure coordination between the two VPN groups? Coordination between different WGs is a well-known task and is usually accomplished through direct communication of the WG chairs, ministration by ADs, and by formation of technology- specific directorates. Formation of the VPN directorate is being considered. 6.7 Have you considered other alternatives to the split? Yes. The alternative to the split would be to organize work within the WG in the form of design teams and have more than one WG session at the face-to-face meetings. However, the WG already has a number of DTs inside of it, so we can consider that this method has been tried already. Increasing the number of WG sessions alone is hardly going to help as majority of work is done outside the face-to-face meetings, in fact, consistent need for more than one session maybe considered as an indication that the WG has more than enough on its charter. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 10 13:17:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02358 for ; Sat, 10 May 2003 13:17:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4AFecM23706 for ; Sat, 10 May 2003 11:40:38 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4AFeZi04034 for ; Sat, 10 May 2003 11:40:35 -0400 (EDT) X-Originating-IP: [219.65.134.205] X-Originating-Email: [sylvia_sugar@hotmail.com] From: "Sylvia Sugar" To: PPVPN@nortelnetworks.com Subject: IPv6 versus unique identifiers Date: Sat, 10 May 2003 15:38:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 May 2003 15:38:48.0532 (UTC) FILETIME=[3FE0E140:01C3170A] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: sylvia_sugar@hotmail.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: bay1-f168.bay1.hotmail.com [65.54.245.168] X-LYRIS-Message-Id: Hi folks, (@_@) Now I get it, Route Distingusiher + version 4 address = 96 bytes. So the unique identifier is 96 bytes. If one was to look at each and very Version 4 route in the MPLS core routing tables of a heavily peered INTER/INRAAS router, it would be 96 bytes long. And, it would uniquely identify the host! A host would be identified by 96 bytes now as far as the core of MPLS is concerned. What is still confusing me is, why not increase the size of the route distinguisher by a few more bytes, and call this new address a version 6 address? That way we have solved the problem of NAT, (how amazing the only way out is to increase the address space!! irrespective of there being such a massive demand for closed user groups...) (@_@) and have also ensured that MPLS can actually be extended till each "host"!! we can actually have MPLS aware NIC cards! But why would I need MPLS aware NIC cards? I could simply use IPv6!! and so I can do with my existing NIC cards.. MPLS doesnt help make addresses unique? Its just a way to help people migrate to IPv6? Isnt it? Could someone help me understand that? It all seems so exciting....!!! -SylviaXO _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 10 13:25:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02786 for ; Sat, 10 May 2003 13:24:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4AF4BM17067 for ; Sat, 10 May 2003 11:04:11 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4AF48725785 for ; Sat, 10 May 2003 11:04:08 -0400 (EDT) Date: Sat, 10 May 2003 00:04:26 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <129276042628.20030510000426@psg.com> To: "Hamid Ould-Brahim" CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: protocol-specific work In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hamid, > If I take the example of LDP extensions proposals in l2vpn > space. Should both MPLS and PPVPN WGs agree to the changes before > accepting the drafts? or should MPLS, PWE3, and PPVPN WGs all > agree to the changes (for example if the changes modify PWE3 > protocols/mechanisms and they add as well new TLVs to LDP > (not related to PWE3's work/charter))? We would sit down with WG chairs of PPVPN, MPLS, and PWE3 and discuss the matter. My goal would be to limit the number of WGs to 2 (PPVPN included), more would be much harder. > Wouldn't that cause more delays for most l2vpn work? I don't think so, because we need this sort of reviews anyways. > The other question I have is if after the draft was accepted > in all the appropriate WGs, and later on additional extensions > are proposed. Should we redo the same process and go to all > related protocol-specific WGs to get a new approval? Hard to say in general. If changes are substential, consensus verification might be warranted, otherwise less formal discussions would suffice. This sort of details are usually left to the WG chairs and ADs. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 10 13:25:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02791 for ; Sat, 10 May 2003 13:25:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4AF4NM17318 for ; Sat, 10 May 2003 11:04:23 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4AF4J726051 for ; Sat, 10 May 2003 11:04:20 -0400 (EDT) From: "Jim Guichard" To: "Rahul Aggarwal" , "Alex Zinin" Cc: Subject: RE: Draft charter for L3VPN: inter-AS/inter-provider Date: Sat, 10 May 2003 07:42:44 -0400 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-msg-core-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ams-msg-core-1.cisco.com [144.254.74.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > >> > >> 1. Jim Guichard said: > >> > >> > 2. Is complexity associated with inter-AS (1 provider) > >scenarios > >> > sufficiently higher than for the single-AS case? > >> > >> potentially yes for the same reasons as (1). Jim > >> > >> Two reasons have been brought in (1): > >> > >> a) different encaps for 2547 (MPLS/GRE) > > > >There is no fundamental difference with regards to supporting different > >encaps in the single AS and inter-AS case. Perhaps, but certainly it is potentially more difficult. In the single AS case one would expect routing information to be available so as to build the ingress/egress PE connectivity. However, in the InterAS case this may not be available and therefore complexity is added as the ASBRs might need to "stitch" things together .. I do however believe that the single AS and multiAS case are similar as typically routing information is leaked between the AS's that make up the multiAS environment. Jim > > > >> b) provisioning end-to-end LSP is more complex in the multi-AS > >> case > >> > >> It seems that this may indeed complicate the mechanisms. > >> I'd love to see a little more discussion on this. > > > >2547 describes the mechansims for inter-AS. IMHO they are well > >understood. > >Set up of a RSVP-TE inter-AS LSP is work in progress. However > >2547 does not need any additional mechanisms for using a RSVP-TE inter-AS > >LSP between the end PEs. > > > >> > >> 2. Are we going to need additional documents compared to what we > >> already have in order to describe inter-AS scenarios > >> appropriately? > > > >Base mechanisms for implementing and deploying inter-AS are in place and > >are described in 2547. > > > >If yes, I'd rather say one-AS first, then multi-AS > >> single provider, and then multi-provider. > >> > > > >I would still say one-AS and multi-AS to begin with. > > > >Regards, > >rahul > > > >> Regards. > >> > >> Alex > >> > >> > >> > >> > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 10 14:11:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02360 for ; Sat, 10 May 2003 13:17:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4AF4EM17119 for ; Sat, 10 May 2003 11:04:14 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4AF4A725845 for ; Sat, 10 May 2003 11:04:11 -0400 (EDT) Date: Fri, 9 May 2003 23:58:41 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <112275697021.20030509235841@psg.com> To: Fabio Chiussi CC: ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? In-Reply-To: <3EBC06ED.4060700@lucent.com> References: <3EBC06ED.4060700@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Fabio, Please see my other message to the list, it should clarify most of your questions. On this particular one: > All this indicates that the issue of splitting the WG and how to split > it (I am among those many people that just fail to see any strong reason > in support of an L2/L3 split) needs, at a minimum, further and more > formal discussion on the mailing list first, and then in person in Vienna. I think that continued uncertainty in this case will only make matters worse. I believe we need to come to Vienna with the resolution at hand--either sessions of the two new WGs, or the decision to leave a single WG and a crisp plan forward. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 10 19:56:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11452 for ; Sat, 10 May 2003 19:56:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4ANwqM15972 for ; Sat, 10 May 2003 19:58:52 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4ANwoo16190 for ; Sat, 10 May 2003 19:58:50 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6C02@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Kireeti Kompella'" , rwilder@masergy.com, zinin@psg.com Cc: ppvpn@nortelnetworks.com Subject: RE: On BGP and VPLS Date: Sat, 10 May 2003 19:57:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3174F.E120113A" X-LYRIS-Message-Id: 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_01C3174F.E120113A Content-Type: text/plain Rick, Marco I concur with Kireeti - based on Alex previous e-mails, a consensus already created during the last three weeks should not be impacted by the new re-org, which in Alex's view is more a management issue, to offload the work of the current WG. Reading again the e-mails from Alex, it was not stipulated anywhere that a re-org would trigger a new process of selecting the WDs. Cheers Vasile -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, May 09, 2003 5:37 PM To: kireeti@juniper.net; rwilder@masergy.com; zinin@psg.com Cc: ppvpn@nortelnetworks.com Subject: RE: On BGP and VPLS Hi Rick, > Regarding the last part of your message, the working group chairs have > been asked to hold off of declarations of consensus on drafts in the > wake of discussions of re-organizing (ie. splitting) of the group. What's the rationale for holding off declarations of consensus? This decision is two weeks overdue, and the split (if it happens) could take several more weeks. It would be a complete travesty if a simple consensus call took weeks but a major decision like a split of the WG was completed in a hurry -- for one, it would suggest that the split was preordained, and not a joint WG decision, a point that Bilel was seeking clarification on. Kireeti. ------_=_NextPart_001_01C3174F.E120113A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: On BGP and VPLS

Rick, Marco

  I concur with Kireeti - based on Alex previous = e-mails,  a consensus already created during the last three weeks = should not be impacted by the new re-org, which in Alex's view is more = a management issue, to offload the work of the current WG.

  Reading again the e-mails from Alex, it was = not stipulated anywhere that a re-org would trigger a new process of = selecting the WDs.

Cheers
   Vasile

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net] =
Sent: Friday, May 09, 2003 5:37 PM
To: kireeti@juniper.net; rwilder@masergy.com; = zinin@psg.com
Cc: ppvpn@nortelnetworks.com
Subject: RE: On BGP and VPLS


Hi Rick,

> Regarding the last part of your message, the = working group chairs have
> been asked to hold off of declarations of = consensus on drafts in the
> wake of discussions of re-organizing (ie. = splitting) of the group.

What's the rationale for holding off declarations of = consensus?  This decision is two weeks overdue, and the split (if = it happens) could take several more weeks.

It would be a complete travesty if a simple consensus = call took weeks but a major decision like a split of the WG was = completed in a hurry -- for one, it would suggest that the split was = preordained, and not a joint WG decision, a point that Bilel was = seeking clarification on.

Kireeti.

------_=_NextPart_001_01C3174F.E120113A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 11 06:20:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01677 for ; Sun, 11 May 2003 06:20:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4BAMhr01348 for ; Sun, 11 May 2003 06:22:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4BAMei28788 for ; Sun, 11 May 2003 06:22:40 -0400 (EDT) X-Original-Recipient: ppvpn@nortelnetworks.com Message-ID: <3EBE2311.9070503@pi.se> Date: Sun, 11 May 2003 12:16:49 +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: steven.wright@BellSouth.com CC: ppvpn@nortelnetworks.com Subject: Re: vpls scaling question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailc.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailc.telia.com [194.22.190.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Steve, just to make sure we are on the same field. For me a vpls is a service I as an oprator offer a customer, could you please give me a scenario where that customer would need 10,000,000 VLANs. If you are talikng about number of vpls's in the operator network, 10,000,000 "service instances" is not a problem, in fact it would be a blessing :) /Loa Steven.Wright wrote: > to clarify the INTRA- AS vpls case > I would like to better understand the expected capabilities of INTRA-AS > vpls vs a network of Ethernet switches. > > What is the scaling objective for vpls ? > Current generation Ethernet switches have evolved from the 4096 > VLAN/network to 4096 VLAN/port. Scale limits on SP Ethernet networks > are typically driven by other factors e.g. MAC address table size, > issues with multicast etc. > > Is vpls intended to tackle any of those scale constraints ? or to put it > another way... > Current Ethernet switch networks can support on the order of 10,000 VLAN > service instances. Will vpls enable scaling to the 10,000,000 or so > service instances/AS necessary to enable Ethernet as a residential service ? > > > > > > -----Original Message----- > *From:* Steven.Wright [mailto:steven.wright@bellsouth.com] > *Sent:* Wednesday, April 23, 2003 5:04 PM > *To:* *Subject:* vpls scaling question > > vpls is proposed as a mechanism to enable large-scale Ethernet networks. > Can anyone quantify for me at what stage flat Ethernet networks > break and vpls is required ? > i.e what should the decision criteria be to convert an Ethernet > network to a vpls network ? > Steven Wright > BellSouth > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 11 06:51:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01978 for ; Sun, 11 May 2003 06:51:54 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4BAsNr06764 for ; Sun, 11 May 2003 06:54:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4BAsJB05833 for ; Sun, 11 May 2003 06:54:20 -0400 (EDT) X-Original-Recipient: ppvpn@nortelnetworks.com Message-ID: <3EBE2A92.90603@pi.se> Date: Sun, 11 May 2003 12:48:50 +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: "Fang, Luyuan, ALABS" CC: "Nagarajan, Ananth [NTWK SVCS]" , jeremy.de_clercq@alcatel.be, Thomas Narten , Alex Zinin , ppvpn@nortelnetworks.com Subject: Re: IMPORTANT: Strategy for VPN work in IETF References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: maila.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: maila.telia.com [194.22.194.231] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit All, many of the points brought up by Thomas, Jeremy, Ananth and Luyuan valid. I would agree that if there is like 13 docs that needs to go into IESG review shortly for the L3VPNs only, this in itself is proof of that there is an abundance of work to be undertaken in the L3VPN area. Haven't checked but if there are MIB modules among those docs, one shouldn't underestimate the amont of work that needs to go into preparing those docs for IESG review. The amount of work is even larger for the L2VPNs. There seems to a, "if only thinking" around the split. "If only we'd done this along time ago!" or "It would have been better if we only had done this from start!". While I can agree on the sentiment, it is focusing on the wrong problem. We have a situation where we need to speed up the output in this ppvpn area, I don't think there is an agreement on this? My experience from the mpls wg is that I as a wg chair very often becomes a bottleneck, solely on reeading and crosschecking capacity. Now if Alex is proposing to throw more manpower on those tasks in an area that is understood to be work intensive, he nees support in this! I really think there are separate issues here, but where splitting the wg could contribute solve more than one, simple by adding fresh blood. - current work load, more people more work - generic co-ordination, an important task for wg chairs and the tasks would be much clearer - "wrapping" up of L3VPN, maybe another mindset than in the inventive phase - new charters, more clearly defining where to go - co-ordination wioth other standards bodies, which is possibly a more or less full time task in itself. - moving the ppvpn work to another area, the current proposal addresses my concerns - closing down the Sub-IP area, don't feel enthusiastic about, but the arguments are strong Conclusion is that if we want to "split work" we do this by sllitting the wg, and we don't wait, because waiting involves delaying. I won't claim that the two months to Vienna is "critical", but holding off decision until after a dual session and starting that process then probably takes close to the autumn meeting. And going on in a non-decision situation would be worse than anything else. I'm ready to say - "Let's jump!" but could understand if a shorter period of discussion is still needed. /Loa Fang, Luyuan, ALABS wrote: > I agree with Jeremy and Ananth. > Luyuan > -----Original Message----- > From: Nagarajan, Ananth [NTWK SVCS] [mailto:ananth.nagarajan@mail.sprint.com] > Sent: Friday, May 09, 2003 11:52 AM > To: jeremy.de_clercq@alcatel.be; Thomas Narten > Cc: Alex Zinin; ppvpn@nortelnetworks.com > Subject: RE: IMPORTANT: Strategy for VPN work in IETF > > I think I agree with Jeremy here. After thinking about the proposed split for some time, I realized that (as I said earlier) it would have made more sense if this was done as soon as L2VPN/PWE3-related stuff was brought into the WG. I also feel that there are several "generic" documents, in addition to the ones I brought up on this thread some time ago, and it will become increasingly complex to decide where those kind of documents would fit. > My preference is to schedule two sessions at Vienna, and spend some time discussing this, before any decision is made. > PS: Another potential problem that would happen is having to subscribe to both the l2 and l3 vpn mailing lists and getting duplicate emails everytime a generic issue is discussed. > Ananth > > -----Original Message----- > > From: jeremy.de_clercq@alcatel.be [] > > Sent: Friday, May 09, 2003 9:54 AM > > To: Thomas Narten > > Cc: Alex Zinin; ppvpn@nortelnetworks.com > > Subject: Re: IMPORTANT: Strategy for VPN work in IETF > > > > > > Hi Thomas, all, > > > > > The chairs themselves seem to agree that there are some 13 documents > > > on L3 that are not through the system yet. I'm a bit > > concerned to hear > > > that there has been minimal discussion on L3 topics over the last > > > year, given the number of L3 work items that apparently need to get > > > completed. > > > > > > The above could be read as indicating that the discussion/urgency of > > > the L2 work is pushing out or drowning out discussion on L3 > > topics. If > > > that is the case, a separate WG, mailing list, etc., may well help. > > > I'm assuming the L3 work is important and should get completed. > > > > I believe that it can also be read as indicating that many feel that > > most of the (current) L3VPN work is stable and agreed upon, > > and doesn't > > need more discussion within the WG. As was already hinted previously, > > the progress of the L3VPN work has been delayed (for a long time) > > because the framework and requirements documents needed to be accepted > > first. > > > > I do believe however that several proposed new working items (QoS, > > security, management, multicast, etc.) have received little attention > > from the WG because of the current L2VPN (VPLS) > > discussions/urgency. But > > as many of these are aimed at both L2 and L3VPNs, and as I don't find > > reference to these items in the proposed charters, I > > understand that the > > goal of the proposed split is not to accomodate these. > > > > On one hand, I believe that the idea of two separate WGs is a > > good one, > > but on the other hand, I'm not sure how much it will help > > now, so far in > > the process. > > > > I also personally believe that the PPVPN WG has produced valuable > > results, and is making progress on complex topics every day > > (look at the > > current IEEE vs VPLS discussions on this list). And this despite the > > fact that the 'market' is not waiting and despite the fact that the > > number of interested individuals (from different backgrounds: SPs, > > vendors, academic and other standard bodies) is very large. > > > > Jeremy. > > > > > > > > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 11 21:58:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17143 for ; Sun, 11 May 2003 21:58:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4C21Or14368 for ; Sun, 11 May 2003 22:01:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4C21Ki28957 for ; Sun, 11 May 2003 22:01:20 -0400 (EDT) Date: Mon, 12 May 2003 10:59:48 +0900 (JST) Message-Id: <20030512.105948.41638476.suzuki.muneyoshi@lab.ntt.co.jp> To: ppvpn@nortelnetworks.com Cc: suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: IMPORTANT: Strategy for VPN work in IETF From: Muneyoshi Suzuki In-Reply-To: <3EBE2A92.90603@pi.se> References: <3EBE2A92.90603@pi.se> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I second Loa. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. > many of the points brought up by Thomas, Jeremy, Ananth and Luyuan > valid. > > I would agree that if there is like 13 docs that needs to go into IESG > review shortly for the L3VPNs only, this in itself is proof of that > there is an abundance of work to be undertaken in the L3VPN area. > Haven't checked but if there are MIB modules among those docs, one > shouldn't underestimate the amont of work that needs to go into > preparing those docs for IESG review. > > The amount of work is even larger for the L2VPNs. > > There seems to a, "if only thinking" around the split. "If only we'd > done this along time ago!" or "It would have been better if we only had > done this from start!". > While I can agree on the sentiment, it is focusing on the wrong problem. > > We have a situation where we need to speed up the output in this ppvpn > area, I don't think there is an agreement on this? > > My experience from the mpls wg is that I as a wg chair very often > becomes a bottleneck, solely on reeading and crosschecking capacity. Now > if Alex is proposing to throw more manpower on those tasks in an area > that is understood to be work intensive, he nees support in this! > > I really think there are separate issues here, but where splitting the > wg could contribute solve more than one, simple by adding fresh blood. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 05:51:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06595 for ; Mon, 12 May 2003 05:51:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4C9sH026782 for ; Mon, 12 May 2003 05:54:17 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4C9sEV26090 for ; Mon, 12 May 2003 05:54:14 -0400 (EDT) Message-ID: <3EBF6ECE.A2260AE0@alcatel.be> Date: Mon, 12 May 2003 11:52:14 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin Cc: Thomas Narten , ppvpn@nortelnetworks.com Subject: Re: IMPORTANT: Strategy for VPN work in IETF References: <3EBBC117.D5730B6C@alcatel.be> <190247000317.20030509160024@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/12/2003 11:52:14, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/12/2003 11:52:16, Serialize complete at 05/12/2003 11:52:16 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: bt0rjw.god.bel.alcatel.be X-SMTP-MAIL-FROM: jeremy.de_clercq@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc240.alcatel.be [195.207.101.240] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Alex, > > I believe that it can also be read as indicating that many feel that > > most of the (current) L3VPN work is stable and agreed upon, and doesn't > > need more discussion within the WG. > > I'd like to make a particular comment on those documents considered > "stable" and "done". Very often it seems that once the active > discussion in the WG is settled, this is it, the document is ready to > fly and not much attention is needed. My experience as an AD and an > IESG member is quite different. Quite often considerable issues are > found during the AD-review and IESG-review processes. I am not talking > about fundamental disagreements like whether MPLS is good or evil, but > about plain technical issues, security aspects, etc. These are parts > of the path of a document through the IETF process and often require > the same level of attention and focus of the WG as during the first > (intra-WG) phase of it. So, my point here is that we should not > underestimate the amount of work that is left for the existing L3 > documents. I agree with this issue. My fear in fact is that the problem there is having "the WG" review a work item that is perceived as 'stable' or non-controversial or should I say 'not hot', and I fear that often this is ortoghonal to whether the WG has other work on its plate or not. Other WGs also struggle with this problem and have even proposed to nominate a 'team of experts' that somehow devotes itself to review WG docs. In many situations, when a WG considers a doc as being 'stable', the WG remains silent and the necessary 'plain technical issues' are discussed between the authors and the ADs... But I don't have a solution for this problem either. > > As was already hinted previously, the progress of the L3VPN work has > > been delayed (for a long time) because the framework and > > requirements documents needed to be accepted first. > > This sounds like the delays for those docs have been primarily on the > IESG side. I think it would be interesting to take a look at the logs > in the ID tracker to see where exactly the delays were. It was not my intention at all to say that the delays were on the IESG side. I just pointed out that the 'next steps' for the other L3 work were delayed because the framework and requirements work was not finalised. Who is responsible for the delays is a different question (that I'm not interested in answering ;-). We can just say that finalising this fw and req work is a task of the WG, and sending good documents to the IESG is a task of the WG. > > I do believe however that several proposed new working items (QoS, > > security, management, multicast, etc.) have received little attention > > from the WG because of the current L2VPN (VPLS) discussions/urgency. But > > as many of these are aimed at both L2 and L3VPNs, and as I don't find > > reference to these items in the proposed charters, I understand that the > > goal of the proposed split is not to accomodate these. > > Could you send the draft names, pls? Note that I'm not implying that they should be in the first charters. I understand your 'basic things first' reasoning. Just wanted to say that they've had little attention. A few examples: - draft-ietf-ppvpn-bgp-ipv6-vpn - draft-ooms-ppvpn-mcast-overview (applies to L2 and L3, expired) - draft-chiussi-ppvpn-qos-framework (L2 and L3) and draft-declercq-ppvpn-l3vpn-qos (L3) - draft-raggarwa-ppvpn-tunnel-encap-sig-00.txt (applies to L2 and L3) - draft-yacine-ppvpn-mgt-frwk-00.txt Thanks, Jeremy. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 06:27:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07182 for ; Mon, 12 May 2003 06:27:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CATd014265 for ; Mon, 12 May 2003 06:29:39 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CATa101287 for ; Mon, 12 May 2003 06:29:37 -0400 (EDT) Message-ID: <3EBF1C3D.7040207@nortelnetworks.com> Date: Sun, 11 May 2003 23:59:57 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Don Fedyk" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? References: <3EBC06ED.4060700@lucent.com> <61241310626.20030509142534@psg.com> <162274975293.20030509234639@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex You have missed some important facts here. There were other VPN BoFs that were unsuccessful. It was very tough just to get a VPN WG going. Early efforts to keep the VPN space small and focused were unsuccessful. L2VPNs have a symbiotic/parasitic relationship with L3VPN technology. The wide scope of VPNs is the nature of the beast. What I find disturbing is the process of this split logic is superficial and the reorganization is rushed. How much time have you spent with stake holders trying to address the current issues? Communication between the ADs the IESG and the WG chairs and the members is perplexing from my standpoint. I suggest it would be more fruitful to spend time from now to Vienna advancing current work and seeing what is holding up the rest. Lets get this train back on the rails before, if necessary, we split the tracks. Don Alex Zinin wrote: >2. Data about PPVPN WG: > > BOF'ed : Pittsburgh, Aug 03, 2000 (NBVPN BOF) > 1st meeting : San Diego , Dec 14, 2000 (PPVPN BOF/WG) > WG drafts : 17 (as of May 09, 2003) > Submitted to IESG : 3 (L3 framework, L3 reqs, generic reqs) > Approved, in RFC-ed queue : None (as of May 09, 2003) > RFCs published : None (as of May 09, 2003) > >3. Problem statement. > > As seen by ADs: slow progress on L3 and L2 VPN work (see section 2 > above) caused by comparatively wide problem space with unusually > big number of correlated technologies (L2, bridging, tunneling, > routing, signalling, etc.) that in turn results in a big number of > tasks and documents within the WG. Overloading of the WG resources > (management cycles, mailing list, and face-to-face meeting time) > causes slow progress on the existing WG documents that (because of > the number of incomplete items) keeps continuing VPN technology > developments outside the WG and makes the process within the WG and > its results less relevant to the community and the industry. Unless > addressed, the situation is expected to get only worse. > >4. Summary of the solution under consideration > > 1. Put L3 and L2 work in separate WGs > Analysis of the L3 and L2 remaining and potential future work items > has shown that there is a sufficient amount of work in each area to > warrant a separate WG. Smaller and more focused WGs tend to be > more efficient in terms of achieving consensus and completing > their tasks. > > 2. Focus the charters to ensure progress on items already in > the pipe; expand the charters and add more work items as > things progress > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 07:26:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08676 for ; Mon, 12 May 2003 07:26:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CBSZ001024 for ; Mon, 12 May 2003 07:28:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CBSW107729 for ; Mon, 12 May 2003 07:28:32 -0400 (EDT) Message-Id: <200305121123.HAA08502@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-bgpvpn-auto-04.txt Date: Mon, 12 May 2003 07:23:37 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Using BGP as an Auto-Discovery Mechanism for Provider-provisioned VPNs Author(s) : H. Ould-Brahim et al. Filename : draft-ietf-ppvpn-bgpvpn-auto-04.txt Pages : 11 Date : 2003-5-9 In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for both layer-2 VPN architectures and layer-3 VPNs ([VPN-VR]). This mechanism is based on the approach used by [RFC2547-bis] for distributing VPN routing information within the service provider(s). Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-bgpvpn-auto-04.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-ietf-ppvpn-bgpvpn-auto-04.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-ietf-ppvpn-bgpvpn-auto-04.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-5-9124005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-bgpvpn-auto-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-bgpvpn-auto-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-9124005.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 07:46:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09209 for ; Mon, 12 May 2003 07:46:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CBnRT09118 for ; Mon, 12 May 2003 07:49:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CBnOt17500 for ; Mon, 12 May 2003 07:49:24 -0400 (EDT) X-Original-Recipient: dwfedyk@nortelnetworks.com Message-ID: <3EBF88ED.6060006@pi.se> Date: Mon, 12 May 2003 13:43:41 +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: "Don Fedyk" CC: Alex Zinin , ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? References: <3EBC06ED.4060700@lucent.com> <61241310626.20030509142534@psg.com> <162274975293.20030509234639@psg.com> <3EBF1C3D.7040207@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailb.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: dwfedyk@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailb.telia.com [194.22.194.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Don, with exception of the allegation that Alex don't spend enough time with "stake holders", this seems to be a fair description of the history, but that's what it is - history. How about looking forward? /Loa Don Fedyk wrote: > Alex > > You have missed some important facts here. There were other VPN BoFs > that were unsuccessful. It was very tough just to get a VPN WG going. > Early efforts to keep the VPN space small and focused were unsuccessful. > L2VPNs have a symbiotic/parasitic relationship with L3VPN technology. > The wide scope of VPNs is the nature of the beast. > What I find disturbing is the process of this split logic is superficial > and the reorganization is rushed. How much time have you spent with > stake holders trying to address the current issues? Communication > between the ADs the IESG and the WG chairs and the members is perplexing > from my standpoint. I suggest it would be more fruitful to spend time > from now to Vienna advancing current work and seeing what is holding up > the rest. Lets get this train back on the rails before, if necessary, > we split the tracks. > > Don > > > Alex Zinin wrote: > >> 2. Data about PPVPN WG: >> >> BOF'ed : Pittsburgh, Aug 03, 2000 (NBVPN BOF) >> 1st meeting : San Diego , Dec 14, 2000 (PPVPN BOF/WG) >> WG drafts : 17 (as of May 09, 2003) >> Submitted to IESG : 3 (L3 framework, L3 reqs, generic reqs) >> Approved, in RFC-ed queue : None (as of May 09, 2003) >> RFCs published : None (as of May 09, 2003) >> >> 3. Problem statement. >> >> As seen by ADs: slow progress on L3 and L2 VPN work (see section 2 >> above) caused by comparatively wide problem space with unusually >> big number of correlated technologies (L2, bridging, tunneling, >> routing, signalling, etc.) that in turn results in a big number of >> tasks and documents within the WG. Overloading of the WG resources >> (management cycles, mailing list, and face-to-face meeting time) >> causes slow progress on the existing WG documents that (because of >> the number of incomplete items) keeps continuing VPN technology >> developments outside the WG and makes the process within the WG and >> its results less relevant to the community and the industry. Unless >> addressed, the situation is expected to get only worse. >> >> 4. Summary of the solution under consideration >> >> 1. Put L3 and L2 work in separate WGs >> Analysis of the L3 and L2 remaining and potential future work items >> has shown that there is a sufficient amount of work in each area to >> warrant a separate WG. Smaller and more focused WGs tend to be >> more efficient in terms of achieving consensus and completing >> their tasks. >> >> 2. Focus the charters to ensure progress on items already in >> the pipe; expand the charters and add more work items as >> things progress >> >> >> > > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 07:48:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09258 for ; Mon, 12 May 2003 07:48:16 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CBojT10869 for ; Mon, 12 May 2003 07:50:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CBogt19642 for ; Mon, 12 May 2003 07:50:43 -0400 (EDT) Subject: Re: On BGP and VPLS From: Giles Heron To: Kireeti Kompella Cc: Alex Zinin , ppvpn@nortelnetworks.com In-Reply-To: <20030509114322.R57166@kummer.juniper.net> References: <51133594448.20030502191439@psg.com> <20030509114322.R57166@kummer.juniper.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 12 May 2003 12:42:35 +0000 Message-Id: <1052743355.2873.22.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Kireeti, sorry for the late reply on this... On Fri, 2003-05-09 at 19:18, Kireeti Kompella wrote: > Hi Alex, > > On Fri, 2 May 2003, Alex Zinin wrote: [snip] > > 2. Distribution of information > > > > When used as an IP routing protocol, BGP distributes routes among > > all participating routers. > > For 2547, you have the same issue: BGP distributes routes among *all* > participating routers, whereas only a few are really interested in them. > So why is this an issue for VPLS but not for 2547? The distribution > mechanisms are identical. I'm not sure the issues are quite the same. In 2547, as far as I understand it, a given labelled route announcement from a PE must be sent to every other PE with a VRF matching the route target for that announcement. In VPLS a unique label is required by each other PE which is a member of a given VPLS, so each label advertised is used by exactly one other PE. So it's a question of degree I think? Or to put it another way, with respect to the set of all PEs: Distribution of IPv4 routes can be characterised as "broadcast". Distribution of VPN-IPv4 labelled routes can be characterised as "multicast". Distribution of VPLS labels can be characterised as "unicast". Why select a broadcast mechanism (BGP with RRs) to meet a unicast requirement? [rest snipped] Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 09:26:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11293 for ; Mon, 12 May 2003 09:26:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CDSZT02766 for ; Mon, 12 May 2003 09:28:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CDSWU04461 for ; Mon, 12 May 2003 09:28:32 -0400 (EDT) Message-ID: <3EBFA104.2020302@nortelnetworks.com> Date: Mon, 12 May 2003 09:26:28 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Don Fedyk" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson CC: "Don Fedyk" , Alex Zinin , ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? References: <3EBC06ED.4060700@lucent.com> <61241310626.20030509142534@psg.com> <162274975293.20030509234639@psg.com> <3EBF1C3D.7040207@nortelnetworks.com> <3EBF88ED.6060006@pi.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Loa My point was that if you don't understand the history you will make the same mistakes. There is a reason the WG is where it is and only a portion of this has to do with the Charter, or organization. I 'm all for moving forward, Don Loa Andersson wrote: > Don, > > with exception of the allegation that Alex don't spend enough time with > "stake holders", this seems to be a fair description of the history, but > that's what it is - history. How about looking forward? > > /Loa > > Don Fedyk wrote: > >> Alex >> >> You have missed some important facts here. There were other VPN BoFs >> that were unsuccessful. It was very tough just to get a VPN WG >> going. Early efforts to keep the VPN space small and focused were >> unsuccessful. L2VPNs have a symbiotic/parasitic relationship with >> L3VPN technology. The wide scope of VPNs is the nature of the beast. >> What I find disturbing is the process of this split logic is >> superficial and the reorganization is rushed. How much time have you >> spent with stake holders trying to address the current issues? >> Communication between the ADs the IESG and the WG chairs and the >> members is perplexing from my standpoint. I suggest it would be >> more fruitful to spend time from now to Vienna advancing current work >> and seeing what is holding up the rest. Lets get this train back on >> the rails before, if necessary, we split the tracks. >> >> Don >> >> >> Alex Zinin wrote: >> >>> 2. Data about PPVPN WG: >>> >>> BOF'ed : Pittsburgh, Aug 03, 2000 (NBVPN BOF) >>> 1st meeting : San Diego , Dec 14, 2000 (PPVPN BOF/WG) >>> WG drafts : 17 (as of May 09, 2003) >>> Submitted to IESG : 3 (L3 framework, L3 reqs, generic reqs) >>> Approved, in RFC-ed queue : None (as of May 09, 2003) >>> RFCs published : None (as of May 09, 2003) >>> >>> 3. Problem statement. >>> >>> As seen by ADs: slow progress on L3 and L2 VPN work (see section 2 >>> above) caused by comparatively wide problem space with unusually >>> big number of correlated technologies (L2, bridging, tunneling, >>> routing, signalling, etc.) that in turn results in a big number of >>> tasks and documents within the WG. Overloading of the WG resources >>> (management cycles, mailing list, and face-to-face meeting time) >>> causes slow progress on the existing WG documents that (because of >>> the number of incomplete items) keeps continuing VPN technology >>> developments outside the WG and makes the process within the WG and >>> its results less relevant to the community and the industry. Unless >>> addressed, the situation is expected to get only worse. >>> >>> 4. Summary of the solution under consideration >>> >>> 1. Put L3 and L2 work in separate WGs >>> Analysis of the L3 and L2 remaining and potential future work >>> items >>> has shown that there is a sufficient amount of work in each >>> area to >>> warrant a separate WG. Smaller and more focused WGs tend to be >>> more efficient in terms of achieving consensus and completing >>> their tasks. >>> >>> 2. Focus the charters to ensure progress on items already in >>> the pipe; expand the charters and add more work items as >>> things progress >>> >>> >>> >> >> >> >> >> > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 09:30:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11411 for ; Mon, 12 May 2003 09:30:57 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CDXRT07304 for ; Mon, 12 May 2003 09:33:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CDXOO09811 for ; Mon, 12 May 2003 09:33:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: unsubscribe Date: Mon, 12 May 2003 09:31:27 -0400 Message-ID: Thread-Topic: unsubscribe Thread-Index: AcMYismdpczCcF1NST+pn2c7qnUnkA== From: "Aleksey Tolchinskiy" To: X-SMTP-HELO: ms3.us.didata.com X-SMTP-MAIL-FROM: Aleksey.Tolchinskiy@us.didata.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ms3.us.didata.com [204.56.122.90] X-LYRIS-Message-Id: unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 10:16:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14284 for ; Mon, 12 May 2003 10:16:21 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CEInT15069 for ; Mon, 12 May 2003 10:18:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CEIkK19907 for ; Mon, 12 May 2003 10:18:47 -0400 (EDT) Message-Id: <200305121412.h4CECbrS029943@rtp-core-1.cisco.com> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: Internet transparency In-reply-to: Your message of Fri, 09 May 2003 15:10:06 -0700. <60243982388.20030509151006@psg.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: Mon, 12 May 2003 10:12:37 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Eric> However, in the case of 2547bis, the "multiple providers" are expected Eric> to be a small number of closely cooperating service providers. There Eric> really isn't much provision for running the VPNs over the public Eric> Internet. It might be good to have this "public Internet Eric> transparency" excluded from the charter. Presumably, that would Eric> prevent the IESG from later rejecting the specs on the grounds that Eric> they don't provide public Internet transparency. Alex> Is this specific to the case of 2547 only or generic to all L3 Alex> mechanisms? If the former, I would rather not like the charter to say Alex> so. I think this applies to all the schemes. Even the CE-based schemes aren't viable, in my opinion, over the public Internet because issues of QoS, SLA, and accountability really prevent a company from using the public Internet as the backbone for its intranet. Alex> As for rejecting the 2547-related specs, I think it would be very Alex> useful if the applicability statement highlighted the detail about Alex> cooperating SPs and state that Internet transparency is a non-goal. The AS already says (in section 1, Introduction): 2547-style VPNs are optimized for the situation in which a customer (an enterprise) expects a service provider to operate and maintain the customer's "backbone" (i.e., the customer's inter-site routing). As such, the service provider becomes a "business partner" of the enterprise. The technical mechanisms accommodate the case in which a number of closely cooperating SPs can jointly offer the VPN service to a customer, in that the BGP-based route distribution mechanisms can operate between different SPs. If a set of SPs have sufficient agreements with respect to QoS, SLA, etc., then the customer's VPN could have sites attached to different SPs from that set. 2547-style VPNs are NOT an optimum ["appropriate" might be a better word] solution for the customer who wants to purchase local connectivity from whatever ISP happens to offer the best price at a given site, nor for the customer who wants his VPN backbone to consist of tunnels running over the public Internet. [2547bis] specifies the inter-AS mechanisms that allow a single VPN to have sites attached to different SPs.. However, the design center is not an environment where a given VPN is spread among a very large number (e.g., hundreds) of SPs. However, in cases where remote offices, individual telecommuters, etc., must use the public Internet to access the VPN, it is possible to "tunnel" the remote traffic to a PE router, and the PE router will treat the traffic as if it had arrived over an interface connected to the PE. Remote PPP connections can be tunneled via L2TP to a PE router; IPsec tunnels can also be used to tunnel traffic to a PE router across the public Internet. Of course when the public Internet is used, issues such as QoS and SLAs must be carefully considered. Isn't this clear enough? From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 10:34:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16330 for ; Mon, 12 May 2003 10:34:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CEbOT21877 for ; Mon, 12 May 2003 10:37:24 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CEbLd06857 for ; Mon, 12 May 2003 10:37:21 -0400 (EDT) Message-Id: <200305121434.h4CEY7u47388@merlot.juniper.net> To: Alex Zinin cc: Pedro Roque Marques , ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: Your message of "Wed, 07 May 2003 11:28:15 PDT." <6857870813.20030507112815@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46228.1052750047.1@juniper.net> Date: Mon, 12 May 2003 07:34:07 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > > This point seems to be predicated in the statement that "BGP uses the > > NLRI field to carry IP reachability"... > > Yes, plus that "BGP is an IP routing protocol." > > > It opens up a sort of philosophical discussion on BGP. This is of > > course a highly subjective topic which is hard to quantify or to prove > > by logical terms. > > > Allow me to present my personal view. > > > > BGP is a particular implementation of an algorithm that performs non > > looping database flooding distribution. That algorithm consists mostly > > on the path vector (used both in ebgp and route reflection) plus route > > advertisement rules. This is the publicly specified part of the beast. > > This is where we disagree in the first place. > > There's a fine line between a database distribution flooding algorithm > and a path-vector routing algorithm. BGP is clearly not the former. Your argument that "BGP is clearly not the former" seems to be in the same category as the argument that "RSVP doesn't do routing". As you may recall the latter was used by some folks few years ago as the reason not to extend RSVP to support explicitly routed LSP. Reality (market) proved this argument to be irrelevant from the practical point of view. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 10:39:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16672 for ; Mon, 12 May 2003 10:39:27 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CEftT26127 for ; Mon, 12 May 2003 10:41:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CEfrd13150 for ; Mon, 12 May 2003 10:41:53 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Rick Wilder , Kireeti Kompella , Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: current wg activities Date: Mon, 12 May 2003 10:40:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31894.63990EEC" X-LYRIS-Message-Id: 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_01C31894.63990EEC Content-Type: text/plain; charset="iso-8859-1" Rick, Marco, In Alex's email on wg splitting it indicates that: "It is our intention to complete this process by the Vienna IETF meeting. Also, these changes are being made for management reasons and are not intended to be a "reset" on WG activities or to halt or interrupt progress on current ongoing WG activities." Should we assume as well that the last call for base l3vpn documents is still in effect or it has been halted (since I saw the drafts in the new charter)? thanks. Hamid. > -----Original Message----- > From: Rick Wilder [mailto:rwilder@masergy.com] > Sent: Friday, May 09, 2003 4:55 PM > To: Kireeti Kompella; Alex Zinin > Cc: ppvpn@nortelnetworks.com > Subject: RE: On BGP and VPLS > > > > Kireeti, > > Regarding the last part of your message, the working group chairs have > been asked to hold off of declarations of consensus on drafts in the > wake of discussions of re-organizing (ie. splitting) of the group. > > Rick > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, May 09, 2003 3:18 PM > To: Alex Zinin > Cc: ppvpn@nortelnetworks.com > Subject: Re: On BGP and VPLS > > Hi Alex, > > On Fri, 2 May 2003, Alex Zinin wrote: > > > More specifically, below I tried to put together a list of concerns > > I have about the approach described in draft-kompella-ppvpn-vpls, > > that I would like the WG to consider. > > > > 1. Use of the NLRI field > > > > As an IP routing protocol, BGP uses the NLRI field to carry IP > > reachability information in the form of IP prefixes. > > As an IP routing protocol, sure. But nowhere in RFC 2858 does it > say that BGP has to only be an IP routing protocol. > > Furthermore, if BGP is used for L2 autodiscovery (which is by the way > a PPVPN *Working Group* document), the exact same issue applies. > > > 2. Distribution of information > > > > When used as an IP routing protocol, BGP distributes routes among > > all participating routers. > > For 2547, you have the same issue: BGP distributes routes among *all* > participating routers, whereas only a few are really > interested in them. > So why is this an issue for VPLS but not for 2547? The distribution > mechanisms are identical. > > > 3. Aggregation of information for large-scale operation > > Nowhere does 2858 talk about aggregation; in fact, the notion of > aggregation is not even mentioned. > > -------------- > > On the issues of BGP for VPLS and also of single solution vs. > multiple, > there seems to me (I'm not a PPVPN WG chair!) good consensus that the > WG wants a BGP solution, and also that they want multiple solutions. > Are you, Alex, proposing to override that consensus? > > The call for consensus to make the various VPLS drafts WG documents > was made over 3 weeks ago, and the call was supposed to last one week. > We are thus two weeks overdue. I would like the WG chairs to declare > what consensus they see, keeping in mind the email that Bert Wijnen > (who is a seasoned Area Director) sent to the TE WG just > today, saying: > > || But it is WG chair(s) who decide on how to gauge WG conensus. > > Or, from RFC 2418: > > 3.3. Session management > > Working groups make decisions through a "rough consensus" process. > .... > It is up to the Chair to determine if rough > consensus has been reached. > > Kireeti. > > > > ------_=_NextPart_001_01C31894.63990EEC Content-Type: text/html; charset="iso-8859-1" current wg activities

Rick, Marco,

In Alex's email on wg splitting it indicates that:

"It is our intention to complete this process by the Vienna IETF meeting.
Also, these changes are being made for management reasons and are not intended
to be a "reset" on WG activities or to halt or interrupt progress on current
ongoing WG activities."

Should we assume as well that the last call for base l3vpn documents
is still in effect or it has been halted (since I saw the
drafts in the new charter)?

thanks.
Hamid.

> -----Original Message-----
> From: Rick Wilder [mailto:rwilder@masergy.com]
> Sent: Friday, May 09, 2003 4:55 PM
> To: Kireeti Kompella; Alex Zinin
> Cc: ppvpn@nortelnetworks.com
> Subject: RE: On BGP and VPLS
>
>
>
> Kireeti,
>
> Regarding the last part of your message, the working group chairs have
> been asked to hold off of declarations of consensus on drafts in the
> wake of discussions of re-organizing (ie. splitting) of the group.
>
> Rick
>
> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Friday, May 09, 2003 3:18 PM
> To: Alex Zinin
> Cc: ppvpn@nortelnetworks.com
> Subject: Re: On BGP and VPLS
>
> Hi Alex,
>
> On Fri, 2 May 2003, Alex Zinin wrote:
>
> >  More specifically, below I tried to put together a list of concerns
> >  I have about the approach described in draft-kompella-ppvpn-vpls,
> >  that I would like the WG to consider.
> >
> >  1. Use of the NLRI field
> >
> >    As an IP routing protocol, BGP uses the NLRI field to carry IP
> >    reachability information in the form of IP prefixes.
>
> As an IP routing protocol, sure.  But nowhere in RFC 2858 does it
> say that BGP has to only be an IP routing protocol.
>
> Furthermore, if BGP is used for L2 autodiscovery (which is by the way
> a PPVPN *Working Group* document), the exact same issue applies.
>
> >  2. Distribution of information
> >
> >    When used as an IP routing protocol, BGP distributes routes among
> >    all participating routers.
>
> For 2547, you have the same issue: BGP distributes routes among *all*
> participating routers, whereas only a few are really
> interested in them.
> So why is this an issue for VPLS but not for 2547?  The distribution
> mechanisms are identical.
>
> >  3. Aggregation of information for large-scale operation
>
> Nowhere does 2858 talk about aggregation; in fact, the notion of
> aggregation is not even mentioned.
>
> --------------
>
> On the issues of BGP for VPLS and also of single solution vs.
> multiple,
> there seems to me (I'm not a PPVPN WG chair!) good consensus that the
> WG wants a BGP solution, and also that they want multiple solutions.
> Are you, Alex, proposing to override that consensus?
>
> The call for consensus to make the various VPLS drafts WG documents
> was made over 3 weeks ago, and the call was supposed to last one week.
> We are thus two weeks overdue.  I would like the WG chairs to declare
> what consensus they see, keeping in mind the email that Bert Wijnen
> (who is a seasoned Area Director) sent to the TE WG just
> today, saying:
>
> || But it is WG chair(s) who decide on how to gauge WG conensus.
>
> Or, from RFC 2418:
>
> 3.3. Session management
>
>    Working groups make decisions through a "rough consensus" process.
> ....
>                          It is up to the Chair to determine if rough
>    consensus has been reached.
>
> Kireeti.
>
>
>
>

------_=_NextPart_001_01C31894.63990EEC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 10:50:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17364 for ; Mon, 12 May 2003 10:50:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CErPT01224 for ; Mon, 12 May 2003 10:53:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CErMY26669 for ; Mon, 12 May 2003 10:53:23 -0400 (EDT) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5E11@trimail2> From: "Serbest, Yetik" To: "'Muneyoshi Suzuki'" , ppvpn@nortelnetworks.com Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 12 May 2003 09:42:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: serbest@tri.sbc.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: I agree with Loa as well. I believe that there is a lot to be done in L2 space (working with 802.1ad etc...). I don't think forming DTs or focus groups would help that much. thanks, yetik > -----Original Message----- > From: Muneyoshi Suzuki [mailto:suzuki.muneyoshi@lab.ntt.co.jp] > Sent: Sunday, May 11, 2003 9:00 PM > To: ppvpn@nortelnetworks.com > Cc: suzuki.muneyoshi@lab.ntt.co.jp > Subject: Re: IMPORTANT: Strategy for VPN work in IETF > > > > I second Loa. > > Thanks, > > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. > > > > many of the points brought up by Thomas, Jeremy, Ananth and Luyuan > > valid. > > > > I would agree that if there is like 13 docs that needs to > go into IESG > > review shortly for the L3VPNs only, this in itself is proof of that > > there is an abundance of work to be undertaken in the L3VPN area. > > Haven't checked but if there are MIB modules among those docs, one > > shouldn't underestimate the amont of work that needs to go into > > preparing those docs for IESG review. > > > > The amount of work is even larger for the L2VPNs. > > > > There seems to a, "if only thinking" around the split. "If > only we'd > > done this along time ago!" or "It would have been better > if we only had > > done this from start!". > > While I can agree on the sentiment, it is focusing on the > wrong problem. > > > > We have a situation where we need to speed up the output > in this ppvpn > > area, I don't think there is an agreement on this? > > > > My experience from the mpls wg is that I as a wg chair very often > > becomes a bottleneck, solely on reeading and crosschecking > capacity. Now > > if Alex is proposing to throw more manpower on those tasks > in an area > > that is understood to be work intensive, he nees support in this! > > > > I really think there are separate issues here, but where > splitting the > > wg could contribute solve more than one, simple by adding > fresh blood. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 10:54:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17479 for ; Mon, 12 May 2003 10:54:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CEv8T05180 for ; Mon, 12 May 2003 10:57:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CEv6Y01929 for ; Mon, 12 May 2003 10:57:06 -0400 (EDT) Message-Id: <200305121452.h4CEqmu48261@merlot.juniper.net> To: Alex Zinin cc: ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: Your message of "Fri, 02 May 2003 19:14:39 PDT." <51133594448.20030502191439@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51739.1052751168.1@juniper.net> Date: Mon, 12 May 2003 07:52:48 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Folks, > > As an Area Director, and an IESG member, I try to express my > technical opinions during WG discussions only when it really matters, > e.g., when I think a WG is going in a wrong direction, or a > technically bad idea is being considered. However, I believe that ADs > do need to do this to prevent surprises when documents get to the > IESG. Also, when documents are ready to go to the RFC status, it is > the responsible AD who takes them to the IESG and defends them there, > so I think it is useful for ADs to communicate their concerns to the > WGs when such exist. > > I have been watching the discussion about draft-kompella-ppvpn-vpls > on the mailing list and didn't get the feeling that certain aspects > of it have been taken seriously enough. Without an attempt to respin > the heated discussion again, it seems it would be useful for the WG > if I provided some feedback on the topic now, when the WG is > discussing the direction in which it should proceed. > > First of all, let me remind you the message Scott and I brought to > the WG in Yokohama--the IESG is very concerned about the tendency of > using routing protocols (and BGP in particular) as a universal > transport mechanism, and a _very_ strong case would need to be made > if the WG decided to go with such a proposal. If the IESG is so much concerned, then it is the IESG's responsibility to substantiate their concerns with *solid* technical arguments that are of practical significance, and not just say that "the IESG is very concerned". So far the IESG clearly failed to do so, as what you put in the rest of this message either lacks solid technical justification (see Pedro's replies to you) or practical significance, or both. Yakov. > > More specifically, below I tried to put together a list of concerns > I have about the approach described in draft-kompella-ppvpn-vpls, > that I would like the WG to consider. > > 1. Use of the NLRI field > > As an IP routing protocol, BGP uses the NLRI field to carry IP > reachability information in the form of IP prefixes. Prefixes > within the NLRI field are used for two main purposes in BGP: a) as > the destination/mask pair in the routes installed by BGP in the > routing table, and b) as a handle to an entry in the BGP RIBs. > > The document in subject changes the semantics of the NLRI field > quite substantially even when compared to 2547. First, all of its > IP prefix-related properties are lost. There is no more IP routing, > or any addressing information in it. Second, the notion of TLVs is > introduced inside this field, which a) is not needed in BGP as an > IP routing protocol, and b) because of its variable length property > changes the nature of the NLRI contents, i.e., it's being a stable > handle in the BGP database. To solve these problems the > implementations would need to use only a part of the contents of > the NLRI field as the handle used to index within the RIBs, and > store the rest as attributes. > > 2. Distribution of information > > When used as an IP routing protocol, BGP distributes routes among > all participating routers. Each router (PE or P using VPN > terminology) is interested in _all_ routes received from its peers; > it selects the best path for each prefix if multiple are available > and installs it in it's routing table; the best paths are > propagated further to other peers. > > The way BGP is used in the document results in a situation where > information relevant only to a subset of routers (e.g. PW-specific, > or VPLS-specific info) is sent to all PEs participating in the BGP > domain. More than that, P routers, usually used as route reflectors > in IP routing, end up storing all information while they are not > using any of it locally. > > Note also, that best path selection that is normally performed by > BGP when it receives information about the same prefix from > multiple peers, is not needed in the VPLS case, and (even if > implementations decided to apply the same algo as in regular BGP) > would just be an artifact. > > The above exposes the difference between the routing nature of BGP > when used for IP (where reachability info is distributed and the > path properties are as important as the info itself), and its > purely transport application in the proposal (where only the fact > of information delivery is important.) > > Interestingly enough, from the transport perspective, BGP, though > reduces the number of sessions a given PE has to maintain (and thus > the sender's complexity), introduces additional overhead from > the receiver's perspective--if a PE router has multiple BGP > sessions (which is normally the case), it will receive the same > information more than once, while clearly a single copy is enough. > > 3. Aggregation of information for large-scale operation > > When distributing information among a large number of systems, it > is important to be able to aggregate information as it travels > further ahead to ensure scalability of the system. In routing this > is achieved by summarizing a set of prefixes and announcing them as > a less specific prefix. For example, AS'es in the Internet do not > exchange granular IP prefixes visible inside IGPs, but instead send > each other aggregate prefixes via BGP. > > It is not clear to me how, given the format of the NLRI field, VPLS > information can be aggregated using the proposal in the document. > > The above gives me a very uncomfortable feeling that the proposal > is stretching BGP to perform functions it was not designed for. > > Below are some additional points that should be taken into > consideration. > > 4. Backwards compatibility and SW upgrade requirements > > Because the proposal suggests using a new AFI/SAFI combination, PE > routers will not be able to announce VPLS information using the > existing BGP infrastructure. All BGP speakers in a SP's network, > including the P routers, will have to be upgraded with new SW, > though information needs to be exchanged only among the PEs. > > 5. Coupling of VPLS and BGP SW > > Putting VPLS-related functions in BGP leads to two unwanted > consequences: > > a) Lesser BGP code stability--bugs in the VPLS part of the code > will likely affect parts of BGP used for Internet routing, > thus increasing the chances of BGP failures in SP networks. > The same argument works in the opposite direction. > > b) Potential dynamic effects--since with a BGP-based approach, > VPLS- and routing-related processes are likely to share > the same internal router resources (such as timers, threads, > locks/mutex'es, queues, memory pools), dynamics of the VPLS > system are likely to influence the dynamics of the routing- > related functions and vice versa. The larger the overlap > between the two systems, the higher are the chances of such > interference. > > My recommendation would be for the WG to consider these points. > > Also, one quite important question I saw brought up by Eric in this > discussion was about the p2p nature of PW signaling in VPLS. I think > this is one of the key questions that we need an agreement on. > > The question asked by Robert today is also quite interesting. > > Regards. > > -- > Alex Zinin > IETF SUB-IP Area Co-Director > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 11:19:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18850 for ; Mon, 12 May 2003 11:19:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CFM4T09640 for ; Mon, 12 May 2003 11:22:05 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CFM1q19019 for ; Mon, 12 May 2003 11:22:02 -0400 (EDT) Message-Id: <200305121517.h4CFHRu49790@merlot.juniper.net> To: Alex Zinin cc: ppvpn@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: Your message of "Fri, 02 May 2003 19:14:39 PDT." <51133594448.20030502191439@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58710.1052752647.1@juniper.net> Date: Mon, 12 May 2003 08:17:27 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, [clipped...] > 3. Aggregation of information for large-scale operation > > When distributing information among a large number of systems, it > is important to be able to aggregate information as it travels > further ahead to ensure scalability of the system. In routing this > is achieved by summarizing a set of prefixes and announcing them as > a less specific prefix. For example, AS'es in the Internet do not > exchange granular IP prefixes visible inside IGPs, but instead send > each other aggregate prefixes via BGP. > > It is not clear to me how, given the format of the NLRI field, VPLS > information can be aggregated using the proposal in the document. It should be abundantly obvious to an informed reader that information aggregation/abstraction is just *one* way to support large-scale operation. But it is certainly *not the only way* possible. Section 15 of draft-ietf-ppvpn-rfc2547bis-03.txt and Section 13 of draft-ietf-ppvpn-as2547-01.txt describe how BGP/MPLS VPNs supports large-scale operation in the absence of aggregation/abstration of VPN routing information. It should be abundantly obvious to an informed reader that use of BGP for autodiscovery (draft-ietf-ppvpn-bgpvpn-auto-03.txt), as well as for VPLS autodiscovery and label distribution utilizes exactly the same mechanisms as BGP/MPLS VPNs to support large-scale operation. > The above gives me a very uncomfortable feeling that the proposal > is stretching BGP to perform functions it was not designed for. IP wasn't designed to support CIDR. TCP wasn't designed to carrying routing information (BGP). RSVP wasn't designed to establish explicitly routed LSPs. etc... And, bwt how do *you* know what BGP was designed for ? If one really wants to know what BGP was (and was not) designed for, then perhaps one should ask the folks who designed BGP. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 11:28:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19832 for ; Mon, 12 May 2003 11:28:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CFUbT14251 for ; Mon, 12 May 2003 11:30:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CFUWR27116 for ; Mon, 12 May 2003 11:30:33 -0400 (EDT) Message-Id: <200305121526.h4CFQsu50248@merlot.juniper.net> To: "Don Fedyk" cc: Alex Zinin , ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? In-Reply-To: Your message of "Sun, 11 May 2003 23:59:57 EDT." <3EBF1C3D.7040207@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61789.1052753214.1@juniper.net> Date: Mon, 12 May 2003 08:26:54 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,dwfedyk@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Don, > Alex > > You have missed some important facts here. There were other VPN BoFs > that were unsuccessful. It was very tough just to get a VPN WG going. > Early efforts to keep the VPN space small and focused were unsuccessful. > L2VPNs have a symbiotic/parasitic relationship with L3VPN technology. > The wide scope of VPNs is the nature of the beast. > > What I find disturbing is the process of this split logic is superficial > and the reorganization is rushed. Agreed. > How much time have you spent with > stake holders trying to address the current issues? Communication > between the ADs the IESG and the WG chairs and the members is perplexing > from my standpoint. Agreed. > I suggest it would be more fruitful to spend time > from now to Vienna advancing current work and seeing what is holding up > the rest. Lets get this train back on the rails before, if necessary, > we split the tracks. I think this is a very reasonble proposal. Yakov. > > Don > > > Alex Zinin wrote: > > >2. Data about PPVPN WG: > > > > BOF'ed : Pittsburgh, Aug 03, 2000 (NBVPN BOF) > > 1st meeting : San Diego , Dec 14, 2000 (PPVPN BOF/WG) > > WG drafts : 17 (as of May 09, 2003) > > Submitted to IESG : 3 (L3 framework, L3 reqs, generic reqs) > > Approved, in RFC-ed queue : None (as of May 09, 2003) > > RFCs published : None (as of May 09, 2003) > > > >3. Problem statement. > > > > As seen by ADs: slow progress on L3 and L2 VPN work (see section 2 > > above) caused by comparatively wide problem space with unusually > > big number of correlated technologies (L2, bridging, tunneling, > > routing, signalling, etc.) that in turn results in a big number of > > tasks and documents within the WG. Overloading of the WG resources > > (management cycles, mailing list, and face-to-face meeting time) > > causes slow progress on the existing WG documents that (because of > > the number of incomplete items) keeps continuing VPN technology > > developments outside the WG and makes the process within the WG and > > its results less relevant to the community and the industry. Unless > > addressed, the situation is expected to get only worse. > > > >4. Summary of the solution under consideration > > > > 1. Put L3 and L2 work in separate WGs > > Analysis of the L3 and L2 remaining and potential future work items > > has shown that there is a sufficient amount of work in each area to > > warrant a separate WG. Smaller and more focused WGs tend to be > > more efficient in terms of achieving consensus and completing > > their tasks. > > > > 2. Focus the charters to ensure progress on items already in > > the pipe; expand the charters and add more work items as > > things progress > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 11:37:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21202 for ; Mon, 12 May 2003 11:37:27 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CFdtT19309 for ; Mon, 12 May 2003 11:39:56 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CFdrR07912 for ; Mon, 12 May 2003 11:39:53 -0400 (EDT) Message-Id: <200305121536.h4CFahu50777@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: Your message of "Mon, 05 May 2003 23:11:40 PDT." <90201253777.20030505231140@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64840.1052753803.1@juniper.net> Date: Mon, 12 May 2003 08:36:43 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Thanks for your input, it is indeed very important for us to be on > the same page here, and I happen to agree with most of what you said. > > I don't think that "solution" == "protocol", but rather a set of > functional components, each addressing its particular problem. The > framework would then put them all together. > > I also view as reasonable an approach where there is a difference > between how intra-domain and inter-domain issues are solved. > > So, from this perspective, the framework MAY very easily look > like this (mechanism == protocol or protocol extension): > > Data-plane : mechanism A > Intra-domain discovery : mechanism B > Intra-domain signaling : mechanism C > Inter-domain discovery : mechanism D > Inter-domain signaling : mechanism C++ > > Of course there must be some architectural glue that brings all > the pieces together. > > What I would like us to avoid is solution space exploration, where > we have many mechanisms for the same function we need, i.e, I would > be disappointed to see us end up with a framework looking like: > > Data-plane : mechanism A, or B, or C > Intra-domain discovery : mechanism D, or E, or F > Intra-domain signaling : mechanism G, or H, or I > Inter-domain discovery : mechanism J, or K, or L > Inter-domain signaling : mechanism M, or N, or O > > This would, in view, impact interoperability. To avoid disappointing you the WG immediately needs to start the discussion on whether to use L2TPv3 encapsulation or MPLS or MPLS over GRE, or MPLS over IPSec. Likewise the WG immediately needs to start the discussion on L2TPv3 vs LDP based signaling. Likewise, the WG immediately needs to start the discussion on BGP vs Radius based auto-discovery. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 12:06:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22385 for ; Mon, 12 May 2003 12:06:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CG8ZT15856 for ; Mon, 12 May 2003 12:08:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CG8W608994 for ; Mon, 12 May 2003 12:08:33 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Yakov Rekhter , Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: RE: On BGP and VPLS Date: Mon, 12 May 2003 12:06:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C318A0.7787768A" X-LYRIS-Message-Id: 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_01C318A0.7787768A Content-Type: text/plain; charset="iso-8859-1" Yakov, > > It should be abundantly obvious to an informed reader that use of > BGP for autodiscovery (draft-ietf-ppvpn-bgpvpn-auto-03.txt), as > well as for VPLS autodiscovery and label distribution utilizes > exactly the same mechanisms as BGP/MPLS VPNs to support large-scale > operation. > > > The above gives me a very uncomfortable feeling that the proposal > > is stretching BGP to perform functions it was not designed for. > > IP wasn't designed to support CIDR. > TCP wasn't designed to carrying routing information (BGP). > RSVP wasn't designed to establish explicitly routed LSPs. > etc... > I add to it that LDP wasn't designed to signal MAC TLVs and to carry l2vpn related information...in fact the whole ietf wasn't designed for sub-ip area (since it is considered temporary)!! Hamid. > And, bwt how do *you* know what BGP was designed for ? If one really > wants to know what BGP was (and was not) designed for, then perhaps > one should ask the folks who designed BGP. > > Yakov. > > ------_=_NextPart_001_01C318A0.7787768A Content-Type: text/html; charset="iso-8859-1" RE: On BGP and VPLS

Yakov,

>
> It should be abundantly obvious to an informed reader that use of
> BGP for autodiscovery (draft-ietf-ppvpn-bgpvpn-auto-03.txt), as
> well as for VPLS autodiscovery and label distribution utilizes
> exactly the same mechanisms as BGP/MPLS VPNs to support large-scale
> operation.
>
> >  The above gives me a very uncomfortable feeling that the proposal
> >  is stretching BGP to perform functions it was not designed for.
>
> IP wasn't designed to support CIDR.
> TCP wasn't designed to carrying routing information (BGP).
> RSVP wasn't designed to establish explicitly routed LSPs.
> etc...
>

I add to it that LDP wasn't designed to signal MAC TLVs and to
carry l2vpn related information...in fact the whole ietf
wasn't designed for sub-ip area (since it is considered temporary)!!

Hamid.

> And, bwt how do *you* know what BGP was designed for ? If one really
> wants to know what BGP was (and was not) designed for, then perhaps
> one should ask the folks who designed BGP.
>
> Yakov.
>
>

------_=_NextPart_001_01C318A0.7787768A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 12:15:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22775 for ; Mon, 12 May 2003 12:15:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CGIRT20655 for ; Mon, 12 May 2003 12:18:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CGIOh20404 for ; Mon, 12 May 2003 12:18:24 -0400 (EDT) Message-Id: <200305121614.h4CGEsu53134@merlot.juniper.net> To: Thomas Narten cc: Alex Zinin , ppvpn@nortelnetworks.com, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: Your message of "Wed, 07 May 2003 12:24:18 EDT." <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <76755.1052756094.1@juniper.net> Date: Mon, 12 May 2003 09:14:54 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Thomas, > Catching up a bit (and summarizing)... [clipped...] > As one example, on the topic of "one vs. multiple solutions", I know > the IESG will ask, why are we standardizing 3 solutions to the same > problem (if that is what the WG thinks it is going to do). The WG will > have to be able to answer that sort of question with a credible > response (and in some cases, a credible justification is that the > solutions are very different and there are different applicabilities > to the mechanisms -- but one needs to look at the details on this). If > the answer simply is "because we want to and we'll let the market > decide", the IESG may well come back and say fine, make them all > experimental, none of them on standards track. Revisit when the market > has decided. And what is wrong with this (make all experimental, revisit when the market has decided) ? > Would that be what the WG wants? Would that be in the > best interests of the IETF and Internet community? I wonder. Even more important what would be in the best interests of the Service Providers ? (as ultimately it is the Service Providers who are going to use this technology). Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 12:24:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23104 for ; Mon, 12 May 2003 12:24:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CGR7T25195 for ; Mon, 12 May 2003 12:27:07 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CGR4h27734 for ; Mon, 12 May 2003 12:27:04 -0400 (EDT) Message-Id: <200305121623.h4CGNeu53899@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN In-Reply-To: Your message of "Wed, 07 May 2003 18:51:57 PDT." <184493545.20030507185157@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79761.1052756620.1@juniper.net> Date: Mon, 12 May 2003 09:23:40 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Folks- > > It is taking longer than I anticipated to set up the mailing lists, so > I am sending the proposed WG charters to this list. These are > _drafts_, so are likely to need more fine-tuning. Below is the > proposed charter for L3VPN. The one on L2VPN is in a separate message. > Comments welcome. Why the list of documents does not include "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs" (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ? Yakov. > > -- > Alex > > Layer 3 Virtual Private Networks (l3vpn) > > Chair(s): > > Area Director(s): > Thomas Narten > Erik Nordmark > > Area Advisor: > Thomas Narten > > Technical Advisor: > Alex Zinin > > Description of Working Group: > > This working group is responsible for defining and specifying a > limited number of solutions for supporting Layer-3 (routed) > Virtual Private Networks (L3VPNs). > > The WG is responsible for standardization of the following solutions: > > 1. BGP/MPLS IP VPNs (based on RFC 2547) > 2. IP VPNs using Virtual Routers > 3. CE-based VPNs using IPSEC > > As part of this effort the WG will work on the following tasks > (additional work items will require rechartering): > > 1. Requirements and framework for Layer 3 VPNs > 2. Solution documents for each approach listed above (including > applicability statements) > 3. MIB definitions for each approach > 4. Security mechanisms for each approach > > Multicast support and Inter-AS considerations are excluded from the charter > at this time. They may be considered for inclusion in an updated charter > at a later time. Future work items may also include OAM support. > > As a general rule, the WG will not create new protocols, but will provide > functional requirements for extensions of the existing protocols that will > be discussed in the protocol-specific WGs. > > WG Milestones (optimistic): > > Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info > (completed) > Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info > (completed) > Aug 2003 Submit L3 VPN Security Analysis to IESG for publication as Info > (draft-fang-ppvpn-security-framework-00) > Aug 2003 Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS > (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01) > > Sep 2003 Submit CE-based specification and AS to IESG for publication as PS > (draft-ietf-ppvpn-ce-based-03) > Sep 2003 Submit Virtual Router specification and AS to IESG for publication a s PS > (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) > Oct 2003 Submit VPN MIB Textual Conventions to IESG for publication as PS > (draft-ietf-ppvpn-tc-mib-02) > Oct 2003 Submit MPLS BGP MIB to IESG for publication as PS > (draft-ietf-ppvpn-mpls-vpn-mib-05) > Oct 2003 Submit VR MIB to IESG for publication as PS > (draft-ietf-ppvpn-vr-mib-04) > > Dec 2003 Submit specification of using IPSEC for PE-PE encapsulation in BGP/M PLS VPNs to IESG > for publication as PS > (draft-ietf-ppvpn-ipsec-2547-03) > Jan 2003 Submit specification of using GRE for PE-PE encapsulation in BGP/MPL S VPNs to IESG > for publication as PS > (draft-ietf-ppvpn-gre-ip-2547-02) > > Jan 2003 Submit specification of CE Route Authentication to IESG for publicat ion as PS > (draft-ietf-ppvpn-l3vpn-auth-03) > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 12:39:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23489 for ; Mon, 12 May 2003 12:39:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CGg7T02769 for ; Mon, 12 May 2003 12:42:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CGg5109510 for ; Mon, 12 May 2003 12:42:05 -0400 (EDT) Message-Id: <200305121637.h4CGbju55730@merlot.juniper.net> To: raszuk@cisco.com cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN In-Reply-To: Your message of "Thu, 08 May 2003 20:06:41 +0200." <3EBA9CB1.99B911B1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84734.1052757465.1@juniper.net> Date: Mon, 12 May 2003 09:37:45 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Robert, > Hi Alex, > > Just two small comments: > > > Multicast support and Inter-AS considerations are excluded from the charter > > at this time. > > This is very bad thing as each extension or proposed solution has to > work both intra and inter domain. There are production deployments > already inter-as and any solution which one would come up and which > would be limited to intra-as would a bad one. Besides while a number of > solutions can be easy to solve intra-domin going out of AS those may no > longer work. So my vote is to delete this line. The Inter-AS border on > L3VPNs is crossed long time ago ;). As Alex said in one of his recent e-mails "I think you might be confusing the IETF with the market". Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 12:45:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23663 for ; Mon, 12 May 2003 12:45:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CGm0T07471 for ; Mon, 12 May 2003 12:48:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CGlvL15865 for ; Mon, 12 May 2003 12:47:57 -0400 (EDT) Message-Id: <200305121643.h4CGhvu56061@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-Reply-To: Your message of "Wed, 07 May 2003 18:53:40 PDT." <17184595822.20030507185340@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86985.1052757837.1@juniper.net> Date: Mon, 12 May 2003 09:43:57 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Proposed L2VPN charter below (draft). Assume that there is a (rough) consensus on splitting the PPVPN WG into two (which is yet TBD), I'd like the following to be added to the L2 VPN charter: The effort will produce a small number of approaches that are based on collections of individual technologies. The goal is to foster interoperability among implementations of a specific approach. Standardization of specific approaches will be gauged on (I)SP support. Yakov. > -- > Alex > > Layer 2 Virtual Private Networks (l2vpn) > > Chairs: > > Area Director(s): > Thomas Narten > Erik Nordmark > > Area Advisor: > Thomas Narten > > Technical Advisor: > Alex Zinin > > Description of Working Group: > > This working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned > layer-2 virtual private networks (L2VPNs). > > The WG is responsible for standardization of the following solutions: > > 1. Virtual Private LAN Service--L2 service that emulates LAN > across an IP and an MPLS-enabled IP network. > > 2. Virtual Private Wire Service--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. > > The WG will address intra-AS scenarios only at this point (inter-AS > considerations will be considered for inclusion in the updated > charter when the current one is completed.) > > As a general rule, the WG will not create new protocols, but will > provide functional requirements for extensions of the existing > protocols that will be discussed in the protocol-specific WGs. > As a specific example, this WG will not define new encapsulation > mechanism, but will use those defined in the PWE3 WG. > > The WG will work on the following items, adding new work items > will require rechartering: > > 1. Discovery of PEs participating in L2 service, and > topology of required connectivity > > 2. Signaling of psuedo-wire and service parameters > > 3. Solution documents (providing the framework for a specific > solution, should include info on how discovery, signaling, > and encaps work together, include security, AS as a separate > document,...) > > 4. MIBs > > 5. L2VPN-specific OAM extensions--extensions to existing OAM > solutions for VPLS and VPWS. > > Milestones (optimistic): > > JUL 2003 Submit L2 requirements to IESG for publication as Informational RFC > JUL 2003 Submit L2 framework to IESG for publication as Informational RFC > JUL 2003 Identify VPLS and VPWS solutions for the WG > AUG 2003 Submit an I-D describing MIB for VPLS > AUG 2003 Submit an I-D describing MIB for VPWS > AUG 2003 Submit an I-D on OAM for VPLS > AUG 2003 Submit an I-D on OAM for VPWS > DEC 2003 Submit VPLS solution documents to IESG > DEC 2003 Submit VPWS solution documents to IESG > JAN 2004 Submit MIB for VPLS to IESG > JAN 2004 Submit MIB for VPWS to IESG > MAR 2004 Submit OAM for VPLS to IESG > MAR 2004 Submit OAM for VPWS to IESG > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 12:58:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23965 for ; Mon, 12 May 2003 12:58:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CH0TT19335 for ; Mon, 12 May 2003 13:00:30 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CH0OC02084 for ; Mon, 12 May 2003 13:00:25 -0400 (EDT) Message-Id: <200305121657.h4CGvAu57011@merlot.juniper.net> To: richard.spencer@bt.com cc: hshah@wavesmithnetworks.com, "Vasile Radoaca" , zinin@psg.com, PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: Your message of "Tue, 06 May 2003 15:27:20 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91633.1052758630.1@juniper.net> Date: Mon, 12 May 2003 09:57:10 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Richard, > I believe that there can exist multiple solutions for different sets > of problems. However, one must not confuse the solution with > signaling. We oughta not have two signaling mechanisms for > two solutions to the same problem. > > [RS: I agree that there should only be one 'functional specification'. > However, I don't think we can rule out the possibility of having to use more > than one protocol for each function until the functional specifications have > been developed.] > > A while back, it was determined that PW setup signaling is not > the charter of PPVPN but of PWE3. Lately, we have been > discussing again whether BGP based signaling is better than LDP > based signaling. We have got to get past this issue once and for > all. My personal experience (having implemented BGP based > signaling for L2VPN) is that my previous company could not find any customer > > demand for BGP-based solution (we did not look into Italy though :-) > However, there was greater interest in LDP based solution and > public forums to test interoperability with. > > [RS: Carrying out a quick count of the individuals that have expressed > support on this mailing list for the two opposing drafts (K.Kompella vs. > V.Kompella/Lasserre), based on whether they work for an SP or a vendor the > results are (roughly): > > Draft Vendor Support SP Support > BGP 4 19 > LDP 7 3 > > These results would suggest that customers (i.e. SPs) prefer the BGP > approach. I am not saying that I agree, far from it, but I don't think that > we should rule out protocols at this stage, especially in the inter-AS case. > Instead we should be focussing on getting the functional specifications > correct.] > > I think we have learned enough lessons from CR-LDP vs RSVP-TE > debacle. One of the lessons we have learned from "CR-LDP vs RSVP-TE debacle" is that when presented with multiple solutions, selecting one of them based on the working code + operational experience is much more productive than based on the debate within an IETF WG. > Lets not repeat it for L2VPN. Agreed. Yet some folks really seem to insist on repeating it... Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 13:03:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24115 for ; Mon, 12 May 2003 13:03:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CH61T15792 for ; Mon, 12 May 2003 13:06:01 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CH5wC06897 for ; Mon, 12 May 2003 13:05:58 -0400 (EDT) Message-Id: <200305121702.h4CH2Pu57621@merlot.juniper.net> To: Juha Heinanen cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: Your message of "Thu, 08 May 2003 09:10:29 +0300." <16057.62677.21745.888768@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93721.1052758945.1@juniper.net> Date: Mon, 12 May 2003 10:02:25 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Juha, > Alex Zinin writes: > > > Let's keep to goal of that line in the text in mind--make progress on > > basic things before going to more complex ones (while still keeping > > the Internet-wide considerations in mind). > > that would be fine if you can guarantee for me that there exists for > each solution a backwards compatible migration path from intra-provider to > inter-provider although the details may not have been worked out yet. > inter-AS is a MUST from the very beginning. I don't think that a guarantee from Alex (or any other individual) that "there exists for each solution a backwards compatible migration path from intra-provider to inter-provider" is enough. The inter-AS solution must has enough details from the very beginning to demonstrate that there is a a backwards compatible migration path from intra-provider to inter-provider. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 13:12:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24386 for ; Mon, 12 May 2003 13:12:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CHElT21150 for ; Mon, 12 May 2003 13:14:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CHEiC28620 for ; Mon, 12 May 2003 13:14:45 -0400 (EDT) Message-Id: <200305121708.h4CH8Mu58037@merlot.juniper.net> To: "Fang, Luyuan, ALABS" cc: PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: Your message of "Tue, 06 May 2003 13:18:16 CDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95792.1052759302.1@juniper.net> Date: Mon, 12 May 2003 10:08:22 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Luyuan, > > I'd like to support the three main solutions for L2 VPNs: > draft-lasserre-vkom pella-ppvpn-vpls, draft-kompella-ppvpn-vpls, > draft-radoaca-ppvpn-gvpls,(and possibly others) to become PPVPN > WG documents. Each solution has its own merits, and may satisfy > different needs for the providers. It is conceivable that all so > lutions get deployed by different providers (indeed, this seems to > be what is h appening), and will eventually coexist. I think the > PPVPN WG should define the solutions and then let the market decide. Agreed. In fact, I don't quite understand why some folks on this list insist that the IETF should be in the business of making business decisions (e.g., selecting a particular solution) for the Service Providers ? Aren't Service Providers competent enough, and know better their business needs than the IETF ? Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 13:15:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24462 for ; Mon, 12 May 2003 13:15:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CHHsT24936 for ; Mon, 12 May 2003 13:17:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CHHpq03396 for ; Mon, 12 May 2003 13:17:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16063.54939.486593.99601@harjus.eng.song.fi> Date: Mon, 12 May 2003 20:15:07 +0300 To: Yakov Rekhter Cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: <200305121702.h4CH2Pu57621@merlot.juniper.net> References: <16057.62677.21745.888768@harjus.eng.song.fi> <200305121702.h4CH2Pu57621@merlot.juniper.net> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > The inter-AS > solution must has enough details from the very beginning to > demonstrate that there is a a backwards compatible migration path > from intra-provider to inter-provider. even better, juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 13:24:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24661 for ; Mon, 12 May 2003 13:24:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CHR8T02616 for ; Mon, 12 May 2003 13:27:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CHR5q13421 for ; Mon, 12 May 2003 13:27:05 -0400 (EDT) Message-Id: From: "Wright, Steven" To: "'Loa Andersson'" Cc: "'ppvpn@nortelnetworks.com'" Subject: RE: vpls scaling question Date: Mon, 12 May 2003 12:21:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: aismtp3g.bls.com X-SMTP-MAIL-FROM: Steven.Wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp3g.bellsouth.com [139.76.165.193] X-LYRIS-Message-Id: Loa, 1) I'm not trying to create requirements here, just to understand what the group consensus is. i.e. is this vpls thing intended to emulate current switch capabilities/constraints or do something more ? 2) Perhaps my terminology was confusing. I was referring to the case of a service provider with 10,000,000 customers, each with their own service instance. This indeed would be a blessing ! (assuming they all pay their bills). Each customer may only want a relatively few VLANs... 3) Is this a realistic target application ?? well that's always debatable! But consider the case of 1 AS per LATA - and what's the max number of households / LATA ? Well there are metro's with 1-10,000,000 households... 4) Specific deployments depend on a lot more than design constraints (e.g. $)..... so ...see 1) above... regards Steven Wright > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Sunday, May 11, 2003 6:17 AM > To: steven.wright@bellsouth.com > Cc: ppvpn@nortelnetworks.com > Subject: Re: vpls scaling question > > > Steve, > > just to make sure we are on the same field. For me a vpls is > a service I > as an oprator offer a customer, could you please give me a scenario > where that customer would need 10,000,000 VLANs. > If you are talikng about number of vpls's in the operator network, > 10,000,000 "service instances" is not a problem, in fact it would be a > blessing :) > > /Loa > > Steven.Wright wrote: > > to clarify the INTRA- AS vpls case > > I would like to better understand the expected capabilities > of INTRA-AS > > vpls vs a network of Ethernet switches. > > > > What is the scaling objective for vpls ? > > Current generation Ethernet switches have evolved from the 4096 > > VLAN/network to 4096 VLAN/port. Scale limits on SP > Ethernet networks > > are typically driven by other factors e.g. MAC address table size, > > issues with multicast etc. > > > > Is vpls intended to tackle any of those scale constraints ? > or to put it > > another way... > > Current Ethernet switch networks can support on the order > of 10,000 VLAN > > service instances. Will vpls enable scaling to the > 10,000,000 or so > > service instances/AS necessary to enable Ethernet as a > residential service ? > > > > > > > > > > > > -----Original Message----- > > *From:* Steven.Wright [mailto:steven.wright@bellsouth.com] > > *Sent:* Wednesday, April 23, 2003 5:04 PM > > *To:* *Subject:* vpls scaling question > > > > vpls is proposed as a mechanism to enable large-scale > Ethernet networks. > > Can anyone quantify for me at what stage flat Ethernet networks > > break and vpls is required ? > > i.e what should the decision criteria be to convert an Ethernet > > network to a vpls network ? > > Steven Wright > > BellSouth > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 13:35:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25010 for ; Mon, 12 May 2003 13:35:09 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CHbbT07771 for ; Mon, 12 May 2003 13:37:38 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CHbZ622665 for ; Mon, 12 May 2003 13:37:35 -0400 (EDT) Message-Id: <200305121734.h4CHYGH9010451@rtp-core-1.cisco.com> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-reply-to: Your message of Wed, 07 May 2003 18:53:40 -0700. <17184595822.20030507185340@psg.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: Mon, 12 May 2003 13:34:16 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Two L2VPN charter issues that come up frequently are (a) whether ARP Mediation (for allowing IP traffic on a p2p link between two unlike attachment circuits) falls into the charter, and (b) whether IPLS (for allowing LAN-like connectivity among a set of IP routers, without requiring MAC learning, BPDUs, etc.) falls into the charter. If there is actually going to be an L2VPN charter, I'd like to see this settled, preferably in favor of including these efforts. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:02:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25851 for ; Mon, 12 May 2003 14:02:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CI51T17227 for ; Mon, 12 May 2003 14:05:02 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CI4xb06699 for ; Mon, 12 May 2003 14:04:59 -0400 (EDT) Message-Id: <200305121759.h4CHxbu62438@merlot.juniper.net> To: "Hamid Ould-Brahim" cc: Thomas Narten , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: Your message of "Wed, 07 May 2003 14:08:52 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14457.1052762377.1@juniper.net> Date: Mon, 12 May 2003 10:59:37 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hamid, > > Thomas> The above could be read as indicating that the > > discussion/urgency of > > Thomas> the L2 work is pushing out or drowning out discussion > > on L3 topics. > > > > Yes, I do think so. > > To be more precise, the discussions were mostly on vpls service, > and since l2vpn includes services other than vpls, this could > be read as well that vpls discussion/urgency is pushing out or > drowning out discussions on other l2vpn services. Agreed. In fact, if the justification for splitting the PPVNP WG into two is to allow discussion for L3 services, then following the same line of reasoning there should be not one, but two L2 VPN WGs, one for L2 VPN services (other than VPLS), and one for VPLS. Yet, the IESG said nothing about having two L2 VPN WGs. Perhaps the IESG would be kind enough to explain this inconsistency. > In that respect, creating a new l2vpn wg will not make the situation any > better. Agreed. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:17:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26398 for ; Mon, 12 May 2003 14:17:46 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CIKGT25791 for ; Mon, 12 May 2003 14:20:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CIKDM16162 for ; Mon, 12 May 2003 14:20:13 -0400 (EDT) Message-ID: From: Joris wils To: "'Wright, Steven'" , "'Loa Andersson'" Cc: "'ppvpn@nortelnetworks.com'" Subject: RE: vpls scaling question Date: Mon, 12 May 2003 14:15:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: CIMA.coriolisnet.com X-SMTP-MAIL-FROM: jwils@coriolisnet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.229.88.162] X-LYRIS-Message-Id: Steve, Questions for you: a) Why does each household need its own VLAN? Why can a set of household not share a vlan, each household with its own, possibly statically assigned, MAC addresses? b) If each household must have its own VLAN, then are such VLANs usually point2point Ethernet circuits to an Internet router? It is far easier to handle very large numbers of point2point circuits, than very large numbers of multipoint VLANs. Cheers, Joris -----Original Message----- From: Wright, Steven [mailto:Steven.Wright@BellSouth.com] Sent: Monday, May 12, 2003 1:21 PM To: 'Loa Andersson' Cc: 'ppvpn@nortelnetworks.com' Subject: RE: vpls scaling question Loa, 1) I'm not trying to create requirements here, just to understand what the group consensus is. i.e. is this vpls thing intended to emulate current switch capabilities/constraints or do something more ? 2) Perhaps my terminology was confusing. I was referring to the case of a service provider with 10,000,000 customers, each with their own service instance. This indeed would be a blessing ! (assuming they all pay their bills). Each customer may only want a relatively few VLANs... 3) Is this a realistic target application ?? well that's always debatable! But consider the case of 1 AS per LATA - and what's the max number of households / LATA ? Well there are metro's with 1-10,000,000 households... 4) Specific deployments depend on a lot more than design constraints (e.g. $)..... so ...see 1) above... regards Steven Wright > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Sunday, May 11, 2003 6:17 AM > To: steven.wright@bellsouth.com > Cc: ppvpn@nortelnetworks.com > Subject: Re: vpls scaling question > > > Steve, > > just to make sure we are on the same field. For me a vpls is > a service I > as an oprator offer a customer, could you please give me a scenario > where that customer would need 10,000,000 VLANs. > If you are talikng about number of vpls's in the operator network, > 10,000,000 "service instances" is not a problem, in fact it would be a > blessing :) > > /Loa > > Steven.Wright wrote: > > to clarify the INTRA- AS vpls case > > I would like to better understand the expected capabilities > of INTRA-AS > > vpls vs a network of Ethernet switches. > > > > What is the scaling objective for vpls ? > > Current generation Ethernet switches have evolved from the 4096 > > VLAN/network to 4096 VLAN/port. Scale limits on SP > Ethernet networks > > are typically driven by other factors e.g. MAC address table size, > > issues with multicast etc. > > > > Is vpls intended to tackle any of those scale constraints ? > or to put it > > another way... > > Current Ethernet switch networks can support on the order > of 10,000 VLAN > > service instances. Will vpls enable scaling to the > 10,000,000 or so > > service instances/AS necessary to enable Ethernet as a > residential service ? > > > > > > > > > > > > -----Original Message----- > > *From:* Steven.Wright [mailto:steven.wright@bellsouth.com] > > *Sent:* Wednesday, April 23, 2003 5:04 PM > > *To:* *Subject:* vpls scaling question > > > > vpls is proposed as a mechanism to enable large-scale > Ethernet networks. > > Can anyone quantify for me at what stage flat Ethernet networks > > break and vpls is required ? > > i.e what should the decision criteria be to convert an Ethernet > > network to a vpls network ? > > Steven Wright > > BellSouth > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:25:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26657 for ; Mon, 12 May 2003 14:25:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CIS1T00458 for ; Mon, 12 May 2003 14:28:01 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CIRwM23081 for ; Mon, 12 May 2003 14:27:58 -0400 (EDT) Date: Mon, 12 May 2003 14:24:36 -0400 (EDT) From: schultz@io.iol.unh.edu To: Yakov Rekhter cc: Thomas Narten , Alex Zinin , ppvpn@nortelnetworks.com, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF In-Reply-To: <200305121614.h4CGEsu53134@merlot.juniper.net> Message-ID: References: <200305121614.h4CGEsu53134@merlot.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: io.iol.unh.edu X-SMTP-MAIL-FROM: schultz@io.iol.unh.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: io.iol.unh.edu [132.177.123.82] X-LYRIS-Message-Id: > > As one example, on the topic of "one vs. multiple solutions", I know > > the IESG will ask, why are we standardizing 3 solutions to the same > > problem (if that is what the WG thinks it is going to do). The WG will > > have to be able to answer that sort of question with a credible > > response (and in some cases, a credible justification is that the > > solutions are very different and there are different applicabilities > > to the mechanisms -- but one needs to look at the details on this). If > > the answer simply is "because we want to and we'll let the market > > decide", the IESG may well come back and say fine, make them all > > experimental, none of them on standards track. Revisit when the market > > has decided. > > And what is wrong with this (make all experimental, revisit when the > market has decided) ? Will these specifications ever be revisited if they are deployed as experimental, and most of the problems are solved in deployment? I suspect that many could remain experimental for a long time. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:33:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26892 for ; Mon, 12 May 2003 14:33:43 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CIaCT05146 for ; Mon, 12 May 2003 14:36:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CIa9E29816 for ; Mon, 12 May 2003 14:36:09 -0400 (EDT) Message-Id: <200305121833.h4CIXMu66005@merlot.juniper.net> To: Alex Zinin cc: "Bilel Jamoussi" , "'PPVPN@nortelnetworks.com'" Subject: Re: Strategy for VPN work in IETF In-Reply-To: Your message of "Tue, 06 May 2003 10:53:41 PDT." <1336000257.20030506105341@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27296.1052764402.1@juniper.net> Date: Mon, 12 May 2003 11:33:22 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,jamoussi@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Bilel, > > BNJ>> it would be good if you clarify your statement instead of pointing me > > to the chairs. > > "Coordinating with Marco and Rick" means that all steps taken by Marco > and Rick as the WG chairs in PPVPN are checked with the involved ADs > and that we are working closer than usually. And as Marco indicated in his e-mail: We (chairs) have just been requested to provide our advice on WG splitting without having had any way to participate in the discussion on issues. The coordination seem to be one way - ADs check all steps taken by WG chairs, yet WG chairs have no way to participate with ADs in the discussion on issues. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:36:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26966 for ; Mon, 12 May 2003 14:36:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CIcnT08911 for ; Mon, 12 May 2003 14:38:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CIcjE04243 for ; Mon, 12 May 2003 14:38:45 -0400 (EDT) X-Authentication-Warning: flame.cs.columbia.edu: pingpan owned process doing -bs Date: Mon, 12 May 2003 14:32:51 -0400 (EDT) From: Ping Pan To: Joris wils cc: "'Wright, Steven'" , "'Loa Andersson'" , "'ppvpn@nortelnetworks.com'" Subject: RE: vpls scaling question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: cs.columbia.edu X-SMTP-MAIL-FROM: pingpan@cs.columbia.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cs.columbia.edu [128.59.16.20] X-LYRIS-Message-Id: On Mon, 12 May 2003, Joris wils wrote: > Steve, > > Questions for you: > a) Why does each household need its own VLAN? Why can a set of household > not share a vlan, each household with its own, possibly statically assigned, > MAC addresses? > Wonder the same thing. IMHO, each household can rely on L3 routing for connectivity. L2VPN is a critical element at IP backbone and transport networks only. > b) If each household must have its own VLAN, then are such VLANs usually > point2point Ethernet circuits to an Internet router? It is far easier to > handle very large numbers of point2point circuits, than very large numbers > of multipoint VLANs. > Follow up question, do we need point-to-multiple VLAN in the backbone? - Ping > Cheers, > Joris > > -----Original Message----- > From: Wright, Steven [mailto:Steven.Wright@BellSouth.com] > Sent: Monday, May 12, 2003 1:21 PM > To: 'Loa Andersson' > Cc: 'ppvpn@nortelnetworks.com' > Subject: RE: vpls scaling question > > > Loa, > > 1) I'm not trying to create requirements here, just to understand what the > group consensus is. i.e. is this vpls thing intended to emulate current > switch capabilities/constraints or do something more ? > > 2) Perhaps my terminology was confusing. I was referring to the case of a > service provider with 10,000,000 customers, each with their own service > instance. This indeed would be a blessing ! (assuming they all pay their > bills). Each customer may only want a relatively few VLANs... > > 3) Is this a realistic target application ?? well that's always debatable! > But consider the case of 1 AS per LATA - and what's the max number of > households / LATA ? Well there are metro's with 1-10,000,000 households... > > 4) Specific deployments depend on a lot more than design constraints (e.g. > $)..... > so ...see 1) above... > > regards > Steven Wright > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se] > > Sent: Sunday, May 11, 2003 6:17 AM > > To: steven.wright@bellsouth.com > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: vpls scaling question > > > > > > Steve, > > > > just to make sure we are on the same field. For me a vpls is > > a service I > > as an oprator offer a customer, could you please give me a scenario > > where that customer would need 10,000,000 VLANs. > > If you are talikng about number of vpls's in the operator network, > > 10,000,000 "service instances" is not a problem, in fact it would be a > > blessing :) > > > > /Loa > > > > Steven.Wright wrote: > > > to clarify the INTRA- AS vpls case > > > I would like to better understand the expected capabilities > > of INTRA-AS > > > vpls vs a network of Ethernet switches. > > > > > > What is the scaling objective for vpls ? > > > Current generation Ethernet switches have evolved from the 4096 > > > VLAN/network to 4096 VLAN/port. Scale limits on SP > > Ethernet networks > > > are typically driven by other factors e.g. MAC address table size, > > > issues with multicast etc. > > > > > > Is vpls intended to tackle any of those scale constraints ? > > or to put it > > > another way... > > > Current Ethernet switch networks can support on the order > > of 10,000 VLAN > > > service instances. Will vpls enable scaling to the > > 10,000,000 or so > > > service instances/AS necessary to enable Ethernet as a > > residential service ? > > > > > > > > > > > > > > > > > > -----Original Message----- > > > *From:* Steven.Wright [mailto:steven.wright@bellsouth.com] > > > *Sent:* Wednesday, April 23, 2003 5:04 PM > > > *To:* *Subject:* vpls scaling question > > > > > > vpls is proposed as a mechanism to enable large-scale > > Ethernet networks. > > > Can anyone quantify for me at what stage flat Ethernet networks > > > break and vpls is required ? > > > i.e what should the decision criteria be to convert an Ethernet > > > network to a vpls network ? > > > Steven Wright > > > BellSouth > > > > > > > > > -- > > /Loa > > > > mobile + 46 739 81 21 64 > > email: loa@pi.se > > > > > ***** > "The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from all > computers." > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:47:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27542 for ; Mon, 12 May 2003 14:47:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CInrT14206 for ; Mon, 12 May 2003 14:49:54 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CInpf14052 for ; Mon, 12 May 2003 14:49:51 -0400 (EDT) Message-Id: <200305121845.h4CIjYu67120@merlot.juniper.net> To: "Himanshu Shah" cc: zinin@psg.com, PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: Your message of "Tue, 06 May 2003 11:23:38 EDT." <049AAFED91851244B9FF74D0D9D0EB7202152606@WHISTLER.WaveSmithNet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31890.1052765134.1@juniper.net> Date: Mon, 12 May 2003 11:45:34 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Himanshu, > Richard, > > Like it or not - this entire debate is about which signaling protocol > to use. K.Kompella VPLS (decoupled feature) could also be supported > using LDP signaling. However, that is not the focus of the debate. > > As for inter-AS case, I remember the discussion in one of the design > team meetings (in Boston) where Yakov himself suggested that inter-AS = > can be handled by one AS handing off the traffic on the Ethernet and other > AS picking that up as customer facing inter-carrier traffic. May be > I misunderstood him. May be you did. > I am (personally) skeptical about the BGP vs LDP support > numbers. There is danger in delaying this decision, it impedes > the L2VPN standardization effort, which in turn causes reluctance > and spurious in offering such service. Your assertion about relation between delaying standardizaiong effort and offering VPLS service is questionable. Perhaps you may consider that 2547bis is widely deployed, even if it is not an IETF standard. Ditto for draft-martini. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:51:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27650 for ; Mon, 12 May 2003 14:51:46 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CIsGT18096 for ; Mon, 12 May 2003 14:54:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CIsDf21002 for ; Mon, 12 May 2003 14:54:13 -0400 (EDT) Message-Id: <200305121850.h4CIoOgf005558@rtp-core-1.cisco.com> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Info aggregation In-reply-to: Your message of Sat, 03 May 2003 18:27:34 -0700. <1611408344.20030503182734@psg.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: Mon, 12 May 2003 14:50:24 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Alex> Some more questions here: when taken to a large scale Alex> (not necessarily just one VPLS) Alex> o what VPLS info from other AS'es do PEs need to know? Vach has been pushing a hierarchical model, in which, for each VPLS, each AS has a "gateway" that only needs to know how to reach a gateway in the other ASes, and within an AS, each PE only needs to know how to reach its own gateway. I've been pushing a somewhat different model in which each PE has to know how to reach its gateway (to a particular AS), and has to know how many PEs supporting that same VPLS there are in the other AS. A PE sets up that number of pseudowires to the gateway, which splices them together with pws that go to the next AS. (The splicing can be done in such a way as to be transparent to the forwarding plane, though some have suggested that the gateway might need to be an OAM boundary, even if that sacrifices scalability.) Both models provide a good summarization of information, I think. They differ in regard to the amount and kind of state needed in the PEs as opposed to the gateway. The hierarchical model helps with the scale of the individual PEs, but requires MAC lookup in the gateways, and also requires of course that a hierarchy be provisioned. (I hope I've not done Vach's model too much of an injustice.) Alex> o given the edge-to-edge nature of PWs, is it feasible Alex> to summarize signalling information among AS'es at all? Both models bound the number of signaling inter-AS connections, so that the number of these connections does not grow as the number of PEs grows. The hierarchical model limits some of the signaling information to the hierarchy boundaries. Alex> o if not, how do we scope distribution of signalling info Alex> so amount of info per participating node has reasonable Alex> growth characteristics? I think it is impossible to make L2 scale as well as L3, because of the flat and non-aggregatable address space, and because of the need to multicast packets with unknown DAs. However, whereas we want our L3 networks to be able to grow without bound, I don't think the same requirement exists with respect to L2 networks. Alex> o is it feasible to summarize VPLS membership information Alex> among AS'es? Yes, to a certain extent, as explained above. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 14:58:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27886 for ; Mon, 12 May 2003 14:58:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CJ17T02485 for ; Mon, 12 May 2003 15:01:07 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CJ14b09485 for ; Mon, 12 May 2003 15:01:04 -0400 (EDT) Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Yakov Rekhter'" , "Fang, Luyuan, ALABS" Cc: PPVPN@nortelnetworks.com Subject: RE: Single vs many solution(s) Date: Mon, 12 May 2003 14:57:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: hoemail1.firewall.lucent.com X-SMTP-MAIL-FROM: busschbach@lucent.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: hoemail1.lucent.com [192.11.226.161] X-LYRIS-Message-Id: > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Monday, May 12, 2003 1:08 PM > Subject: Re: Single vs many solution(s) > > > Luyuan, > > > > > I'd like to support the three main solutions for L2 VPNs: > > draft-lasserre-vkom pella-ppvpn-vpls, draft-kompella-ppvpn-vpls, > > draft-radoaca-ppvpn-gvpls,(and possibly others) to become PPVPN > > WG documents. Each solution has its own merits, and may satisfy > > different needs for the providers. It is conceivable that all so > > lutions get deployed by different providers (indeed, this seems to > > be what is h appening), and will eventually coexist. I think the > > PPVPN WG should define the solutions and then let the market decide. > > Agreed. In fact, I don't quite understand why some folks on this > list insist that the IETF should be in the business of making > business decisions (e.g., selecting a particular solution) for the > Service Providers ? Aren't Service Providers competent enough, and > know better their business needs than the IETF ? > > Yakov. > I don't think the IETF is making business decisions. Vendors are free to develop proprietary solutions and service providers are free to deploy them. However, a standards body should develop one solution as THE standard. In general, large Service Providers have always insisted on standards-based solutions. Superficially, it may seem attractive to have several solutions to choose from, but in the end, I think the industry as a whole is better off with clear, unambigious standards. By the way, Service Providers are involved in the standards process. Why do we need to wait for their buying decisions to know what they want? Peter > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 15:23:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29785 for ; Mon, 12 May 2003 15:23:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CJPuT02099 for ; Mon, 12 May 2003 15:25:56 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CJPrS07787 for ; Mon, 12 May 2003 15:25:53 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6065C76A8@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Yakov Rekhter'" , "'Alex Zinin'" Cc: "'PPVPN@nortelnetworks.com'" Subject: RE: Strategy for VPN work in IETF Date: Mon, 12 May 2003 15:22:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C318BB.D71C4B14" X-LYRIS-Message-Id: 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_01C318BB.D71C4B14 Content-Type: text/plain Yakov, Agreed - The process of this "Strategy" is broken. Bilel. -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Monday, May 12, 2003 2:33 PM To: Alex Zinin Cc: Jamoussi, Bilel [BL60:1A00:EXCH]; 'PPVPN@nortelnetworks.com' Subject: Re: Strategy for VPN work in IETF Alex, > Bilel, > > BNJ>> it would be good if you clarify your statement instead of > BNJ>> pointing me > > to the chairs. > > "Coordinating with Marco and Rick" means that all steps taken by Marco > and Rick as the WG chairs in PPVPN are checked with the involved ADs > and that we are working closer than usually. And as Marco indicated in his e-mail: We (chairs) have just been requested to provide our advice on WG splitting without having had any way to participate in the discussion on issues. The coordination seem to be one way - ADs check all steps taken by WG chairs, yet WG chairs have no way to participate with ADs in the discussion on issues. Yakov. ------_=_NextPart_001_01C318BB.D71C4B14 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Strategy for VPN work in IETF

Yakov,

Agreed - The process of this "Strategy" is = broken.

Bilel.

-----Original Message-----
From: Yakov Rekhter [mailto:yakov@juniper.net]
Sent: Monday, May 12, 2003 2:33 PM
To: Alex Zinin
Cc: Jamoussi, Bilel [BL60:1A00:EXCH]; = 'PPVPN@nortelnetworks.com'
Subject: Re: Strategy for VPN work in IETF


Alex,

> Bilel,
>
> BNJ>> it would be good if you clarify = your statement instead of
> BNJ>> pointing me
> > to the chairs.
>
> "Coordinating with Marco and Rick" = means that all steps taken by Marco
> and Rick as the WG chairs in PPVPN are checked = with the involved ADs
> and that we are working closer than = usually.

And as Marco indicated in his e-mail:

  We (chairs) have just been requested to = provide our advice on
  WG splitting without having had any way to = participate in the
  discussion on issues.

The coordination seem to be one way - ADs check all = steps taken by WG chairs, yet WG chairs have no way to participate with = ADs in the discussion on issues.

 
Yakov.

------_=_NextPart_001_01C318BB.D71C4B14-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 15:34:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00247 for ; Mon, 12 May 2003 15:34:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CJavT08983 for ; Mon, 12 May 2003 15:36:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CJard21198 for ; Mon, 12 May 2003 15:36:54 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG split: why and how? Date: Mon, 12 May 2003 14:33:08 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A70F9@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG split: why and how? Thread-Index: AcMXBNwQ2BLb8cqXSF6RcK32aWyqiQBroxlw From: "Ash, Gerald R (Jerry), ALABS" To: "Alex Zinin" , Cc: "Ash, Gerald R (Jerry), ALABS" X-SMTP-HELO: almso2.proxy.att.com X-SMTP-MAIL-FROM: gash@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: almso2.att.com [192.128.166.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA00247 > 3. Problem statement. > > As seen by ADs: slow progress on L3 and L2 VPN work (see section 2 > above) caused by comparatively wide problem space with unusually > big number of correlated technologies (L2, bridging, tunneling, > routing, signalling, etc.) that in turn results in a big number of > tasks and documents within the WG. Granted that there is a large number of tasks and documents to manage, which is one reason why work has not been completed. However, this problem has only recently been identified for discussion on the list, and apparently has not been discussed to any great extent with the WG chairs (Marco's input). The PPVPN chairs have ably managed the large workload, e.g., see Marco's very thorough update on 'PPVPN WG Status' at IETF-56 http://ietf.org/proceedings/03mar/slides/ppvpn-1.pdf and comprehensive summary in the minutes http://ietf.org/proceedings/03mar/minutes/ppvpn.htm. The PPVPN work across the ITU and IETF is well coordinated without any issues (such as have arisen with ITU-IETF interactions in other WGs). As such, it would be very useful to get the WG chairs' input on the identified issues, and have them propose solution alternatives, rather than taking their comments 'off line' (as Alex has decreed). This could be the basis for more concrete discussion of solution alternatives, rather than just one alternative. > 4. Summary of the solution under consideration > > 1. Put L3 and L2 work in separate WGs > Analysis of the L3 and L2 remaining and potential future work items > has shown that there is a sufficient amount of work in each area to > warrant a separate WG. Smaller and more focused WGs tend to be > more efficient in terms of achieving consensus and completing > their tasks. > ... > > 6.7 Have you considered other alternatives to the split? > > Yes. The alternative to the split would be to organize work within > the WG in the form of design teams and have more than one WG > session at the face-to-face meetings. However, the WG already has > a number of DTs inside of it, so we can consider that this method > has been tried already. Increasing the number of WG sessions alone > is hardly going to help as majority of work is done outside the > face-to-face meetings, in fact, consistent need for more than one > session maybe considered as an indication that the WG has more > than enough on its charter. Seems to conclude that the problem cannot be solved within the existing PPVPN WG. Let's get the WG chairs' proposals on how to fix the problem within the WG, and discuss their proposals. Let's reach a WG consensus as to which solution best solves the problem. Jerry From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 15:39:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00695 for ; Mon, 12 May 2003 15:39:44 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CJgET13706 for ; Mon, 12 May 2003 15:42:14 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CJgBd00172 for ; Mon, 12 May 2003 15:42:11 -0400 (EDT) Message-ID: From: "Lilian Montano" To: Subject: Ppvpn, please........bing Date: Mon, 12 May 03 22:39:47 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".97.D958.A.2_" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: A X-SMTP-MAIL-FROM: starfiresix@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [61.177.35.113] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --.97.D958.A.2_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
I am one of many Russian girls = that would like to marry a
nice American man and come live= in the U.S.A. as a citizen.
Tanka G.
    (takes a couple seconds for my picture to load)
     

 
 
Or let us know and we won't write you again:

Don't write to me
 
tolstoy cistern = acclimate thoreau abyss quadrillion johnston %RANDOM_W= ORD mow zircon nomad twig cream %RANDOM_W= ORD donahue endpoint --.97.D958.A.2_-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 15:51:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01150 for ; Mon, 12 May 2003 15:51:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CJs9T21210 for ; Mon, 12 May 2003 15:54:09 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CJs5M10245 for ; Mon, 12 May 2003 15:54:05 -0400 (EDT) Reply-To: From: "Steven.Wright" To: "'Ping Pan'" , "Joris wils" , "'Eric Rosen'" Cc: Subject: RE: vpls scaling question Date: Mon, 12 May 2003 15:50:10 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp1g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp1g.bellsouth.com [139.76.165.196] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ping, Joris, Eric, See my point(1) below. "IF" the vpls stuff scales to 10,000,000 instances, it would open up some new options for Ethernet services, beyond what can be done with existing Ethernet switches. to make a crude analogy vpls emulates distributed Ethernet switching One of the main reasons for distributing applications is to increase capacity. So What is the capacity increase enabled by vpls compared to networks of existing Ethernet switches ?? Question is - What are the scaling limits of the current proposals (from the service provider's perspective), can anyone quantify them ?? Steven Wright > -----Original Message----- > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > Sent: Monday, May 12, 2003 2:33 PM > To: Joris wils > Cc: 'Wright, Steven'; 'Loa Andersson'; 'ppvpn@nortelnetworks.com' > Subject: RE: vpls scaling question > > > > On Mon, 12 May 2003, Joris wils wrote: > > > Steve, > > > > Questions for you: > > a) Why does each household need its own VLAN? Why can a > set of household > > not share a vlan, each household with its own, possibly > statically assigned, > > MAC addresses? > > > > Wonder the same thing. > > IMHO, each household can rely on L3 routing for connectivity. > L2VPN is a > critical element at IP backbone and transport networks only. > > > b) If each household must have its own VLAN, then are such > VLANs usually > > point2point Ethernet circuits to an Internet router? It is > far easier to > > handle very large numbers of point2point circuits, than > very large numbers > > of multipoint VLANs. > > > > Follow up question, do we need point-to-multiple VLAN in the backbone? > > - Ping > > > Cheers, > > Joris > > > > -----Original Message----- > > From: Wright, Steven [mailto:Steven.Wright@BellSouth.com] > > Sent: Monday, May 12, 2003 1:21 PM > > To: 'Loa Andersson' > > Cc: 'ppvpn@nortelnetworks.com' > > Subject: RE: vpls scaling question > > > > > > Loa, > > > > 1) I'm not trying to create requirements here, just to > understand what the > > group consensus is. i.e. is this vpls thing intended to > emulate current > > switch capabilities/constraints or do something more ? > > > > 2) Perhaps my terminology was confusing. I was referring to > the case of a > > service provider with 10,000,000 customers, each with > their own service > > instance. This indeed would be a blessing ! (assuming they > all pay their > > bills). Each customer may only want a relatively few VLANs... > > > > 3) Is this a realistic target application ?? well that's > always debatable! > > But consider the case of 1 AS per LATA - and what's the > max number of > > households / LATA ? Well there are metro's with > 1-10,000,000 households... > > > > 4) Specific deployments depend on a lot more than design > constraints (e.g. > > $)..... > > so ...see 1) above... > > > > regards > > Steven Wright > > > > > -----Original Message----- > > > From: Loa Andersson [mailto:loa@pi.se] > > > Sent: Sunday, May 11, 2003 6:17 AM > > > To: steven.wright@bellsouth.com > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: vpls scaling question > > > > > > > > > Steve, > > > > > > just to make sure we are on the same field. For me a vpls is > > > a service I > > > as an oprator offer a customer, could you please give me > a scenario > > > where that customer would need 10,000,000 VLANs. > > > If you are talikng about number of vpls's in the operator network, > > > 10,000,000 "service instances" is not a problem, in fact > it would be a > > > blessing :) > > > > > > /Loa > > > > > > Steven.Wright wrote: > > > > to clarify the INTRA- AS vpls case > > > > I would like to better understand the expected capabilities > > > of INTRA-AS > > > > vpls vs a network of Ethernet switches. > > > > > > > > What is the scaling objective for vpls ? > > > > Current generation Ethernet switches have evolved from the 4096 > > > > VLAN/network to 4096 VLAN/port. Scale limits on SP > > > Ethernet networks > > > > are typically driven by other factors e.g. MAC address > table size, > > > > issues with multicast etc. > > > > > > > > Is vpls intended to tackle any of those scale constraints ? > > > or to put it > > > > another way... > > > > Current Ethernet switch networks can support on the order > > > of 10,000 VLAN > > > > service instances. Will vpls enable scaling to the > > > 10,000,000 or so > > > > service instances/AS necessary to enable Ethernet as a > > > residential service ? > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > *From:* Steven.Wright [mailto:steven.wright@bellsouth.com] > > > > *Sent:* Wednesday, April 23, 2003 5:04 PM > > > > *To:* *Subject:* vpls scaling question > > > > > > > > vpls is proposed as a mechanism to enable large-scale > > > Ethernet networks. > > > > Can anyone quantify for me at what stage flat > Ethernet networks > > > > break and vpls is required ? > > > > i.e what should the decision criteria be to convert > an Ethernet > > > > network to a vpls network ? > > > > Steven Wright > > > > BellSouth > > > > > > > > > > > > > -- > > > /Loa > > > > > > mobile + 46 739 81 21 64 > > > email: loa@pi.se > > > > > > > > > ***** > > "The information transmitted is intended only for the > person or entity to > > which it is addressed and may contain confidential, > proprietary, and/or > > privileged material. Any review, retransmission, > dissemination or other use > > of, or taking of any action in reliance upon, this > information by persons or > > entities other than the intended recipient is prohibited. > If you received > > this in error, please contact the sender and delete the > material from all > > computers." > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 15:53:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01239 for ; Mon, 12 May 2003 15:53:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CJtgT23454 for ; Mon, 12 May 2003 15:55:42 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CJtdM12827 for ; Mon, 12 May 2003 15:55:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030512124956.02912eb8@mira-sjcm-3> X-Sender: jayk@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 May 2003 12:50:10 -0700 To: "Lilian Montano" , From: Jay Kumarasamy Subject: Re: Ppvpn, please........bing In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_13712717==_.ALT" X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: jayk@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: --=====================_13712717==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Any takers ?? ;-) At 10:39 PM 5/12/2003 +0000, Lilian Montano wrote: >Content-Type: text/html; > >I am one of many Russian girls that would like to marry a >nice American man and come live in the U.S.A. as a citizen. >Tanka G. > (takes a couple seconds for my picture to load) > > >Check us out here > > >Or let us know and we won't write you again: > >Don't write to me > >tolstoy cistern acclimate thoreau abyss quadrillion johnston %RANDOM_WORD >mow zircon nomad twig cream %RANDOM_WORD donahue endpoint --=====================_13712717==_.ALT Content-Type: text/html; charset="us-ascii" Any takers ?? ;-)

At 10:39 PM 5/12/2003 +0000, Lilian Montano wrote:
Content-Type: text/html;

I am one of many Russian girls that would like to marry a
nice American man and come live in the U.S.A. as a citizen.
Tanka G.
   (takes a couple seconds for my picture to load)
    

Check us out here
 
 
Or let us know and we won't write you again:

Don't write to me
 
tolstoy cistern acclimate thoreau abyss quadrillion johnston %RANDOM_WORD mow zircon nomad twig cream %RANDOM_WORD donahue endpoint

--=====================_13712717==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 15:57:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01448 for ; Mon, 12 May 2003 15:57:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CJxjT27906 for ; Mon, 12 May 2003 15:59:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CJxgM22623 for ; Mon, 12 May 2003 15:59:42 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Subject: RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF - vpls provisioning. Date: Mon, 12 May 2003 15:40:39 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <16058.26748.862246.81098@harjus.eng.song.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp1g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp1g.bellsouth.com [139.76.165.196] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I would like to reinforce the importance of this provisioning aspect for the INTRA-AS case. In my expectation, membership of an L2 VPN / vpls instance would be a relatively static thing. Although in a large network, there may be significant churn. Depending on the service scale objectives, mechanized provisioning support may be required - hopefully something a little better than a hacked-up CLI can be found in order to minimize lifecycle OPEX for this kind of service. Steven Wright > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, May 08, 2003 10:24 AM > To: tnadeau@cisco.com > Cc: Paul Knight; 'Alex Zinin'; ppvpn@nortelnetworks.com; > pwe3@ietf.org; > 'Wijnen, Bert (Bert)'; 'Thomas Narten'; 'Peterson, Jon'; 'Allison > Mankin' > Subject: RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF > > > Thomas D. Nadeau writes: > > > You raise a good point. Is there going to be any discussion of > > actual provisioning of VPNs? > > provisioning is indeed an important issue. i have been told that > commercial provisioning systems for bgp/mpls vpns are very expensive. > may be that is because provisioning of them is difficult to do. > > a good solution is such for which writing automatic provisioning tools > is very easy. this is true for radius based solutions, where the > provisioning system needs little interaction with the actual pes. > > -- juha > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 16:12:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02214 for ; Mon, 12 May 2003 16:12:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CKElT04165 for ; Mon, 12 May 2003 16:14:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CKEh028625 for ; Mon, 12 May 2003 16:14:44 -0400 (EDT) Reply-To: From: "Daniel O. Awduche" To: "'Busschbach, Peter B \(Peter\)'" , "'Yakov Rekhter'" , "'Fang, Luyuan, ALABS'" Cc: Subject: RE: Single vs many solution(s) Date: Mon, 12 May 2003 16:11:20 -0400 Message-ID: <00e901c318c2$a84c98a0$e2916444@awduche.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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-SMTP-HELO: mta1.wss.scd.yahoo.com X-SMTP-MAIL-FROM: awduche@awduche.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mta1.wss.scd.yahoo.com [66.218.85.32] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I too have consistently advocated having a standard solution to a given well defined problem requiring interoperability between products from different vendors -- otherwise we forfeit many of the virtues of standardization, such as economies of scale, etc More importantly, what most people do not realize is that the price paid by the service provider for equipment and support reflects the cost incurred by the vendor in developing and maintaining the multiple solutions -- whether or not the service provider implements any or all the solutions. Cheers, /Dan -----Original Message----- From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] Sent: Monday, May 12, 2003 2:58 PM To: 'Yakov Rekhter'; Fang, Luyuan, ALABS Cc: PPVPN@nortelnetworks.com Subject: RE: Single vs many solution(s) > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Monday, May 12, 2003 1:08 PM > Subject: Re: Single vs many solution(s) > > > Luyuan, > > > > > I'd like to support the three main solutions for L2 VPNs: > > draft-lasserre-vkom pella-ppvpn-vpls, draft-kompella-ppvpn-vpls, > > draft-radoaca-ppvpn-gvpls,(and possibly others) to become PPVPN WG > > documents. Each solution has its own merits, and may satisfy > > different needs for the providers. It is conceivable that all so > > lutions get deployed by different providers (indeed, this seems to > > be what is h appening), and will eventually coexist. I think the > > PPVPN WG should define the solutions and then let the market decide. > > Agreed. In fact, I don't quite understand why some folks on this list > insist that the IETF should be in the business of making business > decisions (e.g., selecting a particular solution) for the Service > Providers ? Aren't Service Providers competent enough, and know better > their business needs than the IETF ? > > Yakov. > I don't think the IETF is making business decisions. Vendors are free to develop proprietary solutions and service providers are free to deploy them. However, a standards body should develop one solution as THE standard. In general, large Service Providers have always insisted on standards-based solutions. Superficially, it may seem attractive to have several solutions to choose from, but in the end, I think the industry as a whole is better off with clear, unambigious standards. By the way, Service Providers are involved in the standards process. Why do we need to wait for their buying decisions to know what they want? Peter > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 16:18:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02446 for ; Mon, 12 May 2003 16:18:52 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CKLKT08812 for ; Mon, 12 May 2003 16:21:20 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CKLGo05971 for ; Mon, 12 May 2003 16:21:16 -0400 (EDT) Message-Id: <200305121754.h4CHsNH9017727@rtp-core-1.cisco.com> To: "Wright, Steven" cc: "'Loa Andersson'" , "'ppvpn@nortelnetworks.com'" Subject: Re: vpls scaling question In-reply-to: Your message of Mon, 12 May 2003 12:21:18 -0500. 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, 12 May 2003 13:54:23 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Steven> I was referring to the case of a service provider with 10,000,000 Steven> customers, each with their own service instance. Each customer may Steven> only want a relatively few VLANs... Steven> there are metro's with 1-10,000,000 households... Of these 10 million households, how many want VLANs? How many have even heard of VLANs? How many households contain more than one site, and want those sites to appear to be on a common LAN? Surely for residential households, you want to treat each one as a single IP subnet, and connect them to a router. I don't see where VPLS even comes into it. Am I missing something? From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 16:21:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02524 for ; Mon, 12 May 2003 16:21:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CKNtT12653 for ; Mon, 12 May 2003 16:23:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CKNro10407 for ; Mon, 12 May 2003 16:23:53 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , ppvpn@nortelnetworks.com Subject: RE: WG split: why and how? Date: Mon, 12 May 2003 16:20:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C318C3.ECAC8748" X-LYRIS-Message-Id: 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_01C318C3.ECAC8748 Content-Type: text/plain; charset="iso-8859-1" Alex, These clarifications of your first email are certainly welcome although they are coming *one* day before May 11 deadline set in your previous email. See some comments inline... > > 4. Summary of the solution under consideration > > 1. Put L3 and L2 work in separate WGs > Analysis of the L3 and L2 remaining and potential > future work items > has shown that there is a sufficient amount of work in > each area to > warrant a separate WG. Smaller and more focused WGs tend to be > more efficient in terms of achieving consensus and completing > their tasks. > > 2. Focus the charters to ensure progress on items already in > the pipe; expand the charters and add more work items as > things progress > I am not sure we exhausted all the options. In addition to what George, Bryan and others suggested on alternatives, other options can be considered as well. If we assume a wg split is necessary (which I am no sure it is at this point in time), then why not address VPLS separately from other l2vpn work. A potential option is Yakov's suggestion to split l2vpn in two wgs. Another option is to: a) Keep ppvpn wg as it is covering l3vpn and l2vpn (other than VPLS), still covering the generic documents, the common documents/mechanisms, the "Provider-Provisioned" aspects, inter-as, etc. and, b) Move VPLS specific related work (including provider-bridges liaison, etc) in a "Temporary" focused wg (we have temporary area why not have "temporary WGs" in INT area as well). While the ppvpn, vpls are progressing we can decide to join them at a given time. At least this option keeps ppvpn as it is in terms of structure, avoids the questions on what to do with common l2+l3 work, does minimum disruption to ppvpn wg activities in l3, l3+l2 space, takes into account that l3vpn work is in its final stage. Other options as well is to look at a re-org from a wider angle that affects both PWE3 and PPVPN. For example, merge some PWE3 work with l2vpn VPW work, etc (I never understood why some l2vpn signaling is done in another wg). It looks to me an "easy-step" approach is more appropriate than drastic change where the vpn problem is simplified into l3 and l2 work. I definitely favor (as Jerry already noted) a 'let's wait a bit longer' approach and progress the current work and if needed discuss in Vienna options and solutions as was suggested by others (and involving all the parties). Hamid. ------_=_NextPart_001_01C318C3.ECAC8748 Content-Type: text/html; charset="iso-8859-1" RE: WG split: why and how?

Alex,

These clarifications of your first email are
certainly welcome although they are coming *one* day
before May 11 deadline set in your previous email.

See some comments inline...

>
> 4. Summary of the solution under consideration
>
>    1. Put L3 and L2 work in separate WGs
>       Analysis of the L3 and L2 remaining and potential
> future work items
>       has shown that there is a sufficient amount of work in
> each area to
>       warrant a separate WG. Smaller and more focused WGs tend to be
>       more efficient in terms of achieving consensus and completing
>       their tasks.
>
>    2. Focus the charters to ensure progress on items already in
>       the pipe; expand the charters and add more work items as
>       things progress
>

I am not sure we exhausted all the options. In addition to what George,
Bryan and others suggested on alternatives, other options can be
considered as well.

If we assume a wg split is necessary (which I am no sure it is
at this point in time), then why not address VPLS
separately from other l2vpn work. A potential option is Yakov's suggestion
to split l2vpn in two wgs. Another option is to:

a) Keep ppvpn wg as it is covering l3vpn and l2vpn
   (other than VPLS), still covering the generic documents,
   the common documents/mechanisms, the "Provider-Provisioned"
   aspects, inter-as, etc.

and,

b) Move VPLS specific related work (including provider-bridges liaison,
   etc) in a "Temporary" focused wg (we have temporary area why not
   have "temporary WGs" in INT area as well).

   While the ppvpn, vpls are progressing we can decide to join them
   at a given time.
  

At least this option keeps ppvpn as it is in terms of structure,
avoids the questions on what to do with common l2+l3
work, does minimum disruption to ppvpn wg activities in l3, l3+l2
space, takes into account that l3vpn work is in its final stage.

Other options as well is to look at a re-org from a wider
angle that affects both PWE3 and PPVPN. For example, merge some
PWE3 work with l2vpn VPW work, etc (I never understood why
some l2vpn signaling is done in another wg). 

It looks to me an "easy-step" approach is more appropriate than
drastic change where the vpn problem is simplified into
l3 and l2 work.

I definitely favor (as Jerry already noted) a 'let's wait a bit longer'
approach and progress the current work and if needed discuss in Vienna
options and solutions as was suggested by others (and
involving all the parties).


Hamid.

------_=_NextPart_001_01C318C3.ECAC8748-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 17:11:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04202 for ; Mon, 12 May 2003 17:11:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CLDTT16666 for ; Mon, 12 May 2003 17:13:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CLDPp24920 for ; Mon, 12 May 2003 17:13:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20030512135018.01635e70@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 May 2003 14:09:27 -0700 To: Mourad BERKANE , "'Ali Sajassi'" From: Ali Sajassi Subject: RE: Comments on the L2 VPN framework and solutions documents Cc: ppvpn@nortelnetworks.com, "'mick_seaman@ieee.org'" In-Reply-To: <8D91FF5277472A45A0A8F9654A146497014949BC@frlnparexcha03.la mbdanet.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_54675739==_.ALT" X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: --=====================_54675739==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 11:03 AM 5/9/2003 +0200, Mourad BERKANE wrote: >Ali, > >Enabling P-STP on a intra-island afraid me a little bit :-) >(a LER is not a ethernet switch, a LSR should never directly interact in a= =20 >STP process) PE has a bridge module and if it interfaces with an Ethernet access network= =20 (e.g., 802.1ad network), then the PE needs to be IEEE 802.1ad compliant. >A short example here: >What will happen during a LSP failure in the backbone? > >Will P-STP instance on the affected PE will wait for the reconstruction of= =20 >this LSP (rsvp fast-reroute for example) > >or > >Will this PE deducted that the Ethernet switches loop is broken and will=20 >change the status of his acces port (or on the remote PEs) from Blocking=20 >to Forwarding? We have had a detailed discuss on this same topic before. Please review the= =20 archive. >The difficulty here will be to synchronise all P-STP process in the=20 >backbone with MPLS signaling if you don't want that a STP message become=20 >quicly useless. Again we had this discussion before. P-STP is not used in the backbone for= =20 inter-island and for intra-island, the P-STP failure detection time needs=20 to be longer than PW failure recovery time. -Ali >Have you an idea of the P-STP convergence (what you want to do and what=20 >you can)? > >I would like to be optimist on this topic but i can't, look like a hard=20 >issue here. > >Mourad > >-----Message d'origine----- >De : Ali Sajassi [mailto:sajassi@cisco.com] >Envoy=E9 : vendredi 9 mai 2003 01:03 >=C0 : Himanshu Shah; mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; >Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis >Cc : ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Objet : RE: Comments on the L2 VPN framework and solutions documents > > > >At 05:46 PM 5/8/2003 -0400, Himanshu Shah wrote: > >I understand this approach. Its a simple approach. > >And if you want to run M-STP (1 instance) across PWs > >you may want to use this approach. > > > >However, the VPLS drafts in IETF explicitly > >talks about not having to run the P-STP across PWs. > >Dual-homing/external loop in Provider's network > >is handled without using P-STP. > > > >There seems to be some disconnect in understanding > >between these two groups that needs to be worked > >out. > >I don't think there is a disconnect. When you talk about P-STP, you need to >consider both intra-island and inter-island. P-STP is NOT used for >inter-island - for that we use full-mesh with split horizon. However, for >intra-island where you can have an arbitrary topology of bridges within an >access domain, then P-STP is the only viable solution (refer to section >11.2 of draft-lasserre-vkompella). Also keep in mind that P-STP is >suggested for Ethernet access domain and not MPLS access domain. > >-Ali > > >/himanshu > > > >-----Original Message----- > >From: Mick Seaman=20 > [mailto:mick_seaman@ieee.org] > >Sent: Wednesday, May 07, 2003 6:42 PM > >To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; > >'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' > >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com > >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > > > > > >Himanshu, > > > >In (1) I think you have your layering a little mixed up. From the point= of > >view of control connectivity the pseudo-wires have to establish a full > >mesh that is never perceived by layer 2 protocols as being less than > >complete. STP is running across the service that runs on top of the > >mechanisms that make the service LAN like. If you wish to provide subset > >LANs to be configured then of course you can have subsets each of which > >has full connectivity in itself. Just never try to pretend to layer 2= that > >two non equal subsets are the same LAN. > > > >In (2) I think you are further into the same pit. > > > >It is trivial to get into BPDU scaleability issues along the path you > >suggest. A much more attractive alternative is to maintain a single full > >mesh for control connectivity which then prunes that mesh per VPLS (each > >VPLS doesn't have to touch certain mesh nodes) and then uses that pruning > >to delete VPLS specific pseudowires to the unwanted mesh nodes. Only one > >instance of the topology determining protocol and the pruning protocol= are > >then required for all VPLSs. The trick here is to put provider > >provisioning in at the right level in the architecture (i.e. not at the > >pseudowire level,but higher up so that it can drive the pseudowire level > >in the context of the actually available resources). > > > >Mick > > > >-----Original Message----- > >From: Himanshu Shah=20 > [mailto:hshah@wavesmithnetworks.com] > >Sent: Wednesday, May 07, 2003 10:29 AM > >To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; > >Les Bell; Paul Congdon; Neil Jarvis > >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com > >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > > > >This digresses from earlier thinking (at least mine) > >that P-STP would not span across pseudowires. > > > >There are several implications to running STP > >across PWs that may need to be clarified/worked out. > > > >1) "fully-meshed" attribute of the PWs only applied > > within a context of a VPLS instance. That is, if > > PE1 and PE2 participated in VPLS instance 1 than > > there was no pseudowire to PE3 which did not > > participate in VPLS instance 1. However, with this > > scheme, each PE would have pseudowire to every > > other VPLS capable PE irrespective of its VPLS > > instance membership > > > >2) Assuming that 1 MSTP instance covers entire provider's > > network, a backdoor link from ProvBridge1 to ProvBridge2 > > of VPLS instance 1, may cause 802.1ad's emulated LAN ports > > to all VPLS instances (i.e. all PWs from that PE are > > in blocked state irrespective of its VPLS instance > > membership). Doesn't this block other VPLS instances's > > traffic across PWs? > > > > Perhaps my assumption is wrong and there is in fact > > P-STP instance for each VPLS instance. However, if that > > is true, PE would run into BPDU scalability issues. > > > > > >/himanshu > > > > > >-----Original Message----- > >From: Mick Seaman=20 > [mailto:mick_seaman@ieee.org] > >Sent: Wednesday, May 07, 2003 10:42 AM > >To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree'; > >'Les Bell'; 'Paul Congdon'; 'Neil Jarvis' > >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com > >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > > > > > >If the fully meshed pseudowires (and the attached equipment/functions at > >their ends) provide a LAN Service (stictly the Internal Sublayer Service > >as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both > >documents) then RSTP/MSTP will work just fine. > > > >To be more specific P802.1ad does specify the operation of a single > >instance of MSTP within a Provider Network, how that travels over > >pseduowires is of course how any LAN traffic travels over psedudowires > >(i.e. the pseudowire protocol looks after making sure the configuration= of > >the pseudo wires correctly provides the fully connected LAN service, that > >not being either MSTPs design goal or the desire of P802.1ad to specify > >the simulation of LANs over non-LAN media, particularly where the non-LAN > >media have native protocols that are to be used as part of the solution - > >MPLS for example). > > > >Mick > > > >-----Original Message----- > >From: Himanshu Shah=20 > [mailto:hshah@wavesmithnetworks.com] > >Sent: Wednesday, May 07, 2003 6:01 AM > >To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; > >Paul Congdon; Neil Jarvis > >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com > >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > > > >Norm, > > > >You have to excuse me for jumping in at the > >tail end and not following the thread. > > > >I would like a clarification. > > > >Are you implying that 802.1ad is contemplating on > >running one or more (Provider's) instances of R/M/STP > >on fully-meshed pseudowires? > > > >/himanshu > >Wavesmith Networks > > > >-----Original Message----- > >From: Norman Finn [mailto:nfinn@cisco.com] > >Sent: Tuesday, May 06, 2003 8:14 PM > >To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon; > >Neil Jarvis > >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com > >Subject: Re: Comments on the L2 VPN framework and solutions documents > > > > > >Muneyoshi, > > > >Muneyoshi Suzuki wrote: > > > > > > > I don't think we're referring to the same model. The correct model > > > > for how a bridge interacts with full-meshes, one full-mesh per VPLS > > > > instance, is: > > > > > > The discussion is in the context of WG last call of the L2 FW doc and > > > how to progress related solution drafts. So, I'm referring Eric's= model > > > describe in the FW doc. The following model completely differ from=20 > Eric's, > > > so the following is disagreement to the FW doc, isn't it? > > > >My abrupt answer: The FW doc is misleading, because it disagrees > >with the way bridges are both defined and built. > > > >Another way to put it: My diagram is the only way that a standard > >bridge CAN interface to the full meshes within the layering model > >shared by IEEE 802 and IETF. I should be more careful in my claims: > >It's the only way that has been presented, to date, to IEEE 802.1, > >and has received a lot of support. > > > >The problem with the model in the L2 FW doc (rev 3) is that it > >clings to the idea, discarded by IEEE 802 in 1996, that separate > >VLANs are handled by separate, independent, virtual bridges. IEEE > >802.1Q chose a model in which one bridge handles all of the VLANs > >using individual physical ports, through which each of the VLANs > >pass. > > > >There is little point in arguing over which model is better. I > >favored the IETF model when 802.1Q was making its decision, but I lost. > >The models, diagrams, and protocols employed by 802.1Q, and hence the > >actual bridges built today, conform to the IEEE model. There is > >every reason to argue over which model is more relevant; the one to > >which bridges are actually built should be of considerably more > >interest than it seems to be on this mailing list. > > > >The diagram, below, brings the IEEE model, in which all VLANs pass > >through a single port, in line with VPLS full meshes, which exist one > >per (Provider VLAN | Customer Service Instance | Forwarding Function). > > > >Rather than rail against the L2 FW doc rev 3, let me suggest this: > >Provider Bridges exist, are making money for their (several) builders, > >and hopefully, are making money for their purchasers. IEEE 802.1AD > >will standardize them. IEEE 802.1AD will be based on the 802.1Q model. > >Deployed pseudowire full meshes will, of market-driven necessity, be > >compatible with this 802.1AD provider bridge model. The only questions > >are whether or not the 802.1AD-compatible implementations will conform > >to the IETF documentation, and if not, whether their will exist naive > >implementations of the incorrect IETF documents that confuse the market. > >(Incorrect by definition, if they disagree with bridge implementations.) > > > > > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-= -------+ > > > > | | | forwarding | | > > > > | | | function +--- | > > > > E i --+ | untagged + VPLS 100 | | > > > > t n | Provider | | for=20 > BPDUs +--- | P r > > > > h t | Bridge | |------------| |=20 > s o > > > > e e | | | +--- |=20 > e u > > > > r r --+ | | forwarding=20 > | | u t > > > > n f | Each "+" in | VLAN 26=20 > + function +--- | d i > > > > e a | the border of | | VPLS=20 > 200 | | o n > > > > t c | this=20 > block | mux- | +--- | w g > > > > e --+ represents one + demux |------------| | i > > > > s | bridge port | function=20 > | +--- | r f > > > > | | | | |=20 > e u > > > > | | | +--- |=20 > s n > > > > --+ | | forwarding=20 > | | c > > > > | | VLAN 589=20 > + function +--- | i t > > > > | | | VPLS=20 > 300 | | n i > > > > | | | +--- |=20 > o > > > > --+ | | | |=20 > n > > > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-= -------+ > > > > A B C > > > > > > > > The single interface above the "A" label at the bottom is the= Provider > > > > Bridge's bridge port that opens to the L3 world. The three= interfaces > > > > above the "B" label are the interfaces between the forwarding=20 > functions > > > > and the mux-demux unit that translates between the Provider Bridge's > > > > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths= of > > > > the pseudowires. The physical ports on the routed side are of no > > > > interest to the bridge. :) > > > > > > > > In my last note, I was pointing out that the each forwarding= function > > > > MUST control its "B" interface so that it provides 1) full service,= or > > > > 2) no service. (Let's be honest -- my last note was a little= confused > > > > between the "A" interface and the "B" interfaces.) > > > > > > > > Since VPLS meshes have one characteristic that physical LANs don't= -- > > > > one VLAN can be disconnected, while another is working -- IEEE 802.1 > > > > needs to examine this situation, and figure out how to deal with it. > > > > > > > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > > > > is absolutely required to prevent a meltdown of the Provider's=20 > network. > > > > A failure of one of the other VPLSs affects only that customer's=20 > traffic. > > > > > > (1) It seems to me, in the above model, PEs are interconnected with= per > > > customer meshes, where the PEs attached to the customer are=20 > interconnected > > > with a full mesh. Therefore, in the worst case, there 2000 full meshes > > > between PEs, if number of customers are 2000. Originally, full mesh=20 > has the > > > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2)=20 > problem. > > > Furthermore, if fast protection is supported to avoid the protection > > > racing problem and partial mesh, there are double meshes between the= =20 > PEs. > > > So, I don't feel any reality from the above model. > > > >For N PEs, the number of LSPs is exactly N, because each LSP is a > >multipiont-to-point tree terminating at the destination PE. The number > >of "branches" on all LSP trees is far less than O(N^2), because there is > >(probably) no single VPLS that spans all of the PEs. The VPLS that > >touches the largest number of PEs determines the largest n^2 full mesh > >of LSP "branches". In a typical network with a very large number of > >PEs, the actual number of LSP "branches" will be far less than N^2. > > > >Within that partial mesh of LSPs, for each VPLS, there is a full mesh > >of pseudowires. The cost of setting up a pseudowire is trivial, > >compared to the cost of an LSP, because it does not involve the > >intervening routers. The number of pseudowires required is O(m^2), > >where m is not the total number of PEs, but some smaller number, > >related to the typical number of PEs attached to each VPLS. > > > > > (2) Frankly, I don't well understand the above model, because it > > > illustrates some implementation, but is not a protocol architecture. > > > >I disagree completely that it is not a protocol architecture. I would > >not implement the above diagram in one of my switches, because it would > >be horribly inefficient, there. This is precisely a protocol > >architecture, because it illustrates exactly where the existing > >standardized interfaces and standardized functions go, and exactly > >where new protocol and/or functional elements are required. = Specifically, > >the "mux/demux function", which is trivial, and the "Forwarding= Function", > >which L2VPN is defining. > > > > > In the Bridge architecture defined in a series of the IEEE standards, > > > a Bridge consists of MAC entities, a MAC relay entity, and a Higher > > > layer entity. Could you clarify where these entities are located in > > > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is= located? > > > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs > > located? > > > What is VLAN mux-demux function? According to the standards, the VLAN= ID > > > value is effective only inside the MAC relay entity, so it does not > > > identify MSAP. I'm not sure whether this conforms with the standards= or > > not, > > > but I think to realize this architecture big changes are needed to the > > > current standards. > > > >All of the standard IEEE bridge functions are contained in the "Provider > >Bridge" block. I did not break it out into its components, because there > >is no need to do so; their existing functions are unchanged. The VLAN > >mux-demux function merely translates between the Provider's VLAN tags and > >the Forwarding Function world. > > > >The IEEE P802.1 Working Group writes the bridging standards. All of the > >members of IEEE 802.1, with whom I have discussed this diagram, and that= is > >most of them, believe the above diagram to be conformant to the IEEE 802 > >standards. It's a shame I cannot explain it better, and I invite > >those members of 802.1 who read this mailing list to respond, and either > >argue with me, or hopefully, explain it better. :) > > > >-- Norm --=====================_54675739==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 11:03 AM 5/9/2003 +0200, Mourad BERKANE wrote:

Ali,

Enabling P-STP on a intra-island afraid me a little bit :-)
(a LER is not a ethernet switch, a LSR should never directly interact in a STP process)

PE has a bridge module and if it interfaces with an Ethernet access network (e.g., 802.1ad network), then the PE needs to be IEEE 802.1ad compliant.


A short example here:
What will happen during a LSP failure in the backbone?=

Will P-STP instance on the affected PE will wait for the= reconstruction of this LSP (rsvp fast-reroute for example)

or

Will this PE deducted that the Ethernet switches loop is= broken and will change the status of his acces port (or on the remote PEs)= from Blocking to Forwarding?

We have had a detailed discuss on this same topic before. Please review the= archive.


The difficulty here will be to= synchronise all P-STP process in the backbone with MPLS signaling if you= don't want that a STP message become quicly= useless.

Again we had this discussion before. P-STP is not used in the backbone for= inter-island and for intra-island, the P-STP failure detection time needs= to be longer than PW failure recovery time.

-Ali


Have you an idea of the P-STP= convergence (what you want to do and what you can)?

I would like to be optimist on this topic but i can't, look= like a hard issue here.

Mourad

-----Message d'origine-----
De : Ali Sajassi [mailto:sajassi@cisco.com]
Envoy=E9 : vendredi 9 mai 2003 01:03
=C0 : Himanshu Shah; mick_seaman@ieee.org; Norman Finn;= Muneyoshi Suzuki;
Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis
Cc : ppvpn@nortelnetworks.com;= Cheng-Yin.Lee@alcatel.com
Objet : RE: Comments on the L2 VPN framework and solutions= documents



At 05:46 PM 5/8/2003 -0400, Himanshu Shah wrote:
>I understand this approach. Its a simple approach.=
>And if you want to run M-STP (1 instance) across= PWs
>you may want to use this approach.
>
>However, the VPLS drafts in IETF explicitly
>talks about not having to run the P-STP across= PWs.
>Dual-homing/external loop in Provider's network=
>is handled without using P-STP.
>
>There seems to be some disconnect in understanding=
>between these two groups that needs to be worked=
>out.

I don't think there is a disconnect. When you talk about= P-STP, you need to
consider both intra-island and inter-island. P-STP is NOT= used for
inter-island - for that we use full-mesh with split horizon.= However, for
intra-island where you can have an arbitrary topology of= bridges within an
access domain, then P-STP is the only viable solution (refer= to section
11.2 of draft-lasserre-vkompella). Also keep in mind that= P-STP is
suggested for Ethernet access domain and not MPLS access= domain.

-Ali

>/himanshu
>
>-----Original Message-----
>From: Mick Seaman [mailto:mick_seaman@ieee.org]
>Sent: Wednesday, May 07, 2003 6:42 PM
>To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki';= 'Tony Jeffree';
>'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'
>Cc: ppvpn@nortelnetworks.com;= Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework and= solutions documents
>
>
>
>Himanshu,
>
>In (1) I think you have your layering a little mixed up.= From the point of
>view of control connectivity the pseudo-wires have to= establish a full
>mesh that is never perceived by layer 2 protocols as= being less than
>complete. STP is running across the service that runs on= top of the
>mechanisms that make the service LAN like. If you wish to= provide subset
>LANs to be configured then of course you can have subsets= each of which
>has full connectivity in itself. Just never try to= pretend to layer 2 that
>two non equal subsets are the same LAN.
>
>In (2) I think you are further into the same pit.=
>
>It is trivial to get into BPDU scaleability issues along= the path you
>suggest. A much more attractive alternative is to= maintain a single full
>mesh for control connectivity which then prunes that mesh= per VPLS (each
>VPLS doesn't have to touch certain mesh nodes) and then= uses that pruning
>to delete VPLS specific pseudowires to the unwanted mesh= nodes. Only one
>instance of the topology determining protocol and the= pruning protocol are
>then required for all VPLSs. The trick here is to put= provider
>provisioning in at the right level in the architecture= (i.e. not at the
>pseudowire level,but higher up so that it can drive the= pseudowire level
>in the context of the actually available= resources).
>
>Mick
>
>-----Original Message-----
>From: Himanshu Shah [mailto:hshah@wavesmithnetworks.= com]
>Sent: Wednesday, May 07, 2003 10:29 AM
>To: mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki;= Tony Jeffree;
>Les Bell; Paul Congdon; Neil Jarvis
>Cc: ppvpn@nortelnetworks.com;= Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework and= solutions documents
>
>
>This digresses from earlier thinking (at least= mine)
>that P-STP would not span across pseudowires.
>
>There are several implications to running STP
>across PWs that may need to be clarified/worked= out.
>
>1) "fully-meshed" attribute of the PWs only= applied
>    within a context of a VPLS instance.= That is, if
>    PE1 and PE2 participated in VPLS= instance 1 than
>    there was no pseudowire to PE3 which= did not
>    participate in VPLS instance 1.= However, with this
>    scheme, each PE would have pseudowire= to every
>    other VPLS capable PE irrespective of= its VPLS
>    instance membership
>
>2) Assuming that 1 MSTP instance covers entire= provider's
>    network, a backdoor link from= ProvBridge1 to ProvBridge2
>    of VPLS instance 1, may cause= 802.1ad's emulated LAN ports
>    to all VPLS instances (i.e. all PWs= from that PE are
>    in blocked state irrespective of its= VPLS instance
>    membership). Doesn't this block other= VPLS instances's
>    traffic across PWs?
>
>    Perhaps my assumption is wrong and= there is in fact
>    P-STP instance for each VPLS instance.= However, if that
>    is true, PE would run into BPDU= scalability issues.
>
>
>/himanshu
>
>
>-----Original Message-----
>From: Mick Seaman [mailto:mick_seaman@ieee.org]
>Sent: Wednesday, May 07, 2003 10:42 AM
>To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki';= 'Tony Jeffree';
>'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'
>Cc: ppvpn@nortelnetworks.com;= Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework and= solutions documents
>
>
>
>If the fully meshed pseudowires (and the attached= equipment/functions at
>their ends) provide a LAN Service (stictly the Internal= Sublayer Service
>as defined in 802.1D and 802.1Q Clause 6.5 (same number= clause in both
>documents) then RSTP/MSTP will work just fine.=
>
>To be more specific P802.1ad does specify the operation= of a single
>instance of MSTP within a Provider Network, how that= travels over
>pseduowires is of course how any LAN traffic travels over= psedudowires
>(i.e. the pseudowire protocol looks after making sure the= configuration of
>the pseudo wires correctly provides the fully connected= LAN service, that
>not being either MSTPs design goal or the desire of= P802.1ad to specify
>the simulation of LANs over non-LAN media, particularly= where the non-LAN
>media have native protocols that are to be used as part= of the solution -
>MPLS for example).
>
>Mick
>
>-----Original Message-----
>From: Himanshu Shah [mailto:hshah@wavesmithnetworks.= com]
>Sent: Wednesday, May 07, 2003 6:01 AM
>To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony= Jeffree; Les Bell;
>Paul Congdon; Neil Jarvis
>Cc: ppvpn@nortelnetworks.com;= Cheng-Yin.Lee@alcatel.com
>Subject: RE: Comments on the L2 VPN framework and= solutions documents
>
>
>Norm,
>
>You have to excuse me for jumping in at the
>tail end and not following the thread.
>
>I would like a clarification.
>
>Are you implying that 802.1ad is contemplating on=
>running one or more (Provider's) instances of= R/M/STP
>on fully-meshed pseudowires?
>
>/himanshu
>Wavesmith Networks
>
>-----Original Message-----
>From: Norman Finn [mailto:nfinn@cisco.com]
>Sent: Tuesday, May 06, 2003 8:14 PM
>To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les= Bell; Paul Congdon;
>Neil Jarvis
>Cc: ppvpn@nortelnetworks.com;= Cheng-Yin.Lee@alcatel.com
>Subject: Re: Comments on the L2 VPN framework and= solutions documents
>
>
>Muneyoshi,
>
>Muneyoshi Suzuki wrote:
> >
> > > I don't think we're referring to the same= model.  The correct model
> > > for how a bridge interacts with full-meshes,= one full-mesh per VPLS
> > > instance, is:
> >
> > The discussion is in the context of WG last call of= the L2 FW doc and
> > how to progress related solution drafts. So, I'm= referring Eric's model
> > describe in the FW doc. The following model= completely differ from Eric's,
> > so the following is disagreement to the FW doc,= isn't it?
>
>My abrupt answer:  The FW doc is misleading, because= it disagrees
>with the way bridges are both defined and built.=
>
>Another way to put it:  My diagram is the only way= that a standard
>bridge CAN interface to the full meshes within the= layering model
>shared by IEEE 802 and IETF.  I should be more= careful in my claims:
>It's the only way that has been presented, to date, to= IEEE 802.1,
>and has received a lot of support.
>
>The problem with the model in the L2 FW doc (rev 3) is= that it
>clings to the idea, discarded by IEEE 802 in 1996, that= separate
>VLANs are handled by separate, independent, virtual= bridges.  IEEE
>802.1Q chose a model in which one bridge handles all of= the VLANs
>using individual physical ports, through which each of= the VLANs
>pass.
>
>There is little point in arguing over which model is= better.  I
>favored the IETF model when 802.1Q was making its= decision, but I lost.
>The models, diagrams, and protocols employed by 802.1Q,= and hence the
>actual bridges built today, conform to the IEEE= model.  There is
>every reason to argue over which model is more relevant;= the one to
>which bridges are actually built should be of= considerably more
>interest than it seems to be on this mailing list.=
>
>The diagram, below, brings the IEEE model, in which all= VLANs pass
>through a single port, in line with VPLS full meshes,= which exist one
>per (Provider VLAN | Customer Service Instance |= Forwarding Function).
>
>Rather than rail against the L2 FW doc rev 3, let me= suggest this:
>Provider Bridges exist, are making money for their= (several) builders,
>and hopefully, are making money for their= purchasers.  IEEE 802.1AD
>will standardize them.  IEEE 802.1AD will be based= on the 802.1Q model.
>Deployed pseudowire full meshes will, of market-driven= necessity, be
>compatible with this 802.1AD provider bridge model. = The only questions
>are whether or not the 802.1AD-compatible implementations= will conform
>to the IETF documentation, and if not, whether their will= exist naive
>implementations of the incorrect IETF documents that= confuse the market.
>(Incorrect by definition, if they disagree with bridge= implementations.)
>
> >= >            = ; |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--------+=
> >= >            = ;= |            &n= bsp;     = |          | forwarding= |       |
> >= >            = ;= |            &n= bsp;     = |          | = function  +---    |
> > >    E  i  = --+            =        | untagged +  VPLS 100 = |       |
> > >    t = n     |     = Provider    = |          | for BPDUs = +---    |  P  r
> > >    h = t     |      = Bridge     = |         = |------------|       |  s  o=
> > >    e = e    = |            &n= bsp;     = |         = |           = +---    |  e  u
> > >    r  r  = --+            =       = |          | forwarding= |       |  u  t
> > >    n = f     |     Each "+"= in   |  VLAN 26 +  function = +---    |  d  i
> > >    e = a     |    the border of = |          |  VPLS= 200  |       |  o  n=
> > >    t = c     |     this= block    |   mux-  = |           = +---    |  w  g
> > >      = e   --+   represents one  + = demux   |------------|      = |  i
> > >      = s     |     bridge port  = | function= |           = +---    |  r  f
> >= >            = ;= |            &n= bsp;     = |         = |           = |       |  e  u
> >= >            = ;= |            &n= bsp;     = |         = |           = +---    |  s  n
> >= >          = --+            =       = |          | forwarding= |       |     c=
> >= >            = ;= |            &n= bsp;      | VLAN 589 +  function = +---    |  i  t
> >= >            = ;= |            &n= bsp;     = |          |  VPLS= 300  |       |  n  i=
> >= >            = ;= |            &n= bsp;     = |         = |           = +---    |     o
> >= >          = --+            =       = |         = |           = |       |     n=
> >= >            = ; |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--------+=
> >= >            = ;            &nb= sp;       = A         = B           = C
> > >
> > > The single interface above the "A"= label at the bottom is the Provider
> > > Bridge's bridge port that opens to the L3= world.  The three interfaces
> > > above the "B" label are the= interfaces between the forwarding functions
> > > and the mux-demux unit that translates between= the Provider Bridge's
> > > P-VLAN space and the VPLS VCID space. = The "C" ports are the mouths of
> > > the pseudowires.  The physical ports on= the routed side are of no
> > > interest to the bridge.  :)
> > >
> > > In my last note, I was pointing out that the= each forwarding function
> > > MUST control its "B" interface so= that it provides 1) full service, or
> > > 2) no service.  (Let's be honest -- my= last note was a little confused
> > > between the "A" interface and the= "B" interfaces.)
> > >
> > > Since VPLS meshes have one characteristic that= physical LANs don't --
> > > one VLAN can be disconnected, while another is= working -- IEEE 802.1
> > > needs to examine this situation, and figure= out how to deal with it.
> > >
> > > Finally, let me note that only one VPLS -- the= one used for BPDUs --
> > > is absolutely required to prevent a meltdown= of the Provider's network.
> > > A failure of one of the other VPLSs affects= only that customer's traffic.
> >
> > (1) It seems to me, in the above model, PEs are= interconnected with per
> > customer meshes, where the PEs attached to the= customer are interconnected
> > with a full mesh. Therefore, in the worst case,= there 2000 full meshes
> > between PEs, if number of customers are 2000.= Originally, full mesh has the
> > O(N^2) problem, so the proposed scheme has= O(#ofCustomers * N^2) problem.
> > Furthermore, if fast protection is supported to= avoid the protection
> > racing problem and partial mesh, there are double= meshes between the PEs.
> > So, I don't feel any reality from the above= model.
>
>For N PEs, the number of LSPs is exactly N, because each= LSP is a
>multipiont-to-point tree terminating at the destination= PE.  The number
>of "branches" on all LSP trees is far less than= O(N^2), because there is
>(probably) no single VPLS that spans all of the= PEs.  The VPLS that
>touches the largest number of PEs determines the largest= n^2 full mesh
>of LSP "branches".  In a typical network= with a very large number of
>PEs, the actual number of LSP "branches" will= be far less than N^2.
>
>Within that partial mesh of LSPs, for each VPLS, there is= a full mesh
>of pseudowires.  The cost of setting up a pseudowire= is trivial,
>compared to the cost of an LSP, because it does not= involve the
>intervening routers.  The number of pseudowires= required is O(m^2),
>where m is not the total number of PEs, but some smaller= number,
>related to the typical number of PEs attached to each= VPLS.
>
> > (2) Frankly, I don't well understand the above= model, because it
> > illustrates some implementation, but is not a= protocol architecture.
>
>I disagree completely that it is not a protocol= architecture.  I would
>not implement the above diagram in one of my switches,= because it would
>be horribly inefficient, there.  This is precisely a= protocol
>architecture, because it illustrates exactly where the= existing
>standardized interfaces and standardized functions go,= and exactly
>where new protocol and/or functional elements are= required.  Specifically,
>the "mux/demux function", which is trivial, and= the "Forwarding Function",
>which L2VPN is defining.
>
> > In the Bridge architecture defined in a series of= the IEEE standards,
> > a Bridge consists of MAC entities, a MAC relay= entity, and a Higher
> > layer entity. Could you clarify where these= entities are located in
> > the above figure? Where are MSAPs defined in= ISO/IEC 15802-1 is located?
> > If the provider Bridge is a VLAN aware Bridge,= where are the E-ISSs
> located?
> > What is VLAN mux-demux function? According to the= standards, the VLAN ID
> > value is effective only inside the MAC relay= entity, so it does not
> > identify MSAP. I'm not sure whether this conforms= with the standards or
> not,
> > but I think to realize this architecture big= changes are needed to the
> > current standards.
>
>All of the standard IEEE bridge functions are contained= in the "Provider
>Bridge" block.  I did not break it out into its= components, because there
>is no need to do so; their existing functions are= unchanged.  The VLAN
>mux-demux function merely translates between the= Provider's VLAN tags and
>the Forwarding Function world.
>
>The IEEE P802.1 Working Group writes the bridging= standards.  All of the
>members of IEEE 802.1, with whom I have discussed this= diagram, and that is
>most of them, believe the above diagram to be conformant= to the IEEE 802
>standards.  It's a shame I cannot explain it better,= and I invite
>those members of 802.1 who read this mailing list to= respond, and either
>argue with me, or hopefully, explain it better. = :)
>
>-- Norm
--=====================_54675739==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 17:23:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04375 for ; Mon, 12 May 2003 17:23:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CLPmT22336 for ; Mon, 12 May 2003 17:25:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CLPjB04235 for ; Mon, 12 May 2003 17:25:45 -0400 (EDT) Message-ID: From: "Joseph Tomkin" To: "'ppvpn@lyris.nortelnetworks.com'" Subject: subscribe Date: Mon, 12 May 2003 16:23:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C318CC.AD86C412" X-LYRIS-Message-Id: 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_01C318CC.AD86C412 Content-Type: text/plain Joe Tomkin Sales Engineering Service Provider Solutions Nortel Networks tel. (905) 863-7020 (ESN 333) fax. (905) 863-8445 josepht@nortelnetworks.com ------_=_NextPart_001_01C318CC.AD86C412 Content-Type: text/html subscribe

Joe Tomkin
Sales Engineering
Service Provider Solutions
Nortel Networks
tel. (905) 863-7020 (ESN 333)
fax. (905) 863-8445
josepht@nortelnetworks.com


------_=_NextPart_001_01C318CC.AD86C412-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 17:43:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04896 for ; Mon, 12 May 2003 17:43:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CLjRT29331 for ; Mon, 12 May 2003 17:45:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CLjJ513524 for ; Mon, 12 May 2003 17:45:20 -0400 (EDT) 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: Comments on the L2 VPN framework and solutions documents Date: Mon, 12 May 2003 17:42:33 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB7202152617@WHISTLER.WaveSmithNet.com> Thread-Topic: Comments on the L2 VPN framework and solutions documents Thread-Index: AcMVthfutE5yawDaTwuoe8N0bgvl5QDF7ekw From: "Himanshu Shah" To: "Ali Sajassi" , , "Norman Finn" , "Muneyoshi Suzuki" , "Tony Jeffree" , "Les Bell" , "Paul Congdon" , "Neil Jarvis" Cc: , X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA04896 Ali, You seem to have different opinion than others in IEEE group. ali> I don't think there is a disconnect. When you talk about ali> P-STP, you need to consider both intra-island and ali> inter-island. P-STP is NOT used for inter-island - ali> for that we use full-mesh with split horizon. ali> Also keep in mind that P-STP is suggested for ali> Ethernet access domain and not MPLS access domain. However, Mick seems to suggest something different mick> If the VPLS drafts have not changed significantly in mick> their intent (I don't think they have) there is not a disconnect here. mick> There is a difference between running spanning tree to cut PWs mick> and reduce their topology to that of a spanning tree mick> (which is what the VPLS folks were correctly rejecting) mick> and conveying spanning tree BPDUs across the emulated LAN mick> formed by PWs so that bridge ports attaching to that emulate LAN mick> service can have the right state, including the 'LAN' or not in the mick> active topology/topologies for VLANs. Again it is neccessary to get mick> the layering straight, focusing on which wire a BPDU goes down before mick> the layering is straight really doesn't help. Can you clarify what you mean? /himanshu From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 17:53:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05066 for ; Mon, 12 May 2003 17:53:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CLtcT04495 for ; Mon, 12 May 2003 17:55:38 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CLtZ522584 for ; Mon, 12 May 2003 17:55:35 -0400 (EDT) Message-ID: <3EC01857.2040401@marconi.com> Date: Mon, 12 May 2003 17:55:35 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030430 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF PPVPN List Subject: Re: ASON reqts References: <9D42C6E086250248810DCADA39CE7EFC972540@nimbus> In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC972540@nimbus> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: David.Charlap@marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit "I have read this document and it is ready to be a CCAMP WG doc" There are a few issues that I don't quite understand and/or need clarification on, but the current vote is WG acceptance, not last-call. I have no issues with it that would keep it out from the WG. -- David From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 17:55:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05200 for ; Mon, 12 May 2003 17:55:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CLwST08695 for ; Mon, 12 May 2003 17:58:28 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CLwO526785 for ; Mon, 12 May 2003 17:58:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20030512143745.01dfa5a0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 May 2003 14:52:03 -0700 To: "Himanshu Shah" , "Ali Sajassi" , , "Norman Finn" , "Muneyoshi Suzuki" , "Tony Jeffree" , "Les Bell" , "Paul Congdon" , "Neil Jarvis" From: Ali Sajassi Subject: RE: Comments on the L2 VPN framework and solutions documents Cc: , In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB720215260D@WHISTLER.WaveSmit hNet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: At 08:29 AM 5/9/2003 -0400, Himanshu Shah wrote: >May be an example will clear up some confusion... :-) > >Lets suppose there is PE-x which is connected to island A >and island B. There is PE-y that is connected to island A >and island C. and there is PE-z that is connected to >island B and island C. > >Based on what I understand from Mick's explanation is that >there is > >1. (using your terminology) network-facing (i.e. PW > based) emulated Vlan ports (one for each island) and > 1 emulated LAN port (for P-STP, 1 instance MSTP) > in each PE. >2. There is P-STP BPDUs generation/propagation on emulated > LAN port to determine its forwarding state. >3. The state of the emulated LAN port also determines the > state of each emulated VLAN port in a PE. > >Please let me know if above understanding is correct. PE-x, y, and z should be considered as part of their corresponding islands. Also if there is a single PE in each island, then there is no need to run STP over the big emulated LAN ports between the PEs because if that big emulated LAN ports fails, then there is no other PE to connect the island into the backbone. However, STP is run within an island to take care of loop within among different Etherent nodes in that island. Now if you have more than one PE in an island, then you run STP between the emulated LAN port of different PE within that island so if one fails, you can connect to the core through another PE. -Ali >Now further suppose, > >1. there is 10GB backdoor connection between island A > (behind PE-x and PE-y). >2. Emulated LAN port in PE-x blocks thus causing emulated > VLAN port blocking for island A and island B. > >How does the traffic from island B behind PE-z reaches to >island B behind PE-x? > >Now let me guess to what you and/or Mick are saying, > >1. 802.1ad does not participate in P-STP. It simply > takes a received P-BPDU from island facing port > and forwards it out to respective emulated > VLAN port (something like what you are suggesting > in your response but not the impression I got from > Mick's explanation) >or > >1a. 802.1ad does not participate in P-STP. It drops > any P-BPDU received from its island facing port. > >or > >2. 802.1ad does participate in P-STP but only on > island/access facing ports. P-BPDU received from > island facing ports is processed for that port > state and forwarded to respective emulated VLAN port. > >or > >3. 802.1ad participates in P-STP on emulated LAN port > to determine the states of all emulated VLAN ports > (my impression from Mick's explanation) > >or > >4. Each PW is treated as separate emulated port (I > don't think anybody is saying this, including me. > This is what old bridges used to do for WAN > ports but does not make sense for VPLS model at all) > > >I think option 1 or 1a makes sense but >has implications of how STP is built and where the >root gets selected (possibility of having traffic >passing through cloud twice). > >/himanshu > > >-----Original Message----- >From: Ali Sajassi [mailto:sajassi@cisco.com] >Sent: Thursday, May 08, 2003 7:03 PM >To: Himanshu Shah; mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; >Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis >Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com >Subject: RE: Comments on the L2 VPN framework and solutions documents > > > > >At 05:46 PM 5/8/2003 -0400, Himanshu Shah wrote: > >I understand this approach. Its a simple approach. > >And if you want to run M-STP (1 instance) across PWs > >you may want to use this approach. > > > >However, the VPLS drafts in IETF explicitly > >talks about not having to run the P-STP across PWs. > >Dual-homing/external loop in Provider's network > >is handled without using P-STP. > > > >There seems to be some disconnect in understanding > >between these two groups that needs to be worked > >out. > >I don't think there is a disconnect. When you talk about P-STP, you need to >consider both intra-island and inter-island. P-STP is NOT used for >inter-island - for that we use full-mesh with split horizon. However, for >intra-island where you can have an arbitrary topology of bridges within an >access domain, then P-STP is the only viable solution (refer to section >11.2 of draft-lasserre-vkompella). Also keep in mind that P-STP is >suggested for Ethernet access domain and not MPLS access domain. > >-Ali > > > >/himanshu > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 17:59:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05294 for ; Mon, 12 May 2003 17:59:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CM25T26614 for ; Mon, 12 May 2003 18:02:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CM22V17117 for ; Mon, 12 May 2003 18:02:03 -0400 (EDT) Date: Mon, 12 May 2003 17:59:41 -0400 (EDT) From: schultz@io.iol.unh.edu To: Alex Zinin cc: PPVPN Subject: Draft charter for L2VPN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: io.iol.unh.edu X-SMTP-MAIL-FROM: schultz@io.iol.unh.edu X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: io.iol.unh.edu [132.177.123.82] X-LYRIS-Message-Id: Hello Alex, One small comment. I know that this does not matter to some, but IMHO if this new group happens, an indication of the WG cooperation with IEEE 802.1 should be part of the charter to add clarity. Thanks, -Ben From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 18:23:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06924 for ; Mon, 12 May 2003 18:23:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CMQ3T19191 for ; Mon, 12 May 2003 18:26:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CMQ0Z25971 for ; Mon, 12 May 2003 18:26:00 -0400 (EDT) Reply-To: From: "Mick Seaman" To: "'Himanshu Shah'" , "'Ali Sajassi'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" Cc: , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Mon, 12 May 2003 15:23:55 -0700 Message-ID: <003801c318d5$2dcfa730$210110ac@corp.telseon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0039_01C3189A.8170CF30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB7202152617@WHISTLER.WaveSmithNet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MS-TNEF-Correlator: 0000000043410BC5A002D6408BB2E6318DA014D2C42DC700 X-SMTP-HELO: pimout3-ext.prodigy.net X-SMTP-MAIL-FROM: mick_seaman@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pimout3-ext.prodigy.net [207.115.63.102] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C3189A.8170CF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Himanshu, I don't see the disconnect between what Ali is saying below and what I said. They may be different statements but I don't see that that means they disagree. Unfortunately I don't see how to resolve your difficulties. Mick -----Original Message----- From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] Sent: Monday, May 12, 2003 2:43 PM To: Ali Sajassi; mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com Subject: RE: Comments on the L2 VPN framework and solutions documents Ali, You seem to have different opinion than others in IEEE group. ali> I don't think there is a disconnect. When you talk about ali> P-STP, you need to consider both intra-island and ali> inter-island. P-STP is NOT used for inter-island - ali> for that we use full-mesh with split horizon. ali> Also keep in mind that P-STP is suggested for ali> Ethernet access domain and not MPLS access domain. However, Mick seems to suggest something different mick> If the VPLS drafts have not changed significantly in mick> their intent (I don't think they have) there is not a disconnect here. mick> There is a difference between running spanning tree to cut PWs mick> and reduce their topology to that of a spanning tree mick> (which is what the VPLS folks were correctly rejecting) mick> and conveying spanning tree BPDUs across the emulated LAN mick> formed by PWs so that bridge ports attaching to that emulate LAN mick> service can have the right state, including the 'LAN' or not in the mick> active topology/topologies for VLANs. Again it is neccessary to get mick> the layering straight, focusing on which wire a BPDU goes down before mick> the layering is straight really doesn't help. Can you clarify what you mean? /himanshu ------=_NextPart_000_0039_01C3189A.8170CF30 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjkWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBQAMAA8AFwAAAAEAEgEB A5AGABAKAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAQ29tbWVudHMgb24gdGhlIEwyIFZQTiBmcmFtZXdvcmsgYW5kIHNvbHV0 aW9ucyBkb2N1bWVudHMAAAAAAgFxAAEAAAAWAAAAAcMY1SxkzHX+zHdSRHW0+w6db1pqsAAAAgEd DAEAAAAaAAAAU01UUDpNSUNLX1NFQU1BTkBJRUVFLk9SRwAAAAsAAQ4AAAAAQAAGDgC6tAvVGMMB AgEKDgEAAAAYAAAAAAAAAENBC8WgAtZAi7LmMY2gFNLCgAAAAwAUDgEAAAALAB8OAQAAAAIBCRAB AAAAswUAAK8FAAAMCQAATFpGdVhGDeYDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMC gA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1 ESIMYGMAUDMLCQFkMzYWUAumIEjjB3AAcWh1LAqiCoQKgGhJIGQCICcFQBQQZWggdGge4GQEAAWg blZuBZAFQGIUIHcJ4SCGdxPgBUBBbGkgBADpHrBheQuAZx/hF7AH4B0AcGQgZB5AITBpZC7kIFQf EHkgAMAjQB/w/x8xASAEkAnwHqEBkA6wB4DzAjAEIGJ1InIeaiCRJiPfB4AGIh8BI0AfQWEJwiLw TFVuAhAAIHVuJJFsiyNAHkpoIdF0byAYIOpzBvB2HuB5CGEjww3gqHVsdAiQcyLwTQ3gqmsdii0s 0k8FEGcLgG8HQAXQB5AnkWUs0x2ERh0DYToc5wYAE+BoIFtnAMADECnwOmgdQC/gQMR3YSpwc21p HwAfoJsgEAWwayugBaBtXR2EVwZgAjAvEE0CIGQhQCyfBdAjcQ4gM3AB0DAzNACkOjQ0QFBNHYRU MHCTILMGEGphBBBpOyNQ1SvhXxQQYQOBQAiQJ9G1BbBnNiBOBbADgkYLgNpuNiBNKHAjMG8dQDWR sHV6dWs2EDTWbiNArkoBEQnRNiBMB5FCIbD7AnA0oGErUBIhIXAeYTeBamUDEUoKwHYEAB2EQ0Jj LxBwcHZwNuBubxfBIbAxijYgQx8QIXAtSlkLgC46wGVAB0BjxyiSMgIyVXViah+xLxDsUkUvEAhQ bSTEAiAe88JMFEBWUE4gA1A2sN8H0DHBIfMqQSUwaQIgBCD/HmArQCTDHYodhCDBM3AdivZZCGAe sm0p4hPgKnEj2LxvcAuARJEmEgOgbx8BrxQAHYQLgCKARUsgIAnAmQhgcC4digdAaT4lV78fAAuA Q+BKMh7gIQFhHzn9IvBXP0Eqkh7wB0BD4QbggyUxTClQLVNUUDNw/09yH6AJgCniH3EAkASBH+Dv SiEg8AIwQ3AtBAALYCIR/yICTClTIQSQU3Ui8FETIPLgTk9UIHUUECIgKDH5VNsgLVBaVuImIyAg VoLzQ1ArUGwtB4Ev8APwUvHecwtQMVApoQUQegIgIvCnTCkgwCpAIGsJ4HBTEY82MSIRJiNVx3N1 Zy4AdyRwVrVMKUVKMjGBIfBj/mMtwR5RMCEDoCICPfAFQLhNUEwF8GB7S7tIIdD6ZSpwcjNxK+FH 0ycBKgD/XlVEMQeATVIhgCPXHYo2Qt1MsWYe80MgYfFkQ3ABgH8EIEhjYZIT0SFwUeEAkGf3AwAr IQBwdCjBSuFnSh8BdmlXBCRBKEzfI0BIYin/Tahhkk5KKaAkEVuGZ6QjEe9N6CP0YJAf53IocAMA IXF/WrAAcHNTU0Ae0lIhJTFQ/lcEIWdZIgIYIRrQHuNsQXUp8HAXoWcjQCnxJiNv72gQTkBzrGdK KCBwDeBTAf8EICBzaDcCEE/QeoFN0gWh/xggH8AowRggQVIhYW5gdT4PH3EqcCFTc6xCUERV704h BQA4wCcDICSwK1AkkfkiIExBQ0BnSigxB4AiIF5iI0B08lxxJiNiBRBk/y4APYAXwU4hAkAA0GYD d5b/gRWBnxQQPLFycWqxSFQfAt0tMWgkVTNwC4BjCkAfQOt0Ah8RJ4GhJ0JwBcBhkr9K4R8CdTt9 EYhSdxUvdwWbK4FW01aBoSuhQWdhEv9a4W7iBZBgkgrAd3MuAFBG9Wu3IAtgeQZxfvJTQYjS/zNw AhArQACQIXFCgXoUA/BvTeFOQIACS1BvB5EeYHf3A6Af8CgxZZC/kcYhApJVfyoRB0AowR5gB5Ae gh8QbP1LrEMDkU9yibAKwAaQI0DXIHNPcibCPx2KLzjgHRQFHYR9nbAAHgBCEAEAAABFAAAAPDA0 OUFBRkVEOTE4NTEyNDRCOUZGNzREMEQ5RDBFQjcyMDIxNTI2MTdAV0hJU1RMRVIuV2F2ZVNtaXRo TmV0LmNvbT4AAAAAAwAJWQEAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAI IAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA AAADABmACCAGAAAAAADAAAAAAAAARgAAAABShQAAfW4BAB4AGoAIIAYAAAAAAMAAAAAAAABGAAAA AFSFAAABAAAABAAAADkuMAALABuACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsAH4AIIAYA AAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAggAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAAD ACKACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAENBC8WgAtZAi7LmMY2g FNICAfoPAQAAABAAAABDQQvFoALWQIuy5jGNoBTSAgH7DwEAAACSAAAAAAAAADihuxAF5RAaobsI ACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNl dHRpbmdzXG1pY2tcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0 bG9va1xtYWlsYm94LnBzdAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDQz NDEwQkM1QTAwMkQ2NDA4QkIyRTYzMThEQTAxNEQyQzQyREM3MDAAAAAAAwAGEB9Rqh4DAAcQzwUA AAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISU1BTlNIVSxJRE9OVFNFRVRIRURJU0NPTk5F Q1RCRVRXRUVOV0hBVEFMSUlTU0FZSU5HQkVMT1dBTkRXSEFUSVNBSURUSEVZTUFZQkVESUZGRVJF TlRTVEFURU1FTlRTQlVUAAAAAFS5 ------=_NextPart_000_0039_01C3189A.8170CF30-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 19:54:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08999 for ; Mon, 12 May 2003 19:54:16 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CNujT21141 for ; Mon, 12 May 2003 19:56:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4CNuhP15051 for ; Mon, 12 May 2003 19:56:43 -0400 (EDT) Date: Mon, 12 May 2003 19:53:52 -0400 (EDT) From: schultz@io.iol.unh.edu To: "'Himanshu Shah'" cc: "'Ali Sajassi'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com, Mick Seaman , Brandon Barry , Gerard Goubert Subject: clarification of Layer 2 sub-layers In-Reply-To: <003801c318d5$2dcfa730$210110ac@corp.telseon.com> Message-ID: References: <003801c318d5$2dcfa730$210110ac@corp.telseon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: io.iol.unh.edu X-SMTP-MAIL-FROM: schultz@io.iol.unh.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: io.iol.unh.edu [132.177.123.82] X-LYRIS-Message-Id: Hello Himanshu, Nice to hear from you again. My understanding of the below discussion is that Ali and Mick are agreed on the following: - Spanning Tree will not run on service providers networks natively - Islands of Spanning Tree may exist on service provider networks - Spanning Tree BPDUs may be encapsulated across PW connections I see the layer model in the following way: Higher layer (usually IP) VLAN (optional) Spanning Tree Encapsulated Ethernet (only on the P-P or P-PE connections) MPLS (only on the P-P and P-PE connections) Ethernet or core network equivalent Does everyone agree that this is the correct order of the layer model? ST resides below VLANs because BPDUs are never tagged (even in the case of 802.1s). Maybe this should be clarified in the proper drafts so that everyone is clear. Thanks, -Ben On Mon, 12 May 2003, Mick Seaman wrote: > Himanshu, > > I don't see the disconnect between what Ali is saying below and what I said. > They may be different statements but I don't see that that means they > disagree. Unfortunately I don't see how to resolve your difficulties. Mick > > -----Original Message----- > From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] > Sent: Monday, May 12, 2003 2:43 PM > To: Ali Sajassi; mick_seaman@ieee.org; Norman Finn; Muneyoshi Suzuki; > Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis > Cc: ppvpn@nortelnetworks.com; Cheng-Yin.Lee@alcatel.com > Subject: RE: Comments on the L2 VPN framework and solutions documents > > > Ali, > > You seem to have different opinion than others > in IEEE group. > > ali> I don't think there is a disconnect. When you talk about > ali> P-STP, you need to consider both intra-island and > ali> inter-island. P-STP is NOT used for inter-island - > ali> for that we use full-mesh with split horizon. > ali> Also keep in mind that P-STP is suggested for > ali> Ethernet access domain and not MPLS access domain. > > However, Mick seems to suggest something different > > mick> If the VPLS drafts have not changed significantly in > mick> their intent (I don't think they have) there is not a disconnect here. > > mick> There is a difference between running spanning tree to cut PWs > mick> and reduce their topology to that of a spanning tree > mick> (which is what the VPLS folks were correctly rejecting) > mick> and conveying spanning tree BPDUs across the emulated LAN > mick> formed by PWs so that bridge ports attaching to that emulate LAN > mick> service can have the right state, including the 'LAN' or not in the > mick> active topology/topologies for VLANs. Again it is neccessary to get > mick> the layering straight, focusing on which wire a BPDU goes down before > mick> the layering is straight really doesn't help. > > Can you clarify what you mean? > > /himanshu > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 22:53:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12144 for ; Mon, 12 May 2003 22:53:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D2tXT02454 for ; Mon, 12 May 2003 22:55:33 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4D2tVx05360 for ; Mon, 12 May 2003 22:55:31 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60662378E@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Ash, Gerald R (Jerry), ALABS'" , "'Alex Zinin'" , "'ppvpn@nortelnetworks.com'" Subject: RE: WG split: why and how? Date: Mon, 12 May 2003 22:52:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C318FA.BB4667F0" X-LYRIS-Message-Id: 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_01C318FA.BB4667F0 Content-Type: text/plain BNJ> Folks, BNJ> I also believe Marco has done a very good job managing the PPVPN WG. BNJ> If you share this "vote of confidence" please voice it to the list. BNJ> Bilel. -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: Monday, May 12, 2003 3:33 PM To: Alex Zinin; ppvpn@nortelnetworks.com Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: WG split: why and how? Granted that there is a large number of tasks and documents to manage, which is one reason why work has not been completed. However, this problem has only recently been identified for discussion on the list, and apparently has not been discussed to any great extent with the WG chairs (Marco's input). The PPVPN chairs have ably managed the large workload, e.g., see Marco's very thorough update on 'PPVPN WG Status' at IETF-56 Jerry ------_=_NextPart_001_01C318FA.BB4667F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: WG split: why and how?

BNJ> Folks,

BNJ> I also believe Marco has done a very good job = managing the PPVPN WG.
BNJ> If you share this "vote of = confidence" please voice it to the list.

BNJ> Bilel.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Monday, May 12, 2003 3:33 PM
To: Alex Zinin; ppvpn@nortelnetworks.com
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: WG split: why and how?

<clip>

Granted that there is a large number of tasks and = documents to manage, which is one reason why work has not been = completed.  However, this problem has only recently been = identified for discussion on the list, and apparently has not been = discussed to any great extent with the WG chairs (Marco's input).  =

The PPVPN chairs have ably managed the large = workload, e.g., see Marco's very thorough update on 'PPVPN WG Status' = at IETF-56  <clip>

Jerry



------_=_NextPart_001_01C318FA.BB4667F0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 12 23:03:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12319 for ; Mon, 12 May 2003 23:03:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D35dT06956 for ; Mon, 12 May 2003 23:05:40 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4D35b724993 for ; Mon, 12 May 2003 23:05:37 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E606623796@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'PPVPN@nortelnetworks.com'" Cc: "'Scott Bradner'" Subject: PPVPN - Date: Mon, 12 May 2003 23:03:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C318FC.47590F30" X-LYRIS-Message-Id: 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_01C318FC.47590F30 Content-Type: text/plain It has been more than a week since the "PPVPN Strategy" discussion started on this mailing list. To date, we have not seen any clarification on why the AD thinks there is a problem that warrants the WG split Marco has been the PPVPN WG Co-chair since the WG has been chartered. Scott has been his AD for several years. Looking at archives of the PPVPN mailing list, the outgoing AD and the WG members did not voice any issues with the WG. Looking at the IESG minutes http://ftp.ietf.org/iesg/ , there is no indication of a problem with the PPVPN WG. This is proposal has consumed too much of the WG valuable time. I call on the AD to drop this proposal and let the WG move on with its work. Bilel. ------_=_NextPart_001_01C318FC.47590F30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable PPVPN -

It has been more than a week since the = "PPVPN Strategy" discussion started on this mailing list. =
To date, we have not seen any = clarification on why the AD thinks there is a problem that warrants the = WG split

Marco has been the PPVPN WG Co-chair = since the WG has been chartered. Scott has been his AD for several = years.
Looking at archives of the PPVPN = mailing list, the outgoing AD and the WG members did not voice any = issues with the WG.

Looking at the IESG minutes http://ftp.ietf.org/iesg/, there is no indication of a problem with the PPVPN = WG.

This is proposal  has consumed = too much of the WG valuable time.
I call on the AD to drop this = proposal and let the WG move on with its work.

Bilel.

------_=_NextPart_001_01C318FC.47590F30-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 00:50:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14648 for ; Tue, 13 May 2003 00:50:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D4qYY13353 for ; Tue, 13 May 2003 00:52:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4D4qV208771 for ; Tue, 13 May 2003 00:52:32 -0400 (EDT) Date: Tue, 13 May 2003 12:49:46 +0800 From: lidefeng Subject: A new draft,IS-IS as PE/CE routing protocol in BGP/MPLS/VPN To: internet-drafts@ietf.org Cc: ppvpn@nortelnetworks.com, isis-wg@ietf.org Message-id: <000c01c3190b$1418a540$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: multipart/mixed; boundary="Boundary_(ID_MED7rmC18pwnozvQ4TY5rg)" X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_MED7rmC18pwnozvQ4TY5rg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi,all, In deploying BGP/MPLS VPN,there are sites that CE run IS-IS protocol with PE,and the corresponding customer is reluctant to change the routing protocol they used in the sites,to accomodate this situation, it is better to run isis protocol between PE and CE,however,ther isn't any draft to specify the scenario in the BGP MPLS VPN. This draft addresses this scenario,the abstract is as following: IS-IS protocol, which is specified in [1], can be used as IGP between the Customer Edge (CE) router and the Provider Edge (PE) router in BGP/MPLS VPNs as per [1]. This document provides a detailed solution for IS-IS working as PE/CE Protocol in VPN services specified in [1]. --Boundary_(ID_MED7rmC18pwnozvQ4TY5rg) Content-type: text/plain; name=draft-sheng-ppvpn-isis-bgp-mpls-00.txt Content-disposition: attachment; filename=draft-sheng-ppvpn-isis-bgp-mpls-00.txt Content-Transfer-Encoding: 7BIT Network Working Group Sheng Cheng INTERNET DRAFT Liu Yu Expiration Date: October 2003 Li Defeng Huawei Technologies. Chen Yunqing China Telecommunication April 2003 ISIS as the PE/CE Protocol in BGP/MPLS VPNs draft-sheng-isis-bgp-mpls-vpn-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract IS-IS protocol, which is specified in [1], can be used as IGP between the Customer Edge (CE) router and the Provider Edge (PE) router in BGP/MPLS VPNs as per [1]. This document provides a detailed solution for IS-IS working as PE/CE Protocol in VPN services specified in [1]. Cheng Sheng Expires October 2003 [Page 1] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 Table of Contents 1 Terms ................................................. 2 2 Introduction .......................................... 2 3 Fundamental Requirments .............................. 3 3.1 Assumptions ........................................... 3 3.2 Multiple instances ................................... 3 3.3 IS-IS interaction with BGP on PE ..................... 3 3.4 Supplement............................................. 3 4 Extended Requirments .................................. 4 4.1 Sham Links ........................................... 4 4.2 Carry IS-IS imformation with BGP Extended communities . 4 4.3 Route loop prevention on PEs ......................... 5 4.4 IS-IS interaction with BGP on PE ..................... 5 4.5 Sham-link Creation ................................... 6 5 Acknowledgments ...................................... 7 6 References ........................................... 7 7 Authors' Address ..................................... 7 1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [IS-IS]. [VPN] describes a VPN service architecture, in which BGP is used to distribute IP-VPN routes between PEs in IP backbone. A CE router can then learn the routes to other CE sites in the same VPN by peering with its attached PE router through a routing protocol. The routing protocol is in charge of exchanging routes between PE and its attached CE. It has been proved till now that BGP, OSPF or RIP can help. And of course, IS-IS can do it as well. Obviously, as one of the most widely used IGPs, IS-IS is capable of distributing routes of CE to PE router. Using IS-IS on the PE-CE link is prefered especially when the VPN use IS-IS as its intra-site routing protocol, which means less administative expense and good backward compatibility. This draft is mainly focusing on proposing two different solutions, in which one is fundamental and the other is somewhat complicated, to implement IS-IS between PE and its attached CE. Cheng Sheng Expires October 2003 [Page 2] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 3. Fundamental Requirments In this part, some basic requirements have been listed out to address the issues of IS-IS working on PE-CE link. 3.1 Assumptions +-----+ +-----+ | PE1 |---------| PE2 | +-----+ +-----+ | | | | +-----+ +-----+ | CE1 | | CE2 | +-----+ +-----+ Two different sites of one VPN are not connected by direct(backdoor) link. Further, if this physical link dose exist, there is no IS-IS adjacency over the backdoor link. If this can not be avoided, the second solution described in 4 should be choosed. 3.2 Multiple instances Multiple IS-IS instances should be supported on PE, which means multiple IS-IS instances can run in one PE with each bound to one specific VRF. The relationship between IS-IS instances and VRFs is listed as follows: Multiple IS-IS instances can be associated with the same VRF (n:1). A single IS-IS instance should not be associated with multiple VRFs (1:n). Of course, a single IS-IS instance can be associated with just a single VRF. 3.3 IS-IS interaction with BGP on PE The PE router should have the capability to import IS-IS and BGP routes to/from a particular VRF with each other. When importing the BGP routes into a single IS-IS instance bound to a specific VRF on PE, the routes will always be regarded as external routes and IS-IS deliver the route with external reachability TLV(TLV 130) in IS-IS LSP. The level of the converted IS-IS LSP is decided through configuration. 3.4 supplement - There is no special toplogy limitation for PE/CE link and CE's sites. - There is no special requirement for CE router. Cheng Sheng Expires October 2003 [Page 3] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 4. Extended Requirments +-----+ +-----+ L1/2| PE1 |---------| PE2 |L1/2 +-----+ +-----+ | | | | +-----+ +-----+ | CE1 |-------- | CE2 | +-----+ +-----+ Though clear and easily implemented, the solution as per 3 has some disvantages, such as: - Routes delivered from one site to another are always treated as external routes is not desirable, because it will make the "false" routes undistinguished from the "real" external routes. - When there exists backdoor link connecting two CEs which belong to two different sites of one VPN, the IS-IS intra-area routes will be prefered to the VPN-IP routes which has been regarded as IS-IS external routes. As a result, the traffic will choose the direct link between CEs instead of passing through the IP backbone, which may be not accepted. - Besides, when backdoor exists between PEs, the route loop will happen on PEs, as both PE1 and PE1 import BGP routes into IS-IS. 4.1 Assumption There exists direct (backdoor) link between two different VPN sites. Further, there is IS-IS adjacency established over the backdoor link. 4.2 Carry IS-IS imformation with BGP Extended communities Per [VPN], BGP is in charge of distributing VPN-IP routes accross the VPN backbone. It is very useful of carrying some of the important original IS-IS route information by BGP with BGP extended communities. These "important" original IS-IS route information are listed as follows: -- IS-IS Route Type Extended Communites Attribute. This attribute is required, which is enconded with a two-byte type field and the type is 0201. The third byte is encoded as follows: -- Level type: The first bit. When it is set 0, it indicates level-1 type route and the value of 1 indicates level-2 type route. Cheng Sheng Expires October 2003 [Page 4] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 -- TLV Reachability type: The second bit. When it is set 0, it indicates that the original IS-IS route is of internal reachability and the value 1 indicates external reachability . -- Metric type: The third bit. When it is set 0, it indicates the original route is of internal metric type and the value of 1 indicates external metric type. -- sham-link endpoint address: the fourth bit. When it is set 1 , it indicates the route is of sham-link endpoint address, which will be specified in 4.5. By default, this bit should be set as 0. -- IS-IS System Id Extended Communites Attribute This attribute specifies the system id of the particular VRF from which this route was exported. It is encoded with a two-byte type and the type is 0202. The system id is carried in the rest six bytes. This attribute is optional, which means it is only necessary to be carried in the sham-link endpoint address route. 4.3 Route loop prevention on PEs As per the diagram of 4, when PE1 and PE2 both import bgp routes into their attached CE sites, the route loop will happen on both PEs. To avoid the route loop, it is assumed here that both PE1 and PE2 act as L1/2 router and there exists level-1 adjacency between each PE-CE link. The mechanism of how to avoid route loop with up/down bit in IS-IS level-1 LSP is specified in [ROUTE-LEAKING]. 4.4 IS-IS interaction with BGP on PE When PE receives a VPN-IP route, it will convert the route back to IS-IS. The creation of IS-IS LSP will be based on IS-IS route original information carried by BGP extended communities(as per 4.2). For example, if the orignal IS-IS route is of level-1 type /internal reachability/internal metric type, the route will be re-converted to a level-1 intra-area route with internal metric type. Besides, the configuration for route redistribution about the IS-IS LSP information is prefered. Cheng Sheng Expires October 2003 [Page 5] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 4.5 Sham-link Creation As per [OSPF-VPN], sham-link plays a very important role for an link state IGP such as IS-IS and OSPF in preventing the VPN traffic going through backdoor between CEs. Before establishing the sham-link, each end PE should be assigned an real shamlink endpoint address which can be a loopback address in VRF to which the CE belongs. Also, we should ensure that the endpoint address of one side PE is visible to the PE of the other side. The source and destination sham-link endpoint address is desigated by configuraiton. For example, as per the diagram in 4, it is necessary to establish a sham-link between PE1 and PE2. As the first step for PE1, BGP imports the loopback direct route which is desigated as source shamlink endpoint address on PE2. Next, the converted BGP route carries BGP extended communities with sham-link endpoint address bit(as per 4.2) set and IS-IS System Id Extended Communites Attribute with the value be equal to the System id of the specific IS-IS instance on the PE2. When PE1 receives the route, it checks the sham-link endpoint address bit and gets the IS-IS System Id the BGP route carry. If the endpoint address PE1 get is similar to its configured destination sham-link endpoint address, it is believed that there exists an sham-link from PE1 to PE2. Finally, PE1 adds one Neighbor reachability TLV(TLV 2) in its self-originated LSP and floods it out to CE1. Similiar process will happend on PE2. Note: when the PE found the system id of the other end of the sham-link changed, it will flush the old LSP and generate new LSP according to the new system id get from BGP route. 5. Acknowledgments The authors would like to thank yangang, heqian, xuxiaofei, weixiugang chenjie for their comments on this work. Cheng Sheng Expires October 2003 [Page 6] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 6. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)". [Also republished as RFC 1142.] [IS-IS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [BGP-EXT] "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext- communities-05.txt>, Sangli, S., Tappan, D., Rekhter, Y., May 2002 [VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-02.txt, Rosen, E., et. al., July, 2002 [ROUTE-LEAKING] "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, T. Li Request, October 2000 [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-rosen-vpns-ospf-bgp-mpls-06.txt, Eric C. Rosen, April 2003 7. Author's Addresses: Sheng Cheng D401 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : shengc@huawei.com Liu Yu A401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : liu_yu@huawei.com Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Chen Yunqing Email : chenyunqing@vip.sina.com Cheng Sheng Expires October 2003 [Page 7] Internet Draft draft-sheng-isis-bgp-mpls-vpn-00.txt April 2003 --Boundary_(ID_MED7rmC18pwnozvQ4TY5rg)-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 01:55:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16292 for ; Tue, 13 May 2003 01:55:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D5w1Y11345 for ; Tue, 13 May 2003 01:58:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4D5vwa00941 for ; Tue, 13 May 2003 01:57:58 -0400 (EDT) X-Original-Recipient: hbrahim@nortelnetworks.com Message-ID: <3EC08813.5060202@pi.se> Date: Tue, 13 May 2003 07:52:19 +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: Yakov Rekhter CC: "Hamid Ould-Brahim" , Thomas Narten , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF References: <200305121759.h4CHxbu62438@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailg.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailg.telia.com [194.22.194.26] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, just because something is "too big", you don't need to split each and every atom. "logical extremes" does not very often make sense in disucssion on how to organize a work load, we should look for opitmization in this context "splitting" makes perfetly sense /Loa Yakov Rekhter wrote: < snip > > > Agreed. In fact, if the justification for splitting the PPVNP WG > into two is to allow discussion for L3 services, then following > the same line of reasoning there should be not one, but two L2 VPN > WGs, one for L2 VPN services (other than VPLS), and one for VPLS. > Yet, the IESG said nothing about having two L2 VPN WGs. Perhaps the > IESG would be kind enough to explain this inconsistency. > > >>In that respect, creating a new l2vpn wg will not make the situation any >>better. > > > Agreed. > > Yakov. > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 02:43:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28998 for ; Tue, 13 May 2003 02:42:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D6jSY10004 for ; Tue, 13 May 2003 02:45:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4D6jOQ23339 for ; Tue, 13 May 2003 02:45:24 -0400 (EDT) Date: Tue, 13 May 2003 15:35:07 +0900 (JST) Message-Id: <20030513.153507.74744142.suzuki.muneyoshi@lab.ntt.co.jp> To: nfinn@cisco.com Cc: mick_seaman@ieee.org, tony@jeffree.co.uk, Les_Bell@eur.3com.com, paul_congdon@hp.com, njarvis@cisco.com, ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <3EB84FB5.8630E288@cisco.com> References: <3EA95C0A.3077599@cisco.com> <20030430.171312.41636959.suzuki.muneyoshi@lab.ntt.co.jp> <3EB84FB5.8630E288@cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Norm, > Another way to put it: My diagram is the only way that a standard > bridge CAN interface to the full meshes within the layering model > shared by IEEE 802 and IETF. I should be more careful in my claims: > It's the only way that has been presented, to date, to IEEE 802.1, > and has received a lot of support. I carefully red this thread in this week, but I'm increasingly confused. I think intention of Eric's model shown in the below is that the Interface means a MSAP and the VPLS Forwarder provides an logical entity that is compatible with a MAC entity. This is very clear architecture for me, while it has loop/blackhole or flaky PEs problems. > | | | | > | | | | > |---|------|-----|-----|----| > | -|------|-----|-----|--- | > | VPLS Forwarder | == MAC entity > | ----------|------------- | > ..|.............................. MSAP > | | Interface | > | ----------|------------ | > | | Bridge | | > | -|--------|---------|-- | > |---|--------|---------|----| > | | | > | | Access | > | | Networks| Regarding your reply, I understand that the point "A" in the following model means a MSAP. However, I'm not sure what the right part is. Could you clarify the following points? > |===========================================--------+ > | | | forwarding | | > | | | function +--- | > E i --+ | untagged + VPLS 100 | | > t n | Provider | | for BPDUs +--- | P r > h t | Bridge | |------------| | s o > e e | | | +--- | e u > r r --+ | | forwarding | | u t > n f | Each "+" in | VLAN 26 + function +--- | d i > e a | the border of | | VPLS 200 | | o n > t c | this block | mux- | +--- | w g > e --+ represents one + demux |------------| | i > s | bridge port | function | +--- | r f > | | | | | e u > | | | +--- | s n > --+ | | forwarding | | c > | | VLAN 589 + function +--- | i t > | | | VPLS 300 | | n i > | | | +--- | o > --+ | | | | n > |===========================================--------+ > A B C (1) Could you clarify what the mistake is in the Eric's model, and and how your model resolved it? (2) Could you clarify what the right part from "A" means? I my understanding it must be a MAC entity or a part of a MAC relay entity that distributed PEs. (3) Could you clarify why the above model is consistent with the following Mick's interpretation of the Bridge protocol architecture. > An IEEE Bridge connects to a LAN, or more properly an instance of the MAC > Service. The functionality of multiplexing and demultiplexing VLANs to and > from distinguishable packet formats on the LAN is an imbedded function of > the Bridge. Further the multiplexing/demultiplexing of certain control > protocols to and from the LAN is independent of the VLAN mux/demux. This can > be important from the protocol efficiency/scaleability point of view since > VLAN mux/demux is limited to associating each whole frames with a given > VLAN. Frames that are not VLAN associated can convey information that has > been aggregated for a number of VLANs (e.g. GVRP) or information that is the > same and applies to all VLANs (is this media working etc. etc.). > Accordingly the IEEE Bridge > model does not include the possibility of any of the VLANs or the control > protocols accessed through a single M-SAP (point of attachment to the MAC > Service) being separately supported with methods that can lead to > independent/different connectivity/reachability/failure, i.e. data path == > control path. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 08:43:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08027 for ; Tue, 13 May 2003 08:43:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DCk9Y23585 for ; Tue, 13 May 2003 08:46:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DCk6t03044 for ; Tue, 13 May 2003 08:46:07 -0400 (EDT) Message-ID: <3EC0E878.6080607@acm.org> Date: Tue, 13 May 2003 08:43:36 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: erosen@cisco.com CC: mick_seaman@ieee.org, "'Pedro Roque Marques'" , "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200305091459.h49ExKZC001931@rtp-core-1.cisco.com> In-Reply-To: <200305091459.h49ExKZC001931@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric Rosen wrote: > Mick> Of course the IEEE model doesn't require all provider bridges to be on > Mick> the same emulated LAN, only all those that are optimising their > Mick> control traffic by sharing its results between them - i.e. just like > Mick> ordinary LAN. So VPLS's that are on the *same* underlying connectivity > Mick> can share that knowledge and don't have to suffer BPDU sending > Mick> inefficiency. > > So the difference between the IEEE model and the FW model is that the IEEE > model allows this optimization. But I don't quite understand how to benefit > from this optimization in the VPLS environment. A particular set of VPLSes > could only be considered to have the same "underlying connectivity" if it is > known that they are supported by the same set of PEs, both now and in the > future. I'm not sure whether this is a common enough case to worry about, > and I'm also not sure how one would get this information from the > auto-discovery provisioning model. > > The benefit, at least to me, is that everything else can treat the VPLS instance as a LAN and doesn't need to be aware. So provisioning and forwarding behavior for bridges doesn't need VPLS awareness. Otherwise, certain higher level functions have to know that a port is a VPLS port or an Ethernet port. Additionally, it allows arbitrary topologies to be built. Right now, most people are on the direction that there's a single VPLS per customer and that it spans edge-to-edge. And people are complaining about the scaleability of that solution. Back in older days with previous incarnations of emulated LANs, many people designed their networks differently. I recollect some carriers building mostly regional emulated LANs, putting multiple customers within a region on the same regional VPLS and putting bridges together between the regions. The logic as I recall was that bandwidth within a region was pretty much free, but between regions it was real money. Many customers stayed within a single region, which was even better, and multicast/broadcast traffic was policed properly. The specific example I recall was a carrier that had 5-10 switches in NY and DC, and they created a single emulated LAN instance in NY and DC with VLANs across it, and they had a bridge between the two that switched a small number of VLANs between NY & DC. Later, they replaced the emulated LAN with a big honking Ethernet switch and everything continued to operate. Now I'm not promoting this topology over any other. But ensuring the emulated and real technologies are transparent to the higher layer, one can build arbitrary networks based on traditional bridging models. I hope thats a good thing. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 10:18:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14264 for ; Tue, 13 May 2003 10:18:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DEL4Y13858 for ; Tue, 13 May 2003 10:21:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DEL2T05370 for ; Tue, 13 May 2003 10:21:02 -0400 (EDT) Message-ID: <004101c3195a$78281670$02c1d541@WORKGROUP> From: "Rajiv Papneja" To: "Bilel Jamoussi" , "'Ash, Gerald R \(Jerry\), ALABS'" , "'Alex Zinin'" , References: <0D7FC1D8D861D511AEA70002A52CE5E60662378E@zcard0ke.ca.nortel.com> Subject: Re: WG split: why and how? Date: Tue, 13 May 2003 10:18:04 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C31938.F0850BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: mta1.wss.scd.yahoo.com X-SMTP-MAIL-FROM: rpapneja@isocore.com X-SMTP-RCPT-TO: jamoussi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mta1.wss.scd.yahoo.com [66.218.85.32] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C31938.F0850BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG split: why and how?Same here. I offer my full support for Marco = and his great contribution to the WG.=20 -Rajiv ----- Original Message -----=20 From: Bilel Jamoussi=20 To: 'Ash, Gerald R (Jerry), ALABS' ; 'Alex Zinin' ; = 'ppvpn@nortelnetworks.com'=20 Sent: Monday, May 12, 2003 10:52 PM Subject: RE: WG split: why and how? BNJ> Folks,=20 BNJ> I also believe Marco has done a very good job managing the PPVPN = WG.=20 BNJ> If you share this "vote of confidence" please voice it to the = list.=20 BNJ> Bilel.=20 -----Original Message-----=20 From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 Sent: Monday, May 12, 2003 3:33 PM=20 To: Alex Zinin; ppvpn@nortelnetworks.com=20 Cc: Ash, Gerald R (Jerry), ALABS=20 Subject: RE: WG split: why and how?=20 =20 Granted that there is a large number of tasks and documents to manage, = which is one reason why work has not been completed. However, this = problem has only recently been identified for discussion on the list, = and apparently has not been discussed to any great extent with the WG = chairs (Marco's input). =20 The PPVPN chairs have ably managed the large workload, e.g., see = Marco's very thorough update on 'PPVPN WG Status' at IETF-56 Jerry=20 ------=_NextPart_000_003E_01C31938.F0850BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG split: why and how?
Same here. I offer my full support for = Marco and=20 his great contribution to the WG.
  -Rajiv
----- Original Message -----
From:=20 Bilel Jamoussi
To: 'Ash, Gerald R (Jerry), ALABS' ; 'Alex Zinin' ; = 'ppvpn@nortelnetworks.com'=
Sent: Monday, May 12, 2003 = 10:52 PM
Subject: RE: WG split: why and = how?

BNJ> Folks,

BNJ> I also believe Marco has done a very good = job managing=20 the PPVPN WG.
BNJ> If you share this = "vote of=20 confidence" please voice it to the list.

BNJ> Bilel.

-----Original Message-----
From: Ash,=20 Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Monday, May 12, 2003 3:33 PM
To: Alex=20 Zinin; ppvpn@nortelnetworks.com=20
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: WG split: why and how?

<clip>

Granted that there is a large number of tasks and = documents to=20 manage, which is one reason why work has not been completed.  = However,=20 this problem has only recently been identified for discussion on the = list, and=20 apparently has not been discussed to any great extent with the WG = chairs=20 (Marco's input). 

The PPVPN chairs have ably managed the large = workload, e.g.,=20 see Marco's very thorough update on 'PPVPN WG Status' at IETF-56  = <clip>

Jerry



------=_NextPart_000_003E_01C31938.F0850BE0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 12:32:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19311 for ; Tue, 13 May 2003 12:32:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DGZ9Y27127 for ; Tue, 13 May 2003 12:35:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DGZ6G28785 for ; Tue, 13 May 2003 12:35:06 -0400 (EDT) Message-Id: <200305131611.h4DGBp8X006204@rotala.raleigh.ibm.com> To: "Bilel Jamoussi" cc: "'PPVPN@nortelnetworks.com'" , "'Scott Bradner'" Subject: Re: PPVPN - In-Reply-To: Message from jamoussi@nortelnetworks.com of "Mon, 12 May 2003 23:03:50 EDT." <0D7FC1D8D861D511AEA70002A52CE5E606623796@zcard0ke.ca.nortel.com> Date: Tue, 13 May 2003 12:11:51 -0400 From: Thomas Narten X-SMTP-HELO: e6.ny.us.ibm.com X-SMTP-MAIL-FROM: narten@us.ibm.com X-SMTP-RCPT-TO: jamoussi@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: e6.ny.us.ibm.com [32.97.182.106] X-LYRIS-Message-Id: Bilel, > It has been more than a week since the "PPVPN Strategy" discussion > started on this mailing list. To date, we have not seen any > clarification on why the AD thinks there is a problem that warrants > the WG split Disagree. There have been reasons given. I think it is fair to say that some agree with the proposed split, while others do not see a need, and still others have raised concerns about coordination for documents that deal with both L2 and L3 in the same document. That input is being considered by the ADs. I'll also note that in the end, the ADs will make the decision on whether the split is to take place. That's why we get paid the big bucks. > Marco has been the PPVPN WG Co-chair since the WG has been > chartered. Scott has been his AD for several years. Looking at > archives of the PPVPN mailing list, the outgoing AD and the WG > members did not voice any issues with the WG. Need I point out that Rick Wilder is also a co-chair of the WG? Also, I do not think it is constructive to have a detailed public discussion about issues people may have with the WG operation. When people are unhappy with the way a WG is making progress, they contact the ADs privately. The public mailing list is the last place I'd expect people would raise such issues. > Looking at the IESG minutes http://ftp.ietf.org/iesg/ > , there is no indication of a problem > with the PPVPN WG. People have noted repeatedly that the IESG minutes are rather dry and bland (e.g., see the recent discussion on the problem-statement list). It is the case that with regards to WG management issues, such discussions are not included in the minutes for obvious reasons. Thomas From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:29:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21206 for ; Tue, 13 May 2003 13:29:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHVeY18813 for ; Tue, 13 May 2003 13:31:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHVZl05403 for ; Tue, 13 May 2003 13:31:36 -0400 (EDT) Message-ID: <635C6B4620C6D411909100508BCFE67A0B791089@zrtpd0jd.us.nortel.com> From: "Paul Unbehagen" To: Rajiv Papneja , "Bilel Jamoussi" , "'Ash, Gerald R (Jerry), ALABS'" , "'Alex Zinin'" , ppvpn@nortelnetworks.com Subject: RE: WG split: why and how? Date: Tue, 13 May 2003 13:29:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31975.34745C98" X-LYRIS-Message-Id: 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_01C31975.34745C98 Content-Type: text/plain I agree as well, Marco has done a great job for the working group. Regards, Paul Unbehagen -----Original Message----- From: Rajiv Papneja [mailto:rpapneja@isocore.com] Sent: Tuesday, May 13, 2003 10:18 AM To: Jamoussi, Bilel [BL60:1A00:EXCH]; 'Ash, Gerald R (Jerry), ALABS'; 'Alex Zinin'; ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? Same here. I offer my full support for Marco and his great contribution to the WG. -Rajiv ----- Original Message ----- From: Bilel Jamoussi To: 'Ash, Gerald R (Jerry), ALABS' ; 'Alex Zinin' ; 'ppvpn@nortelnetworks.com' Sent: Monday, May 12, 2003 10:52 PM Subject: RE: WG split: why and how? BNJ> Folks, BNJ> I also believe Marco has done a very good job managing the PPVPN WG. BNJ> If you share this "vote of confidence" please voice it to the list. BNJ> Bilel. -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com ] Sent: Monday, May 12, 2003 3:33 PM To: Alex Zinin; ppvpn@nortelnetworks.com Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: WG split: why and how? Granted that there is a large number of tasks and documents to manage, which is one reason why work has not been completed. However, this problem has only recently been identified for discussion on the list, and apparently has not been discussed to any great extent with the WG chairs (Marco's input). The PPVPN chairs have ably managed the large workload, e.g., see Marco's very thorough update on 'PPVPN WG Status' at IETF-56 Jerry ------_=_NextPart_001_01C31975.34745C98 Content-Type: text/html RE: WG split: why and how?

I agree as well, Marco has done a great job for the working group.

 

Regards,

Paul Unbehagen

 

-----Original Message-----
From: Rajiv Papneja [mailto:rpapneja@isocore.com]
Sent: Tuesday, May 13, 2003 10:18 AM
To: Jamoussi, Bilel [BL60:1A00:EXCH]; 'Ash, Gerald R (Jerry), ALABS'; 'Alex Zinin'; ppvpn@nortelnetworks.com
Subject: Re: WG split: why and how?

 

Same here. I offer my full support for Marco and his great contribution to the WG.

  -Rajiv

----- Original Message -----

Sent: Monday, May 12, 2003 10:52 PM

Subject: RE: WG split: why and how?

 

BNJ> Folks,

BNJ> I also believe Marco has done a very good job managing the PPVPN WG.
BNJ> If you share this "vote of confidence" please voice it to the list.

BNJ> Bilel.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Monday, May 12, 2003 3:33 PM
To: Alex Zinin; ppvpn@nortelnetworks.com
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: WG split: why and how?

<clip>

Granted that there is a large number of tasks and documents to manage, which is one reason why work has not been completed.  However, this problem has only recently been identified for discussion on the list, and apparently has not been discussed to any great extent with the WG chairs (Marco's input). 

The PPVPN chairs have ably managed the large workload, e.g., see Marco's very thorough update on 'PPVPN WG Status' at IETF-56  <clip>

Jerry

 

------_=_NextPart_001_01C31975.34745C98-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:40:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21739 for ; Tue, 13 May 2003 13:40:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHgeY24035 for ; Tue, 13 May 2003 13:42:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHgbl15862 for ; Tue, 13 May 2003 13:42:37 -0400 (EDT) Message-Id: <4.3.2.20030513105011.028acb40@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 13 May 2003 13:32:42 -0400 To: "Bilel Jamoussi" , ppvpn@nortelnetworks.com From: Ross Callon Subject: RE: WG split: why and how? Cc: "'Alex Zinin'" In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E60662378E@zcard0ke.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_923527==_.ALT" X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: rcallon@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,jamoussi@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: --=====================_923527==_.ALT Content-Type: text/plain; charset="us-ascii" At 10:52 PM 5/12/2003 -0400, Bilel Jamoussi wrote: >BNJ> Folks, > >BNJ> I also believe Marco has done a very good job managing the PPVPN WG. >BNJ> If you share this "vote of confidence" please voice it to the list. > >BNJ> Bilel. I also agree that Marco and Rick have done a good job of chairing the PPVPN working group. My recollection is that before Marco and Rick got involved in this, there was one or two BOFs on a similar subject (VPNs) which sort of went nowhere. When the PPVPN working group was started, there was a lot of contention, multiple proposals, and considerable skepticism regarding whether it was even possible to get some sort of reasonable agreement on direction. Marco and Rick should be commended on getting us to the point where we have made considerable progress and where a lot of good work has been done. I can certainly speak from direct experience that they were very helpful in getting the layer 3 framework document done (including, for example, helping to set up the group which wrote the document). However, I don't see how this is particularly relevant in deciding whether to split up the PPVPN working group into two (or more) parts. There are a huge number of documents being progressed in one group. This slows down progress. The enthusiasm with which various Layer 2 issues are being discussed takes time and attention away from discussing other issues. I don't think that having two different meetings at an IETF will solve the problem. What we really need is to have two different email exploders, so that Email related to enhancements to various Layer 3 proposals is not on the same Email list as debates over the relative merits of VPLS proposals. Ross --=====================_923527==_.ALT Content-Type: text/html; charset="us-ascii" At 10:52 PM 5/12/2003 -0400, Bilel Jamoussi wrote:

BNJ> Folks,

BNJ> I also believe Marco has done a very good job managing the PPVPN WG.
BNJ> If you share this "vote of confidence" please voice it to the list.

BNJ> Bilel.

I also agree that Marco and Rick have done a good job of chairing the
PPVPN working group. My recollection is that before Marco and Rick
got involved in this, there was one or two BOFs on a similar subject
(VPNs) which sort of went nowhere. When the PPVPN working group
was started, there was a lot of contention, multiple proposals, and
considerable skepticism regarding whether it was even possible to
get some sort of reasonable agreement on direction. Marco and Rick
should be commended on getting us to the point where we have made
considerable progress and where a lot of good work has been done. I
can certainly speak from direct experience that they were very helpful
in getting the layer 3 framework document done (including, for example,
helping to set up the group which wrote the document).

However, I don't see how this is particularly relevant in deciding
whether to split up the PPVPN working group into two (or more) parts.
There are a huge number of documents being progressed in one group.
This slows down progress. The enthusiasm with which various Layer 2
issues are being discussed takes time and attention away from
discussing other issues.

I don't think that having two different meetings at an IETF will solve the
problem. What we really need is to have two different email exploders,
so that Email related to enhancements to various Layer 3 proposals
is not on the same Email list as debates over the relative merits of
VPLS proposals.

Ross
--=====================_923527==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:42:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21825 for ; Tue, 13 May 2003 13:42:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHj0Y27072 for ; Tue, 13 May 2003 13:45:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHivl19511 for ; Tue, 13 May 2003 13:44:57 -0400 (EDT) Date: Tue, 13 May 2003 10:37:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <66164936526.20030513103752@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: <200305121536.h4CFahu50777@merlot.juniper.net> References: <200305121536.h4CFahu50777@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Summarizing a bit: Monday, May 12, 2003, 8:36:43 AM, Yakov Rekhter wrote: > To avoid disappointing you the WG immediately needs to start the > discussion on whether to use L2TPv3 encapsulation or MPLS or MPLS > over GRE, or MPLS over IPSec. > Likewise the WG immediately needs to start the discussion on L2TPv3 > vs LDP based signaling. > Likewise, the WG immediately needs to start the discussion on BGP > vs Radius based auto-discovery. If the goal of the WG is to produce the IETF Standards for L2 VPNs, I think the WG should indeed be discussing which mechanisms should be chosen as mandatory to implement. Not requiring a mandatory one will affect interoperability, and more than one mandatory mechanism per function are just not needed--one is enough. If folks believe other (optional to implement) mechanisms would really add value, I don't think anyone would object. The key point here is if we want implementations of the IETF standard to interoperate, we need to define the minimal function set to be supported. Monday, May 12, 2003, 10:08:22 AM, Yakov Rekhter wrote: > Agreed. In fact, I don't quite understand why some folks on this > list insist that the IETF should be in the business of making > business decisions... I don't think anyone is trying to insist on that, quite on the contrary. I think there's a general agreement that the IETF should NOT be making business decisions, and the disagreement is in which decisions are business and which are technical. If we come here believing that the IETF is nothing but a market battlefield, then we can call any situation where more than one existing implementation is available a "business issue", and agree that trying to resolve it would cost too much blood, so "the market" should pick the one that they like more. If instead we believe that the IETF is an engineering organization, where we come to work together on something we can later use to interoperate in SP networks (even though we may have our own existing implementations), I think we should be ready to sit down, talk to each other and try to build consensus on what should that IETF Standard be. Which mindset do we choose? Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:45:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21909 for ; Tue, 13 May 2003 13:45:41 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHmBY01243 for ; Tue, 13 May 2003 13:48:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHm8X24550 for ; Tue, 13 May 2003 13:48:08 -0400 (EDT) Message-Id: <4.3.2.20030513113708.0287fb10@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 13 May 2003 13:30:11 -0400 To: "Busschbach, Peter B (Peter)" , "'Yakov Rekhter'" , "Fang, Luyuan, ALABS" From: Ross Callon Subject: RE: Single vs many solution(s) (LONG reply) Cc: PPVPN@nortelnetworks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: rcallon@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: >I don't think the IETF is making business decisions. Vendors are free to develop proprietary solutions and service providers are free to deploy them. However, a standards body should develop one solution as THE standard. > >... >Peter This is ignoring 17 years of IETF experience, and more than 20 years of standards experience. The reality is that neither the IETF nor any other standards body is good at choosing between major approaches. When we have tried to do this (or when any other standards group has tried this) we have failed more often than succeeded. Where we have let more than one major approach be progressed, we have succeeded most of the time (although usually most of the approaches eventually go away). Standards groups such as the IETF are very good at taking any one well defined solution and working out all of the details. If there are two main approaches, then we are very good at having two groups of people progress the two approaches. This allows vendors to build interoperable solutions. This is essential for data communications networks to progress and to work well. Where there have been more than one approach progressed, the competition between approaches have made the proponents of each approach improve their approach as much as possible and has given us better standards. If we look at some examples from history, there is a very clear trend that progressing two or slightly more approaches works out okay. Bad approaches go away because they don't work well when deployed (for example, scaling might be difficult, or stability might be lacking). Trying to pick one winner in a heavily politicized large group just doesn't work. Committees aren't very good at figuring out where there are going to be problems. I apologize that this message is quite long. However, to make a good choice in this area it is important to understand a bit of history, and so I have written down some historical examples below (there are more). For one example let's consider routing protocols. If we have tried back in 1986 (when the first four IETF's were held) to pick a single standard routing protocol then we would have picked RIP. This would have been over the strong objections of a few of us from BBN, but would have happened anyway because the great majority of implementers would have supported RIP for the simple reason that it is easy to implement. Also, it is possible to have lots of "fun" trying to come up with various ways to fix the very poor dynamic behavior of RIP in a large network. Thus means that at the time there were a number of researchers who has various fixes which they could have proposed to go along with RIP as THE standard routing protocol. Fortunately, at the time we didn't think that it was necessary to pick a single routing protocol. Instead we waited a few years, and then decided to do so. At the first meeting to do so, there was a great debate between advocates of link state routing protocols (such as OSPF, IS-IS, and the "New Arpanet Routing Algorithm" which was deployed by BBN in the Arpanet in approximately 1979), versus advocates of distance vector routing algorithms (such as RIP, IGRP, or the old Arpanet routing algorithm, used prior to 1979). This debate sort of went on for a while, and didn't appear to be about to resolve. If we had had to pick one solution, it is entirely possible that we might have picked distance vector, which in retrospect would have been a mistake. Instead Phill Gross (original chair of the IETF) allowed two working groups to be created -- one to define a link state routing protocol, and one to define a distance vector routing protocol. This was very much consistent with Phill's general approach of allowing more than one approach to be developed -- an approach which was instrumental in resolving differences and which was a BIG part of why the IETF became successful in the first place (there were other much less successful task forces prior to creation of the IETF). So, eventually we *did* pick one interior routing protocol (for routing within a routing domain), which was OSPF. At the time there was some controversy between OSPF versus IS-IS as the proposed standard IETF routing protocol (both are link state protocols, and actually relatively similar in many ways). However, the politics were pretty clearly slanted towards OSPF, so we managed to finally pick one protocol. Did this matter? If you look carefully you will notice that the result was that we now have **TWO** interior routing protocols deployed widely in the Internet. In fact IS-IS is used in very slightly more than 50% of the largest ISPs. Picking one protocol didn't do us any good. Regarding inter-domain protocols, we had somewhat more difficulty picking a single standard. There was some opposition to BGP in high places. The result was that we were not able to pick a single protocol until long after it was obvious to pretty much everyone that BGP was the right protocol to use. The failure to pick a single protocol didn't do any harm in terms of stopping us from ending up with one protocol. The first time that I attended any standards meeting was an IEEE 802 meeting in 1980. I had been warned that standards meetings were quite boring. In fact nothing could have been further from the truth: This was *THE MEETING* at which IEEE 802 was going to decide between CSMA/CD versus Token Bus as *THE* standard for local area networks. There were large number of presentations on the subject all week, which was the cumulation of many months of similar debate. Finally at the end of the week the big vote took place. I don't remember the exact numbers, but it was something like 8 votes for one approach, 9 votes for the other approach, and 30 abstentions. We all sat there and stared at each other for a minute or so ("It was finally over"). Then someone stuck up his hand and said essentially "We just picked the entire future for all local area networks for all time based on a vote of 8 to 9 with 30 abstentions, this can't be right. Let's progress both standards". After a little more debate, the proposal to progress both standards was passed. Now, was this a failure on the part of IEEE 802? Would it have been better if they had picked Token Bus for the future of LANs rather than allowing both to progress? Would the credibility of the standards process and of IEEE 802 or the economic viability of the industry been improved if they had made this decision? No, of course not. The economic and technical realities of the market have been very good at picking Ethernet -- CSMA/CD. Making decisions like this is just something that a standards body is not capable of doing well. Ross From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:47:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22021 for ; Tue, 13 May 2003 13:47:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHo5Y03701 for ; Tue, 13 May 2003 13:50:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHivl19511 for ; Tue, 13 May 2003 13:44:57 -0400 (EDT) Date: Tue, 13 May 2003 10:37:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <66164936526.20030513103752@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: <200305121536.h4CFahu50777@merlot.juniper.net> References: <200305121536.h4CFahu50777@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Summarizing a bit: Monday, May 12, 2003, 8:36:43 AM, Yakov Rekhter wrote: > To avoid disappointing you the WG immediately needs to start the > discussion on whether to use L2TPv3 encapsulation or MPLS or MPLS > over GRE, or MPLS over IPSec. > Likewise the WG immediately needs to start the discussion on L2TPv3 > vs LDP based signaling. > Likewise, the WG immediately needs to start the discussion on BGP > vs Radius based auto-discovery. If the goal of the WG is to produce the IETF Standards for L2 VPNs, I think the WG should indeed be discussing which mechanisms should be chosen as mandatory to implement. Not requiring a mandatory one will affect interoperability, and more than one mandatory mechanism per function are just not needed--one is enough. If folks believe other (optional to implement) mechanisms would really add value, I don't think anyone would object. The key point here is if we want implementations of the IETF standard to interoperate, we need to define the minimal function set to be supported. Monday, May 12, 2003, 10:08:22 AM, Yakov Rekhter wrote: > Agreed. In fact, I don't quite understand why some folks on this > list insist that the IETF should be in the business of making > business decisions... I don't think anyone is trying to insist on that, quite on the contrary. I think there's a general agreement that the IETF should NOT be making business decisions, and the disagreement is in which decisions are business and which are technical. If we come here believing that the IETF is nothing but a market battlefield, then we can call any situation where more than one existing implementation is available a "business issue", and agree that trying to resolve it would cost too much blood, so "the market" should pick the one that they like more. If instead we believe that the IETF is an engineering organization, where we come to work together on something we can later use to interoperate in SP networks (even though we may have our own existing implementations), I think we should be ready to sit down, talk to each other and try to build consensus on what should that IETF Standard be. Which mindset do we choose? Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:49:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22099 for ; Tue, 13 May 2003 13:49:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHptY05229 for ; Tue, 13 May 2003 13:51:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHpqX00742 for ; Tue, 13 May 2003 13:51:52 -0400 (EDT) Message-ID: <0A11633F61BD9F40B43ABCC694004F9301DCA68C@zsc3c026.us.nortel.com> From: "Shashi Kiran" To: "'Rajiv Papneja'" , "'Ash, Gerald R (Jerry), ALABS'" , "'Alex Zinin'" , ppvpn@nortelnetworks.com Subject: RE: WG split: why and how? Date: Tue, 13 May 2003 10:41:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31976.E1D3F2A8" X-LYRIS-Message-Id: 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_01C31976.E1D3F2A8 Content-Type: text/plain Agree on the excellent work being done by the current WG. Should be allowed to continue and progress. Rgds Shashi Kiran -----Original Message----- From: Rajiv Papneja [mailto:rpapneja@isocore.com] Sent: Tuesday, May 13, 2003 7:18 AM To: Jamoussi, Bilel [BL60:1A00:EXCH]; 'Ash, Gerald R (Jerry), ALABS'; 'Alex Zinin'; ppvpn@nortelnetworks.com Subject: Re: WG split: why and how? Same here. I offer my full support for Marco and his great contribution to the WG. -Rajiv ----- Original Message ----- From: Bilel Jamoussi To: 'Ash, Gerald R (Jerry), ALABS' ; 'Alex Zinin' ; 'ppvpn@nortelnetworks.com' Sent: Monday, May 12, 2003 10:52 PM Subject: RE: WG split: why and how? BNJ> Folks, BNJ> I also believe Marco has done a very good job managing the PPVPN WG. BNJ> If you share this "vote of confidence" please voice it to the list. BNJ> Bilel. -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com ] Sent: Monday, May 12, 2003 3:33 PM To: Alex Zinin; ppvpn@nortelnetworks.com Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: WG split: why and how? Granted that there is a large number of tasks and documents to manage, which is one reason why work has not been completed. However, this problem has only recently been identified for discussion on the list, and apparently has not been discussed to any great extent with the WG chairs (Marco's input). The PPVPN chairs have ably managed the large workload, e.g., see Marco's very thorough update on 'PPVPN WG Status' at IETF-56 Jerry ------_=_NextPart_001_01C31976.E1D3F2A8 Content-Type: text/html Message
Agree on the excellent work being done by the current WG. Should be allowed to continue and progress.
 
Rgds
Shashi Kiran
-----Original Message-----
From: Rajiv Papneja [mailto:rpapneja@isocore.com]
Sent: Tuesday, May 13, 2003 7:18 AM
To: Jamoussi, Bilel [BL60:1A00:EXCH]; 'Ash, Gerald R (Jerry), ALABS'; 'Alex Zinin'; ppvpn@nortelnetworks.com
Subject: Re: WG split: why and how?

Same here. I offer my full support for Marco and his great contribution to the WG.
  -Rajiv
----- Original Message -----
Sent: Monday, May 12, 2003 10:52 PM
Subject: RE: WG split: why and how?

BNJ> Folks,

BNJ> I also believe Marco has done a very good job managing the PPVPN WG.
BNJ> If you share this "vote of confidence" please voice it to the list.

BNJ> Bilel.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Monday, May 12, 2003 3:33 PM
To: Alex Zinin; ppvpn@nortelnetworks.com
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: WG split: why and how?

<clip>

Granted that there is a large number of tasks and documents to manage, which is one reason why work has not been completed.  However, this problem has only recently been identified for discussion on the list, and apparently has not been discussed to any great extent with the WG chairs (Marco's input). 

The PPVPN chairs have ably managed the large workload, e.g., see Marco's very thorough update on 'PPVPN WG Status' at IETF-56  <clip>

Jerry



------_=_NextPart_001_01C31976.E1D3F2A8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:52:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22176 for ; Tue, 13 May 2003 13:52:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHsaY08984 for ; Tue, 13 May 2003 13:54:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHsXX04948 for ; Tue, 13 May 2003 13:54:33 -0400 (EDT) Date: Tue, 13 May 2003 10:39:59 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <36165062887.20030513103959@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: WG split: why and how? In-Reply-To: <3EBF1C3D.7040207@nortelnetworks.com> References: <3EBC06ED.4060700@lucent.com> <61241310626.20030509142534@psg.com> <162274975293.20030509234639@psg.com> <3EBF1C3D.7040207@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- Regarding the dead-line for this discussion and making the decision. Given the activity on the list, we'd like to give it till the end of this week. We _will_ make the decision then. Addressing what hasn't been yet: Sunday, May 11, 2003, 8:59:57 PM, Don Fedyk wrote: > ...I suggest it would be more fruitful to spend time > from now to Vienna advancing current work and seeing what is holding up > the rest. Lets get this train back on the rails before, if necessary, > we split the tracks. From the perspective of advancing the current work, there's no delay associated with this discussion. For example, L3 requirements and L3 framework are on the IESG agenda for the telechat this week. Monday, May 12, 2003, 2:52:14 AM, jeremy.de_clercq@alcatel.be wrote: ... >> Could you send the draft names, pls? > Note that I'm not implying that they should be in the first charters. I > understand your 'basic things first' reasoning. Just wanted to say that > they've had little attention. A few examples: I got them on my list for further discussion if we decide to go with the split. Thanks. Monday, May 12, 2003, 10:59:37 AM, Yakov Rekhter wrote: > Agreed. In fact, if the justification for splitting the PPVNP WG > into two is to allow discussion for L3 services, then following > the same line of reasoning there should be not one, but two L2 VPN > WGs, one for L2 VPN services (other than VPLS), and one for VPLS. > Yet, the IESG said nothing about having two L2 VPN WGs. Perhaps the > IESG would be kind enough to explain this inconsistency. Thanks for trying to catch a possible inconsistency. "Following the same line" can take one quite far in splitting big WGs in smaller ones. One clearly has to stop somewhere. Based on the conversations we had, splitting between L2 and L3 is the most reasonable choice. Monday, May 12, 2003, 12:33:08 PM, Ash, Gerald R (Jerry), ALABS wrote: ... > Seems to conclude that the problem cannot be solved within the > existing PPVPN WG. Let's get the WG chairs' proposals on how to fix > the problem within the WG, and discuss their proposals. Let's reach > a WG consensus as to which solution best solves the problem. To repeat what I stated already--WG management decisions are not made by consensus within the WG. It is the AD's and the IESG responsibility. The ADs will consider the discussion on the list and conversations with the WG chairs and will make the decision. Monday, May 12, 2003, 1:20:26 PM, Hamid Ould-Brahim wrote: ... > If we assume a wg split is necessary (which I am no sure it is > at this point in time), then why not address VPLS > separately from other l2vpn work. A potential option is Yakov's suggestion > to split l2vpn in two wgs. See my answer to Yakov above. > Another option is to: > a) Keep ppvpn wg as it is covering l3vpn and l2vpn > (other than VPLS), still covering the generic documents, > the common documents/mechanisms, the "Provider-Provisioned" > aspects, inter-as, etc. I think this would still be too much for one WG. > and, > b) Move VPLS specific related work (including provider-bridges liaison, > etc) in a "Temporary" focused wg (we have temporary area why not > have "temporary WGs" in INT area as well). FYI, formally all WGs in the IETF are considered "temporary", leaving only as long as their charters allow. When all milestones are completed, the WG potential is reconsidered. > While the ppvpn, vpls are progressing we can decide to join them > at a given time. > At least this option keeps ppvpn as it is in terms of structure, > avoids the questions on what to do with common l2+l3 > work, does minimum disruption to ppvpn wg activities in l3, l3+l2 > space, takes into account that l3vpn work is in its final stage. I suggest you look at it this way: L3 WG would be a rechartered and a focused version of PPVPN with L2-related work removed. The discussion about common L2/3 documents is yet to happen, and if we decide to go with the split, this will be one of the first things to discuss. We got the message about importance of these items, rest assured. Wrt l3vpn in its final stage--it's not going to be affected. > Other options as well is to look at a re-org from a wider > angle that affects both PWE3 and PPVPN. For example, merge some > PWE3 work with l2vpn VPW work, etc (I never understood why > some l2vpn signaling is done in another wg). Seems to me PWE3 has enough workload... Thanks for the suggestion though, we'll discuss it. > It looks to me an "easy-step" approach is more appropriate than > drastic change where the vpn problem is simplified into > l3 and l2 work. I don't believe anyone is thinking that L2 and L3 things are perfectly splittable. Just like between RTG WGs or in the MPLS/CCAMP case, there are a lot of connections. We are well aware of that and will deal with this. Splitting the work in two WGs is targeted to help manage the workload. > I definitely favor (as Jerry already noted) a 'let's wait a bit longer' > approach and progress the current work and if needed discuss in Vienna > options and solutions as was suggested by others (and > involving all the parties). I think I replied to a similar proposal before--uncertainty wrt the question under discussion is not a good thing. We (the ADs) need to make the decision sooner than that. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:54:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22352 for ; Tue, 13 May 2003 13:54:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DHvPY13523 for ; Tue, 13 May 2003 13:57:25 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DHvMX09278 for ; Tue, 13 May 2003 13:57:22 -0400 (EDT) Date: Tue, 13 May 2003 10:40:37 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <79165100742.20030513104037@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: <200305121452.h4CEqmu48261@merlot.juniper.net> References: <200305121452.h4CEqmu48261@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Monday, May 12, 2003, 7:52:48 AM, Yakov Rekhter wrote: > If the IESG is so much concerned, then it is the IESG's responsibility > to substantiate their concerns with *solid* technical arguments > that are of practical significance, and not just say that "the IESG > is very concerned". So far the IESG clearly failed to do so, as > what you put in the rest of this message either lacks solid technical > justification (see Pedro's replies to you) or practical significance, > or both. Clarification: in case I didn't make it clear in my message, those are _my_ concerns, not a statement from the IESG as a body. Regarding lack of "solid technical justification" or "practical significance", our opinions diverge. > And, bwt how do *you* know what BGP was designed for ? If one really > wants to know what BGP was (and was not) designed for, then perhaps > one should ask the folks who designed BGP. What I will do instead is take this document to IDR, and a couple of directorates for a review, so "folks who designed BGP", folks who work on BGP, and folks who use BGP, have a chance to say what they think. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 13:57:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22469 for ; Tue, 13 May 2003 13:57:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DI0LY25215 for ; Tue, 13 May 2003 14:00:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DI0HJ19719 for ; Tue, 13 May 2003 14:00:17 -0400 (EDT) Date: Tue, 13 May 2003 10:40:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4165115994.20030513104052@psg.com> To: PPVPN@nortelnetworks.com CC: Eric Rosen Subject: Re: Draft charter for L3VPN: Internet transparency In-Reply-To: <200305121412.h4CECbrS029943@rtp-core-1.cisco.com> References: <200305121412.h4CECbrS029943@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, Alex>> Is this specific to the case of 2547 only or generic to all L3 Alex>> mechanisms? If the former, I would rather not like the charter to say Alex>> so. > I think this applies to all the schemes. Even the CE-based schemes aren't > viable, in my opinion, over the public Internet because issues of QoS, SLA, > and accountability really prevent a company from using the public Internet > as the backbone for its intranet. I understand your position. I'd like to see more opinions here. Alex>> As for rejecting the 2547-related specs, I think it would be very Alex>> useful if the applicability statement highlighted the detail about Alex>> cooperating SPs and state that Internet transparency is a non-goal. > The AS already says (in section 1, Introduction): Yep, this is good, I think. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 14:00:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22605 for ; Tue, 13 May 2003 14:00:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DI3NY12588 for ; Tue, 13 May 2003 14:03:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DI3JJ07358 for ; Tue, 13 May 2003 14:03:19 -0400 (EDT) Date: Tue, 13 May 2003 10:41:00 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <191165124216.20030513104100@psg.com> To: PPVPN@nortelnetworks.com CC: Yakov Rekhter Subject: Re: Draft charter for L3VPN In-Reply-To: <200305121623.h4CGNeu53899@merlot.juniper.net> References: <200305121623.h4CGNeu53899@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, > Why the list of documents does not include "Using BGP as an Auto-Discovery > Mechanism for Network-based VPNs" (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ? Because I wanted to hear opinions on where it should go: L2 or L3, and whether it should be in the first set of documents a specific WG should work on or not. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 14:03:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22768 for ; Tue, 13 May 2003 14:03:41 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DI6BY27679 for ; Tue, 13 May 2003 14:06:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DI67J24108 for ; Tue, 13 May 2003 14:06:08 -0400 (EDT) Date: Tue, 13 May 2003 10:41:18 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <45165142272.20030513104118@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-Reply-To: <200305121643.h4CGhvu56061@merlot.juniper.net> References: <200305121643.h4CGhvu56061@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Monday, May 12, 2003, 9:43:57 AM, Yakov Rekhter wrote: > Assume that there is a (rough) consensus on splitting the PPVPN WG > into two (which is yet TBD), I'd like the following to be added to > the L2 VPN charter: > The effort will produce a small number of approaches that are based > on collections of individual technologies. The goal is to foster > interoperability among implementations of a specific approach. > Standardization of specific approaches will be gauged on (I)SP support. Please state why you believe this should be in the charter and what exactly your proposed text would mean. Monday, May 12, 2003, 10:34:16 AM, Eric Rosen wrote: > Two L2VPN charter issues that come up frequently are (a) whether ARP > Mediation (for allowing IP traffic on a p2p link between two unlike > attachment circuits) falls into the charter, and (b) whether IPLS (for > allowing LAN-like connectivity among a set of IP routers, without requiring > MAC learning, BPDUs, etc.) falls into the charter. If there is actually > going to be an L2VPN charter, I'd like to see this settled, preferably in > favor of including these efforts. I'd like to see more opinions on this. Monday, May 12, 2003, 2:59:41 PM, schultz@io.iol.unh.edu wrote: > I know that this does not matter to some, but IMHO if this new group > happens, an indication of the WG cooperation with IEEE 802.1 should be > part of the charter to add clarity. Noted. Thanks. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 14:12:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23111 for ; Tue, 13 May 2003 14:12:57 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DIFRY03885 for ; Tue, 13 May 2003 14:15:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DIFP224924 for ; Tue, 13 May 2003 14:15:25 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E606623F8B@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Alex Zinin'" , "'PPVPN@nortelnetworks.com'" Cc: "'Yakov Rekhter'" Subject: RE: Draft charter for L3VPN Date: Tue, 13 May 2003 14:13:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3197B.53E670CE" X-LYRIS-Message-Id: 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_01C3197B.53E670CE Content-Type: text/plain Alex, not sure what you mean by "L2 or L3"? Bilel. -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Tuesday, May 13, 2003 1:41 PM To: PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: Re: Draft charter for L3VPN Yakov, > Why the list of documents does not include "Using BGP as an > Auto-Discovery Mechanism for Network-based VPNs" > (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ? Because I wanted to hear opinions on where it should go: L2 or L3, and whether it should be in the first set of documents a specific WG should work on or not. Alex ------_=_NextPart_001_01C3197B.53E670CE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft charter for L3VPN

Alex, not sure what you mean by "L2 or L3"? =

Bilel.

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Tuesday, May 13, 2003 1:41 PM
To: PPVPN@nortelnetworks.com
Cc: Yakov Rekhter
Subject: Re: Draft charter for L3VPN


Yakov,

> Why the list of documents does not include = "Using BGP as an
> Auto-Discovery Mechanism for Network-based = VPNs"
> (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ?

Because I wanted to hear opinions on where it should = go: L2 or L3, and whether it should be in the first set of documents a = specific WG should work on or not.

Alex


------_=_NextPart_001_01C3197B.53E670CE-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 14:32:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23637 for ; Tue, 13 May 2003 14:32:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DIYYY09754 for ; Tue, 13 May 2003 14:34:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DIYVR07597 for ; Tue, 13 May 2003 14:34:31 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Ross Callon" , "Bilel Jamoussi" , Cc: "'Alex Zinin'" Subject: RE: WG split: why and how? Date: Tue, 13 May 2003 11:30:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C31943.164F8800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.3.2.20030513105011.028acb40@zircon.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 13 May 2003 18:30:24.0907 (UTC) FILETIME=[B83C45B0:01C3197D] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: jamoussi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C31943.164F8800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the last few ppvpn WG sessions, several people were turned away for lack of time, a couple tried to make presentations after the time slot was over, and so on. Fundamentally, there is still a lot of work (finishing up on existing drafts, new drafts, and discussions galore). We need another session. We have before us two approaches: - have two ppvpn WG sessions - split the WG into two focus areas (L2VPNs and L3VPNs), each with its own session and WG chairs It's a large effort, and Marco and Rick have done well to progress it. But this is a management issue. If you believe that there is no easy split down the ppvpn group along the lines of L2 and L3, then it makes more sense to have 2 sessions. If you believe that there is a logical split of the existing WG, then the more reasonable "throw bandwidth at the problem" solution is to have 2 WGs. I think there is enough work and a reasonable split of the ppvpn effort that having two focus areas is the better approach. Can we reorganize our thoughts around solving the management issue instead of whether Rick or Marco did a good job with ppvpn? What do we lose or gain with either of the two suggestions above? Thanks. -Vach ------=_NextPart_000_008F_01C31943.164F8800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In the=20 last few ppvpn WG sessions, several people were turned away for = lack of=20 time, a couple tried to make presentations after the time slot was over, = and so=20 on.  Fundamentally, there is still a lot of work (finishing up on = existing=20 drafts, new drafts, and discussions galore).  We need another=20 session.  We have before us two approaches:
 =20 - have two ppvpn WG sessions
 =20 - split the WG into two focus areas (L2VPNs and L3VPNs), each with its = own=20 session and WG chairs
 
It's a=20 large effort, and Marco and Rick have done well to progress = it. =20 But this is a management issue.  If you believe that there is no = easy split=20 down the ppvpn group along the lines of L2 and L3, then it makes more = sense to=20 have 2 sessions.  If you believe that there is a logical split of = the=20 existing WG, then the more reasonable "throw bandwidth at the problem" = solution=20 is to have 2 WGs.
 
I=20 think there is enough work and a reasonable split of the ppvpn = effort=20 that having two focus areas is the better=20 approach.
 
Can we=20 reorganize our thoughts around solving the management issue instead of = whether=20 Rick or Marco did a good job with ppvpn?  What do we lose or gain = with=20 either of the two suggestions above?
 
Thanks.
 
-Vach
------=_NextPart_000_008F_01C31943.164F8800-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 15:43:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27233 for ; Tue, 13 May 2003 15:43:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DJk0Y22440 for ; Tue, 13 May 2003 15:46:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DJjuq28700 for ; Tue, 13 May 2003 15:45:57 -0400 (EDT) Message-ID: <3EC14AA5.A0444867@alcatel.com> Date: Tue, 13 May 2003 15:42:29 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mattsquire@acm.org CC: erosen@cisco.com, mick_seaman@ieee.org, "'Pedro Roque Marques'" , "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200305091459.h49ExKZC001931@rtp-core-1.cisco.com> <3EC0E878.6080607@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mick, Matt, Mick Seaman wrote: > From the point of > view of control connectivity the pseudo-wires have to establish a full mesh > that is never perceived by layer 2 protocols as being less than complete. How can this "lower layer emulated LAN" (using full mesh split horizon) be perceived by IEEE L2 as being _never_ less than complete? > STP is running across the service that runs on top of the mechanisms that > make the service LAN like. Matt Squire wrote: > But ensuring the > emulated and real technologies are transparent to the higher layer, one > can build arbitrary networks based on traditional bridging models. I > hope thats a good thing. From the architecture point of view, it looks clean to make the lower layer transparent and to mandate the lower layer should do its job properly (in this case IEEE 802.1ad assumes PPVPN VPLS always provide a properly emulated LAN, no configuration loops, connectivity issues, etc). However, I do not know how loops in the forwarding paths can be prevented, if a tree is concatenated/spliced with the lower layer forwarding path (or another tree), unless all common nodes in the forwarding path (both higher and lower layer) participate in one common spanning tree or a similar algorithm to prevent forwarding loops. Thanks Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 15:56:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27485 for ; Tue, 13 May 2003 15:56:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DJx8Y27985 for ; Tue, 13 May 2003 15:59:08 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DJx4q06642 for ; Tue, 13 May 2003 15:59:04 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG split: why and how? Date: Tue, 13 May 2003 14:55:40 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A7102@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG split: why and how? Thread-Index: AcMZeKNmDU/dvIxgQke723tKW/71bAADGfow From: "Ash, Gerald R (Jerry), ALABS" To: "Alex Zinin" Cc: "Ash, Gerald R (Jerry), ALABS" , X-SMTP-HELO: kcmso2.proxy.att.com X-SMTP-MAIL-FROM: gash@att.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kcmso2.att.com [192.128.134.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA27485 Jerry> Seems to conclude that the problem cannot be solved within the Jerry> existing PPVPN WG. Let's get the WG chairs' proposals on how to fix Jerry> the problem within the WG, and discuss their proposals. Alex> The ADs will consider the discussion on the list and conversations Alex> with the WG chairs and will make the decision. Your proposal to split the WG is the only 'solution' being considered. I suggested to compare your solution to the WG chairs' solution for how to progress the work of PPVPN faster within the current WG. Surely the WG chairs have been asked for their proposals on this in (private) discussions with you and the other ADs. Can we consider what they propose? And if not, why not? Jerry From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 16:06:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27679 for ; Tue, 13 May 2003 16:06:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DK8rY17134 for ; Tue, 13 May 2003 16:08:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DK8or25299 for ; Tue, 13 May 2003 16:08:50 -0400 (EDT) Message-ID: <3EC14D82.AAFA2D9B@alcatel.com> Date: Tue, 13 May 2003 15:54:42 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Info aggregation References: <200305121850.h4CIoOgf005558@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, Alex, Eric Rosen wrote: > > Alex> Some more questions here: when taken to a large scale > Alex> (not necessarily just one VPLS) > > Alex> o what VPLS info from other AS'es do PEs need to know? > > Vach has been pushing a hierarchical model, in which, for each VPLS, each AS > has a "gateway" that only needs to know how to reach a gateway in the other > ASes, and within an AS, each PE only needs to know how to reach its own > gateway. > > I've been pushing a somewhat different model in which each PE has to know > how to reach its gateway (to a particular AS), and has to know how many PEs > supporting that same VPLS there are in the other AS. A PE sets up that > number of pseudowires to the gateway, which splices them together with pws > that go to the next AS. (The splicing can be done in such a way as to be > transparent to the forwarding plane, though some have suggested that the > gateway might need to be an OAM boundary, even if that sacrifices > scalability.) Are the proponents of these models considering loop prevention measures? > Both models provide a good summarization of information, I think. They > differ in regard to the amount and kind of state needed in the PEs as > opposed to the gateway. The hierarchical model helps with the scale of the > individual PEs, but requires MAC lookup in the gateways, and also requires > of course that a hierarchy be provisioned. > > (I hope I've not done Vach's model too much of an injustice.) > > Alex> o given the edge-to-edge nature of PWs, is it feasible > Alex> to summarize signalling information among AS'es at all? > > Both models bound the number of signaling inter-AS connections, so that the > number of these connections does not grow as the number of PEs grows. The > hierarchical model limits some of the signaling information to the hierarchy > boundaries. I think this is limiting distribution of L2VPN info to a smaller number of devices (this is fine, disregarding forwarding loops and resiliency for now). In what scenario will it reduce the amount of L2VPN info on the devices where this information is distributed? > > Alex> o if not, how do we scope distribution of signalling info > Alex> so amount of info per participating node has reasonable > Alex> growth characteristics? > > I think it is impossible to make L2 scale as well as L3, because of the flat > and non-aggregatable address space, and because of the need to multicast > packets with unknown DAs. Yes. > However, whereas we want our L3 networks to be > able to grow without bound, I don't think the same requirement exists with > respect to L2 networks. I would like to understand what this requirement means. If we consider IP and Ethernet (not network based VPLS/VPN), then yes, if a LAN becomes large we can subnet it and interconnect the subnets with IP. Similarly for end customer IP VPN and LAN. If the L2 network is required to support VPLS sites in different SP networks or regions, using network based VPLS, does this imply the network based VPLS solution should scale for large networks (i.e. PEs should be able to support a large number of total VPLS instances)? Or are we saying, only a few SP networks or regions can be interconnected to offer VPLS because: i) that's all we need or ii) it seems we cannot really scale network based VPLS or/and another solution would be needed to allow large number of VPLS instances offering? > Alex> o is it feasible to summarize VPLS membership information > Alex> among AS'es? How to aggregate VPLS membership ID, VPLS_ID/VPN_ID ? (cf IP addresses/routes can be aggregated). Thanks, Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 16:11:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27770 for ; Tue, 13 May 2003 16:11:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DKDxY20349 for ; Tue, 13 May 2003 16:13:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DKDtr02062 for ; Tue, 13 May 2003 16:13:56 -0400 (EDT) Message-ID: <3EC14FC5.6090805@marconi.com> Date: Tue, 13 May 2003 16:04:21 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030430 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF PPVPN List Subject: Latest MPLS-VPN MIB? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: David.Charlap@marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit draft-ietf-ppvpn-mpls-vpn-mib no longer exists. Version -06 is a message saying it expired. Is an updated version on the way? Has it been superseded by a different document? I still have version -05 (even though it no longer exists on the IETF server), so I have no critical problem, but it would be good to know what is planned for the future of this draft and the MIB it defines. Thanks in advance. -- David From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 16:16:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27963 for ; Tue, 13 May 2003 16:16:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DKItY24393 for ; Tue, 13 May 2003 16:18:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DKIrm09038 for ; Tue, 13 May 2003 16:18:53 -0400 (EDT) Message-Id: <5.2.0.9.0.20030513151912.00b11ed0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 13 May 2003 15:51:27 -0400 To: Alex Zinin , PPVPN@nortelnetworks.com From: Mark Duffy Subject: Re: Draft charter for L3VPN: Internet transparency In-Reply-To: <4165115994.20030513104052@psg.com> References: <200305121412.h4CECbrS029943@rtp-core-1.cisco.com> <200305121412.h4CECbrS029943@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: At 10:40 AM 5/13/2003 -0700, Alex Zinin wrote: >Eric, > >Alex>> Is this specific to the case of 2547 only or generic to all L3 >Alex>> mechanisms? If the former, I would rather not like the charter to say >Alex>> so. > > > I think this applies to all the schemes. Even the CE-based schemes > aren't > > viable, in my opinion, over the public Internet because issues of QoS, > SLA, > > and accountability really prevent a company from using the public > Internet > > as the backbone for its intranet. > >I understand your position. I'd like to see more opinions here. [This thread was about whether an updated L3 vpn wg charter should not specify the ability to operate across the public Internet as an objective.] I would contend that the VR and CE-based solutions are viable across the public Internet, in a way that 2547 is not. Yes, QOS and SLA are issues, but folks have been deploying CE-based VPNs on the Internet for years; evidently they don't consider these a show-stopper. And the VR-based approach is similar to the CE-based approach as far as the impact of running across the Internet is concerned. I do think that 2547 IS appropriate for the wg to pursue. However different tools (alone or used together) are optimal for different situations and that is why we have multiple L3 vpn approaches. Should the charter REQUIRE solutions to be viable across the Internet? No. Should it encourage development of 1 or more solutions that are viable across the Internet? Yes. --Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 16:26:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28100 for ; Tue, 13 May 2003 16:26:21 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DKSqY29535 for ; Tue, 13 May 2003 16:28:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DKSnm16779 for ; Tue, 13 May 2003 16:28:49 -0400 (EDT) Reply-To: From: "Vach Kompella" To: , Cc: "Alex Zinin" , Subject: RE: Info aggregation Date: Tue, 13 May 2003 13:23:24 -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.2911.0) Importance: Normal In-Reply-To: <3EC14D82.AAFA2D9B@alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 13 May 2003 20:23:08.0182 (UTC) FILETIME=[77762360:01C3198D] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Cheng-Yin, Stay tuned for my draft. Yes, there are some loop issues that are addressed. Eric jumped the gun a little when he spoke of my draft because I have been talking to a couple of people about the requirements of the solution. I believe Eric has captured the gist of what I am proposing. There are two different problems, both of which have there own positives and negatives. E.g., something along the lines of 10(c) requires a 3-label stack, vc label per PE, and the replication issues are significant. The other approach is to have a 2-label stack learning gateway, and have it perform replications. That way you distribute the replication, but you incur the learning. Both models have their uses, depending on the inter-region traffic patterns. -Vach > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: Tuesday, May 13, 2003 12:55 PM > To: erosen@cisco.com > Cc: Alex Zinin; PPVPN@nortelnetworks.com > Subject: Re: Info aggregation > > > Eric, Alex, > > Eric Rosen wrote: > > > > Alex> Some more questions here: when taken to a large scale > > Alex> (not necessarily just one VPLS) > > > > Alex> o what VPLS info from other AS'es do PEs need to know? > > > > Vach has been pushing a hierarchical model, in which, for each VPLS, each AS > > has a "gateway" that only needs to know how to reach a gateway in the other > > ASes, and within an AS, each PE only needs to know how to reach its own > > gateway. > > > > I've been pushing a somewhat different model in which each PE has to know > > how to reach its gateway (to a particular AS), and has to know how many PEs > > supporting that same VPLS there are in the other AS. A PE sets up that > > number of pseudowires to the gateway, which splices them together with pws > > that go to the next AS. (The splicing can be done in such a way as to be > > transparent to the forwarding plane, though some have suggested that the > > gateway might need to be an OAM boundary, even if that sacrifices > > scalability.) > Are the proponents of these models considering loop prevention measures? > > > Both models provide a good summarization of information, I think. They > > differ in regard to the amount and kind of state needed in the PEs as > > opposed to the gateway. The hierarchical model helps with the scale of the > > individual PEs, but requires MAC lookup in the gateways, and also requires > > of course that a hierarchy be provisioned. > > > > (I hope I've not done Vach's model too much of an injustice.) > > > > Alex> o given the edge-to-edge nature of PWs, is it feasible > > Alex> to summarize signalling information among AS'es at all? > > > > Both models bound the number of signaling inter-AS connections, so that the > > number of these connections does not grow as the number of PEs grows. The > > hierarchical model limits some of the signaling information to the hierarchy > > boundaries. > I think this is limiting distribution of L2VPN info to a smaller number > of devices (this is fine, disregarding forwarding loops and resiliency > for now). In what scenario will it reduce the amount of L2VPN info on > the devices where this information is distributed? > > > > > Alex> o if not, how do we scope distribution of signalling info > > Alex> so amount of info per participating node has reasonable > > Alex> growth characteristics? > > > > I think it is impossible to make L2 scale as well as L3, because of the flat > > and non-aggregatable address space, and because of the need to multicast > > packets with unknown DAs. > Yes. > > > However, whereas we want our L3 networks to be > > able to grow without bound, I don't think the same requirement exists with > > respect to L2 networks. > I would like to understand what this requirement means. > If we consider IP and Ethernet (not network based VPLS/VPN), then yes, > if a LAN becomes large we can subnet it and interconnect the subnets > with IP. Similarly for end customer IP VPN and LAN. > > If the L2 network is required to support VPLS sites in different SP > networks or regions, using network based VPLS, does this imply the > network based VPLS solution should scale for large networks (i.e. PEs > should be able to support a large number of total VPLS instances)? > Or are we saying, only a few SP networks or regions can be > interconnected to offer VPLS because: > i) that's all we need or > ii) it seems we cannot really scale network based VPLS or/and another > solution would be needed to allow large number of VPLS instances > offering? > > > Alex> o is it feasible to summarize VPLS membership information > > Alex> among AS'es? > How to aggregate VPLS membership ID, VPLS_ID/VPN_ID ? (cf IP > addresses/routes can be aggregated). > > Thanks, > Cheng-Yin > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 16:51:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28674 for ; Tue, 13 May 2003 16:51:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DKrtY06246 for ; Tue, 13 May 2003 16:53:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DKrlW02509 for ; Tue, 13 May 2003 16:53:48 -0400 (EDT) Message-ID: <3EC156F1.4B395BC0@alcatel.com> Date: Tue, 13 May 2003 16:34:57 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vkompella@timetra.com CC: erosen@cisco.com, Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Info aggregation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, Would you be addressing loops due to misconfiguration e.g. in the gateway hierarchy? Thanks Cheng-Yin Vach Kompella wrote: > > Cheng-Yin, > > Stay tuned for my draft. Yes, there are some loop issues that are addressed. > Eric jumped the gun a little when he spoke of my draft because I have been > talking to a couple of people about the requirements of the solution. > > I believe Eric has captured the gist of what I am proposing. There are two > different problems, both of which have there own positives and negatives. E.g., > something along the lines of 10(c) requires a 3-label stack, vc label per PE, > and the replication issues are significant. The other approach is to have a > 2-label stack learning gateway, and have it perform replications. That way you > distribute the replication, but you incur the learning. > > Both models have their uses, depending on the inter-region traffic patterns. > > -Vach > > > -----Original Message----- > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > Sent: Tuesday, May 13, 2003 12:55 PM > > To: erosen@cisco.com > > Cc: Alex Zinin; PPVPN@nortelnetworks.com > > Subject: Re: Info aggregation > > > > > > Eric, Alex, > > > > Eric Rosen wrote: > > > > > > Alex> Some more questions here: when taken to a large scale > > > Alex> (not necessarily just one VPLS) > > > > > > Alex> o what VPLS info from other AS'es do PEs need to know? > > > > > > Vach has been pushing a hierarchical model, in which, for each VPLS, each AS > > > has a "gateway" that only needs to know how to reach a gateway in the other > > > ASes, and within an AS, each PE only needs to know how to reach its own > > > gateway. > > > > > > I've been pushing a somewhat different model in which each PE has to know > > > how to reach its gateway (to a particular AS), and has to know how many PEs > > > supporting that same VPLS there are in the other AS. A PE sets up that > > > number of pseudowires to the gateway, which splices them together with pws > > > that go to the next AS. (The splicing can be done in such a way as to be > > > transparent to the forwarding plane, though some have suggested that the > > > gateway might need to be an OAM boundary, even if that sacrifices > > > scalability.) > > Are the proponents of these models considering loop prevention measures? > > > > > Both models provide a good summarization of information, I think. They > > > differ in regard to the amount and kind of state needed in the PEs as > > > opposed to the gateway. The hierarchical model helps with the scale of the > > > individual PEs, but requires MAC lookup in the gateways, and also requires > > > of course that a hierarchy be provisioned. > > > > > > (I hope I've not done Vach's model too much of an injustice.) > > > > > > Alex> o given the edge-to-edge nature of PWs, is it feasible > > > Alex> to summarize signalling information among AS'es at all? > > > > > > Both models bound the number of signaling inter-AS connections, so that the > > > number of these connections does not grow as the number of PEs grows. The > > > hierarchical model limits some of the signaling information to the hierarchy > > > boundaries. > > I think this is limiting distribution of L2VPN info to a smaller number > > of devices (this is fine, disregarding forwarding loops and resiliency > > for now). In what scenario will it reduce the amount of L2VPN info on > > the devices where this information is distributed? > > > > > > > > Alex> o if not, how do we scope distribution of signalling info > > > Alex> so amount of info per participating node has reasonable > > > Alex> growth characteristics? > > > > > > I think it is impossible to make L2 scale as well as L3, because of the flat > > > and non-aggregatable address space, and because of the need to multicast > > > packets with unknown DAs. > > Yes. > > > > > However, whereas we want our L3 networks to be > > > able to grow without bound, I don't think the same requirement exists with > > > respect to L2 networks. > > I would like to understand what this requirement means. > > If we consider IP and Ethernet (not network based VPLS/VPN), then yes, > > if a LAN becomes large we can subnet it and interconnect the subnets > > with IP. Similarly for end customer IP VPN and LAN. > > > > If the L2 network is required to support VPLS sites in different SP > > networks or regions, using network based VPLS, does this imply the > > network based VPLS solution should scale for large networks (i.e. PEs > > should be able to support a large number of total VPLS instances)? > > Or are we saying, only a few SP networks or regions can be > > interconnected to offer VPLS because: > > i) that's all we need or > > ii) it seems we cannot really scale network based VPLS or/and another > > solution would be needed to allow large number of VPLS instances > > offering? > > > > > Alex> o is it feasible to summarize VPLS membership information > > > Alex> among AS'es? > > How to aggregate VPLS membership ID, VPLS_ID/VPN_ID ? (cf IP > > addresses/routes can be aggregated). > > > > Thanks, > > Cheng-Yin > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 16:52:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28695 for ; Tue, 13 May 2003 16:52:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DKtKY08082 for ; Tue, 13 May 2003 16:55:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DKtHW04664 for ; Tue, 13 May 2003 16:55:17 -0400 (EDT) Message-ID: <3EC153C2.E4AD6897@alcatel.com> Date: Tue, 13 May 2003 16:21:22 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vkompella@timetra.com, Ross Callon CC: "Bilel Jamoussi" , ppvpn@nortelnetworks.com, "'Alex Zinin'" Subject: Re: WG split: why and how? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, Ross, I also agree that the WG chairs have put in a lot of effort and have pushed for progress and consensus in PPVPN, and that the division of the work in PPVPN is an independent issue. I think the chairs have encouraged consensus, and perhaps ultimately, the success of the WG(s) may be determined by the WG members e.g. by the relevance of the solutions specified here in addressing market requirements and their technical viability, and not so much by the number of WG drafts or RFCs produced. Regards, Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 17:00:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28982 for ; Tue, 13 May 2003 17:00:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DL3OY05146 for ; Tue, 13 May 2003 17:03:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DL3Lx07475 for ; Tue, 13 May 2003 17:03:21 -0400 (EDT) Message-ID: <3EC15BAE.CADC172F@alcatel.com> Date: Tue, 13 May 2003 16:55:10 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ross Callon CC: "Busschbach Peter B (Peter)" , "'Yakov Rekhter'" , "Fang Luyuan ALABS" , PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) (LONG reply) References: <4.3.2.20030513113708.0287fb10@zircon.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ross, Ross Callon wrote: > > If we look at some examples from history, there is a very clear trend > that progressing two or slightly more approaches works out okay. Bad > approaches go away because they don't work well when deployed (for > example, scaling might be difficult, or stability might be lacking). > Trying to pick one winner in a heavily politicized large group just > doesn't work. Committees aren't very good at figuring out where there > are going to be problems. Agree. Alas the "bad" approaches may only go away after resources have been invested in them. Some say, not to worry, this benefits vendors, but I'm not so sure about this. Perhaps that's the way things have been and will be ... > I apologize that this message is quite long. However, to make a good > choice in this area it is important to understand a bit of history, and so > I have written down some historical examples below (there are more). Thanks for taking the time to put some of the issues here in perspective. Regards, Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 17:02:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29012 for ; Tue, 13 May 2003 17:02:52 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DL5MY13685 for ; Tue, 13 May 2003 17:05:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DL5Jx19652 for ; Tue, 13 May 2003 17:05:19 -0400 (EDT) From: "tom nadeau" To: "'David Charlap'" , "'IETF PPVPN List'" Subject: RE: Latest MPLS-VPN MIB? Date: Tue, 13 May 2003 16:49:38 -0400 Message-ID: <000001c31991$2f700a50$99472ca1@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: <3EC14FC5.6090805@marconi.com> X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: Tuesday, May 13, 2003 4:04 PM > To: IETF PPVPN List > Subject: Latest MPLS-VPN MIB? > > > draft-ietf-ppvpn-mpls-vpn-mib no longer exists. Version -06 is a > message saying it expired. > > Is an updated version on the way? Has it been superseded by > a different document? Yes, I was updating it last week, but was preempted by the MIB doctor final-final-final review of the MPLS base MIBs. > I still have version -05 (even though it no longer exists on the IETF > server), so I have no critical problem, but it would be good to know > what is planned for the future of this draft and the MIB it defines. A few hopefully minor changes. --Tom > > Thanks in advance. > > -- David > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 17:07:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29231 for ; Tue, 13 May 2003 17:07:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DL9gY17383 for ; Tue, 13 May 2003 17:09:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DL9dx15408 for ; Tue, 13 May 2003 17:09:39 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Date: Tue, 13 May 2003 16:31:36 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <45165142272.20030513104118@psg.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp1g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: aismtp1g.bellsouth.com [139.76.165.196] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Tuesday, May 13, 2003 1:41 PM > To: PPVPN@nortelnetworks.com > Subject: Re: Draft charter for L2VPN > > > Monday, May 12, 2003, 9:43:57 AM, Yakov Rekhter wrote: > > Assume that there is a (rough) consensus on splitting the PPVPN WG > > into two (which is yet TBD), I'd like the following to be added to > > the L2 VPN charter: > Monday, May 12, 2003, 10:34:16 AM, Eric Rosen wrote: > > Two L2VPN charter issues that come up frequently are > (a) whether ARP > > Mediation (for allowing IP traffic on a p2p link > between two unlike > > attachment circuits) falls into the charter, and (b) > whether IPLS (for > > allowing LAN-like connectivity among a set of IP routers, > without requiring > > MAC learning, BPDUs, etc.) falls into the charter. If > there is actually > > going to be an L2VPN charter, I'd like to see this > settled, preferably in > > favor of including these efforts. > > I'd like to see more opinions on this. > I'd like to see the work in this area - IPLS & ARP Mediation -progressed and documented in a published RFC. They are not the most widely deployed cases, but they do exist and have real network applications. I do not care which group does the work. Given the current emphasis on polishing charters, it should appear within the scope of one of them. Steven Wright From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 17:46:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00103 for ; Tue, 13 May 2003 17:46:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DLnPY24338 for ; Tue, 13 May 2003 17:49:25 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DLnMW09649 for ; Tue, 13 May 2003 17:49:22 -0400 (EDT) Message-ID: <007301c31998$d714e4e0$89a7fea9@Sunny> From: "Brijesh Kumar" To: "Pedro Roque Marques" , "Juha Heinanen" Cc: "Alex Zinin" , References: <184493545.20030507185157@psg.com><16057.55991.734081.636661@harjus.eng.song.fi><200305080439.h484dLL65952@roque-bsd.juniper.net> <16057.58591.713308.53655@harjus.eng.song.fi> Subject: Re: Draft charter for L3VPN Date: Tue, 13 May 2003 14:44:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: mtiwmhc13.worldnet.att.net X-SMTP-MAIL-FROM: brijesh.kumar@att.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mtiwmhc13.worldnet.att.net [204.127.131.117] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I strongly believe that Juha's points merit a serious consideration. A VPN solution must be able to span as many providers as needed to connect an organization. This requirement may be much more useful in the European context given that businesses there operate in many countries while many carriers may not operate outside their local operating regions. If BGP/MPLS VPNS can be a charter item, it is hard to understand why this group's charter can exclude proposals such as Juha's Radius based approach which does provide a simple and perhaps much more manageable environment for multi-carrier VPNs. Every approach should be discussed at its own merit. Regards, --brijesh ----- Original Message ----- From: "Juha Heinanen" To: "Pedro Roque Marques" Cc: "Alex Zinin" ; Sent: Wednesday, May 07, 2003 10:02 PM Subject: Draft charter for L3VPN > Pedro Roque Marques writes: > > > > looks like I in Ietf doesn't mean Internet anymore. > > > > I'm not sure i understand the comment. The Internet is a public > > network, a VPN a private one. Do you mean to refer to Internet access > > from a VPN ? inter-action between the two ? I would believe that to be > > in scope. Alex, would you please clarify ? > > what i meant was that ietf should work on solutions that work across the > internet, not just within a single as. if a vpn according to a > particular solution cannot span more than one as, the solution is > completely useless to us, because in our own network alone there are > five-to-six different ases as the result of mergers with and purchases > of other providers. > > also, a regional provider like us needs to have partnerships with other > providers that cover other parts of the world. therefore it is almost > as important to us that a vpn according to a given solution can span > more than one provider. > > for example, consider the case where we provide a vpn solution for a > given customer that initially only has sites within our own network and > then suddenly they want to add another site is china, where we do not > operate? it would be very unfortunate if we would need at that point to > switch from a single provider vpn solution to a multi-provider solution > also for the old sites. > > therefore, i don't see much point in postponing the multi-provider > aspects either. > > -- juha > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 17:59:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00411 for ; Tue, 13 May 2003 17:59:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DM1qY14328 for ; Tue, 13 May 2003 18:01:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DM1o106083 for ; Tue, 13 May 2003 18:01:51 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , PPVPN@nortelnetworks.com Cc: Yakov Rekhter Subject: RE: Draft charter for L3VPN Date: Tue, 13 May 2003 18:00:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3199B.0490DCF6" X-LYRIS-Message-Id: 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_01C3199B.0490DCF6 Content-Type: text/plain; charset="iso-8859-1" Alex, > > > Why the list of documents does not include "Using BGP as an > Auto-Discovery > > Mechanism for Network-based VPNs" > (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ? > > Because I wanted to hear opinions on where it should go: L2 or L3, Unfortunately, it's neither L2 or L3, it's L2+L3. I really think (if wg split happens), that the new re-org needs to leave room for potential l2+l3 work/common mechanisms. > and whether it should be in the first set of documents a specific > WG should work on or not. > Not sure I understand that part. It is already a working group document. Hamid. ------_=_NextPart_001_01C3199B.0490DCF6 Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L3VPN

Alex,

>
> > Why the list of documents does not include "Using BGP as an
> Auto-Discovery
> > Mechanism for Network-based VPNs"
> (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ?
>
> Because I wanted to hear opinions on where it should go: L2 or L3,

Unfortunately, it's neither L2 or L3, it's L2+L3. I really think
(if wg split happens), that the new re-org needs to leave room
for potential l2+l3 work/common mechanisms.

> and whether it should be in the first set of documents a specific
> WG should work on or not.
>

Not sure I understand that part. It is already a working group
document.

Hamid.

------_=_NextPart_001_01C3199B.0490DCF6-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 18:02:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00502 for ; Tue, 13 May 2003 18:02:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DM4lY20356 for ; Tue, 13 May 2003 18:04:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DM4i124815 for ; Tue, 13 May 2003 18:04:44 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: steven.wright@BellSouth.com, PPVPN@nortelnetworks.com Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Date: Tue, 13 May 2003 18:03:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3199B.6E2B2554" X-LYRIS-Message-Id: 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_01C3199B.6E2B2554 Content-Type: text/plain; charset="iso-8859-1" > > I'd like to see the work in this area - IPLS & ARP Mediation > -progressed and > documented in a published RFC. They are not the most widely > deployed cases, > but they do exist and have real network applications. > > I do not care which group does the work. Given the current emphasis on > polishing charters, it should appear within the scope of one of them. > I agree. In fact I would like the l2vpn interworking topic to be considered. Hamid. ------_=_NextPart_001_01C3199B.6E2B2554 Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L2VPN - IPLS & ARP Mediation

>
> I'd like to see the work in this area - IPLS & ARP Mediation
> -progressed and
> documented in a published RFC. They are not the most widely
> deployed cases,
> but they do exist and  have real network applications.
>
> I do not care which group does the work. Given the current emphasis on
> polishing charters, it should appear within the scope of one of them.
>

I agree. In fact I would like the l2vpn interworking topic
to be considered.

Hamid.

------_=_NextPart_001_01C3199B.6E2B2554-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 19:16:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03693 for ; Tue, 13 May 2003 19:16:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4DNIqY10205 for ; Tue, 13 May 2003 19:18:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4DNInu17394 for ; Tue, 13 May 2003 19:18:49 -0400 (EDT) From: "Thomas D. Nadeau" To: "'Loa Andersson'" , "'Yakov Rekhter'" Cc: "Hamid Ould-Brahim" , "'Thomas Narten'" , "'Alex Zinin'" , , , "'Wijnen, Bert \(Bert\)'" , "'Peterson, Jon'" , "'Allison Mankin'" Subject: RE: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Tue, 13 May 2003 19:06:22 -0400 Message-ID: <001d01c319a4$4882f9e0$99472ca1@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: <3EC08813.5060202@pi.se> X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I agree Loa. The argument doesn't make much sense. I think the point is to optimize the work load not create administravia. --Tom > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Loa Andersson > Sent: Tuesday, May 13, 2003 1:52 AM > To: Yakov Rekhter > Cc: Hamid Ould-Brahim; Thomas Narten; Alex Zinin; > ppvpn@nortelnetworks.com; pwe3@ietf.org; Wijnen, Bert (Bert); > Peterson, Jon; Allison Mankin > Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF > > > Yakov, > > just because something is "too big", you don't need to split > each and every atom. "logical extremes" does not very often > make sense in disucssion on how to organize a work load, we > should look for opitmization > > in this context "splitting" makes perfetly sense > > /Loa > > Yakov Rekhter wrote: > < snip > > > > > Agreed. In fact, if the justification for splitting the > PPVNP WG into > > two is to allow discussion for L3 services, then following the same > > line of reasoning there should be not one, but two L2 VPN > WGs, one for > > L2 VPN services (other than VPLS), and one for VPLS. Yet, the IESG > > said nothing about having two L2 VPN WGs. Perhaps the IESG would be > > kind enough to explain this inconsistency. > > > > > >>In that respect, creating a new l2vpn wg will not make the > situation > >>any > >>better. > > > > > > Agreed. > > > > Yakov. > > > > > > > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 20:30:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05122 for ; Tue, 13 May 2003 20:30:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E0X6Y01616 for ; Tue, 13 May 2003 20:33:06 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4E0X2p06319 for ; Tue, 13 May 2003 20:33:02 -0400 (EDT) Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Ross Callon'" , "'Yakov Rekhter'" , "Fang, Luyuan, ALABS" Cc: PPVPN@nortelnetworks.com Subject: RE: Single vs many solution(s) (LONG reply) Date: Tue, 13 May 2003 20:31:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: hoemail1.firewall.lucent.com X-SMTP-MAIL-FROM: busschbach@lucent.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: hoemail1.lucent.com [192.11.226.161] X-LYRIS-Message-Id: > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: Tuesday, May 13, 2003 1:30 PM > Subject: RE: Single vs many solution(s) (LONG reply) > >I don't think the IETF is making business decisions. Vendors > are free to develop proprietary solutions and service > providers are free to deploy them. However, a standards body > should develop one solution as THE standard. > > > >... > >Peter > > This is ignoring 17 years of IETF experience, and more than > 20 years of > standards experience. The reality is that neither the IETF > nor any other > standards body is good at choosing between major approaches. When > we have tried to do this (or when any other standards group has tried > this) we have failed more often than succeeded. Where we have let more > than one major approach be progressed, we have succeeded most of the > time (although usually most of the approaches eventually go away). > Ross, I think there is a difference between new, unproven technologies - like IP routing protocols in the eigthies and the various wireless protocols more recently - and more mature technologies. SONET, ATM, GR-303 etc. were based on experiences with earlier technologies and for all intents and purposes, they have led to a clear set of standards that have been adopted widely. I don't know why you suggest that in general standards groups fail to advance single solutions. I maintain that having multiple solutions for the same problem comes at great cost to the industry. Developing multiple routing protocols may have been unavoidable, but the fact that every router now has to support both IS-IS and OSPF is inefficient from multiple perspectives. I think that the issues that are being discussed in the PPVPN WG (e.g. discovery and signaling)are not new. There are several existing protocols that can do the trick and the question is which ones are best suited to be used in L2 VPNs. In this particular case, I think that advancing multiple solutions will have more negative than positive consequences. In summary, I stick with my original point (but with different capitalization): a standards body SHOULD develop one solution as the standard. Peter < snipped > > Making decisions like this is just something that a standards > body is not capable of doing well. > > Ross > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 13 22:59:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08018 for ; Tue, 13 May 2003 22:59:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E32AY03198 for ; Tue, 13 May 2003 23:02:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4E327R19706 for ; Tue, 13 May 2003 23:02:07 -0400 (EDT) Message-Id: <200305140300.h4E30Ia27768@zcars0jk.ca.nortel.com> Subject: =?KOI8-R?Q?UREGNT ASSISTANCE NEEDED?= Content-type: text/plain;charset=koi8-r; Date: Wed, 14 May 2003 06:56 +0400 Mime-version: 1.0 X-sender-ip: 80.179.104.206 To: hamasalama@boxmail.biz From: =?KOI8-R?Q?Hama salama?= X-SMTP-HELO: mail.rin.ru X-SMTP-MAIL-FROM: hamasalama@boxmail.biz X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [195.161.112.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA08018 DEAR SIR, I received encouraging information about you; hence I decided to contact you. I am Gen. Hama Salama, Military Commander with POLISARIO (Political Front for the Liberation of Western Sahara) and a member of council of the National Secretariat of Western Sahara (Saharawi Democratic Republic), I was the second in command to the former military Commander. He was however killed in battle in early January. MY PURPOSE OF CONTACTING YOU: The struggle for liberation of the Saharawi people has enjoyed funding from private, religious and corporate organizations that recognize our struggle. They are the ones who assist/aid with funds and materials in prosecution of the war. Before the death of my former boss, we were given some funds (US$38,000,000.00Million) by international donors to procure ammunitions for POLISARIO. My boss deposited it with a private security company in Europe, because this was one of those incentives Political Front for the Liberation of Western Sahara get year in and year out. I came to realize that he intended to keep these particular funds for himself after a meeting we had in March last year. I quite agreed because I was promised a fraction of the goodies. But as fate may have it he died and I became the only man who has privilege to this information of this ca! sh deposit, and all it's relevant documents, as the new herds man. Now, I want to claim this funds knowing fully well that I have all the relating documents needed in my disposal, to collect the deposit; including the Certificate of Deposit with which the Cash was deposited as Precious stones, and also the Deposit Agreement. I therefore want you to team/partner up with me to collect the funds in Europe, as I require a foreigner to perfect the operation. Let me know your terms. I will provide all the necessary documentation needed to claim this funds. There are no risks involved as long as the transaction can be kept confidential, because someone else knowledge remain the only thing that can import any risk to this deal. I say it again; it is a simple and straight transaction but must be kept highly confidential. Upon the receipt of a positive response from you, I will give you further Details; outlining the method of operation, which has been mastered to pull this transaction through, soonest. Therefore, if you are interested, please do reach me via e-mail(isioma@rediffmail.com) I perfect a better communication means for this project. Let me reiterate it again, I will want everything about this transaction to be treated in strictest confidence even if you are not interested. I await your response. Yours Gen. Hama Salama. Military Commander Western Sahara From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 01:37:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10436 for ; Wed, 14 May 2003 01:37:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E5dZj02113 for ; Wed, 14 May 2003 01:39:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4E5dXJ24048 for ; Wed, 14 May 2003 01:39:33 -0400 (EDT) Message-ID: <3EC1D610.8040407@acm.org> Date: Wed, 14 May 2003 01:37:20 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: Cheng-Yin.Lee@alcatel.com CC: erosen@cisco.com, mick_seaman@ieee.org, "'Pedro Roque Marques'" , "'Himanshu Shah'" , "'Norman Finn'" , "'Muneyoshi Suzuki'" , "'Tony Jeffree'" , "'Les Bell'" , "'Paul Congdon'" , "'Neil Jarvis'" , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200305091459.h49ExKZC001931@rtp-core-1.cisco.com> <3EC0E878.6080607@acm.org> <3EC14AA5.A0444867@alcatel.com> In-Reply-To: <3EC14AA5.A0444867@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Cheng-Yin Lee wrote: > Mick, Matt, > > Mick Seaman wrote: > >>From the point of >>view of control connectivity the pseudo-wires have to establish a full mesh >>that is never perceived by layer 2 protocols as being less than complete. > > How can this "lower layer emulated LAN" (using full mesh split horizon) > be perceived by IEEE L2 as being _never_ less than complete? > One has to take precautions/measure to ensure that the virtual port to the emulated LAN is operationally down if there is an incomplete mesh for that emulated LAN. There are various ways this could be accomplished. > >>But ensuring the >>emulated and real technologies are transparent to the higher layer, one >>can build arbitrary networks based on traditional bridging models. I >>hope thats a good thing. > >>From the architecture point of view, it looks clean to make the lower > layer transparent and to mandate the lower layer should do its job > properly (in this case IEEE 802.1ad assumes PPVPN VPLS always provide a > properly emulated LAN, no configuration loops, connectivity issues, > etc). However, I do not know how loops in the forwarding paths can be > prevented, if a tree is concatenated/spliced with the lower layer > forwarding path (or another tree), unless all common nodes in the > forwarding path (both higher and lower layer) participate in one common > spanning tree or a similar algorithm to prevent forwarding loops. > I'm having a hard time parsing that last sentence. Loops in a VPLS are prevented with split horizon, and I'm not sure what tree is being spliced/concatenated with what. But emulated LAN segments would be bridged to other emulated or real LAN segments, and if the bridged topology is not a tree, then STP has to be used to reduce it to a tree. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 01:41:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10479 for ; Wed, 14 May 2003 01:41:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E5hbj06373 for ; Wed, 14 May 2003 01:43:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4E5hYJ28377 for ; Wed, 14 May 2003 01:43:34 -0400 (EDT) Message-ID: <3EC1D714.5080800@acm.org> Date: Wed, 14 May 2003 01:41:40 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: vkompella@timetra.com CC: Ross Callon , "Bilel Jamoussi" , ppvpn@nortelnetworks.com, "'Alex Zinin'" Subject: Re: WG split: why and how? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,jamoussi@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > > Can we reorganize our thoughts around solving the management issue > instead of whether Rick or Marco did a good job with ppvpn? What do we > lose or gain with either of the two suggestions above? > Ditto. Rick and Marco doing a good job shouldn't be the deciding factor in whether the technical work is best served with two WGs with distinct goals and objectives. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 01:52:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10593 for ; Wed, 14 May 2003 01:52:45 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E5tEj10627 for ; Wed, 14 May 2003 01:55:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4E5tBY07098 for ; Wed, 14 May 2003 01:55:11 -0400 (EDT) Message-ID: <3EC1D9B0.3050608@acm.org> Date: Wed, 14 May 2003 01:52:48 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: Alex Zinin CC: PPVPN@nortelnetworks.com, Eric Rosen Subject: Re: Draft charter for L3VPN: Internet transparency References: <200305121412.h4CECbrS029943@rtp-core-1.cisco.com> <4165115994.20030513104052@psg.com> In-Reply-To: <4165115994.20030513104052@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit >>I think this applies to all the schemes. Even the CE-based schemes aren't >>viable, in my opinion, over the public Internet because issues of QoS, SLA, >>and accountability really prevent a company from using the public Internet >>as the backbone for its intranet. > > > I understand your position. I'd like to see more opinions here. I'm missing the part where a VPN has to be used as the backbone of a companies Internet, or that QoS and SLAs are an absolute pre-requisite. I'm not saying the application is invalid, or that SLAs aren't good things, but connectivity can be provided for other applications and without an SLA, and its not a useless objective. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 02:08:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19010 for ; Wed, 14 May 2003 02:08:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E6AUj01703 for ; Wed, 14 May 2003 02:10:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4E6ARB11927 for ; Wed, 14 May 2003 02:10:27 -0400 (EDT) Message-ID: <3EC1DD50.7030904@acm.org> Date: Wed, 14 May 2003 02:08:16 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: Alex Zinin CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN References: <17184595822.20030507185340@psg.com> In-Reply-To: <17184595822.20030507185340@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > > This working group is responsible for defining and specifying a > limited number of solutions for supporting provider-provisioned > layer-2 virtual private networks (L2VPNs). > > The WG is responsible for standardization of the following solutions: > > 1. Virtual Private LAN Service--L2 service that emulates LAN > across an IP and an MPLS-enabled IP network. > > 2. Virtual Private Wire Service--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. > > The WG will address intra-AS scenarios only at this point (inter-AS > considerations will be considered for inclusion in the updated > charter when the current one is completed.) I'd like to include an objective that the VPLS services are transparent to higher layer protocols (e.g. really emulated a LAN). Maybe words like... " The WG will drive for solutions that are transparent to higher layer protocols such as 802.1D bridging and IP. Optimizations to a basic transparent architecture may be developed to foster more efficient transport in special cases (such as IP only transport). The WG will cooperate with IEEE 802.1 to ensure proper interworking of VPLS and VPWS solutions with traditional bridging networks. " > > As a general rule, the WG will not create new protocols, but will > provide functional requirements for extensions of the existing > protocols that will be discussed in the protocol-specific WGs. > As a specific example, this WG will not define new encapsulation > mechanism, but will use those defined in the PWE3 WG. > > The WG will work on the following items, adding new work items > will require rechartering: > > 1. Discovery of PEs participating in L2 service, and > topology of required connectivity > > 2. Signaling of psuedo-wire and service parameters > > 3. Solution documents (providing the framework for a specific > solution, should include info on how discovery, signaling, > and encaps work together, include security, AS as a separate > document,...) You mention discovery, signaling, and solutions. Should we mention data plane forwarding in #3? > > 4. MIBs > > 5. L2VPN-specific OAM extensions--extensions to existing OAM > solutions for VPLS and VPWS. > > Milestones (optimistic): > > JUL 2003 Submit L2 requirements to IESG for publication as Informational RFC > JUL 2003 Submit L2 framework to IESG for publication as Informational RFC > JUL 2003 Identify VPLS and VPWS solutions for the WG > AUG 2003 Submit an I-D describing MIB for VPLS > AUG 2003 Submit an I-D describing MIB for VPWS > AUG 2003 Submit an I-D on OAM for VPLS > AUG 2003 Submit an I-D on OAM for VPWS > DEC 2003 Submit VPLS solution documents to IESG > DEC 2003 Submit VPWS solution documents to IESG > JAN 2004 Submit MIB for VPLS to IESG > JAN 2004 Submit MIB for VPWS to IESG > MAR 2004 Submit OAM for VPLS to IESG > MAR 2004 Submit OAM for VPWS to IESG > > Seems strange to me that the VPLS solutions come AFTER the MIB and OAM. I would have thought it would go the other way, where we define the solution(s) first and the MIB and OAM follow from that. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 03:59:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08801 for ; Wed, 14 May 2003 03:59:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4E81bj22222 for ; Wed, 14 May 2003 04:01:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4E81Ys28501 for ; Wed, 14 May 2003 04:01:34 -0400 (EDT) Message-ID: <3EC1F74F.30734EFD@alcatel.be> Date: Wed, 14 May 2003 09:59:11 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin Cc: PPVPN@nortelnetworks.com, Eric Rosen Subject: Re: Draft charter for L3VPN: Internet transparency References: <200305121412.h4CECbrS029943@rtp-core-1.cisco.com> <4165115994.20030513104052@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/14/2003 09:59:12, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/14/2003 09:59:13, Serialize complete at 05/14/2003 09:59:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-SMTP-HELO: relay4.alcatel.be X-SMTP-MAIL-FROM: jeremy.de_clercq@alcatel.be X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: alc245.alcatel.be [195.207.101.245] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex, Eric, > > I think this applies to all the schemes. Even the CE-based schemes aren't > > viable, in my opinion, over the public Internet because issues of QoS, SLA, > > and accountability really prevent a company from using the public Internet > > as the backbone for its intranet. > > I understand your position. I'd like to see more opinions here. It is clear that using CE-based VPNs over the public Internet will have different QoS properties, different SLAs and different accounting frameworks. It's the applicability statement document's task to clearly formulate that. And it's the SLA that will also reflect this from a service perspective (a VPN scheme shouldn't promise what it can't accomplish). But I don't think this means that it's "not viable". Jeremy. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 07:23:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12893 for ; Wed, 14 May 2003 07:23:46 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EBQGj09648 for ; Wed, 14 May 2003 07:26:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EBQDd22187 for ; Wed, 14 May 2003 07:26:14 -0400 (EDT) Message-Id: <200305141120.HAA12775@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-bgpvpn-auto-05.txt Date: Wed, 14 May 2003 07:20:57 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Using BGP as an Auto-Discovery Mechanism for Provider-provisioned VPNs Author(s) : H. Ould-Brahim et al. Filename : draft-ietf-ppvpn-bgpvpn-auto-05.txt Pages : 12 Date : 2003-5-13 In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for both layer-2 VPN architectures and layer-3 VPNs ([VPN-VR]). This mechanism is based on the approach used by [RFC2547-bis] for distributing VPN routing information within the service provider(s). Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-bgpvpn-auto-05.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-ietf-ppvpn-bgpvpn-auto-05.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-ietf-ppvpn-bgpvpn-auto-05.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-5-13133505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-bgpvpn-auto-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-bgpvpn-auto-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-13133505.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 07:25:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12975 for ; Wed, 14 May 2003 07:25:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EBRsj11922 for ; Wed, 14 May 2003 07:27:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EBRpd24799 for ; Wed, 14 May 2003 07:27:52 -0400 (EDT) Subject: Re: Draft charter for L2VPN From: Giles Heron To: Alex Zinin Cc: PPVPN@nortelnetworks.com In-Reply-To: <45165142272.20030513104118@psg.com> References: <200305121643.h4CGhvu56061@merlot.juniper.net> <45165142272.20030513104118@psg.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 May 2003 12:20:21 +0000 Message-Id: <1052914821.1575.48.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On Tue, 2003-05-13 at 17:41, Alex Zinin wrote: [snip] > Monday, May 12, 2003, 10:34:16 AM, Eric Rosen wrote: > > Two L2VPN charter issues that come up frequently are (a) whether ARP > > Mediation (for allowing IP traffic on a p2p link between two unlike > > attachment circuits) falls into the charter, and (b) whether IPLS (for > > allowing LAN-like connectivity among a set of IP routers, without requiring > > MAC learning, BPDUs, etc.) falls into the charter. If there is actually > > going to be an L2VPN charter, I'd like to see this settled, preferably in > > favor of including these efforts. > > I'd like to see more opinions on this. I'd like to see ARP mediation (or an equivalent means of supporting unlike attachment circuits) and IPLS being progressed in L2VPN. Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 10:32:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20165 for ; Wed, 14 May 2003 10:32:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EEZNj21151 for ; Wed, 14 May 2003 10:35:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EEZKC21210 for ; Wed, 14 May 2003 10:35:20 -0400 (EDT) Message-Id: <200305141432.h4EEWunt016683@rtp-core-1.cisco.com> To: Mark Duffy cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: Internet transparency In-reply-to: Your message of Tue, 13 May 2003 15:51:27 -0400. <5.2.0.9.0.20030513151912.00b11ed0@email> 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, 14 May 2003 10:32:56 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Mark> Yes, QOS and SLA are issues, but folks have been deploying CE-based Mark> VPNs on the Internet for years; evidently they don't consider these a Mark> show-stopper. If a provider came to you and said, "for a lot of money, I will provision and manage your enterprise backbone; however, you will not be able to hold me accountable for the service", would you buy it? Sounds like a good business if you can get it! Provider-provisioned L3VPNs are meant to compete with ATM and Frame Relay services backbone services. User-provisioned CE-based VPNS such as IPsec tunnels from a residence to a corporate backbone compete with dialup services. Mark> Should the charter REQUIRE solutions to be viable across the Internet? Mark> No. Should it encourage development of 1 or more solutions that are Mark> viable across the Internet? Yes. I wouldn't really disagree, but I wouldn't want to be the one developing a solution which is really viable across the Internet. Matt> I'm missing the part where a VPN has to be used as the backbone of a Matt> companies Internet, "Intranet." That's really the target of L3VPN and VPWS schemes, else you'd just do everything in a hub and spoke manner. (I'm not as sure what the target of VPLS is.) Matt> or that QoS and SLAs are an absolute pre-requisite. Well, I'd like to see VPLS working over arbitrary paths across the public Internet, where all you know is you have a best effort datagram service with no accountability for problems! From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 10:42:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20377 for ; Wed, 14 May 2003 10:42:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EEj8j26363 for ; Wed, 14 May 2003 10:45:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EEj5I03835 for ; Wed, 14 May 2003 10:45:05 -0400 (EDT) Message-Id: <200305141437.h4EEaunt017939@rtp-core-1.cisco.com> To: mattsquire@acm.org cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-reply-to: Your message of Wed, 14 May 2003 02:08:16 -0400. <3EC1DD50.7030904@acm.org> 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, 14 May 2003 10:36:55 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Matt> I'd like to include an objective that the VPLS services are Matt> transparent to higher layer protocols (e.g. really emulated a LAN) I would be opposed to this as a charter requirement. This kind of requirement can easily get you into a situation in which you end up doing 90% of the work to handle a 1% problem. Given a particular solution which doesn't quite meet this requirement, the WG should be able to decide whether the solution comes close enough or not; this shouldn't be predetermined by the charter. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 10:49:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20488 for ; Wed, 14 May 2003 10:49:45 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EEqGj00952 for ; Wed, 14 May 2003 10:52:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EEqDI17118 for ; Wed, 14 May 2003 10:52:13 -0400 (EDT) Message-Id: <4.3.2.20030514101405.027e0808@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 14 May 2003 10:47:07 -0400 To: "Busschbach, Peter B (Peter)" From: Ross Callon Subject: RE: Single vs many solution(s) (LONG reply) Cc: PPVPN@nortelnetworks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: rcallon@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: At 08:31 PM 5/13/2003 -0400, Busschbach, Peter B (Peter) wrote: >... >I think there is a difference between new, unproven technologies - like IP routing protocols in the eigthies and the various wireless protocols more recently - and more mature technologies. IP routing protocols in the mid 80's were in fact pretty well understood. The problem was that a large political group which was primarily composed of people who had a less than thorough understanding of routing was making the decision. >... >In summary, I stick with my original point (but with different capitalization): a standards body SHOULD develop one solution as the standard. > >Peter At this point I think that we know that both of the VPLS proposals would work, with some level of administrative effort. I don't think that we have a complete understanding of the relative administrative effort required. I could certainly live with a solution in which both proposals are progressed as Experimental, with the understanding that in two or three years we will look and see how widely deployed each proposal is, and what the operational experience is. In a few years we could then progress each proposal if it has positive operational experience and also lets say at least about 30% of the overall market (meaning that if both proposals work well and are widely deployed we might progress both to Standard status, but if one gets the overwhelming % of the overall market then only it would be progressed as a full standard). Ross From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 11:09:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21004 for ; Wed, 14 May 2003 11:09:41 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EFCBj27457 for ; Wed, 14 May 2003 11:12:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EFC8800542 for ; Wed, 14 May 2003 11:12:08 -0400 (EDT) Message-Id: <200305141507.h4EF7Hnt029064@rtp-core-1.cisco.com> To: Cheng-Yin.Lee@alcatel.com cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Info aggregation In-reply-to: Your message of Tue, 13 May 2003 15:54:42 -0400. <3EC14D82.AAFA2D9B@alcatel.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: Wed, 14 May 2003 11:07:16 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Cheng-Yin> Are the proponents of these models considering loop prevention Cheng-Yin> measures? Once the PWs are properly set up according to the provisioned hierarchy, split horizon prevents loops. Perhaps you are asking whether the auto-discovery process can be guaranteed to provide the information needed to set up a cycle-free hierarchy, even in the presence of provisioning errors. With BGP-based auto-discovery, this could be an issue if the pws needed to go through an arbitrary set of ASes, each of which summarizes information from its neighbors before passing it on. If we wanted to support a model like that, we could use AS-path to prevent loops. But I'm not at all sure that that would be useful, as I don't think we want the VPLS pws to travel through arbitrary sets of ASes. Eric> Both models bound the number of signaling inter-AS connections, so Eric> that the number of these connections does not grow as the number of Eric> PEs grows. The hierarchical model limits some of the signaling Eric> information to the hierarchy boundaries. Cheng-Yin> I think this is limiting distribution of L2VPN info to a smaller Cheng-Yin> number of devices I don't think so, when you impose hierarchy or add inter-AS gateways you are explicitly distributing the info to more devices, in order to bound the amount of something or other that each device must deal with. Cheng-Yin> How to aggregate VPLS membership ID, VPLS_ID/VPN_ID ? (cf IP Cheng-Yin> addresses/routes can be aggregated). VPN ids obviously cannot be aggregated. Probably the best we can do is make the inter-AS discovery process scale linearly with the number of inter-AS VPLSes. But I don't really think the discovery process is going to be the bottleneck here. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 12:27:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25393 for ; Wed, 14 May 2003 12:27:02 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EGTYj22547 for ; Wed, 14 May 2003 12:29:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EGTW722950 for ; Wed, 14 May 2003 12:29:32 -0400 (EDT) Message-ID: From: "Moranganti, Ashwin" To: PPVPN@nortelnetworks.com Subject: RE: Draft charter for L2VPN Date: Wed, 14 May 2003 10:00:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: smtp2.adc.com X-SMTP-MAIL-FROM: Ashwin.Moranganti@adc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: smtp2.adc.com [155.226.10.211] X-LYRIS-Message-Id: I would also like to extend my support for the inclusion of the "Arp Mediation" and "IPLS drafts". Ashwin -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Monday, May 12, 2003 1:34 PM To: Alex Zinin Cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN Two L2VPN charter issues that come up frequently are (a) whether ARP Mediation (for allowing IP traffic on a p2p link between two unlike attachment circuits) falls into the charter, and (b) whether IPLS (for allowing LAN-like connectivity among a set of IP routers, without requiring MAC learning, BPDUs, etc.) falls into the charter. If there is actually going to be an L2VPN charter, I'd like to see this settled, preferably in favor of including these efforts. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 13:16:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27881 for ; Wed, 14 May 2003 13:16:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EHJDj13874 for ; Wed, 14 May 2003 13:19:13 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EHJAH07085 for ; Wed, 14 May 2003 13:19:10 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF05C2D8C4@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: jeremy.de_clercq@alcatel.be, Alex Zinin Cc: PPVPN@nortelnetworks.com, Eric Rosen Subject: RE: Draft charter for L3VPN: Internet transparency Date: Wed, 14 May 2003 13:14:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31A3C.3DDEA14A" X-LYRIS-Message-Id: 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_01C31A3C.3DDEA14A Content-Type: text/plain I definitely have to agree with Jeremy (and Mark Duffy) here: CE-based IPsec VPNs are not only viable, but there are hundreds, if not thousands, of sizable examples. Currently, these are mostly user-managed, but the provider-provisioned numbers are growing faster. These are NOT simply residence-to-backbone replacements for dial-up, but are often replacing frame relay, ATM, and leased lines between sites of all sizes, across the enterprise. Enterprises of all sizes are installing CE-based IPsec VPNs. While it's clear that QOS and SLAs will typically not be guaranteed, several years of experience shows that adequate sizing of the access link (site to ISP) usually gives perfectly acceptable performance. Traffic prioritization at the VPN gateway device and high encryption rates help ensure that even delay-sensitive traffic performs acceptably. I don't really understand how the "viability" can be questioned, unless we envision a future where the Internet no longer provides reasonable performance for best-effort traffic. Regards, Paul > -----Original Message----- > From: jeremy.de_clercq@alcatel.be > [mailto:jeremy.de_clercq@alcatel.be] > Sent: Wednesday, May 14, 2003 3:59 AM > To: Alex Zinin > Cc: PPVPN@nortelnetworks.com; Eric Rosen > Subject: Re: Draft charter for L3VPN: Internet transparency > > > Alex, Eric, > > > > I think this applies to all the schemes. Even the CE-based > > > schemes aren't viable, in my opinion, over the public Internet > > > because issues of QoS, SLA, and accountability really prevent a > > > company from using the public Internet as the backbone for its > > > intranet. > > > > I understand your position. I'd like to see more opinions here. > > It is clear that using CE-based VPNs over the public Internet > will have different QoS properties, different SLAs and > different accounting frameworks. It's the applicability > statement document's task to clearly formulate that. And it's > the SLA that will also reflect this from a service > perspective (a VPN scheme shouldn't promise what it can't > accomplish). But I don't think this means that it's "not viable". > > Jeremy. > > ------_=_NextPart_001_01C31A3C.3DDEA14A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft charter for L3VPN: Internet transparency

I definitely have to agree with Jeremy (and Mark = Duffy) here:

CE-based IPsec VPNs are not only viable, but there = are hundreds, if not thousands, of sizable examples.  Currently, = these are mostly user-managed, but the provider-provisioned numbers are = growing faster.

These are NOT simply residence-to-backbone = replacements for dial-up, but are often replacing frame relay, ATM, and = leased lines between sites of all sizes, across the enterprise.  = Enterprises of all sizes are installing CE-based IPsec VPNs.

While it's clear that QOS and SLAs will typically not = be guaranteed, several years of experience shows that adequate sizing = of the access link (site to ISP) usually gives perfectly acceptable = performance.  Traffic prioritization at the VPN gateway device and = high encryption rates help ensure that even delay-sensitive traffic = performs acceptably. 

I don't really understand how the = "viability" can be questioned, unless we envision a future = where the Internet no longer provides reasonable performance for = best-effort traffic.

Regards,
Paul

> -----Original Message-----
> From: jeremy.de_clercq@alcatel.be
> [mailto:jeremy.de_clercq@alca= tel.be]
> Sent: Wednesday, May 14, 2003 3:59 AM
> To: Alex Zinin
> Cc: PPVPN@nortelnetworks.com; Eric Rosen
> Subject: Re: Draft charter for L3VPN: Internet = transparency
>
>
> Alex, Eric,
>
> > > I think this  applies to all the = schemes.  Even  the CE-based
> > > schemes aren't viable, in my opinion, = over the  public Internet
> > > because issues of QoS, SLA, and = accountability really  prevent a
> > > company from using  the public = Internet as the backbone for its
> > > intranet.
> >
> > I understand your position. I'd like to = see more opinions here.
>
> It is clear that using CE-based VPNs over the = public Internet
> will have different QoS properties, different = SLAs and
> different accounting frameworks. It's the = applicability
> statement document's task to clearly formulate = that. And it's
> the SLA that will also reflect this from a = service
> perspective (a VPN scheme shouldn't promise = what it can't
> accomplish). But I don't think this means that = it's "not viable".
>
> Jeremy.
>
>

------_=_NextPart_001_01C31A3C.3DDEA14A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 15:26:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02424 for ; Wed, 14 May 2003 15:26:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EJSxj19340 for ; Wed, 14 May 2003 15:29:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EJSuY25920 for ; Wed, 14 May 2003 15:28:56 -0400 (EDT) Message-ID: <3EC2982D.6020105@acm.org> Date: Wed, 14 May 2003 15:25:33 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: erosen@cisco.com CC: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN References: <200305141437.h4EEaunt017939@rtp-core-1.cisco.com> In-Reply-To: <200305141437.h4EEaunt017939@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric Rosen wrote: > Matt> I'd like to include an objective that the VPLS services are > Matt> transparent to higher layer protocols (e.g. really emulated a LAN) > > I would be opposed to this as a charter requirement. This kind of > requirement can easily get you into a situation in which you end up doing > 90% of the work to handle a 1% problem. Given a particular solution which > doesn't quite meet this requirement, the WG should be able to decide whether > the solution comes close enough or not; this shouldn't be predetermined by > the charter. > If this requirement is not met, then we're not really providing a virtual X service (X=FR, X=Ethernet, etc.). If the group is chartered to define new service types, and I'm not saying it can't be, thats fine. But a virtual Ethernet wire that requires applications to be aware of the virualness of the wire has a high cost of entry. I'm also not saying that the IPLS isn't applicable. I had a sentence in there that said optimizations for specific applications are allowed. And thats what IPLS is - its an optimization of VPLS for IP-only LANs. Note its not really a virtual L2 service as there is no "real" service that its virtualizing, but it can be useful. People made IP-only ATM LAN implementation doing the same thing, so its been done before and has utility. But the base constructs have to have a goal of transparency. I can't see how we can charter a work effort where the core development is to develop virtual services (wire, LAN) that don't have an equivalent "real" counterpart. That opens up the door for anything - e.g. it would be within the charter to create a virtual Ethernet LAN that uses source route bridging. If we view VPLS as the base construct, and IPLS as an optimization, then I see how it fits. Otherwise, IPLS on its own seems like a new thing. There is not "IP only Ethernet" standard, yet its what the document attempts to create. Again, I'm not against IPLS by any means. But transparency is a very useful objective, even if you want to violate it on occassion improve efficiency under certain restrictions. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 15:30:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02547 for ; Wed, 14 May 2003 15:30:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EJWdj23044 for ; Wed, 14 May 2003 15:32:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EJWZw02138 for ; Wed, 14 May 2003 15:32:36 -0400 (EDT) Message-ID: <3EC294E2.6030807@acm.org> Date: Wed, 14 May 2003 15:11:30 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: erosen@cisco.com CC: Mark Duffy , Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: Internet transparency References: <200305141432.h4EEWunt016683@rtp-core-1.cisco.com> In-Reply-To: <200305141432.h4EEWunt016683@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > Matt> I'm missing the part where a VPN has to be used as the backbone of a > Matt> companies Internet, > > "Intranet." That's really the target of L3VPN and VPWS schemes, else > you'd just do everything in a hub and spoke manner. (I'm not as sure what > the target of VPLS is.) I think they're also being targeted for the access space. E.g. remote sites accessing a core network, where the virtual network is not a core application but an access appllication. > > Matt> or that QoS and SLAs are an absolute pre-requisite. > > Well, I'd like to see VPLS working over arbitrary paths across the public > Internet, where all you know is you have a best effort datagram service with > no accountability for problems! > > People by best-effort services all the time. They pay less for them of course, but best-effort service isn't uncommon. I know you have a particular application in mind and therefore the requirements you put forth make sense for that application. But the technology can and should be applicable to other deployment scenarios and applications. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 15:50:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03235 for ; Wed, 14 May 2003 15:50:43 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EJrEj29641 for ; Wed, 14 May 2003 15:53:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EJrAb22978 for ; Wed, 14 May 2003 15:53:11 -0400 (EDT) X-Server-Uuid: 10D0A2A9-F440-43BF-99A9-027523D2618D Subject: RE: Draft charter for L2VPN To: PPVPN@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: william.a.bjorkman@verizon.com Date: Wed, 14 May 2003 15:40:31 -0400 X-MIMETrack: Serialize by Router on FHSMTP01/NYNEX(Release 5.0.9a |January 7, 2002) at 05/14/2003 03:40:35 PM MIME-Version: 1.0 X-WSS-ID: 12DC44391346572-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tpamail2.bdi.gte.com X-SMTP-MAIL-FROM: william.a.bjorkman@verizon.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: tpamail2.bdi.gte.com [192.76.82.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit yes...definitely include both... /bb -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Monday, May 12, 2003 1:34 PM To: Alex Zinin Cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN Two L2VPN charter issues that come up frequently are (a) whether ARP Mediation (for allowing IP traffic on a p2p link between two unlike attachment circuits) falls into the charter, and (b) whether IPLS (for allowing LAN-like connectivity among a set of IP routers, without requiring MAC learning, BPDUs, etc.) falls into the charter. If there is actually going to be an L2VPN charter, I'd like to see this settled, preferably in favor of including these efforts. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 16:36:58 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04511 for ; Wed, 14 May 2003 16:36:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EKdTj26133 for ; Wed, 14 May 2003 16:39:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EKdP628291 for ; Wed, 14 May 2003 16:39:25 -0400 (EDT) Message-Id: <200305142035.h4EKZtuT010143@rtp-core-1.cisco.com> To: mattsquire@acm.org cc: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-reply-to: Your message of Wed, 14 May 2003 15:25:33 -0400. <3EC2982D.6020105@acm.org> 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, 14 May 2003 16:35:55 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: The issue of what constitutes a virtual service arose when PWE3 was chartered. The PWE3 charter states: PWE3 will not strive for pseudo wires to perfectly emulate the characteristics of the native service. For each type of pseudo wire, an applicability statement will describe the degree of similarity of a pseudo wire to the native service it emulates. The same should apply to VPLS. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 17:06:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05584 for ; Wed, 14 May 2003 17:06:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EL8bj12737 for ; Wed, 14 May 2003 17:08:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4EL8Yn05544 for ; Wed, 14 May 2003 17:08:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030514134158.01deb008@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 May 2003 13:56:18 -0700 To: , From: Ali Sajassi Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation In-Reply-To: References: <45165142272.20030513104118@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: >I'd like to see the work in this area - IPLS & ARP Mediation -progressed and >documented in a published RFC. They are not the most widely deployed cases, >but they do exist and have real network applications. Steven, Does Bell South plan to offer VPLS ? If it plans to offer it, then there should be no need for IPLS because VPLS can be considered as a super-set since it covers both switches and routers as CEs and it supports both IP and non-IP traffic. Also inter-operability between IPLS and VPLS is another thing to consider if you plan to offer both !! However, if Bell South plans to offer IPLS in lieu of VPLS and assumes that all the end-points for a transparent LAN service are IPs, then that's a different story. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 17:30:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06390 for ; Wed, 14 May 2003 17:30:14 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4ELWjj18321 for ; Wed, 14 May 2003 17:32:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4ELWgY21642 for ; Wed, 14 May 2003 17:32:42 -0400 (EDT) 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: Wed, 14 May 2003 17:29:20 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB7202150094@WHISTLER.WaveSmithNet.com> Thread-Topic: Draft charter for L2VPN - IPLS & ARP Mediation Thread-Index: AcMaXRMKEjgolk+8Q6aUI5yXZ7ZuMwAAPLrA From: "Himanshu Shah" To: "Ali Sajassi" , , X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA06390 That is like asking for every draft that Cisco employee has contributed whether Cisco is planning to implement it? IETF operates on individual contributions and opinions. /himanshu > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Wednesday, May 14, 2003 4:56 PM > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > -progressed and > >documented in a published RFC. They are not the most widely > deployed cases, > >but they do exist and have real network applications. > > Steven, > > Does Bell South plan to offer VPLS ? If it plans to offer it, > then there > should be no need for IPLS because VPLS can be considered as > a super-set > since it covers both switches and routers as CEs and it > supports both IP > and non-IP traffic. Also inter-operability between IPLS and > VPLS is another > thing to consider if you plan to offer both !! However, if > Bell South plans > to offer IPLS in lieu of VPLS and assumes that all the > end-points for a > transparent LAN service are IPs, then that's a different story. > > -Ali > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 20:25:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10965 for ; Wed, 14 May 2003 20:25:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4F0SMM14076 for ; Wed, 14 May 2003 20:28:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4F0SJu03009 for ; Wed, 14 May 2003 20:28:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 May 2003 17:26:23 -0700 To: "Himanshu Shah" , "Ali Sajassi" , , From: Ali Sajassi Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB7202150094@WHISTLER.WaveSmit hNet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Why am I not surprised to hear from you first :-) My questions was directed to the providers and I'd like to know which providers are considering to offer IPLS and get some feedback from them: How many are considering to offer IPLS in lieu of VPLS ? and How many are considering to offer both IPLS and VPLS ? -Ali At 05:29 PM 5/14/2003 -0400, Himanshu Shah wrote: >That is like asking for every draft that >Cisco employee has contributed whether Cisco >is planning to implement it? > >IETF operates on individual contributions >and opinions. > >/himanshu > > > -----Original Message----- > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > Sent: Wednesday, May 14, 2003 4:56 PM > > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > > -progressed and > > >documented in a published RFC. They are not the most widely > > deployed cases, > > >but they do exist and have real network applications. > > > > Steven, > > > > Does Bell South plan to offer VPLS ? If it plans to offer it, > > then there > > should be no need for IPLS because VPLS can be considered as > > a super-set > > since it covers both switches and routers as CEs and it > > supports both IP > > and non-IP traffic. Also inter-operability between IPLS and > > VPLS is another > > thing to consider if you plan to offer both !! However, if > > Bell South plans > > to offer IPLS in lieu of VPLS and assumes that all the > > end-points for a > > transparent LAN service are IPs, then that's a different story. > > > > -Ali > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 21:45:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12283 for ; Wed, 14 May 2003 21:45:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4F1ldM17808 for ; Wed, 14 May 2003 21:47:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4F1lab11406 for ; Wed, 14 May 2003 21:47:36 -0400 (EDT) Date: Thu, 15 May 2003 10:45:23 +0900 (JST) Message-Id: <20030515.104523.130226272.suzuki.muneyoshi@lab.ntt.co.jp> To: mattsquire@acm.org, erosen@cisco.com, zinin@psg.com, PPVPN@nortelnetworks.com Cc: suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Draft charter for L2VPN From: Muneyoshi Suzuki In-Reply-To: <3EC2982D.6020105@acm.org> References: <200305141437.h4EEaunt017939@rtp-core-1.cisco.com> <3EC2982D.6020105@acm.org> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > > Matt> I'd like to include an objective that the VPLS services are > > Matt> transparent to higher layer protocols (e.g. really emulated a LAN) > > I would be opposed to this as a charter requirement. This kind of > > requirement can easily get you into a situation in which you end up doing > > 90% of the work to handle a 1% problem. Given a particular solution which > > doesn't quite meet this requirement,the WG should be able to decide whether > > the solution comes close enough or not; this shouldn't be predetermined by > > the charter. > If this requirement is not met, then we're not really providing a > virtual X service (X=FR, X=Ethernet, etc.). If the group is chartered > to define new service types, and I'm not saying it can't be, thats fine. > But a virtual Ethernet wire that requires applications to be aware of > the virualness of the wire has a high cost of entry. I agree with Matt. I think the solution(s) doesn't need to perfectly conform with the original technology. However, it must not violate the standards for interworking with existing implementations. And it must be robust and must not cause fatal problems such as loop, blackhole, and flaky PEs. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 14 22:21:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12851 for ; Wed, 14 May 2003 22:21:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4F2NZM07767 for ; Wed, 14 May 2003 22:23:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4F2NWh17363 for ; Wed, 14 May 2003 22:23:32 -0400 (EDT) Date: Wed, 14 May 2003 19:18:18 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <131282562233.20030514191818@psg.com> To: "'PPVPN@nortelnetworks.com'" Subject: Re: Draft charter for L3VPN In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E606623F8B@zcard0ke.ca.nortel.com> References: <0D7FC1D8D861D511AEA70002A52CE5E606623F8B@zcard0ke.ca.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Tuesday, May 13, 2003, 11:13:17 AM, Bilel Jamoussi wrote: > Alex, not sure what you mean by "L2 or L3"? L2vpn or L3Vpn proposed WG charters. Tuesday, May 13, 2003, 3:00:08 PM, Hamid Ould-Brahim wrote: >> Because I wanted to hear opinions on where it should go: L2 or L3, > Unfortunately, it's neither L2 or L3, it's L2+L3. It's about which WG it would be "hosted" in. > I really think > (if wg split happens), that the new re-org needs to leave room > for potential l2+l3 work/common mechanisms. Noted. >> and whether it should be in the first set of documents a specific >> WG should work on or not. > Not sure I understand that part. It is already a working group > document. Indeed, and that part is not changed (i.e., we should not revisit that decision). It is about when the WG should do the LC and submit it to the IESG, i.e. a mere planning issue. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 01:47:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16155 for ; Thu, 15 May 2003 01:47:48 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4F5oJI14293 for ; Thu, 15 May 2003 01:50:19 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4F5oGX20862 for ; Thu, 15 May 2003 01:50:16 -0400 (EDT) Message-ID: <7160873.1052977705009.JavaMail.nobody@wamui05.slb.atl.earthlink.net> Date: Thu, 15 May 2003 01:48:24 -0400 (GMT) From: Matt Squire To: erosen@cisco.com, mattsquire@acm.org Subject: Re: Re: Draft charter for L2VPN Cc: Alex Zinin , PPVPN@nortelnetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Web Access Mail version 3.0 X-SMTP-HELO: blount.mail.mindspring.net X-SMTP-MAIL-FROM: msquire@mindspring.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: blount.mail.mindspring.net [207.69.200.226] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit -------Original Message------- From: Eric Rosen Sent: 05/14/03 04:35 PM To: mattsquire@acm.org Subject: Re: Draft charter for L2VPN > > The issue of what constitutes a virtual service arose when PWE3 was chartered. The PWE3 charter states: PWE3 will not strive for pseudo wires to perfectly emulate the characteristics of the native service. For each type of pseudo wire, an applicability statement will describe the degree of similarity of a pseudo wire to the native service it emulates. The same should apply to VPLS. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 06:01:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02207 for ; Thu, 15 May 2003 06:01:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FA3lI20840 for ; Thu, 15 May 2003 06:03:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FA3iB02837 for ; Thu, 15 May 2003 06:03:44 -0400 (EDT) Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation From: Giles Heron To: Ali Sajassi Cc: Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com In-Reply-To: <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> References: <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 May 2003 10:57:57 +0000 Message-Id: <1052996277.1688.31.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit OK, I'll bite ;-) personally I'd rather deploy IPLS than VPLS given the choice, though I accept that some of our customers may demand VPLS. IPLS meets the requirement for which I originally envisaged VPLS being useful (i.e. interconnecting IP routers or hosts) and does this more efficiently than VPLS. I would be reluctant to use VPLS to interconnect switches, as that exposes the SP to the customer network's MAC addresses, but I can see why this might be attractive to customers in the metropolitan area at least. However in terms of what we'll offer it depends to an extent on what vendors provide. I'm not aware of anyone shipping IPLS code yet... Giles On Thu, 2003-05-15 at 00:26, Ali Sajassi wrote: > > Why am I not surprised to hear from you first :-) > My questions was directed to the providers and I'd like to know which > providers are considering to offer IPLS and get some feedback from them: > > How many are considering to offer IPLS in lieu of VPLS ? and > How many are considering to offer both IPLS and VPLS ? > > -Ali > > At 05:29 PM 5/14/2003 -0400, Himanshu Shah wrote: > >That is like asking for every draft that > >Cisco employee has contributed whether Cisco > >is planning to implement it? > > > >IETF operates on individual contributions > >and opinions. > > > >/himanshu > > > > > -----Original Message----- > > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > > Sent: Wednesday, May 14, 2003 4:56 PM > > > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > > > -progressed and > > > >documented in a published RFC. They are not the most widely > > > deployed cases, > > > >but they do exist and have real network applications. > > > > > > Steven, > > > > > > Does Bell South plan to offer VPLS ? If it plans to offer it, > > > then there > > > should be no need for IPLS because VPLS can be considered as > > > a super-set > > > since it covers both switches and routers as CEs and it > > > supports both IP > > > and non-IP traffic. Also inter-operability between IPLS and > > > VPLS is another > > > thing to consider if you plan to offer both !! However, if > > > Bell South plans > > > to offer IPLS in lieu of VPLS and assumes that all the > > > end-points for a > > > transparent LAN service are IPs, then that's a different story. > > > > > > -Ali > > > > > > > > > > > > > > > > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 07:48:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04726 for ; Thu, 15 May 2003 07:48:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FBp2I18160 for ; Thu, 15 May 2003 07:51:02 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FBoxD20056 for ; Thu, 15 May 2003 07:50:59 -0400 (EDT) Date: Thu, 15 May 2003 17:14:15 +0530 From: Manav Bhatia Subject: Re: IS-IS as PE/CE routing protocol in BGP/MPLS/VPN To: lidefeng Cc: ppvpn@nortelnetworks.com, isis-wg@ietf.org Reply-to: Manav Bhatia Message-id: <048801c31ad7$51225080$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000c01c3190b$1418a540$07436e0a@HUAWEI.COM> X-SMTP-HELO: mailout3.samsung.com X-SMTP-MAIL-FROM: manav@samsung.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: u33.gpu114.samsung.co.kr [203.254.224.33] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Lidefeng, Just a general observation: - Whenever a PE router receives a MP-BGP UPDATE, it must execute the BGP Decision Process to decide the best path to the prefix contained in the UPDATE. When this decision process completes, the *best* route is passed onto the IS-IS selection process for import into any relevant VRFs. Because multiple UPDATEs for the same prefix might be received, and because IS-IS has its own selection process for differing metric types, the BGP Decision Process IMHO should be modified to prefer routes with internal metrics over the routes with external metrics. The Decision process will be based on the ISIS metric type that will be conveyed within the IS-IS Route Type Extended Community Attribute that accompanies the ISIS VPN-IPv4 route. There seems to be no mention of this in the draft. - Is there a reason why you're not sending any metrics (wide/narrow) info in the extended community? Regards, Manav ----- Original Message ----- From: "lidefeng" To: Cc: ; Sent: Tuesday, May 13, 2003 10:19 AM Subject: [Isis-wg] A new draft,IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > Hi,all, > > In deploying BGP/MPLS VPN,there are sites that CE run IS-IS protocol with > PE,and the corresponding customer is reluctant to change the routing > protocol they used in the sites,to accomodate this situation, it is better > to run isis protocol between PE and CE,however,ther isn't any draft to > specify the scenario in the BGP MPLS VPN. This draft addresses this > scenario,the abstract is as following: > > IS-IS protocol, which is specified in [1], can be used as IGP between > the Customer Edge (CE) router and the Provider Edge (PE) router in > BGP/MPLS VPNs as per [1]. This document provides a detailed solution > for IS-IS working as PE/CE Protocol in VPN services specified in [1]. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 08:43:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07144 for ; Thu, 15 May 2003 08:43:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FCk2I12323 for ; Thu, 15 May 2003 08:46:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FCk0w03364 for ; Thu, 15 May 2003 08:46:00 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , "'PPVPN@nortelnetworks.com'" Subject: RE: Draft charter for L3VPN Date: Thu, 15 May 2003 08:43:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31ADF.A2416FD4" X-LYRIS-Message-Id: 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_01C31ADF.A2416FD4 Content-Type: text/plain; charset="iso-8859-1" Alex, > > Tuesday, May 13, 2003, 3:00:08 PM, Hamid Ould-Brahim wrote: > >> Because I wanted to hear opinions on where it should go: L2 or L3, > > Unfortunately, it's neither L2 or L3, it's L2+L3. > > It's about which WG it would be "hosted" in. > > > I really think > > (if wg split happens), that the new re-org needs to leave room > > for potential l2+l3 work/common mechanisms. > > Noted. > I meant ideally the draft will be hosted in the same WG where l2+l3 work is captured. To answer your specific question, I don't have strong opinion although it looks logical to put it with l2vpn wg (if there is any change, it will be on l2vpn stuff). > >> and whether it should be in the first set of documents a specific > >> WG should work on or not. > > Not sure I understand that part. It is already a working group > > document. > > Indeed, and that part is not changed (i.e., we should not revisit > that decision). It is about when the WG should do the LC and submit > it to the IESG, i.e. a mere planning issue. > I don't have strong opinion on that as well. The draft is stable in terms of changes (at least for now). I will say if it is hosted in l2vpn charter, maybe LC and submission can be done while solutions are submitted. If it is in l3vpn wg then submission can be done with vr/l3vpn submission. If I use the dates provided, Dec 03 is an example..In fact I see no objection as well if it is done before this date. Hamid. ------_=_NextPart_001_01C31ADF.A2416FD4 Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L3VPN

Alex,

>
> Tuesday, May 13, 2003, 3:00:08 PM, Hamid Ould-Brahim wrote:
> >> Because I wanted to hear opinions on where it should go: L2 or L3,
> > Unfortunately, it's neither L2 or L3, it's L2+L3.
>
> It's about which WG it would be "hosted" in.
>
> > I really think
> > (if wg split happens), that the new re-org needs to leave room
> > for potential l2+l3 work/common mechanisms.
>
> Noted.
>

I meant ideally the draft will be hosted in the same WG where
l2+l3 work is captured. To answer your specific question, I don't
have strong opinion although it looks logical to put it with
l2vpn wg (if there is any change, it will be on l2vpn stuff).

> >> and whether it should be in the first set of documents a specific
> >> WG should work on or not.
> > Not sure I understand that part. It is already a working group
> > document.
>
> Indeed, and that part is not changed (i.e., we should not revisit
> that decision). It is about when the WG should do the LC and submit
> it to the IESG, i.e. a mere planning issue.
>

I don't have strong  opinion on that as well.
The draft is stable in terms of changes (at least for now).
I will say if it is hosted in l2vpn charter, maybe LC and
submission can be done while solutions are submitted. If it
is in l3vpn wg then submission can be done with vr/l3vpn
submission. If I use the dates provided, Dec 03 is
an example..In fact I see no objection as well if it is
done before this date.

Hamid.

------_=_NextPart_001_01C31ADF.A2416FD4-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 08:46:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07232 for ; Thu, 15 May 2003 08:46:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FCmWI16225 for ; Thu, 15 May 2003 08:48:33 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FCmUw07516 for ; Thu, 15 May 2003 08:48:30 -0400 (EDT) Date: Thu, 15 May 2003 01:03:23 -0700 (PDT) From: adams efe Subject: SOLICITING To: adamsefe@zapo.net Message-id: <7566865.1052985803418.JavaMail.adamsefe10@gomailjtp01> MIME-version: 1.0 X-Mailer: GoMail 3.0.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-SMTP-HELO: webmailmta.go.com X-SMTP-MAIL-FROM: adamsefe10@go.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [199.181.134.23] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Dr.Adams Efe Head, Banking Operations, Pacific International Bank Plc. 40 Marina, Lagos, Nigeria. Sir. CONFIDENTIAL LETTER First, I must solicit your confidence in this transaction, this is by virtue of its nature as being utterly CONFIDENTIAL and TOP SECRET. Though I know that a transaction of this magnitude will make any one apprehensive and worried, but I am assuring you that all will be well at the end of the transaction. We have decided to contact you by e-mail due to the urgency of this transaction, as we have been reliably informed of it's swiftness and confidentiality. For the purpose of introduction, I am Dr.Adams Efe Head, Banking Operations, Pacific International Bank Plc, in charge of personal and corporate accounts above US$5,000,000.00(five million US Dollars only). I came to know of you in my private search for a reliable and reputable person to handle a very confidential transaction which involves the transfer of a huge sum of money to a foreign account requiring maximum confidence. THE PROPOSITION: A foreigner, late Engineer Johnson Creek, an Oil Merchant/Contractor with the Federal Govenment of Nigeria, until his death three years ago in a plan crash, banked with us here at Pacific International Bank PLC., Lagos, and had a closing balance of USD$10M ( Ten Million United States Dollars only) which the bank now unquestionably expects to be claimed by any of his available foreign next of kin or alternatively be donated to a discredited trust fund for arms and ammunition at a military war college here in Nigeria. Fervent valuable efforts are being made by the Bank to get in touch with any of the Creek family or relatives but all have proved to no avail.It is because of the perceived possibility of not going to be able to locate any of late Engr. Johnson Creek's next of kin (he had no known wife and children) that the management under the influence of our Chairman, Board of Directors, Retired Major General Kalu Uke Kalu, that an arrangement for the fund to be declared "UNCLAIMABLE" and then be subsequently donated to the Trust Fund for Arms and Ammunition which will further enhance the course of war in Africa and the world in general. In order to avert this negative development, myself and some of my trusted colleagues in the bank now seek for your permission to have you stand as late Engr. Johnson Creek's next of kin so that the fund, USD$10M would be subsequently transferred and paid into your bank account as the beneficiary next of kin. All documents and proves to enable you get this fund have been carefully worked out and we are assuring you a 100% risk free involvement. Your share would be 30% of the total amount,5% has been set aside for expenses while the rest would be for myself and my colleagues for investment purposes in your company or any country of your choice where the returns on investment will be optimal . If this proposal is acceptable to you and you do not wish to take advantage of the trust we hope to bestow on you and your company, then kindly get to me immediately via my e-mail furnishing me with : 1.Your most confidential telephone 2.Fax number 3.Exclusive e-mail so that I can forward to you the relevant details of this transaction. Thank you in advance for your anticipated co-operation. You can reach me on my private e- mail adamsefe@zwallet.com Regards, Dr.Adams Efe Pacific International Bank ___________________________________________________ GO.com Mail Get Your Free, Private E-mail at http://mail.go.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 08:54:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07621 for ; Thu, 15 May 2003 08:54:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FCvII23280 for ; Thu, 15 May 2003 08:57:18 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FCvFw15669 for ; Thu, 15 May 2003 08:57:15 -0400 (EDT) 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, 15 May 2003 08:54:38 -0400 Message-ID: <049AAFED91851244B9FF74D0D9D0EB720215261F@WHISTLER.WaveSmithNet.com> Thread-Topic: Draft charter for L2VPN - IPLS & ARP Mediation Thread-Index: AcMaeKeRb56S1jpzTfOKZktZJ7pmgwAZonuQ From: "Himanshu Shah" To: "Ali Sajassi" , , X-SMTP-HELO: telluride.wavesmithnet.com X-SMTP-MAIL-FROM: hshah@wavesmithnetworks.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ext.wavesmithnetworks.com [64.3.160.50] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA07621 Its a dubious question. It appears to indicate that if South Bell is planning to offer VPLS, he should not support the IPLS draft. It is particularly disturbing to have it asked in response to his individual technical opinion. /himanshu > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Wednesday, May 14, 2003 8:26 PM > To: Himanshu Shah; Ali Sajassi; steven.wright@BellSouth.com; > PPVPN@nortelnetworks.com > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > Why am I not surprised to hear from you first :-) > My questions was directed to the providers and I'd like to know which > providers are considering to offer IPLS and get some feedback > from them: > > How many are considering to offer IPLS in lieu of VPLS ? and > How many are considering to offer both IPLS and VPLS ? > > -Ali > > At 05:29 PM 5/14/2003 -0400, Himanshu Shah wrote: > >That is like asking for every draft that > >Cisco employee has contributed whether Cisco > >is planning to implement it? > > > >IETF operates on individual contributions > >and opinions. > > > >/himanshu > > > > > -----Original Message----- > > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > > Sent: Wednesday, May 14, 2003 4:56 PM > > > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > > > -progressed and > > > >documented in a published RFC. They are not the most widely > > > deployed cases, > > > >but they do exist and have real network applications. > > > > > > Steven, > > > > > > Does Bell South plan to offer VPLS ? If it plans to offer it, > > > then there > > > should be no need for IPLS because VPLS can be considered as > > > a super-set > > > since it covers both switches and routers as CEs and it > > > supports both IP > > > and non-IP traffic. Also inter-operability between IPLS and > > > VPLS is another > > > thing to consider if you plan to offer both !! However, if > > > Bell South plans > > > to offer IPLS in lieu of VPLS and assumes that all the > > > end-points for a > > > transparent LAN service are IPs, then that's a different story. > > > > > > -Ali > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 13:17:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15708 for ; Thu, 15 May 2003 13:17:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FHK8I10951 for ; Thu, 15 May 2003 13:20:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FHK4o24129 for ; Thu, 15 May 2003 13:20:05 -0400 (EDT) Reply-To: From: "Steven.Wright" To: "'Ali Sajassi'" , Subject: RE: IPLS & ARP Mediation Date: Thu, 15 May 2003 12:59:05 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20030514134158.01deb008@airborne.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp1g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: aismtp1g.bellsouth.com [139.76.165.196] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, As I tried to indicate in my earlier postings, I do NOT regard ARP Mediation and IPLS as the "ultimate" solution. None-the-less, they provide well defined features that are scoped, point solutions to particular customer's problems. And so I believe that we need them documented. Having two more tools in the toolbox does not invalidate the need for other solutions with better properties. I have NOT asked for interoperability between IPLS and VPLS. I suspect IP routing resolves the market requirements in that area anyway. Bellsouth already provides multiple instances of a variety of different data services within the constraints of different jurisdictions. Application of a particular protocol in one context does not mean that it is automatically viable everywhere. Most service providers design a service considering protocol constraints, but also considering a variety of other non-technical factors eg. cost, regulatory treatment, incumbent equipment capabilities etc. For operational simplicity we prefer a single solution to a single problem, but our network infrastructure must support solutions to multiple problems for multiple customers, i.e. we are inherently in a multiservice environment. I guess I'm just not sure which of my problems you are suggesting vpls as the solution to... 8^} Steven Wright > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Wednesday, May 14, 2003 4:56 PM > To: steven.wright@bellsouth.com; PPVPN@nortelnetworks.com > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > -progressed and > >documented in a published RFC. They are not the most widely > deployed cases, > >but they do exist and have real network applications. > > Steven, > > Does Bell South plan to offer VPLS ? If it plans to offer it, > then there > should be no need for IPLS because VPLS can be considered as > a super-set > since it covers both switches and routers as CEs and it > supports both IP > and non-IP traffic. Also inter-operability between IPLS and > VPLS is another > thing to consider if you plan to offer both !! However, if > Bell South plans > to offer IPLS in lieu of VPLS and assumes that all the > end-points for a > transparent LAN service are IPs, then that's a different story. > > -Ali > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 14:01:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17038 for ; Thu, 15 May 2003 14:01:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FI44I29954 for ; Thu, 15 May 2003 14:04:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FI40f21778 for ; Thu, 15 May 2003 14:04:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20030515103317.01e6e518@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 10:55:20 -0700 To: Giles Heron , Ali Sajassi From: Ali Sajassi Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Cc: Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com In-Reply-To: <1052996277.1688.31.camel@gizpad> References: <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: At 10:57 AM 5/15/2003 +0000, Giles Heron wrote: >OK, I'll bite ;-) > >personally I'd rather deploy IPLS than VPLS given the choice, though I >accept that some of our customers may demand VPLS. > >IPLS meets the requirement for which I originally envisaged VPLS being >useful (i.e. interconnecting IP routers or hosts) and does this more >efficiently than VPLS. I would be reluctant to use VPLS to interconnect >switches, as that exposes the SP to the customer network's MAC >addresses, but I can see why this might be attractive to customers in >the metropolitan area at least. Both IPLS and VPLS learn customer MAC addresses. IPLS does it in control plane and VPLS does it in data plane. Also in VPLS, number of customer MAC addresses can be limited per VPLS instance - this is one of the main requirements. -Ali >However in terms of what we'll offer it depends to an extent on what >vendors provide. I'm not aware of anyone shipping IPLS code yet... > >Giles > >On Thu, 2003-05-15 at 00:26, Ali Sajassi wrote: > > > > Why am I not surprised to hear from you first :-) > > My questions was directed to the providers and I'd like to know which > > providers are considering to offer IPLS and get some feedback from them: > > > > How many are considering to offer IPLS in lieu of VPLS ? and > > How many are considering to offer both IPLS and VPLS ? > > > > -Ali > > > > At 05:29 PM 5/14/2003 -0400, Himanshu Shah wrote: > > >That is like asking for every draft that > > >Cisco employee has contributed whether Cisco > > >is planning to implement it? > > > > > >IETF operates on individual contributions > > >and opinions. > > > > > >/himanshu > > > > > > > -----Original Message----- > > > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > > > Sent: Wednesday, May 14, 2003 4:56 PM > > > > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > > > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > > > > > > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > > > > -progressed and > > > > >documented in a published RFC. They are not the most widely > > > > deployed cases, > > > > >but they do exist and have real network applications. > > > > > > > > Steven, > > > > > > > > Does Bell South plan to offer VPLS ? If it plans to offer it, > > > > then there > > > > should be no need for IPLS because VPLS can be considered as > > > > a super-set > > > > since it covers both switches and routers as CEs and it > > > > supports both IP > > > > and non-IP traffic. Also inter-operability between IPLS and > > > > VPLS is another > > > > thing to consider if you plan to offer both !! However, if > > > > Bell South plans > > > > to offer IPLS in lieu of VPLS and assumes that all the > > > > end-points for a > > > > transparent LAN service are IPs, then that's a different story. > > > > > > > > -Ali > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-- >================================================================= >Giles Heron Principal Network Architect PacketExchange Ltd. >ph: +44 7880 506185 "if you build it they will yawn" >================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 14:09:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17306 for ; Thu, 15 May 2003 14:09:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FIC6I04547 for ; Thu, 15 May 2003 14:12:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FIC3f12995 for ; Thu, 15 May 2003 14:12:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20030515105539.01cb4a00@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 11:05:11 -0700 To: "Himanshu Shah" , "Ali Sajassi" , , From: Ali Sajassi Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB720215261F@WHISTLER.WaveSmit hNet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: The question was stated very clearly and was intended to get feedback from the operators and to ensure that we are all working under the same assumption. IPLS has been designed and optimized for VPLS-challenged PE routers. In other words, PE routers that perform IPLS are not expected to perform VPLS functionality. All I want to do is to make sure that operators are O.K. with it. In other words, to have one PE for IPLS functionality and another for VPLS functionality. In cases that the operator doesn't need to offer VPLS functionality, then all they need is an IPLS-capable PE. I just want to confirm if that's what the operators expect. -Ali At 08:54 AM 5/15/2003 -0400, Himanshu Shah wrote: >Its a dubious question. > >It appears to indicate that if South Bell >is planning to offer VPLS, he should not >support the IPLS draft. It is particularly >disturbing to have it asked in response >to his individual technical opinion. > >/himanshu > > > -----Original Message----- > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > Sent: Wednesday, May 14, 2003 8:26 PM > > To: Himanshu Shah; Ali Sajassi; steven.wright@BellSouth.com; > > PPVPN@nortelnetworks.com > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > Why am I not surprised to hear from you first :-) > > My questions was directed to the providers and I'd like to know which > > providers are considering to offer IPLS and get some feedback > > from them: > > > > How many are considering to offer IPLS in lieu of VPLS ? and > > How many are considering to offer both IPLS and VPLS ? > > > > -Ali > > > > At 05:29 PM 5/14/2003 -0400, Himanshu Shah wrote: > > >That is like asking for every draft that > > >Cisco employee has contributed whether Cisco > > >is planning to implement it? > > > > > >IETF operates on individual contributions > > >and opinions. > > > > > >/himanshu > > > > > > > -----Original Message----- > > > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > > > Sent: Wednesday, May 14, 2003 4:56 PM > > > > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > > > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > > > > > > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > > > > -progressed and > > > > >documented in a published RFC. They are not the most widely > > > > deployed cases, > > > > >but they do exist and have real network applications. > > > > > > > > Steven, > > > > > > > > Does Bell South plan to offer VPLS ? If it plans to offer it, > > > > then there > > > > should be no need for IPLS because VPLS can be considered as > > > > a super-set > > > > since it covers both switches and routers as CEs and it > > > > supports both IP > > > > and non-IP traffic. Also inter-operability between IPLS and > > > > VPLS is another > > > > thing to consider if you plan to offer both !! However, if > > > > Bell South plans > > > > to offer IPLS in lieu of VPLS and assumes that all the > > > > end-points for a > > > > transparent LAN service are IPs, then that's a different story. > > > > > > > > -Ali > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 16:03:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21417 for ; Thu, 15 May 2003 16:03:21 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FK5rI13170 for ; Thu, 15 May 2003 16:05:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FK5nD12283 for ; Thu, 15 May 2003 16:05:49 -0400 (EDT) Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation From: Giles Heron To: Ali Sajassi Cc: Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com In-Reply-To: <4.3.2.7.2.20030515103317.01e6e518@airborne.cisco.com> References: <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> <4.3.2.7.2.20030515103317.01e6e518@airborne.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 May 2003 20:50:14 +0000 Message-Id: <1053031814.1991.31.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On Thu, 2003-05-15 at 17:55, Ali Sajassi wrote: > At 10:57 AM 5/15/2003 +0000, Giles Heron wrote: > >OK, I'll bite ;-) > > > >personally I'd rather deploy IPLS than VPLS given the choice, though I > >accept that some of our customers may demand VPLS. > > > >IPLS meets the requirement for which I originally envisaged VPLS being > >useful (i.e. interconnecting IP routers or hosts) and does this more > >efficiently than VPLS. I would be reluctant to use VPLS to interconnect > >switches, as that exposes the SP to the customer network's MAC > >addresses, but I can see why this might be attractive to customers in > >the metropolitan area at least. > > Both IPLS and VPLS learn customer MAC addresses. IPLS does it in control > plane and VPLS does it in data plane. Also in VPLS, number of customer MAC > addresses can be limited per VPLS instance - this is one of the main > requirements. I think I've got a fair idea of how IPLS and VPLS work thanks ;-) So yes, IPLS learns MAC addresses, but it only ever learns the MAC addresses of the CEs. If VPLS is used to interconnect switches then it will learn MAC addresses behind the CEs. Sure, you can limit the number of MACs - and if I deploy VPLS then I will do so - but that brings other issues (e.g. if that limit is hit then how do we automatically inform the customer that this is the cause of the partial connectivity on the VPN). Giles > -Ali > > > >However in terms of what we'll offer it depends to an extent on what > >vendors provide. I'm not aware of anyone shipping IPLS code yet... > > > >Giles > > > >On Thu, 2003-05-15 at 00:26, Ali Sajassi wrote: > > > > > > Why am I not surprised to hear from you first :-) > > > My questions was directed to the providers and I'd like to know which > > > providers are considering to offer IPLS and get some feedback from them: > > > > > > How many are considering to offer IPLS in lieu of VPLS ? and > > > How many are considering to offer both IPLS and VPLS ? > > > > > > -Ali > > > > > > At 05:29 PM 5/14/2003 -0400, Himanshu Shah wrote: > > > >That is like asking for every draft that > > > >Cisco employee has contributed whether Cisco > > > >is planning to implement it? > > > > > > > >IETF operates on individual contributions > > > >and opinions. > > > > > > > >/himanshu > > > > > > > > > -----Original Message----- > > > > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > > > > Sent: Wednesday, May 14, 2003 4:56 PM > > > > > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > > > > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > > > > > > > > > > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > > > > > -progressed and > > > > > >documented in a published RFC. They are not the most widely > > > > > deployed cases, > > > > > >but they do exist and have real network applications. > > > > > > > > > > Steven, > > > > > > > > > > Does Bell South plan to offer VPLS ? If it plans to offer it, > > > > > then there > > > > > should be no need for IPLS because VPLS can be considered as > > > > > a super-set > > > > > since it covers both switches and routers as CEs and it > > > > > supports both IP > > > > > and non-IP traffic. Also inter-operability between IPLS and > > > > > VPLS is another > > > > > thing to consider if you plan to offer both !! However, if > > > > > Bell South plans > > > > > to offer IPLS in lieu of VPLS and assumes that all the > > > > > end-points for a > > > > > transparent LAN service are IPs, then that's a different story. > > > > > > > > > > -Ali > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-- > >================================================================= > >Giles Heron Principal Network Architect PacketExchange Ltd. > >ph: +44 7880 506185 "if you build it they will yawn" > >================================================================= > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 16:46:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22707 for ; Thu, 15 May 2003 16:46:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FKnJI20268 for ; Thu, 15 May 2003 16:49:19 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FKnGt10955 for ; Thu, 15 May 2003 16:49:17 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Giles Heron , Ali Sajassi Cc: Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Date: Thu, 15 May 2003 16:47:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31B23.2EEFD702" X-LYRIS-Message-Id: 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_01C31B23.2EEFD702 Content-Type: text/plain; charset="iso-8859-1" Giles, > > IPLS meets the requirement for which I originally envisaged VPLS being > useful (i.e. interconnecting IP routers or hosts) and does this more > efficiently than VPLS. I would be reluctant to use VPLS to > interconnect > switches, as that exposes the SP to the customer network's MAC > addresses, but I can see why this might be attractive to customers in > the metropolitan area at least. > What do you suggest as a service to interconnect switches besides using VPLS? (particularly across IP/MPLS network). (your observation seems similar to l3vpns where the SP is exposed to customer routes which seems okay for some customers)... Hamid. ------_=_NextPart_001_01C31B23.2EEFD702 Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L2VPN - IPLS & ARP Mediation

Giles,

>
> IPLS meets the requirement for which I originally envisaged VPLS being
> useful (i.e. interconnecting IP routers or hosts) and does this more
> efficiently than VPLS.  I would be reluctant to use VPLS to
> interconnect
> switches, as that exposes the SP to the customer network's MAC
> addresses, but I can see why this might be attractive to customers in
> the metropolitan area at least.
>

What do you suggest as a service to interconnect switches
besides using VPLS? (particularly across IP/MPLS network).

(your observation seems similar to l3vpns where the SP is
exposed to customer routes which seems okay for some
customers)...

Hamid.

------_=_NextPart_001_01C31B23.2EEFD702-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 16:52:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22799 for ; Thu, 15 May 2003 16:52:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FKsgI24349 for ; Thu, 15 May 2003 16:54:42 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FKset19634 for ; Thu, 15 May 2003 16:54:40 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Ali Sajassi , Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Date: Thu, 15 May 2003 16:49:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31B23.69B8D212" X-LYRIS-Message-Id: 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_01C31B23.69B8D212 Content-Type: text/plain; charset="iso-8859-1" Ali, > > IPLS has been designed and optimized for VPLS-challenged PE > routers. In > other words, PE routers that perform IPLS are not expected to > perform VPLS > functionality. > Not sure I understand your conclusion. IPLS looks designed for IP-based CEs. I am not sure why a PE that provides IPLS service cannot provide as well VPLS service to other CEs (for example LAN switches) - if that PE can handle both -. The operator has the choice anyway given the situation and what functionality is supported on that PE. > All I want to do is to make sure that operators are O.K. with > it. In other > words, to have one PE for IPLS functionality and another for VPLS > functionality. If an operator plans to provide IPLS or VPLS wouldn't she/he engineer the PE to meet the vpls/ipls requirements? >In cases that the operator doesn't need to offer VPLS > functionality, then all they need is an IPLS-capable PE. I > just want to > confirm if that's what the operators expect. > You may be asking fair question, I just don't see why an operator needs two distinct PEs if it needs to offer both IPLS and VPLS? Looking at the IPLS draft, I may agree with you that there is too much emphasis that an IPLS-capable-PE is a PE that cannot provide VPLS service while in fact - in my opinion - it should state that if an operator knows apriori that the CEs are all IP host/routers, then an IPLS like service may be offered (to what extent it simplifies/optimize the PE compared to VPLS service needs to be known)...and IPLS (as Steven pointed out) is considered just additional tool in an operator toolbox (unless in your question you wanted to refer/point to something else). Hamid. ------_=_NextPart_001_01C31B23.69B8D212 Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L2VPN - IPLS & ARP Mediation

Ali,

>
> IPLS has been designed and optimized for VPLS-challenged PE
> routers. In
> other words, PE routers that perform IPLS are not expected to
> perform VPLS
> functionality.
>

Not sure I understand your conclusion. IPLS looks designed for
IP-based CEs. I am not sure why a PE that provides IPLS service
cannot provide as well VPLS service to other CEs
(for example LAN switches) - if that PE can handle both -.
The operator has the choice anyway given the situation and
what functionality is supported on that PE.

> All I want to do is to make sure that operators are O.K. with
> it. In other
> words, to have one PE for IPLS functionality and another for VPLS
> functionality.

If an operator plans to provide IPLS or VPLS
wouldn't she/he engineer the PE to meet the vpls/ipls requirements?

>In cases that the operator doesn't need to offer VPLS
> functionality, then all they need is an IPLS-capable PE. I
> just want to
> confirm if that's what the operators expect.
>

You may be asking fair question, I just don't see why an
operator needs two distinct PEs if it needs to
offer both IPLS and VPLS?

Looking at the IPLS draft, I may agree with you that there
is too much emphasis that an IPLS-capable-PE is a PE
that cannot provide VPLS service while in fact - in my
opinion - it should state that if an operator knows apriori
that the CEs are all IP host/routers, then an IPLS like
service may be offered (to what extent it simplifies/optimize
the PE compared to VPLS service needs to be known)...and IPLS
(as Steven pointed out) is considered just additional tool in
an operator toolbox (unless in your question you wanted
to refer/point to something else).

Hamid.









------_=_NextPart_001_01C31B23.69B8D212-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 17:05:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23069 for ; Thu, 15 May 2003 17:05:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FL78I14684 for ; Thu, 15 May 2003 17:07:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FL74V11764 for ; Thu, 15 May 2003 17:07:05 -0400 (EDT) Date: Thu, 15 May 2003 13:58:09 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5349753619.20030515135809@psg.com> To: PPVPN@nortelnetworks.com Subject: IESG on draft-ietf-ppvpn-framework and draft-ietf-ppvpn-requirements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- News from the IESG telechat today: - draft-ietf-ppvpn-framework has been tentatively approved subject to addressing minor editorial points, we're working with the authors on the rfc-ed note that will be attached to the document; once it's ready the draft will go the RFC editor team for publication as INFO RFC. It was mentioned by several IESG people that the document is of a really high quality. Thanks! - draft-ietf-ppvpn-requirements: the IESG will need to continue discussion on this document. I'm following up with the IESG members, we should be able to get back to the WG next week. Regards, -- Alex http://www.psg.com/~zinin/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 17:09:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23170 for ; Thu, 15 May 2003 17:09:41 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FLCCI19689 for ; Thu, 15 May 2003 17:12:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FLC9V18238 for ; Thu, 15 May 2003 17:12:09 -0400 (EDT) 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: decisions on L2 solutions documents Date: Thu, 15 May 2003 17:06:39 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C47F@m-va-bsod03.add0.masergy.com> Thread-Topic: decisions on L2 solutions documents thread-index: AcMbJeCy5XkwRZbgQSS6nOHwGQAZ8w== From: "Rick Wilder" To: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA23170 Below are decisions regarding L2 solution documents which have been considered for WG document status since the SF meeting. - VPLS  draft-lasserre-vkompella-ppvpn-vpls-04.txt is now a WG document based on strong support in SF and on this mailing list.  - VPLS draft-kompella-ppvpn-vpls-01 is now a WG draft based on the support shown on the list.  The discussion of the appropriateness of BGP for VPLS signaling will continue on the list and, if needed, in Vienna. - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is not made a WG document at this time. Several questions have come up regarding this document during discussions between the ADs and WG chairs. In order to make an informed decision, these questions will be posted shortly to begin a discussion. - Radius for PE-Based VPN Discovery (draft-heinanen-radius-pe-discovery) : This draft is not made a WG document at this time. Though the draft received a high degree of support in SF, concerns have been brought to the attention of the ADs on the appropriateness of this use of Radius. Before we can make an informed decision, we would like the WG to have this discussion. Concerns will be forwarded to the WG shortly. -Provisioning Models and Endpoint Identifiers in L2VPN Signaling (draft-rosen-ppvpn-l2-signaling-03.txt) -IP over LAN Service (shah-ppvpn-ipls-01.txt) These drafts require further discussion prior to evaluating WG support. Rick From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 17:12:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23274 for ; Thu, 15 May 2003 17:12:54 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FLFPI22226 for ; Thu, 15 May 2003 17:15:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FLFMW21547 for ; Thu, 15 May 2003 17:15:23 -0400 (EDT) Message-ID: <3EC40271.B5104E42@alcatel.com> Date: Thu, 15 May 2003 17:11:13 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Alex Zinin , PPVPN@nortelnetworks.com Subject: Re: Info aggregation References: <200305141507.h4EF7Hnt029064@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, Eric Rosen wrote: > > Cheng-Yin> Are the proponents of these models considering loop prevention > Cheng-Yin> measures? > > Once the PWs are properly set up according to the provisioned hierarchy, > split horizon prevents loops. Perhaps you are asking whether the > auto-discovery process can be guaranteed to provide the information needed > to set up a cycle-free hierarchy, even in the presence of provisioning > errors. In this case, I am concerned with loops caused by provisioning errors (could be in the hierarchy, or in the mesh itself). I am not sure if an end customer would tolerate even one such service disruption, and how viable the solution is without some kind of loop prevention. > With BGP-based auto-discovery, this could be an issue if the pws needed to > go through an arbitrary set of ASes, But I think loops may form even with just 2 ASes (and even within one AS). > each of which summarizes information > from its neighbors before passing it on. If we wanted to support a model > like that, we could use AS-path to prevent loops. But I'm not at all sure > that that would be useful, as I don't think we want the VPLS pws to travel > through arbitrary sets of ASes. I am not sure if using AS-path is sufficient as the devices (PEs or others) doing the multipoint switching (VPLS forwarding) need to be involved in loop prevention. > Cheng-Yin> How to aggregate VPLS membership ID, VPLS_ID/VPN_ID ? (cf IP > Cheng-Yin> addresses/routes can be aggregated). > > VPN ids obviously cannot be aggregated. Probably the best we can do is make > the inter-AS discovery process scale linearly with the number of inter-AS > VPLSes. But I don't really think the discovery process is going to be the > bottleneck here. Perhaps not, especially if there are going to be few VPLS instances, and there are other aspects of the service (e.g. in the forwarding plane) which will need to be resolved first. Thanks Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 17:15:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23392 for ; Thu, 15 May 2003 17:15:46 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FLIII25866 for ; Thu, 15 May 2003 17:18:18 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FLIEW25833 for ; Thu, 15 May 2003 17:18:15 -0400 (EDT) Message-ID: <3EC402F5.F17017BF@alcatel.com> Date: Thu, 15 May 2003 17:13:25 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Muneyoshi Suzuki CC: mattsquire@acm.org, erosen@cisco.com, zinin@psg.com, PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN References: <200305141437.h4EEaunt017939@rtp-core-1.cisco.com> <3EC2982D.6020105@acm.org> <20030515.104523.130226272.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit If existing routers and bridges cannot expect an emulated LAN service, and cannot work properly using VPLS, how useful are the solutions then? I think it is a requirement that VPLS emulate a LAN (appear as a LAN to higher layer protocols), otherwise I am afraid the WG may not be producing useful work. Regards Cheng-Yin Muneyoshi Suzuki wrote: > > > > Matt> I'd like to include an objective that the VPLS services are > > > Matt> transparent to higher layer protocols (e.g. really emulated a LAN) > > > I would be opposed to this as a charter requirement. This kind of > > > requirement can easily get you into a situation in which you end up doing > > > 90% of the work to handle a 1% problem. Given a particular solution which > > > doesn't quite meet this requirement,the WG should be able to decide whether > > > the solution comes close enough or not; this shouldn't be predetermined by > > > the charter. > > If this requirement is not met, then we're not really providing a > > virtual X service (X=FR, X=Ethernet, etc.). If the group is chartered > > to define new service types, and I'm not saying it can't be, thats fine. > > But a virtual Ethernet wire that requires applications to be aware of > > the virualness of the wire has a high cost of entry. > > I agree with Matt. > > I think the solution(s) doesn't need to perfectly conform with the original > technology. However, it must not violate the standards for interworking > with existing implementations. And it must be robust and must not cause > fatal problems such as loop, blackhole, and flaky PEs. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 17:23:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23601 for ; Thu, 15 May 2003 17:23:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FLPpI29838 for ; Thu, 15 May 2003 17:25:52 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FLPnW01504 for ; Thu, 15 May 2003 17:25:49 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Rick Wilder , PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Thu, 15 May 2003 17:24:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31B28.500E1D90" X-LYRIS-Message-Id: 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_01C31B28.500E1D90 Content-Type: text/plain; charset="iso-8859-1" Rick, > > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is > not made a WG document at this time. Several questions have > come up regarding this document during discussions between > the ADs and WG chairs. In order to make an informed decision, > these questions will be posted shortly to begin a discussion. > In your opinion as ppvpn chair was there consensus on the mailing list that this draft should advance to WG doc status? Hamid. ------_=_NextPart_001_01C31B28.500E1D90 Content-Type: text/html; charset="iso-8859-1" RE: decisions on L2 solutions documents

Rick,

>
> - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is
> not made a WG document at this time. Several questions have
> come up regarding this document during discussions between
> the ADs and WG chairs. In order to make an informed decision,
> these questions will be posted shortly to begin a discussion.
>

In your opinion as ppvpn chair was there consensus on the mailing
list that this draft should advance to WG doc status?

Hamid.

------_=_NextPart_001_01C31B28.500E1D90-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 17:47:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24304 for ; Thu, 15 May 2003 17:47:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FLoJI06898 for ; Thu, 15 May 2003 17:50:19 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FLoGI15099 for ; Thu, 15 May 2003 17:50:16 -0400 (EDT) Message-Id: <200305152146.h4FLkER18698@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Manav Bhatia , lidefeng Subject: Re: [Isis-wg] Re: IS-IS as PE/CE routing protocol in BGP/MPLS/VPN Date: Thu, 15 May 2003 23:45:59 +0200 X-Mailer: KMail [version 1.3.1] Cc: ppvpn@nortelnetworks.com, isis-wg@ietf.org References: <000c01c3190b$1418a540$07436e0a@HUAWEI.COM> <048801c31ad7$51225080$b4036c6b@sisodomain.com> In-Reply-To: <048801c31ad7$51225080$b4036c6b@sisodomain.com> MIME-Version: 1.0 X-SMTP-HELO: strange-brew.cisco.com X-SMTP-MAIL-FROM: sprevidi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: weird-brew.cisco.com [144.254.15.118] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA24304 On Thursday 15 May 2003 13:44, Manav Bhatia wrote: > Lidefeng, > Just a general observation: > > - Whenever a PE router receives a MP-BGP UPDATE, it must execute the BGP > Decision Process to decide the best path to the prefix contained in the > UPDATE. When this decision process completes, the *best* route is passed > onto the IS-IS selection process for import into any relevant VRFs. Because > multiple UPDATEs for the same prefix might be received, and because IS-IS > has its own selection process for differing metric types, the BGP Decision > Process IMHO should be modified to prefer routes with internal metrics over > the routes with external metrics. The Decision process will be based on the > ISIS metric type that will be conveyed within the IS-IS Route Type Extended > Community Attribute that accompanies the ISIS VPN-IPv4 route. If I understand correctly the concept of the sham-link, the PE will receive a mp-bgp route containing the other end of the sham-link and the extComm describing it. This route need to be the best among other (possible) mp-bgp routes (with same RD) for the same prefix. If such route is best, then you won't really import it into the vrf but rather you will "use it" in order to add a (fake) adjacency into the isis lsp the PE will originate. Then you run spf as part of the isis instance running in the vrf and compute your routes. After spf computation you'll find that the prefixes of the remote site are reachable through the sham link (according to the metric of your links of course). So I don't believe you really need to change the bgp selection process. Btw, I don't see any reference to TLVs 22 and 135 in the draft... s. > > There seems to be no mention of this in the draft. > > - Is there a reason why you're not sending any metrics (wide/narrow) info > in the extended community? > > Regards, > Manav > > ----- Original Message ----- > From: "lidefeng" > To: > Cc: ; > Sent: Tuesday, May 13, 2003 10:19 AM > Subject: [Isis-wg] A new draft,IS-IS as PE/CE routing protocol in > BGP/MPLS/VPN > > > > Hi,all, > > > > In deploying BGP/MPLS VPN,there are sites that CE run IS-IS protocol with > > PE,and the corresponding customer is reluctant to change the routing > > protocol they used in the sites,to accomodate this situation, it is > better > > to run isis protocol between PE and CE,however,ther isn't any draft to > > specify the scenario in the BGP MPLS VPN. This draft addresses this > > scenario,the abstract is as following: > > > > IS-IS protocol, which is specified in [1], can be used as IGP between > > the Customer Edge (CE) router and the Provider Edge (PE) router in > > BGP/MPLS VPNs as per [1]. This document provides a detailed solution > > for IS-IS working as PE/CE Protocol in VPN services specified in [1]. > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 18:15:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25730 for ; Thu, 15 May 2003 18:15:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FMDPI08103 for ; Thu, 15 May 2003 18:13:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FMDMc07322 for ; Thu, 15 May 2003 18:13:22 -0400 (EDT) X-Original-Recipient: hbrahim@nortelnetworks.com Message-ID: <3EC40FB8.7090607@pi.se> Date: Fri, 16 May 2003 00:07:52 +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: "Hamid Ould-Brahim" CC: Rick Wilder , PPVPN@nortelnetworks.com Subject: Re: decisions on L2 solutions documents References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailg.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailg.telia.com [194.22.194.26] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick, the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the wg support from the mailing list at the time, which I don't know), that the issues the AD / wg chair discussion should be made available to the list/wg. Review results may change how you feel about making things wg doc or not, even if they come form ADs :) Mailing list discussion of those review results may lift or confirm those conserns. /Loa Hamid Ould-Brahim wrote: > Rick, > > > > > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is > > not made a WG document at this time. Several questions have > > come up regarding this document during discussions between > > the ADs and WG chairs. In order to make an informed decision, > > these questions will be posted shortly to begin a discussion. > > > > In your opinion as ppvpn chair was there consensus on the mailing > list that this draft should advance to WG doc status? > > Hamid. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 18:29:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26313 for ; Thu, 15 May 2003 18:29:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FMViI12357 for ; Thu, 15 May 2003 18:31:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FMVgQ15439 for ; Thu, 15 May 2003 18:31:42 -0400 (EDT) Message-Id: <5.2.0.9.0.20030515180207.02000c68@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 15 May 2003 18:13:19 -0400 To: "Marco Carugi" , ppvpn@nortelnetworks.com From: Mark Duffy Subject: Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: Hi, here are some last call comments on draft-ietf-ppvpn-rfc2547bis-03.txt. The title is currently "BGP/MPLS VPNs". Since this work originated there are now other, completely different VPN approaches that also use BGP and MPLS. For this reason perhaps, many people refer to VPNs of this type as "2547 VPNs". That may become awkward as this draft becomes an RFC, or if there are future revisions. Perhaps a more specific name should be applied. "BGP-MPLS L3 VPNs" perhaps? -------- Sect 4.1(?) There have been some inconclusive discussions on the list as to whether it is advisable to use the same RD or different RDs for VRFs in a given VPN that are in different PEs. The question seems especially important in the case where a site is multihomed to 2 different PEs. If a route from the CE is advertised by both PEs with the same RD, BGP path selection on the VPN-IPv4 routes can be used. If a route from the CE is advertised by both PEs with different RDs, then the conflict needs to be resolved in another way at remote PEs when the RDs are stripped and the 2 IPv4 routes for the same prefix would be placed in a VRF. It would be good if the draft gave guidance on this issue. -------- In the last paragraph of 4.3 (p. 17) there are 4 uses of the term "VPN-IP" route and "VPN-IP" address prefix. Are these supposed to be "VPN-IPv4"? If not, the VPN-IP concept needs to be explained. -------- Sect 4.3.2 p. 20 (and a similar statement in sect. 5 p. 25) says the following about the outer tunnel: To ensure interoperability among systems which implement this VPN architecture using MPLS label switched paths as the tunneling technology, all such systems MUST support LDP [MPLS-LDP]. I think "support LDP" is not a strong enough requirement here to ensure interoperability. If this requirement is to be retained at all shouldn't it also require support for some specific combination of DU/DOD, ordered/independent control, liberal/conservative retention? (I am not up on all the subtleties of which mode combinations can work with each other but I suppose it is at least necessary that participating equipment use compatible DU/DOD modes.) -------- Sect. 4.3.4 says to encode VPN-IPv4 NLRI with AFI=1 and SAFI=128. RFC 2858 section 8 says "SAFI values 128 through 255 are for "private use", and values in this range are not to be assigned by IANA." Why does the draft specify 128? Shouldn't the value be in 5-127? -------- In sect. 5 p. 26 there is a list item "- Otherwise" and the 3rd item in the sub-list below that says: * Otherwise, the IGP Next Hop will have assigned a label for the route which best matches the address of the BGP Next Hop. Call this the "tunnel label". The tunnel label gets pushed on as the packet's top label. The packet is then forwarded to the IGP next hop. I see this says to use an outer LSP for a FEC that *best matches* the BGP Next Hop. I had always been under the impression that it was necessary to select an outer LSP for a /32 FEC exactly matching the BGP NH (as the first item in the outer list here describes). An LSP for a FEC shorter than a /32 would seem almost guaranteed to terminate before reaching the BGP NH system where the inner label is meaningful. No? -------- In sect. 7 item 4a re using BGP as the PE-CE protocol: a) Unlike the IGP alternatives, this does not require the PE to run multiple routing algorithm instances in order to talk to multiple CEs Wouldn't multiple instance of BGP be needed in the general case where the CEs are in VPNs with overlapping address spaces? -------- A few typos & nits Sect. 1.6 s/determine that whether/determine whether/ Sect 1.6 [MPLS/BGP-IPsec] is not in the refs. Presume this should refer to draft-ietf-ppvpn-ipsec-2547-03. Sect 4.1 s/VPN-IPv4 addresses are IPv4/VPN-IPv4 addresses and IPv4/ Sect. 4.3.1 s/to be installed those/to be installed in those/ p. 20 s/than a label switched/that a label switched/ Sect. 7 p.28: s/In the case where the CE device is a host or a switch/In the case where the CE device is a host/ (Sect 1.2 on p.7 has defined the CE device NOT to be a L2 device.) Thanks, Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 18:33:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26386 for ; Thu, 15 May 2003 18:33:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FMaUI16055 for ; Thu, 15 May 2003 18:36:30 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FMaRQ19651 for ; Thu, 15 May 2003 18:36:27 -0400 (EDT) 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="us-ascii" Subject: RE: decisions on L2 solutions documents Date: Thu, 15 May 2003 18:33:55 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C483@m-va-bsod03.add0.masergy.com> Thread-Topic: decisions on L2 solutions documents thread-index: AcMbLuvjTprC0dKISE6/npaInMSWvQAAdzPg From: "Rick Wilder" To: "Loa Andersson" , "Hamid Ould-Brahim" Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA26386 Agreed, Loa. Here are the questions/requests-for-clarification that came up. a) how do the discovery and signaling parts of the document relate to those described in the other solutions documents and which of them are suggested to be mandatory to implement b) what is the status of the MAC-in-MAC encapsulation work in IEEE? c) for the case where the U-PE network is a completely ethernet switched network, and encapsulation like MAC-in-MAC is used, what part of the architecture belongs to the IETF? c) definition of M2P PWs is outside the scope of this WG and probably should go to PWE3 d) how does the definition of semantics of the PW CW given in the document relate to those defined in the PWE3 WG? -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, May 15, 2003 4:08 PM To: Hamid Ould-Brahim Cc: Rick Wilder; PPVPN@nortelnetworks.com Subject: Re: decisions on L2 solutions documents Rick, the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the wg support from the mailing list at the time, which I don't know), that the issues the AD / wg chair discussion should be made available to the list/wg. Review results may change how you feel about making things wg doc or not, even if they come form ADs :) Mailing list discussion of those review results may lift or confirm those conserns. /Loa Hamid Ould-Brahim wrote: > Rick, > > > > > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is > > not made a WG document at this time. Several questions have > > come up regarding this document during discussions between > > the ADs and WG chairs. In order to make an informed decision, > > these questions will be posted shortly to begin a discussion. > > > > In your opinion as ppvpn chair was there consensus on the mailing > list that this draft should advance to WG doc status? > > Hamid. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 18:52:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26740 for ; Thu, 15 May 2003 18:52:09 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FMsfI20795 for ; Thu, 15 May 2003 18:54:41 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FMsce27615 for ; Thu, 15 May 2003 18:54:38 -0400 (EDT) Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation From: Giles Heron To: "Hamid Ould-Brahim" Cc: Ali Sajassi , Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 May 2003 23:49:07 +0000 Message-Id: <1053042548.1924.19.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On Thu, 2003-05-15 at 20:47, Hamid Ould-Brahim wrote: > Giles, > > > > > IPLS meets the requirement for which I originally envisaged VPLS being > > useful (i.e. interconnecting IP routers or hosts) and does this more > > efficiently than VPLS. I would be reluctant to use VPLS to > > interconnect > > switches, as that exposes the SP to the customer network's MAC > > addresses, but I can see why this might be attractive to customers in > > the metropolitan area at least. > > > > What do you suggest as a service to interconnect switches > besides using VPLS? (particularly across IP/MPLS network). I don't think there is much alternative to VPLS for this (other than using meshes of draft-martini VCs, and either running spanning tree over the top or implementing split horizon in the CE devices). > (your observation seems similar to l3vpns where the SP is > exposed to customer routes which seems okay for some > customers)... Agreed. But of course there tend to be more MAC addresses than prefixes in the average network. And, just to be pedantic, the scaling problem with 2547 or VPLS isn't a question of what the customer is okay with, but rather of what the provider can support. Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 19:57:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27829 for ; Thu, 15 May 2003 19:57:27 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FNouI14775 for ; Thu, 15 May 2003 19:50:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4FNosL10025 for ; Thu, 15 May 2003 19:50:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20030515162328.01c67358@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 16:44:01 -0700 To: Giles Heron , Ali Sajassi From: Ali Sajassi Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation Cc: Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com In-Reply-To: <1053031814.1991.31.camel@gizpad> References: <4.3.2.7.2.20030515103317.01e6e518@airborne.cisco.com> <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> <4.3.2.7.2.20030514170217.01e67bc0@airborne.cisco.com> <4.3.2.7.2.20030515103317.01e6e518@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: > > >If VPLS is used to interconnect switches then it will learn MAC >addresses behind the CEs. Sure, you can limit the number of MACs - and >if I deploy VPLS then I will do so - but that brings other issues (e.g. >if that limit is hit then how do we automatically inform the customer >that this is the cause of the partial connectivity on the VPN). Yes, this is a good question which has also been asked by some providers and there are several options - one of which to notify the customer through UNI (ELMI) or some other means (when getting close to the limit). One can ask the same question for IPLS since many end-points can sit behind an AC and whether there should be a limit on number of of IP end-points since each end-point consumes resources in the PE. -Ali >Giles > > > -Ali > > > > > > >However in terms of what we'll offer it depends to an extent on what > > >vendors provide. I'm not aware of anyone shipping IPLS code yet... > > > > > >Giles > > > > > >On Thu, 2003-05-15 at 00:26, Ali Sajassi wrote: > > > > > > > > Why am I not surprised to hear from you first :-) > > > > My questions was directed to the providers and I'd like to know which > > > > providers are considering to offer IPLS and get some feedback from > them: > > > > > > > > How many are considering to offer IPLS in lieu of VPLS ? and > > > > How many are considering to offer both IPLS and VPLS ? > > > > > > > > -Ali > > > > > > > > At 05:29 PM 5/14/2003 -0400, Himanshu Shah wrote: > > > > >That is like asking for every draft that > > > > >Cisco employee has contributed whether Cisco > > > > >is planning to implement it? > > > > > > > > > >IETF operates on individual contributions > > > > >and opinions. > > > > > > > > > >/himanshu > > > > > > > > > > > -----Original Message----- > > > > > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > > > > > Sent: Wednesday, May 14, 2003 4:56 PM > > > > > > To: steven.wright@BellSouth.com; PPVPN@nortelnetworks.com > > > > > > Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation > > > > > > > > > > > > > > > > > > > > > > > > >I'd like to see the work in this area - IPLS & ARP Mediation > > > > > > -progressed and > > > > > > >documented in a published RFC. They are not the most widely > > > > > > deployed cases, > > > > > > >but they do exist and have real network applications. > > > > > > > > > > > > Steven, > > > > > > > > > > > > Does Bell South plan to offer VPLS ? If it plans to offer it, > > > > > > then there > > > > > > should be no need for IPLS because VPLS can be considered as > > > > > > a super-set > > > > > > since it covers both switches and routers as CEs and it > > > > > > supports both IP > > > > > > and non-IP traffic. Also inter-operability between IPLS and > > > > > > VPLS is another > > > > > > thing to consider if you plan to offer both !! However, if > > > > > > Bell South plans > > > > > > to offer IPLS in lieu of VPLS and assumes that all the > > > > > > end-points for a > > > > > > transparent LAN service are IPs, then that's a different story. > > > > > > > > > > > > -Ali > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-- > > >================================================================= > > >Giles Heron Principal Network Architect PacketExchange Ltd. > > >ph: +44 7880 506185 "if you build it they will yawn" > > >================================================================= > > > > >-- >================================================================= >Giles Heron Principal Network Architect PacketExchange Ltd. >ph: +44 7880 506185 "if you build it they will yawn" >================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 20:03:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27972 for ; Thu, 15 May 2003 20:03:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4G05YI26273 for ; Thu, 15 May 2003 20:05:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4G05VL04949 for ; Thu, 15 May 2003 20:05:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20030515164748.01c8f978@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 17:02:06 -0700 To: "Hamid Ould-Brahim" , Ali Sajassi , Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com From: Ali Sajassi Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_115040329==_.ALT" X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: --=====================_115040329==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:49 PM 5/15/2003 -0400, Hamid Ould-Brahim wrote: >Ali, > > > > > IPLS has been designed and optimized for VPLS-challenged PE > > routers. In > > other words, PE routers that perform IPLS are not expected to > > perform VPLS > > functionality. > > > >Not sure I understand your conclusion. IPLS looks designed for >IP-based CEs. I am not sure why a PE that provides IPLS service >cannot provide as well VPLS service to other CEs >(for example LAN switches) - if that PE can handle both -. >The operator has the choice anyway given the situation and >what functionality is supported on that PE. With respect to IP-based CEs, both IPLS and VPLS services look the same and they can't tell the difference. However, if end-points are IP, then certain optimization wrt to PE internal operation can be achieved. > > All I want to do is to make sure that operators are O.K. with > > it. In other > > words, to have one PE for IPLS functionality and another for VPLS > > functionality. > >If an operator plans to provide IPLS or VPLS >wouldn't she/he engineer the PE to meet the vpls/ipls requirements? With VPLS you can offer TLS service to both IP and non-IP end points and with IPLS you can offer TLS service to IP end-points only. -Ali > >In cases that the operator doesn't need to offer VPLS > > functionality, then all they need is an IPLS-capable PE. I > > just want to > > confirm if that's what the operators expect. > > > >You may be asking fair question, I just don't see why an >operator needs two distinct PEs if it needs to >offer both IPLS and VPLS? > >Looking at the IPLS draft, I may agree with you that there >is too much emphasis that an IPLS-capable-PE is a PE >that cannot provide VPLS service while in fact - in my >opinion - it should state that if an operator knows apriori >that the CEs are all IP host/routers, then an IPLS like >service may be offered (to what extent it simplifies/optimize >the PE compared to VPLS service needs to be known)...and IPLS >(as Steven pointed out) is considered just additional tool in >an operator toolbox (unless in your question you wanted >to refer/point to something else). > >Hamid. > > > > > > > --=====================_115040329==_.ALT Content-Type: text/html; charset="us-ascii" At 04:49 PM 5/15/2003 -0400, Hamid Ould-Brahim wrote:

Ali,

>
> IPLS has been designed and optimized for VPLS-challenged PE
> routers. In
> other words, PE routers that perform IPLS are not expected to
> perform VPLS
> functionality.
>

Not sure I understand your conclusion. IPLS looks designed for
IP-based CEs. I am not sure why a PE that provides IPLS service
cannot provide as well VPLS service to other CEs
(for example LAN switches) - if that PE can handle both -.
The operator has the choice anyway given the situation and
what functionality is supported on that PE.

With respect to IP-based CEs, both IPLS and VPLS services look the same and they can't tell the difference. However, if end-points are IP, then certain optimization wrt to PE internal operation can be achieved.


> All I want to do is to make sure that operators are O.K. with
> it. In other
> words, to have one PE for IPLS functionality and another for VPLS
> functionality.

If an operator plans to provide IPLS or VPLS
wouldn't she/he engineer the PE to meet the vpls/ipls requirements?

With VPLS you can offer TLS service to both IP and non-IP end points and with IPLS you can offer TLS service to IP end-points only.

-Ali


>In cases that the operator doesn't need to offer VPLS
> functionality, then all they need is an IPLS-capable PE. I
> just want to
> confirm if that's what the operators expect.
>

You may be asking fair question, I just don't see why an
operator needs two distinct PEs if it needs to
offer both IPLS and VPLS?

Looking at the IPLS draft, I may agree with you that there
is too much emphasis that an IPLS-capable-PE is a PE
that cannot provide VPLS service while in fact - in my
opinion - it should state that if an operator knows apriori
that the CEs are all IP host/routers, then an IPLS like
service may be offered (to what extent it simplifies/optimize
the PE compared to VPLS service needs to be known)...and IPLS
(as Steven pointed out) is considered just additional tool in
an operator toolbox (unless in your question you wanted
to refer/point to something else).

Hamid.







--=====================_115040329==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 20:17:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28147 for ; Thu, 15 May 2003 20:17:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4G0JWI01335 for ; Thu, 15 May 2003 20:19:32 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4G0JTf10867 for ; Thu, 15 May 2003 20:19:30 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Loa Andersson Cc: Rick Wilder , PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Thu, 15 May 2003 20:17:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31B40.7B98CFD8" X-LYRIS-Message-Id: 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_01C31B40.7B98CFD8 Content-Type: text/plain; charset="iso-8859-1" Loa, > > the question from Hamid is what I should call "loaded". It's not "loaded" or "unloaded". It's a simple question and it will be nice to have an answer. That's all. Hamid. ------_=_NextPart_001_01C31B40.7B98CFD8 Content-Type: text/html; charset="iso-8859-1" RE: decisions on L2 solutions documents

Loa,

>
> the question from Hamid is what I should call "loaded".

It's not "loaded" or "unloaded". It's a simple question
and it will be nice to have an answer. That's all. 

Hamid.

------_=_NextPart_001_01C31B40.7B98CFD8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 15 22:50:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00103 for ; Thu, 15 May 2003 22:50:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4G2qKI27922 for ; Thu, 15 May 2003 22:52:21 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4G2qGM05608 for ; Thu, 15 May 2003 22:52:16 -0400 (EDT) Date: Thu, 15 May 2003 19:41:04 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <47370328063.20030515194104@psg.com> To: PPVPN@nortelnetworks.com Subject: New WG co-chair MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- This note announces a management change for the PPVPN WG, effective immediately. I have asked Loa Andersson to step up as PPVPN co-chair and he has accepted this position. He will be replacing Marco Carugi, whom I would like to thank for his efforts in forming the WG and taking it to the point it is at today. -- Alex Zinin IETF SUB-IP Area Co-Director From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 02:22:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14774 for ; Fri, 16 May 2003 02:22:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4G6PBB29380 for ; Fri, 16 May 2003 02:25:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4G6P8726673 for ; Fri, 16 May 2003 02:25:09 -0400 (EDT) X-Original-Recipient: hbrahim@nortelnetworks.com Message-ID: <3EC482F7.1030808@pi.se> Date: Fri, 16 May 2003 08:19:35 +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: "Hamid Ould-Brahim" , PPVPN Subject: Re: decisions on L2 solutions documents References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailb.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailb.telia.com [194.22.194.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit maybe it is a "nice to know" question from your point of view i did not say "intentionally loaded, from Ricks point of view it is definitely a question that shouldn't be answered for the time being point was that whether or not Rick had enough support for making it a wg doc is not "interesting" now, and an answer on a yes and no basis would/could trigger an unfruitful discussion you've seen the issues brought up in the AD/wg chair discussion method to promote the draft to a wg doc is to address those questions /Loa Hamid Ould-Brahim wrote: > Loa, > > > > > the question from Hamid is what I should call "loaded". > > It's not "loaded" or "unloaded". It's a simple question > and it will be nice to have an answer. That's all. > > Hamid. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 02:48:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15232 for ; Fri, 16 May 2003 02:48:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4G6p7B03847 for ; Fri, 16 May 2003 02:51:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4G6p3h03800 for ; Fri, 16 May 2003 02:51:04 -0400 (EDT) Date: Fri, 16 May 2003 12:15:14 +0530 From: Manav Bhatia Subject: Re: [Isis-wg] Re: IS-IS as PE/CE routing protocol in BGP/MPLS/VPN To: stefano previdi , lidefeng Cc: ppvpn@nortelnetworks.com, isis-wg@ietf.org Reply-to: Manav Bhatia Message-id: <03db01c31b76$b5b0f570$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000c01c3190b$1418a540$07436e0a@HUAWEI.COM> <048801c31ad7$51225080$b4036c6b@sisodomain.com> <200305152146.h4FLkER18698@strange-brew.cisco.com> X-SMTP-HELO: mailout3.samsung.com X-SMTP-MAIL-FROM: manav@samsung.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: u33.gpu114.samsung.co.kr [203.254.224.33] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Stefano, AFAIK a sham link is only required when two VPN sites that belong to the same area share a direct backdoor link. If no backdoor link exists between the sites then no sham link is required. So what happens if i dont have that direct (backdoor) link between two different VPN sites or if there is no IS-IS adjacency over that backdoor link? Regards, Manav ----- Original Message ----- From: "stefano previdi" To: "Manav Bhatia" ; "lidefeng" Cc: ; Sent: Friday, May 16, 2003 3:15 AM Subject: Re: [Isis-wg] Re: IS-IS as PE/CE routing protocol in BGP/MPLS/VPN If I understand correctly the concept of the sham-link, the PE will receive a mp-bgp route containing the other end of the sham-link and the extComm describing it. This route need to be the best among other (possible) mp-bgp routes (with same RD) for the same prefix. If such route is best, then you won't really import it into the vrf but rather you will "use it" in order to add a (fake) adjacency into the isis lsp the PE will originate. Then you run spf as part of the isis instance running in the vrf and compute your routes. After spf computation you'll find that the prefixes of the remote site are reachable through the sham link (according to the metric of your links of course). So I don't believe you really need to change the bgp selection process. Btw, I don't see any reference to TLVs 22 and 135 in the draft... s. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 04:20:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16333 for ; Fri, 16 May 2003 04:20:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4G8NCB26652 for ; Fri, 16 May 2003 04:23:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4G8N9l03925 for ; Fri, 16 May 2003 04:23:09 -0400 (EDT) Message-ID: <3EC49F6F.9050902@alcatel.fr> Date: Fri, 16 May 2003 10:21:03 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 CC: ppvpn@nortelnetworks.com Subject: Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt References: <5.2.0.9.0.20030515180207.02000c68@email> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 05/16/2003 10:21:02, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 05/16/2003 10:21:04, Serialize complete at 05/16/2003 10:21:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new X-SMTP-HELO: smail3.alcatel.fr X-SMTP-MAIL-FROM: yacine.el_mghazli@alcatel.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: gc-na5.alcatel.fr [64.208.49.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit hi all, another last call comment on the 2547bis draft: the RFC should state clearly if the following situation is the normal situation: > In a situation where site A belongs to VPN1, site B to VPN2 and site C > to VPN1 and VPN2; then sites A,B,C map to 3 different VRFs, and the > VRF for C will contain the union of the routings tables of VPN1 and > VPN2. I found some kind of inconsistency (at least unclear) between the 2 paragraphs quoted below: [section 3.1. "VRFs and Attachment Circuits"] "We allow the case in which a single attachment circuit is associated with a set of VRFs, rather than with a single VRF. This can be useful if it is desired to divide a single VPN into several "sub- VPNs", each with different connectivity restrictions, where some characteristic of the customer packets is used to select from among the sub-VPNs. For simplicity though, we will usually speak of an attachment circuit as being associated with a single VRF." [section 3.2. "Associating IP packets with VRF"]: "If an attachment circuit leads to a site which is in multiple VPNs, the attachment circuit may still associated with a single VRF, in which case the VRF will contain routes from the full set of VPNs of which the site is a member." thanks, yacine From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 04:23:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16379 for ; Fri, 16 May 2003 04:23:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4G8PnB00382 for ; Fri, 16 May 2003 04:25:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4G8Pjl07872 for ; Fri, 16 May 2003 04:25:46 -0400 (EDT) Message-Id: <200305160823.h4G8NIR17757@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Manav Bhatia , lidefeng Subject: Re: [Isis-wg] Re: IS-IS as PE/CE routing protocol in BGP/MPLS/VPN Date: Fri, 16 May 2003 10:23:00 +0200 X-Mailer: KMail [version 1.3.1] Cc: ppvpn@nortelnetworks.com, isis-wg@ietf.org References: <000c01c3190b$1418a540$07436e0a@HUAWEI.COM> <200305152146.h4FLkER18698@strange-brew.cisco.com> <03db01c31b76$b5b0f570$b4036c6b@sisodomain.com> In-Reply-To: <03db01c31b76$b5b0f570$b4036c6b@sisodomain.com> MIME-Version: 1.0 X-SMTP-HELO: strange-brew.cisco.com X-SMTP-MAIL-FROM: sprevidi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: weird-brew.cisco.com [144.254.15.118] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA16379 On Friday 16 May 2003 08:45, Manav Bhatia wrote: > Stefano, > > AFAIK a sham link is only required when two VPN sites that belong to the > same area share a direct backdoor link. If no backdoor link exists between > the sites then no sham link is required. > > So what happens if i dont have that direct (backdoor) link between two > different VPN sites or if there is no IS-IS adjacency over that backdoor > link? Then you do the usual propagation from/to isis/mp-bgp and I believe BGP has already all you need to make your own selection decision (localPref, MED). Anyway, if you advertise the same prefix from different sites, I suppose is because these sites have some sort of common connectivity to that prefix... and what is the operational scenario where the same prefix is advertised with different metric-type ? If it is just a matter of preference you can just play with the metric value (with wide metric you have all you need) s. > > Regards, > Manav > > ----- Original Message ----- > From: "stefano previdi" > To: "Manav Bhatia" ; "lidefeng" > Cc: ; > Sent: Friday, May 16, 2003 3:15 AM > Subject: Re: [Isis-wg] Re: IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > > If I understand correctly the concept of the sham-link, the > PE will receive a mp-bgp route containing the other end of > the sham-link and the extComm describing it. This route need > to be the best among other (possible) mp-bgp routes (with > same RD) for the same prefix. If such route is best, then you > won't really import it into the vrf but rather you will "use > it" in order to add a (fake) adjacency into the isis lsp the > PE will originate. Then you run spf as part of the isis > instance running in the vrf and compute your routes. After > spf computation you'll find that the prefixes of the remote > site are reachable through the sham link (according to the > metric of your links of course). So I don't believe you > really need to change the bgp selection process. > > Btw, I don't see any reference to TLVs 22 and 135 in the > draft... > > s. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 07:53:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20376 for ; Fri, 16 May 2003 07:53:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GBtlB21175 for ; Fri, 16 May 2003 07:55:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GBtih18484 for ; Fri, 16 May 2003 07:55:44 -0400 (EDT) Message-Id: <200305161149.h4GBnek3022488@anf-webmail.abercrombie.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: EMUmail 5.2 X-Originating-Ip: 80.179.100.100 X-Webmail-User: m_bank@anfmail.com To: m_bank@anfmail.com MIME-Version: 1.0 X-Http_host: www.anfmail.com From: m_bank@anfmail.com Subject: GREEING Date: Fri, 16 May 2003 11:49:40 GMT Reply-To: m_bank@anfmail.com X-SMTP-HELO: anf-webmail.abercrombie.com X-SMTP-MAIL-FROM: m_bank@anfmail.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: host209.abercrombie.com [208.255.29.209] X-LYRIS-Message-Id: Content-Transfer-Encoding: binary From The Desk Of Mr.Mohammed Dauda, metrolitan Bank Of Nigeria Plc, Lagos Nigeria. Email:m_dauda4@yahoo.com Dear Sir, I am Mr.Mohammed Dauda ,Bank Manager of metrolitan Bank PLC,Lagos Branch.I got your contact from the world trade center (WTC) Regional office in lagos,Nigeria.Although the details of my intention was not made known to them.Actually,I listed your name amongst four other names & prayed over them & decided to contact you directly.I have a very urgent & confidential bussiness proposition for you & for our overall mutual interest. on june 6 1997,an American oil consultant/contractor with the Nigerian National Petroleum Corporation Mr Barry Kelly made a numbered time(fixed) deposit for twelve calendar months,valued at USD$15,000,000.00(fifteen million dollars) in my branch.Upon maturity,i sent a routine notification to his forwarded address but got no reply.After a month we sent a reminder,& finally we discovered from his contract employers NNPC,that Mr.Barry died in an automobile accident.On further investigation,i found out that he did not leave a WILL & all attempts to trace his next of kin were fruitless.I therefore made further investigation & discovered that Mr.Barry did not declare any next of kin in all his official documents,including his bank deposit paperwork. This sum USD$15,000,000.00 is still floating in the bank and the interest is being rolled over with the principal sum at the end of each year.No one will come forward to claim it.According to Nigerian Laws, At the expiration of 6 (six) years,the money will revert to the ownership of the Nigerian government if nobody applies to claim the funds. Consequently,my proposal is that i will like you as a foreigner to stand in as a next of kin of Mr Barry Kelly.This is simple 1)I will like you to provide me immediately with your full names & address so that the attorney will prepare the necessary documents & affidavits,which will put you as next of kin. 2)We shall employ the services of an attorneys for drafting & notarization of the WILL and obtain the necessary documents and letter of robate/administration in your favour for the transfer. 3)Forward to me your bank details ,which you will provide to facilitate the transfer of this money to you as the beneficiary.The money will be paid into your account for us to share in the ratio of 60% for me and 30% for you and 10% for expencies.There is no risk at all as the attorney and my position will do the paperwork for this transaction as the branch manager guarantees the successful execution of this transaction.If you are interested,please reply immediately via this private email address and also send to me your telephone number and fax number. Upon your response,I shall then provide you with more details and relevant documents that will help you understand.PLEASE OBSERVE UTMOST CONFIDENTIALITY,and be rest assured that this would be most profitable for both of us because i shall require your assistance to invest my share in your country. Awaiting your urgent reply via this email above,please save me the anxiety of endless waiting. God bless you. Mr.Mohammed Dauda. metrolitan Bank PLC, Lagos,Nigeria. --------------------------------------------------------------- This message was sent using ANFMAIL at Abercrombie.com. Please help us fight spam by forwarding any unsolicited emails to abuse@anfmail.com. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 09:38:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23952 for ; Fri, 16 May 2003 09:38:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GDepB29444 for ; Fri, 16 May 2003 09:40:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GDemf26552 for ; Fri, 16 May 2003 09:40:48 -0400 (EDT) Message-Id: <200305161338.h4GDcXkL027396@rtp-core-1.cisco.com> To: Cheng-Yin.Lee@alcatel.com cc: Muneyoshi Suzuki , mattsquire@acm.org, zinin@psg.com, PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-reply-to: Your message of Thu, 15 May 2003 17:13:25 -0400. <3EC402F5.F17017BF@alcatel.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, 16 May 2003 09:38:33 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Cheng-Yin> If existing routers and bridges cannot expect an emulated LAN Cheng-Yin> service, and cannot work properly using VPLS, how useful are the Cheng-Yin> solutions then? Nobody said that existing routers and bridges should not be able to work properly with VPLS. What is at issue is the extent to which this requires absolutely perfect emulation. Cheng-Yin> I am afraid the WG may not be producing useful work. Suppose the WG produced something which only handled 99.9% of the existing base. Would this be "not useful"? From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 09:48:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24574 for ; Fri, 16 May 2003 09:48:09 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GDofB04346 for ; Fri, 16 May 2003 09:50:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GDobE05023 for ; Fri, 16 May 2003 09:50:38 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Subject: Structuring L2VPN work... Date: Fri, 16 May 2003 09:48:10 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200305121734.h4CHYGH9010451@rtp-core-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp2g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: aismtp2g.bellsouth.com [139.76.165.197] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Assuming the WG is to be split in order to provide greater focus and progress the work,... I have some doubts that the current proposals to partition along the lines of Layer2 vs Layer 3 PPVPNs will achieve (my) desired results in terms of providing effective solutions for any of my network service problems. Instead, I expect this will result in elegant solutions to the wrong problems which will ultimately prove difficult for folks like me to utilize. I think it would behoove the group to consider splitting between (i) INTRA-AS PPVPN and (ii)INTER-AS PPVPNs . I expect this partition would reflect real differences in 1) the scaling properties of the underlying solutions 2) the types of SPs interested in these protocols 3) the service problems that these SPs are interested in having solved 4) the protocol environments in which solutions must be found. Such a split would also allow both groups to focus on developing and leveraging commonality between the L2 & L3 VPN solutions where possible. regards Steven Wright From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 09:54:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24813 for ; Fri, 16 May 2003 09:54:52 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GDvOB07815 for ; Fri, 16 May 2003 09:57:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GDvLE10164 for ; Fri, 16 May 2003 09:57:21 -0400 (EDT) Message-Id: <200305161353.h4GDrSkL001465@rtp-core-1.cisco.com> To: "Hamid Ould-Brahim" cc: Ali Sajassi , Himanshu Shah , steven.wright@BellSouth.com, PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN - IPLS & ARP Mediation In-reply-to: Your message of Thu, 15 May 2003 16:49:01 -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: Fri, 16 May 2003 09:53:28 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Ali's point is that once you have deployed a PE which can do the MAC learning in the data plane, you can always shut off the other unnecessary parts of the VPLS service (e.g., bridging control protocols, sequencing), and you have the equivalent of an IPLS service. This assumes that all the PEs on which you want to provide the IPLS service also provide the VPLS service. It also assumes that the MAC learning in the data plane comes "for free", so that there is no advantage to shutting it off on certain ports and on certain pseudowires. It also overlooks the fact that the IPLS is a true multipoint service; like L3VPN, but unlike VPLS, when you receive a packet from a pseudowire, you don't care where it came from because you don't have to do any MAC address learning from the packet. Since there is no point-to-point state to maintain, the overhead is less and the service should be more scalable. If you think that the main requirement is providing an ethernet service which allows you to transparently connect bridged ethernet networks, then you'll tend to think VPLS solves the problem and IPLS is just a niche which doesn't really merit its own architecture. If, on the other hand, you think that the main requirement is providing a lan-like intetrconnect for IP routers, and that the generalized ethernet service is just a niche, then IPLS seems much more important, as VPLS is really overkill. I also don't see any reason why IPLS and "VPLS as restricted to interconnect of IP routers" cannot be made interoperable. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 10:27:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27247 for ; Fri, 16 May 2003 10:27:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GEULB08798 for ; Fri, 16 May 2003 10:30:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GEUJP20335 for ; Fri, 16 May 2003 10:30:19 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6C3A@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Rick Wilder'" , Loa Andersson , "Hamid Ould-Brahim" Cc: PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Fri, 16 May 2003 10:28:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BB7.5E22E098" X-LYRIS-Message-Id: 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_01C31BB7.5E22E098 Content-Type: text/plain Loa/Rick My whish was to have these questions public before the decision was made, so we will be more effective to defend our postion. While your questions are reasonable and important for the debate, I do have my self couple of clarifications that I would like to be addressed: - these are the only questions regarding the draft? - the decision for GVPLS as WD is revocable or depends how satisfactory are the answers to such questions? - if the decision is not irrevocable, do we have a deadline till the debate would proof positive or not ? A new version of the draft, that would addres your questions, would a prefer way to go - can we recognize that it was support in the group from both vendors and SPs? I would try to answer to your questions during the next days. However, I would like to invite other people to participate in the debate, that have supported the draft, and they know GVPLS is working in the field and is scalable as is defined in the draft. In a simplistic view, I see the following relationship: - vpls < hvpls < gvpls VPLS is the default one - probable every vendor thought about this solution. HVPLS was invented because VPLS doesn't scale and impose some restrictions that would be hard validated in the real field. HVPLS does scale in only one dimension - VC-LABEL space. GVPLS was invented to increase the scalability in multiple dimensions, and to distribute the load between different network components so the network performance and stability is maintained. As any other solution a this level, there are more "liberal" ideas proposed in the draft [like M2P], and probable they request more time to be incorporated in the current cycle of thinking. Cheers Vasile -----Original Message----- From: Rick Wilder [mailto:rwilder@masergy.com] Sent: Thursday, May 15, 2003 6:34 PM To: Loa Andersson; Ould-Brahim, Hamid [CAR:1A00:EXCH] Cc: PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Agreed, Loa. Here are the questions/requests-for-clarification that came up. a) how do the discovery and signaling parts of the document relate to those described in the other solutions documents and which of them are suggested to be mandatory to implement b) what is the status of the MAC-in-MAC encapsulation work in IEEE? c) for the case where the U-PE network is a completely ethernet switched network, and encapsulation like MAC-in-MAC is used, what part of the architecture belongs to the IETF? c) definition of M2P PWs is outside the scope of this WG and probably should go to PWE3 d) how does the definition of semantics of the PW CW given in the document relate to those defined in the PWE3 WG? -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, May 15, 2003 4:08 PM To: Hamid Ould-Brahim Cc: Rick Wilder; PPVPN@nortelnetworks.com Subject: Re: decisions on L2 solutions documents Rick, the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the wg support from the mailing list at the time, which I don't know), that the issues the AD / wg chair discussion should be made available to the list/wg. Review results may change how you feel about making things wg doc or not, even if they come form ADs :) Mailing list discussion of those review results may lift or confirm those conserns. /Loa Hamid Ould-Brahim wrote: > Rick, > > > > > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is > not > made a WG document at this time. Several questions have > come up > regarding this document during discussions between > the ADs and WG > chairs. In order to make an informed decision, > these questions will > be posted shortly to begin a discussion. > > > In your opinion as ppvpn chair was there consensus on the mailing list > that this draft should advance to WG doc status? > > Hamid. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se ------_=_NextPart_001_01C31BB7.5E22E098 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: decisions on L2 solutions documents

Loa/Rick

My whish was to have these questions public before = the decision was made, so we will be  more effective to defend our = postion.

While your questions are reasonable and important for = the debate, I do have my self couple of clarifications that I would = like to be addressed:

- these are the only questions regarding the = draft?
- the decision for GVPLS as WD is revocable or = depends how satisfactory
  are the answers to such questions?
- if the decision is not irrevocable, do we have a = deadline till the debate would proof positive or not ? A new version of = the draft, that would addres your questions, would  a prefer way = to go

- can we recognize that it was support in the  = group from both vendors and SPs?

I would try to answer to your questions during the = next days. However, I would like to invite other people to participate = in the debate, that have supported the draft, and they know GVPLS is = working in the field and is scalable as  is defined in the = draft.

In a simplistic view, I see the following = relationship:
- vpls < hvpls < gvpls

VPLS is the default one - probable every vendor = thought about this solution.
HVPLS was invented because VPLS doesn't scale and = impose some restrictions that would be hard  validated in the real = field. HVPLS does scale in only one dimension - VC-LABEL = space.

GVPLS was invented to increase the scalability in = multiple dimensions, and to distribute the load between different = network components so the network performance and stability is = maintained. As any other solution a this level, there are  more = "liberal" ideas proposed in the draft [like M2P], and = probable they request more time to be incorporated in the current cycle = of thinking.

Cheers
   Vasile

-----Original Message-----
From: Rick Wilder [mailto:rwilder@masergy.com] =
Sent: Thursday, May 15, 2003 6:34 PM
To: Loa Andersson; Ould-Brahim, Hamid = [CAR:1A00:EXCH]
Cc: PPVPN@nortelnetworks.com
Subject: RE: decisions on L2 solutions = documents



Agreed, Loa.

Here are the questions/requests-for-clarification = that came up.

    a) how do the discovery and = signaling parts of the document
       relate to those = described in the other solutions documents and which
       of them are = suggested to be mandatory to implement

    b) what is the status of the = MAC-in-MAC encapsulation work in IEEE?

    c) for the case where the U-PE = network is a completely ethernet
       switched = network, and encapsulation like MAC-in-MAC is used,
       what part of = the architecture belongs to the IETF?

    c) definition of M2P PWs is = outside the scope of this WG and
       probably should = go to PWE3

    d) how does the definition of = semantics of the PW CW given
       in the document = relate to those defined in the PWE3 WG?

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, May 15, 2003 4:08 PM
To: Hamid Ould-Brahim
Cc: Rick Wilder; PPVPN@nortelnetworks.com
Subject: Re: decisions on L2 solutions = documents

Rick,

the question from Hamid is what I should call = "loaded". The real issue here is (evn if you felt you had the = wg support from the mailing list at the time, which I don't know), that = the issues the AD / wg chair discussion should be made available to the = list/wg.

Review results may change how you feel about making = things wg doc or not, even if they come form ADs :)

Mailing list discussion of those review results may = lift or confirm those conserns.

/Loa

Hamid Ould-Brahim wrote:
> Rick,
>
>  >
>  > - GVPLS/LPE = draft-radoaca-ppvpn-gvpls-01.txt : This draft is  > not
> made a WG document at this time. Several = questions have  > come up
> regarding this document during discussions = between  > the ADs and WG
> chairs. In order to make an informed = decision,  > these questions will
> be posted shortly to begin a discussion.  = >
>
> In your opinion as ppvpn chair was there = consensus on the mailing list
> that this draft should advance to WG doc = status?
>
> Hamid.
>


--
/Loa

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


------_=_NextPart_001_01C31BB7.5E22E098-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 12:55:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02889 for ; Fri, 16 May 2003 12:55:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GGwFB00335 for ; Fri, 16 May 2003 12:58:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GGwBs13433 for ; Fri, 16 May 2003 12:58:12 -0400 (EDT) Message-Id: <200305161651.h4GGpmkL020470@rtp-core-1.cisco.com> To: Mark Duffy cc: ppvpn@nortelnetworks.com Subject: Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt In-reply-to: Your message of Thu, 15 May 2003 18:13:19 -0400. <5.2.0.9.0.20030515180207.02000c68@email> 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, 16 May 2003 12:51:48 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Thanks for your comments, most have been incorporated. Mark> The title is currently "BGP/MPLS VPNs". Since this work originated Mark> there are now other, completely different VPN approaches that also use Mark> BGP and MPLS. For this reason perhaps, many people refer to VPNs of Mark> this type as "2547 VPNs". That may become awkward as this draft Mark> becomes an RFC, or if there are future revisions. Perhaps a more Mark> specific name should be applied. "BGP-MPLS L3 VPNs" perhaps? I have no problem with "BGP/MPLS L3 VPNs" as the title, though I've tended to use "2547-style VPNs" in other documents. Frankly, I never have thought of a really catchy name. Mark> Sect 4.1(?) There have been some inconclusive discussions on the list Mark> as to whether it is advisable to use the same RD or different RDs for Mark> VRFs in a given VPN that are in different PEs. The question seems Mark> especially important in the case where a site is multihomed to 2 Mark> different PEs. If a route from the CE is advertised by both PEs with Mark> the same RD, BGP path selection on the VPN-IPv4 routes can be used. Mark> If a route from the CE is advertised by both PEs with different RDs, Mark> then the conflict needs to be resolved in another way at remote PEs Mark> when the RDs are stripped and the 2 IPv4 routes for the same prefix Mark> would be placed in a VRF. It would be good if the draft gave guidance Mark> on this issue. This seems like a deployment issue. Mark> I think "support LDP" is not a strong enough requirement here to Mark> ensure interoperability. If this requirement is to be retained at all Mark> shouldn't it also require support for some specific combination of Mark> DU/DOD, ordered/independent control, liberal/conservative retention? Don't you believe in section 5.2.3 of RFC 3031? From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 14:34:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06222 for ; Fri, 16 May 2003 14:34:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GIbSB15756 for ; Fri, 16 May 2003 14:37:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GIbO327639 for ; Fri, 16 May 2003 14:37:24 -0400 (EDT) Message-Id: <4.3.2.20030516140719.028fab60@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 16 May 2003 14:32:23 -0400 To: Yakov Rekhter , Juha Heinanen , Alex Zinin From: Ross Callon Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider Cc: PPVPN@nortelnetworks.com In-Reply-To: <200305121702.h4CH2Pu57621@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: rcallon@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: At 10:02 AM 5/12/2003 -0700, Yakov Rekhter wrote: >... The inter-AS >solution must has enough details from the very beginning to >demonstrate that there is a a backwards compatible migration path >from intra-provider to inter-provider. > >Yakov. My understanding is that this discussion is still related to what goes into the proposed charter for the Layer 3 VPN working group. In this context we don't have to solve the problem right now, we just need to decide what goes into the charter. My personal view is that multi-AS one-provider is important enough that it is worth mentioning in the charter. Multi-AS, multi-provider is probably also something that we want to have as a possible option. Thus I think that we might as well mention these in the charter. I am not so sure about slowing down the base documents in order to get the multi-AS cases fully fleshed out. We have already slowed down the base documents to wait to finish the Framework and Requirements documents, and there is the possibility of slowing them down to wait for a security document. To me whether to insist on the inter-AS case being solved and fully documented before progressing the solutions documents comes down to three things: (i) How important are the multi-AS cases; and (ii) How confident are we that if we postpone the multi-AS work, that we won't end up with a situation where we wish that we had changed the base documents; and (iii) How long will it take to fully document the inter-AS cases? A question for Alex and Thomas Narten: Suppose hypothetically that there is consensus to work on the inter-AS cases, and suppose that we don't want to slow down the base documents to wait for this to complete. In this case, the L3 VPN working group might work on progressing existing documents (the long list from the proposed charter that Alex sent out) as a high priority item, and work on the inter-AS cases as a lower priority. In this case, would we want to explicitly mention the Inter-AS cases in the charter? Ross From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 15:34:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08912 for ; Fri, 16 May 2003 15:34:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GJaaB11446 for ; Fri, 16 May 2003 15:36:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GJaWh09621 for ; Fri, 16 May 2003 15:36:32 -0400 (EDT) Message-Id: <5.2.1.1.0.20030516153042.03b08c98@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 16 May 2003 15:34:18 -0400 To: william.a.bjorkman@verizon.com From: "Andrew G. Malis" Subject: RE: Draft charter for L2VPN Cc: PPVPN@nortelnetworks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 May 2003 19:34:24.0741 (UTC) FILETIME=[2831B150:01C31BE2] X-SMTP-HELO: ns2.vivacenetworks.com X-SMTP-MAIL-FROM: Andy.Malis@vivacenetworks.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: [64.221.212.135] X-LYRIS-Message-Id: I'm neutral on IPLS (let the debate continue) but I certainly agree that ARP meditation is important and should be included in the WG charter (whether there's one or two WGs, it should still be in there as a L2 work item). Thanks, Andy -------- At 5/14/2003 03:40 PM -0400, william.a.bjorkman@verizon.com wrote: >yes...definitely include both... > >/bb > >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Monday, May 12, 2003 1:34 PM >To: Alex Zinin >Cc: PPVPN@nortelnetworks.com >Subject: Re: Draft charter for L2VPN > >Two L2VPN charter issues that come up frequently are (a) whether >ARP Mediation (for allowing IP traffic on a p2p link between two >unlike attachment circuits) falls into the charter, and (b) whether >IPLS (for allowing LAN-like connectivity among a set of IP routers, >without requiring MAC learning, BPDUs, etc.) falls into >the charter. If there is actually going to be an L2VPN charter, >I'd like to see this settled, preferably in favor of including these efforts. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 18:36:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13562 for ; Fri, 16 May 2003 18:36:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GMcoB09619 for ; Fri, 16 May 2003 18:38:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GMcle26143 for ; Fri, 16 May 2003 18:38:48 -0400 (EDT) Message-ID: <3EC566FB.60305@level3.net> Date: Fri, 16 May 2003 16:32:27 -0600 From: Luca Martini Organization: Level3 Communications LLC. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- MIME-Version: 1.0 To: PPVPN@nortelnetworks.com Subject: Call for Presenations at MPLS 2003, October 26-28, Washington DC Content-Type: text/plain; charset=windows-1252; format=flowed X-SMTP-HELO: ix.eng.level3.com X-SMTP-MAIL-FROM: luca@level3.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: machine77.Level3.com [209.244.4.106] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA13562 The MPLS 2003 Conference will be held in Washington D.C. from October 26 through October 28. This year’s conference will include but not limited to topics such as: - MPLS as a convergence technology - MPLS network management and operational issues - Provisioning and migration strategies - MPLS in multi-AS networks - L2 VPNs (pseudo-wire, VPLS, and other) - L3 VPNs (BGP/MPLS, IPSec interworking, virtual routers, and other) - Scalability and performance - Traffic engineering and QoS - Network processor architectures for next generation applications - Testing MPLS applications and performance - Network security - Disaster recovery - Reliability and graceful restart techniques - Optical Integration and challenges The Program Committee of MPLS 2003 is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution please send a one page long proposal, including speaker’s contact details to the attention of the Technical Program Committee at TPC@mpls2003.com by June 27, 2003. See www.mpls2003.com for more details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider and user community are solicited on new technologies and operational experience. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 16 18:37:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13581 for ; Fri, 16 May 2003 18:37:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GMdqB11019 for ; Fri, 16 May 2003 18:39:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4GMdne27626 for ; Fri, 16 May 2003 18:39:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BFB.6B31DD0C" Subject: RE: decisions on L2 solutions documents Date: Fri, 16 May 2003 18:35:14 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C489@m-va-bsod03.add0.masergy.com> Thread-Topic: decisions on L2 solutions documents thread-index: AcMbt2L4MOwLS3c5TCiI6vy8Iy2YYwAQOmtQ From: "Rick Wilder" To: "Vasile Radoaca" , "Loa Andersson" , "Hamid Ould-Brahim" Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C31BFB.6B31DD0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vasile, =20 See my comments in-line. =20 -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]=20 Sent: Friday, May 16, 2003 8:28 AM To: Rick Wilder; Loa Andersson; Hamid Ould-Brahim Cc: PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents =20 Loa/Rick=20 My whish was to have these questions public before the decision was made, so we will be more effective to defend our postion. I think this is in line with the course we are taking. We will have a public discussion of these questions prior to making a decision about the future of the draft in the WG. While your questions are reasonable and important for the debate, I do have my self couple of clarifications that I would like to be addressed: - these are the only questions regarding the draft?=20 I can't guarantee that. Those are the questions so far. During the discussion others could come up. In a reasonable time we should reach a point where we can make an informed decision. - the decision for GVPLS as WD is revocable or depends how satisfactory=20 are the answers to such questions?=20 All that has been said is that we'll have a discussion, get more information, and then decide. - if the decision is not irrevocable, do we have a deadline till the debate would proof positive or not ? A new version of the draft, that would addres your questions, would a prefer way to go I don't think we want a long-term on-going debate. Let Loa and I decide schedule details and get back to you early next week. - can we recognize that it was support in the group from both vendors and SPs?=20 The email list input is not forgotten. I would try to answer to your questions during the next days. However, I would like to invite other people to participate in the debate, that have supported the draft, and they know GVPLS is working in the field and is scalable as is defined in the draft. Input is invited from the WG as a whole as long as it can be focused on clarifying the draft and analysis of its merits. In a simplistic view, I see the following relationship:=20 - vpls < hvpls < gvpls=20 VPLS is the default one - probable every vendor thought about this solution.=20 HVPLS was invented because VPLS doesn't scale and impose some restrictions that would be hard validated in the real field. HVPLS does scale in only one dimension - VC-LABEL space. GVPLS was invented to increase the scalability in multiple dimensions, and to distribute the load between different network components so the network performance and stability is maintained. As any other solution a this level, there are more "liberal" ideas proposed in the draft [like M2P], and probable they request more time to be incorporated in the current cycle of thinking.=20 Cheers=20 Vasile=20 Thanks for your help, Vasile! =20 Rick -----Original Message-----=20 From: Rick Wilder [mailto:rwilder@masergy.com]=20 Sent: Thursday, May 15, 2003 6:34 PM=20 To: Loa Andersson; Ould-Brahim, Hamid [CAR:1A00:EXCH]=20 Cc: PPVPN@nortelnetworks.com=20 Subject: RE: decisions on L2 solutions documents=20 =20 Agreed, Loa.=20 Here are the questions/requests-for-clarification that came up.=20 a) how do the discovery and signaling parts of the document=20 relate to those described in the other solutions documents and which=20 of them are suggested to be mandatory to implement=20 b) what is the status of the MAC-in-MAC encapsulation work in IEEE?=20 c) for the case where the U-PE network is a completely ethernet=20 switched network, and encapsulation like MAC-in-MAC is used,=20 what part of the architecture belongs to the IETF?=20 c) definition of M2P PWs is outside the scope of this WG and=20 probably should go to PWE3=20 d) how does the definition of semantics of the PW CW given=20 in the document relate to those defined in the PWE3 WG?=20 -----Original Message-----=20 From: Loa Andersson [mailto:loa@pi.se]=20 Sent: Thursday, May 15, 2003 4:08 PM=20 To: Hamid Ould-Brahim=20 Cc: Rick Wilder; PPVPN@nortelnetworks.com=20 Subject: Re: decisions on L2 solutions documents=20 Rick,=20 the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the wg support from the mailing list at the time, which I don't know), that the issues the AD / wg chair discussion should be made available to the list/wg. Review results may change how you feel about making things wg doc or not, even if they come form ADs :)=20 Mailing list discussion of those review results may lift or confirm those conserns.=20 /Loa=20 Hamid Ould-Brahim wrote:=20 > Rick,=20 >=20 > >=20 > > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is > not > made a WG document at this time. Several questions have > come up=20 > regarding this document during discussions between > the ADs and WG=20 > chairs. In order to make an informed decision, > these questions will > be posted shortly to begin a discussion. >=20 >=20 > In your opinion as ppvpn chair was there consensus on the mailing list > that this draft should advance to WG doc status?=20 >=20 > Hamid.=20 >=20 =20 --=20 /Loa=20 mobile + 46 739 81 21 64=20 email: loa@pi.se=20 =20 ------_=_NextPart_001_01C31BFB.6B31DD0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: decisions on L2 solutions documents

Vasile,

 

See my comments = in-line.

 

-----Original = Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: Friday, May 16, = 2003 8:28 AM
To: Rick Wilder; Loa = Andersson; Hamid Ould-Brahim
Cc: = PPVPN@nortelnetworks.com
Subject: RE: decisions on = L2 solutions documents

 

Loa/Rick

My whish was to have these questions public = before the decision was made, so we will be  more effective to defend our = postion.

I think this is in line with the course we are taking. = We will have a public discussion of these questions prior to making a = decision about the future of the draft in the WG.

While your questions are reasonable and = important for the debate, I do have my self couple of clarifications that I would like = to be addressed:

- these are the only questions regarding the = draft?

I can’t guarantee that. Those are the questions = so far. During the discussion others could come up. In a reasonable time we = should reach a point where we can make an informed decision.


- the = decision for GVPLS as WD is revocable or depends how satisfactory
  are the answers = to such questions?

All that has been said is that we’ll have a = discussion, get more information, and then decide.


- if the = decision is not irrevocable, do we have a deadline till the debate would proof = positive or not ? A new version of the draft, that would addres your questions, = would  a prefer way to go

I don’t think we want a long-term on-going = debate. Let Loa and I decide schedule details and get back to you early next = week.

- can we recognize that it was support in = the  group from both vendors and SPs?

The email list input is not = forgotten.

I would try to answer to your questions = during the next days. However, I would like to invite other people to participate = in the debate, that have supported the draft, and they know GVPLS is working in = the field and is scalable as  is defined in the = draft.

Input is invited from the WG as a whole as long as it = can be focused on clarifying the draft and analysis of its = merits.

In a simplistic view, I see the following relationship:
- vpls < hvpls < = gvpls

VPLS is the default one - probable every = vendor thought about this solution.
HVPLS was invented = because VPLS doesn't scale and impose some restrictions that would be hard  = validated in the real field. HVPLS does scale in only one dimension - VC-LABEL = space.

GVPLS was invented to increase the = scalability in multiple dimensions, and to distribute the load between different = network components so the network performance and stability is maintained. As = any other solution a this level, there are  more "liberal" ideas = proposed in the draft [like M2P], and probable they request more time to be = incorporated in the current cycle of thinking.

Cheers
   Vasile =

Thanks for your help, Vasile!

 

Rick

-----Original Message-----
From: Rick Wilder [mailto:rwilder@masergy.com] =
Sent: = Thursday, = May 15, 2003 6:34 PM
To: Loa Andersson; = Ould-Brahim, Hamid [CAR:1A00:EXCH]
Cc: = PPVPN@nortelnetworks.com
Subject: RE: decisions = on L2 solutions documents

 

Agreed, Loa.

Here are the = questions/requests-for-clarification that came up.

    a) how do the discovery = and signaling parts of the document
       relate to those described in the other solutions documents and = which
       of them are suggested to be mandatory to implement

    b) what is the status of = the MAC-in-MAC encapsulation work in IEEE?

    c) for the case where the = U-PE network is a completely ethernet
       switched network, and encapsulation like MAC-in-MAC is = used,
       what part of the architecture belongs to the IETF?

    c) definition of M2P PWs = is outside the scope of this WG and
       probably should go to PWE3

    d) how does the definition = of semantics of the PW CW given
       in the document relate to those defined in the PWE3 WG? =

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, May 15, = 2003 4:08 PM
To: Hamid = Ould-Brahim
Cc: Rick Wilder; PPVPN@nortelnetworks.com
Subject: Re: decisions = on L2 solutions documents

Rick,

the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the = wg support from the mailing list at the time, which I don't know), that the = issues the AD / wg chair discussion should be made available to the = list/wg.

Review results may change how you feel about = making things wg doc or not, even if they come form ADs :)

Mailing list discussion of those review = results may lift or confirm those conserns.

/Loa

Hamid Ould-Brahim wrote:
> Rick, =
>
>  = >
>  > - = GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is  > not =
> made a WG document = at this time. Several questions have  > come up
> regarding this = document during discussions between  > the ADs and WG
> chairs. In order to = make an informed decision,  > these questions will
> be posted shortly = to begin a discussion.  >
>
> In your opinion as = ppvpn chair was there consensus on the mailing list
> that this draft = should advance to WG doc status?
>
> = Hamid.
>

 

--
/Loa

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

 

=00 ------_=_NextPart_001_01C31BFB.6B31DD0C-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 17 00:25:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19033 for ; Sat, 17 May 2003 00:25:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4H4Rlv26547 for ; Sat, 17 May 2003 00:27:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4H4RiV06528 for ; Sat, 17 May 2003 00:27:44 -0400 (EDT) Message-Id: <5.2.0.9.0.20030516132949.020a93d0@email> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 17 May 2003 00:23:51 -0400 To: erosen@cisco.com, ppvpn@nortelnetworks.com From: Mark Duffy Subject: Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt In-Reply-To: <200305161651.h4GGpmkL020470@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: Thanks Eric, see below... At 12:51 PM 5/16/2003 -0400, Eric Rosen wrote: >Thanks for your comments, most have been incorporated. > >Mark> The title is currently "BGP/MPLS VPNs". Since this work originated >Mark> there are now other, completely different VPN approaches that also use >Mark> BGP and MPLS. For this reason perhaps, many people refer to VPNs of >Mark> this type as "2547 VPNs". That may become awkward as this draft >Mark> becomes an RFC, or if there are future revisions. Perhaps a more >Mark> specific name should be applied. "BGP-MPLS L3 VPNs" perhaps? > >I have no problem with "BGP/MPLS L3 VPNs" as the title, though I've tended >to use "2547-style VPNs" in other documents. Frankly, I never have thought >of a really catchy name. Whatever. I don't have anything catchy to suggest. Clearly this is not of great importance. >Mark> Sect 4.1(?) There have been some inconclusive discussions on the list >Mark> as to whether it is advisable to use the same RD or different RDs for >Mark> VRFs in a given VPN that are in different PEs. The question seems >Mark> especially important in the case where a site is multihomed to 2 >Mark> different PEs. If a route from the CE is advertised by both PEs with >Mark> the same RD, BGP path selection on the VPN-IPv4 routes can be used. >Mark> If a route from the CE is advertised by both PEs with different RDs, >Mark> then the conflict needs to be resolved in another way at remote PEs >Mark> when the RDs are stripped and the 2 IPv4 routes for the same prefix >Mark> would be placed in a VRF. It would be good if the draft gave guidance >Mark> on this issue. > >This seems like a deployment issue. That was the answer I expected :-) But I'm not sure I agree that it's only a deployment issue, or that if it is it is out of the scope of the doc. Does the scheme work if routes to the same subnet are advertised from VRFs in 2 PEs, using different RDs? I don't think the current memo says for this case how the PE learning these routes should decide which to install. I don't know if that constitutes a problem or not. If no one else is concerned by this then fine. >Mark> I think "support LDP" is not a strong enough requirement here to >Mark> ensure interoperability. If this requirement is to be retained at all >Mark> shouldn't it also require support for some specific combination of >Mark> DU/DOD, ordered/independent control, liberal/conservative retention? > >Don't you believe in section 5.2.3 of RFC 3031? I don't know if 5.2.3 implies that an LSR must support all these schemes to "comply with the MPLS architecture", or whether it implies that they have to behave as stated in 5.2.3 or else give up. Isn't an LSR allowed to support only DU? And its neighbor only DOD? For the case where LDP is used for label distribution, we could presumably look for guidance in rfc 3036. In sect 3.5.3 if the adjacent LSRs cannot agree on a common mode it says: If the label advertisement discipline determined in this way is unacceptable to an LSR, it must send a Session Rejected/Parameters Advertisement Mode Notification message in response to the Initialization message and not establish the session. There is similar text in 2.5.3 also. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 17 08:04:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06012 for ; Sat, 17 May 2003 08:04:13 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4HC6iv18930 for ; Sat, 17 May 2003 08:06:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4HC6f017542 for ; Sat, 17 May 2003 08:06:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20030517080217.02aa4690@pilgrim.cisco.com> X-Sender: tappan@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 May 2003 08:04:48 -0400 To: Mark Duffy From: Dan Tappan Subject: Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt Cc: erosen@cisco.com, ppvpn@nortelnetworks.com In-Reply-To: <5.2.0.9.0.20030516132949.020a93d0@email> References: <200305161651.h4GGpmkL020470@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tappan@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: At 12:23 AM 5/17/2003 -0400, Mark Duffy wrote: >>Mark> Sect 4.1(?) There have been some inconclusive discussions on the list >>Mark> as to whether it is advisable to use the same RD or different RDs for >>Mark> VRFs in a given VPN that are in different PEs. The question seems >>Mark> especially important in the case where a site is multihomed to 2 >>Mark> different PEs. If a route from the CE is advertised by both PEs with >>Mark> the same RD, BGP path selection on the VPN-IPv4 routes can be used. >>Mark> If a route from the CE is advertised by both PEs with different RDs, >>Mark> then the conflict needs to be resolved in another way at remote PEs >>Mark> when the RDs are stripped and the 2 IPv4 routes for the same prefix >>Mark> would be placed in a VRF. It would be good if the draft gave guidance >>Mark> on this issue. >> >>This seems like a deployment issue. > >That was the answer I expected :-) >But I'm not sure I agree that it's only a deployment issue, or that if it >is it is out of the scope of the doc. Does the scheme work if routes to >the same subnet are advertised from VRFs in 2 PEs, using different RDs? It is certainly (empirically) possible for an implementation to handle that case. I'd have said that it was an implementation issue, and therefore beyond the scope of the document. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 17 11:42:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10344 for ; Sat, 17 May 2003 11:42:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4HFiuv13223 for ; Sat, 17 May 2003 11:44:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4HFirS03973 for ; Sat, 17 May 2003 11:44:53 -0400 (EDT) Message-ID: From: "Jodi Randolph" To: Subject: We Can Pay Off Your Debt ............................ breakup Date: Sat, 17 May 03 11:35:49 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E7.E45DC.4DDC8BE69FB3.C2" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: customer-148-223-229-125.uninet.net.mx X-SMTP-MAIL-FROM: zcoughlin@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: customer-148-223-229-125.uninet.net.mx [148.223.229.125] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --E7.E45DC.4DDC8BE69FB3.C2 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable




Please go here if you would no longer like t= o receive our special offers.
baird loren = addition distal candid bombast bedraggle %RANDOM_W= ORD sectarian einsteinian balance and this website capsize --E7.E45DC.4DDC8BE69FB3.C2-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 19 13:25:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27960 for ; Mon, 19 May 2003 13:25:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4JHPeg26028 for ; Mon, 19 May 2003 13:25:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4JHPct04207 for ; Mon, 19 May 2003 13:25:38 -0400 (EDT) Message-Id: <200305191721.h4JHLvkL023110@rtp-core-1.cisco.com> To: Mark Duffy cc: ppvpn@nortelnetworks.com Subject: Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt In-reply-to: Your message of Sat, 17 May 2003 00:23:51 -0400. <5.2.0.9.0.20030516132949.020a93d0@email> 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, 19 May 2003 13:21:57 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Mark> Perhaps a more specific name should be applied. "BGP-MPLS L3 VPNs" Mark> perhaps? I'll probably go with "BGP/MPLS IP VPNs", to head off questions like "does it work with IPX and Appletalk". Mark> Does the scheme work if routes to the same subnet are advertised from Mark> VRFs in 2 PEs, using different RDs? Yes. Obviously though only one of those routes will be installed in the VRF. Mark> I don't think the current memo says for this case how the PE learning Mark> these routes should decide which to install. Correct, it does not. This question comes up regularly. One could specify, for example, that the one (or more, if load balancing is being provided) installed should be the one that BGP would have chosen if the two routes had had the same RD. Or one could specify that the one installed should be the one whose BGP next hop is the closest. There may also be other possibilities. However, leaving it as an implementation decision does not seem to cause any loops or interoperability problems, so it is probably best to leave it unspecified. Mark> Isn't an LSR allowed to support only DU? And its neighbor only DOD? Good catch, so per section 3.5.3 of RFC 3036 we should really require that DU be supported on non-LC-ATM interfaces, and DoD on LC-ATM interfaces. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 19 14:56:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00824 for ; Mon, 19 May 2003 14:55:50 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4JIw9g16943 for ; Mon, 19 May 2003 14:58:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4JIw6502208 for ; Mon, 19 May 2003 14:58:07 -0400 (EDT) Message-Id: <5.2.0.9.0.20030519144119.0203c630@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 19 May 2003 14:54:00 -0400 To: erosen@cisco.com, ppvpn@nortelnetworks.com From: Mark Duffy Subject: Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt In-Reply-To: <200305191721.h4JHLvkL023110@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: At 01:21 PM 5/19/2003 -0400, Eric Rosen wrote: >Mark> Perhaps a more specific name should be applied. "BGP-MPLS L3 VPNs" >Mark> perhaps? > >I'll probably go with "BGP/MPLS IP VPNs", to head off questions like "does >it work with IPX and Appletalk". sounds fine to me >Mark> Does the scheme work if routes to the same subnet are advertised from >Mark> VRFs in 2 PEs, using different RDs? > >Yes. Obviously though only one of those routes will be installed in the >VRF. > >Mark> I don't think the current memo says for this case how the PE learning >Mark> these routes should decide which to install. > >Correct, it does not. This question comes up regularly. One could specify, >for example, that the one (or more, if load balancing is being provided) >installed should be the one that BGP would have chosen if the two routes had >had the same RD. Or one could specify that the one installed should be the >one whose BGP next hop is the closest. There may also be other >possibilities. However, leaving it as an implementation decision does not >seem to cause any loops or interoperability problems, so it is probably best >to leave it unspecified. I would be more comfortable with that if the document at least mentioned that this case exists and needs to be dealt with. It is a bit subtle and it is not unlikely that people might build implementations that do not address it. >Mark> Isn't an LSR allowed to support only DU? And its neighbor only DOD? > >Good catch, so per section 3.5.3 of RFC 3036 we should really require that >DU be supported on non-LC-ATM interfaces, and DoD on LC-ATM interfaces. fine by me. probably the text should also mention LC-FR, in the DoD camp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 19 22:01:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12914 for ; Mon, 19 May 2003 22:01:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K23wg21362 for ; Mon, 19 May 2003 22:03:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K23tJ23135 for ; Mon, 19 May 2003 22:03:55 -0400 (EDT) Date: Tue, 20 May 2003 10:01:52 +0800 From: lidefeng Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt To: ppvpn@nortelnetworks.com Cc: mpls@UU.NET, pwe3@ietf.org Message-id: <001601c31e73$c8a5fea0$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are "Encapsulation Type" field and " L2 specific Sub-TLV (Optional)" field in the proposed Hierarchical L2 Circuit,while,in the "L2 specific Sub-TLV (Optional)" field, there is "Type (0x000B)" field in it,I want to know what's the difference between the "Encapsulation Type" in the Hierarchical L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" ? If they are both used,isn't one of them is redundant? Isn't reasonable use only one of them? The relevant format is copied to the following. Hierarchical L2 Circuit: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulation Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 specific Sub-TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 specific Sub-TLV : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x000B) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Ethernet MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 802.1Q Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Ethernet MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 802.1Q Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 19 23:40:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14640 for ; Mon, 19 May 2003 23:40:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K3gdg04531 for ; Mon, 19 May 2003 23:42:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K3gaw20969 for ; Mon, 19 May 2003 23:42:36 -0400 (EDT) Date: Tue, 20 May 2003 10:11:44 +0800 From: lidefeng Subject: Glossary puzzle To: ppvpn@nortelnetworks.com Message-id: <001c01c31e75$291a4420$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta1.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT What's the relation between "configuration" and "provision" in PPVPN context? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 00:46:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16128 for ; Tue, 20 May 2003 00:46:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K4nNN16204 for ; Tue, 20 May 2003 00:49:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K4nKw21291 for ; Tue, 20 May 2003 00:49:20 -0400 (EDT) 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="us-ascii" Subject: call for discussion on draft-heinanen-radius-pe-discovery-03.txt Date: Tue, 20 May 2003 00:47:27 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C495@m-va-bsod03.add0.masergy.com> Thread-Topic: call for discussion on draft-heinanen-radius-pe-discovery-03.txt thread-index: AcMeiufZLUvdITLwRWa0qQ+7GntKOw== From: "Rick Wilder" To: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA16128 Below is feedback which raises some concerns about draft-heinanen-radius-pe-discovery-03.txt. I invite your participation in a two-week email discussion of this feedback, after which a decision will be taken on whether the draft should become a working group document. Rick Bernard Aboba writes: > Overall, I believe that there are things that this draft does that are > genuinely useful and that are within the scope of legitimate AAA > activity. Fundamentally, I think that this draft is about > authenticating and providing configuration of (PP)VPN connections -- > which fits reasonably well with previous work in authentication and > configuration of VPNs -- RFC 2867 and 2868. > That said, there is also a lot of material in this draft which is > inappropriate and in some cases dangerous, and so if it is allowed to > proceed it must be with the understanding that it will have to change > significantly in order to become acceptable. > Since the same thing could be said of many other AAA-related Internet > Drafts, it is worthwhile to try to provide some perspective. Below > find a proposal for a Protocol Abuse Rating ScalE (PARSE): > 1 = An idea so bad that it will not work at all, and anyone who tries it > will likely to be weeded out by Darwinian Selection. Mike O'Dell has > suggested that we not choose to fix things in this category so as > to allow evolution to continue to work, since ideas in this > category are so toxic that the host dies quickly. An example of > this would be attempting to use AAA as an inter-domain routing > protocol. > 2 = A bad idea that will work well enough to get significant deployment, > but will show intermittent failures and poor interoperability and > therefore can cause significant damage which the IETF will have to > clean up later. For things in this category, darwinism may not be a > satisfactory solution, since the host may not know they are sick > until they have spread the problem to a significant population. > In general, I think we need to be more strongly discouraging > such things rather than hoping they will go away. An example of > this would be attempting to use an unreliable AAA accounting > protocol for usage-based billing. > 3 = Garden variety abuse -- there are better ways to do this, > but one could conceive of it working. This category is like a > chronic condition in that in the long term these kind of > mediocre ideas can degrade the quality of the Internet experience, > and lead to shortened lifespan for adopters, so that education > and discouragement is appropriate. > 4 = An appropriate use with lots of potential security > vulnerabilties. Things in this category can be fixed, but > implementers will undoubtedly take the easy way out. The original > RADIUS RFCs [RFC2865]-[RFC2869] fall into this category. 5 = An > appropriate use of where there is some evidence of > real thought about security. In AAA, I unfortunately > cannot think of an example that fits in this category :) > In terms of this draft, portions appear to be a 2 (Discovery) and some > parts would be a 4 (authentication and configuration). Note that > Section 2 attempts to update RFC 2486, which is not good. There is > currently an effort to do an RFC 2486bis (talk to > jari.arkko@piuha.net) so I'd recommend piggybacking on that instead. > Use of RADIUS for service discovery is a bad idea for many reasons, > not the least of which is that RADIUS security presumes a pre-existing > security association between the RADIUS client and server. > Use of RADIUS for authentication and configuration of (PP)VPNs is > within the scope of things envisaged in RFC 2867-68. Similar things > were done in draft-congdon with respect to dynamic configuration of > VLANs as well so there is some precedent. > Section 5.1 puts constraints on the implementation of the RADIUS > backend database, and appears to require that RADIUS servers be > stateful (which most current implementations are not). So this rates > a 2. > In Section 5.4 Interim Accounting is misused for failure detection. > This is level 2 protocol abuse. > Section 7 is a largely empty security considerations section so it > contains no bad ideas and therefore rates a 4 :) From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 01:32:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17173 for ; Tue, 20 May 2003 01:32:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K5ZBN29658 for ; Tue, 20 May 2003 01:35:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K5Z8s17657 for ; Tue, 20 May 2003 01:35:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16073.48665.490529.628432@harjus.eng.song.fi> Date: Tue, 20 May 2003 08:33:13 +0300 To: "Rick Wilder" Cc: Subject: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C495@m-va-bsod03.add0.masergy.com> References: <6B25E083A064374CA3D2FAB305CFAF7A03C495@m-va-bsod03.add0.masergy.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick Wilder writes: > > Note that > > Section 2 attempts to update RFC 2486, which is not good. this was already fixed in 04 that i announced to the list a few weeks ago. the terms conflicting 2486 are gone. > > Use of RADIUS for service discovery is a bad idea for many reasons, > > not the least of which is that RADIUS security presumes a pre-existing > > security association between the RADIUS client and server. my draft doesn't use radius for service discovery. the service type in the radius request that the pe makes is VPN-Login. so the pe already knows what service to ask for. what comes to the security issue, it is not at all unreasonable to assume that there exists a security relationship between pes of a provider and the radius servers of the same provider. it is in the same category than assuming that there is a security association between pes and their snmp management system. > > Section 5.1 puts constraints on the implementation of the RADIUS > > backend database, and appears to require that RADIUS servers be > > stateful (which most current implementations are not). So this rates > > a 2. it is very common that radius requests have side effects. any reasonable radius server on the market supports configuration of pre and post authentication hooks. otherwise routine things like checking of simultaneous use would not be possible. > > In Section 5.4 Interim Accounting is misused for failure detection. > > This is level 2 protocol abuse. i don't see the use of Interim Accounting for failure detection a big protocol abuse. that request is normally used to keep accounting information as accurate as possible in case the nas fails and is not able to send stop accounting request. its use here is close to that purpose. > > Section 7 is a largely empty security considerations section so it > > contains no bad ideas and therefore rates a 4 :) thanks for the "joke". now that you have proved your superiority, could you please send another email that would include some "concerns" regarding the draft, because the one i now replied to was empty of them. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 02:04:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22766 for ; Tue, 20 May 2003 02:04:03 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K66VN11110 for ; Tue, 20 May 2003 02:06:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K66Sh09940 for ; Tue, 20 May 2003 02:06:28 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: jh@lohi.eng.song.fi, rwilder@masergy.com Cc: PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Tue, 20 May 2003 07:04:33 +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" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Rick I wonder what the results would be if the other discovery and signalling drafts defined by PPVPN so far were evaluated using a "Protocol Abuse Rating Scale (PARSE)"? I suspect that most of them (if not all) would also receive 2's and 3's. The RADIUS discovery draft is the only one that includes CE authentication and meets all the discovery requirements identified within the PPVPN WG so far including "Limits VPN information to only those PEs involved in that VPN", "Extendible to provide information in additional to VPN endpoint IP address" and "Supports inter-provider VPNs". It seems to me the main issues raised so far are: 1) Presumption of pre-existing security (which is more relevant in the inter-AS case) 2) Requirement that RADIUS databases be stateful 3) Use of interim accounting for failure detection Considering Juha's replies below, can we get further clarification on what the *actual implications* of the above issues are, and on what the 'many reasons' are that makes RADIUS a bad idea for PE (not service) discovery? Thanks, Richard -----Original Message----- From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] Sent: 20 May 2003 06:33 To: Rick Wilder Cc: PPVPN@nortelnetworks.com Subject: call for discussion on draft-heinanen-radius-pe-discovery-03.txt Rick Wilder writes: > > Note that > > Section 2 attempts to update RFC 2486, which is not good. this was already fixed in 04 that i announced to the list a few weeks ago. the terms conflicting 2486 are gone. > > Use of RADIUS for service discovery is a bad idea for many reasons, > > not the least of which is that RADIUS security presumes a pre-existing > > security association between the RADIUS client and server. my draft doesn't use radius for service discovery. the service type in the radius request that the pe makes is VPN-Login. so the pe already knows what service to ask for. what comes to the security issue, it is not at all unreasonable to assume that there exists a security relationship between pes of a provider and the radius servers of the same provider. it is in the same category than assuming that there is a security association between pes and their snmp management system. > > Section 5.1 puts constraints on the implementation of the RADIUS > > backend database, and appears to require that RADIUS servers be > > stateful (which most current implementations are not). So this rates > > a 2. it is very common that radius requests have side effects. any reasonable radius server on the market supports configuration of pre and post authentication hooks. otherwise routine things like checking of simultaneous use would not be possible. > > In Section 5.4 Interim Accounting is misused for failure detection. > > This is level 2 protocol abuse. i don't see the use of Interim Accounting for failure detection a big protocol abuse. that request is normally used to keep accounting information as accurate as possible in case the nas fails and is not able to send stop accounting request. its use here is close to that purpose. > > Section 7 is a largely empty security considerations section so it > > contains no bad ideas and therefore rates a 4 :) thanks for the "joke". now that you have proved your superiority, could you please send another email that would include some "concerns" regarding the draft, because the one i now replied to was empty of them. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 02:08:58 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27838 for ; Tue, 20 May 2003 02:08:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K6BUN14679 for ; Tue, 20 May 2003 02:11:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K6BQh14158 for ; Tue, 20 May 2003 02:11:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16073.50843.509331.122789@harjus.eng.song.fi> Date: Tue, 20 May 2003 09:09:31 +0300 To: richard.spencer@bt.com Cc: rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit richard.spencer@bt.com writes: > 1) Presumption of pre-existing security (which is more relevant in the > inter-AS case) in inter-as case, ipsec tunnels are routinely used between radius servers of different providers and between providers and clearing house proxy servers. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 04:40:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03088 for ; Tue, 20 May 2003 04:40:02 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K8gcN09453 for ; Tue, 20 May 2003 04:42:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K8gZ719277 for ; Tue, 20 May 2003 04:42:36 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6880@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Tue, 20 May 2003 09:40:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: All, I agree with the remarks of Richard Spencer on this thread which (paraphrased) stated that a test of protocol abuse should be applied to all candidates being proposed for this purpose. But why is this 'abuse' test suddenly being applied here and in a restricted sense? I can see far more serious layered network architecture abuse happening, but I'll refrain from going into this on this thread. If we want to address the VPN problem properly (so I am including layered architecture considerations here) I believe we have to do the following things: 1 Recognise that IP and MPLS are independent layer networks that provide different networking modes and hence different behaviours....IP is cnls and MPLS is co pkt-sw (else why bother with MPLS?). 2 A corollary of 1 is that MPLS requires consistent/independent addressing of access points. It does indeed get these today. However, this is done unconsciously(?) and they are determined by the specific signalling protocol used as a combination of a v4 address + some further 'tunnel IDs'. These addresses *do not* belong in the same space as the IP v4 addresses, and (sadly) they are different for each instance of signalling protocol.....the correct requirement here is that the addresses should be consistent and independent of the signalling protocol (inc case of none) as they belong to the *data-plane*, ie they identify the access points of the MPLS network. 3 We now need to break the VPN problem up into 2 distinct parts: (i) the discovery/signalling aspects that belong to the *server* layer technology (either IP or MPLS say, but it could be *any* technology); (ii) the (most usual) requirement to distribute *client* layer reachability information, ie which client layer network addresses lie where wrt to the access points that delimit the server layer topology. 4 (i) above is *common* to all VPN types and should be independent of the client. So we need a method of associating a set of server layer access point addresses with a VPN ID and creating topological mesh of trails between these access points. Now this would provide the most basic server layer VPN service. The analogy today would be a FR or ATM VPN. There is no reason why this could also not be applied to MPLS, and in fact a SP offering a transit MPLS bearer service would be an example of such a basic VPN. It should also be obvious that this observation can also be extended to (creating basic VPNs in) co cct-sw mode technologies like SDH and OTNs. 5 So I see Juha's draft being a *common* discovery functional solution that can apply to *any* VPN type. It also allows one to choose/use an appropriate signalling protocol that is independent of the discovery function and appropriate to the data-plane technology/mode being considered.....which IMO is a very good thing. 6 (ii) above is something else entirely. It sits above the common discovery/signalling topology creation of the server layer and strictly belongs in the client layer network. In fact, in a basic server layer VPN this is exactly what happens, ie the client layer network is responsible for the distribution of its own reachability information. Indeed, this option should be allowed because its the essence of a basic managed BW VPN service, and no doubt some customers will still want this. Currently we seem to have completely overlooked this potential service opportunity. 7 The alternative of course is for the SP to take on this 'client layer reachability/distribution' function as some 'value-add' proposition. This is what rfc2547 is all about in the case of an IP client. Here, the SP uses his own BGP protocol to provide this function. This seems natural as BGP was indeed developed for an IP layer network. But this does not have to be a restricted case. All network modes (be they cnls, co pkt-sw or co cct-sw) can use a distributed routing protocol......in fact addressing and routing are the 2 most fundamental functional components that *any* layer network must have to scale/work. And herein lies the problem for an ethernet client....its does not have either of these components as one would understand them in the context of a properly specified WAN technology. 8 So, looking for a SP value-add role in client layer reachability distribution, we seem to have 2 options: - migrate to a generic solution for the distribution of *any* client layer's reachability information.......this was my point above that BGP does not have to be restricted to an IP client only (and I have seen at least one person (Muneyoshi I believe) sort-of saying this); - or use (in some way by the SP) the intrinsic client layer reachability distribution.....in the case of ethernet this is simply data-plane learning, though it brings the downside of loop prevention (which IMO is a problem that can never be properly/fully sorted by appeal to the server layer proxying for this....as indeed the many threads on this have already discussed). So in summary: - I support the direction being advocated by Juha's draft, ie identifying the server layer discovery/signalling function as an independent and common issue requiring its own solution that can be recursively applied to *any* of the technologies falling 3 networking modes of cnls, co pkt-sw and co cct-sw; - the signalling protocol that can be used is completely independent of the above; - for 'proper' layer networks that have well defined addressing and routing functions, there seems no reason why a common client layer reachability solution could not be defined as a SP value-add proposition, eg BGP may be a good solution here; - for an ethernet client.....well I am not sure. Ultimately it can't really scale/work as it is functionally deficient. All I will say is this: There is a massive difference between recognising that ethernet is an important CPE interface and then (somehow) wrongly interpreting that observation to mean we must build WAN solutions based on ethernet technology....these are quite different points. My key objective in going through the above is to try and get us all to think a little bit more architecturally about the problem. I hope there are some reading this who can recognise that there are benefits from doing this. regards, Neil > -----Original Message----- > From: Rick Wilder [mailto:rwilder@masergy.com] > Sent: 20 May 2003 05:47 > To: PPVPN@nortelnetworks.com > Subject: call for discussion on > draft-heinanen-radius-pe-discovery-03.txt > > > > > Below is feedback which raises some concerns about > draft-heinanen-radius-pe-discovery-03.txt. > > I invite your participation in a two-week email discussion of this > feedback, after which a decision will be taken on whether the draft > should become a working group document. > > Rick > > > > Bernard Aboba writes: > > > Overall, I believe that there are things that this draft > does that are > > > genuinely useful and that are within the scope of legitimate AAA > > activity. Fundamentally, I think that this draft is about > > authenticating and providing configuration of (PP)VPN > connections -- > > which fits reasonably well with previous work in authentication and > > configuration of VPNs -- RFC 2867 and 2868. > > > That said, there is also a lot of material in this draft which is > > inappropriate and in some cases dangerous, and so if it is > allowed to > > proceed it must be with the understanding that it will have > to change > > significantly in order to become acceptable. > > > Since the same thing could be said of many other > AAA-related Internet > > Drafts, it is worthwhile to try to provide some perspective. Below > > find a proposal for a Protocol Abuse Rating ScalE (PARSE): > > > 1 = An idea so bad that it will not work at all, and anyone > who tries > it > > will likely to be weeded out by Darwinian Selection. > Mike O'Dell > has > > suggested that we not choose to fix things in this > category so as > > to allow evolution to continue to work, since ideas in this > > category are so toxic that the host dies quickly. An example of > > this would be attempting to use AAA as an inter-domain routing > > protocol. > > 2 = A bad idea that will work well enough to get significant > deployment, > > but will show intermittent failures and poor > interoperability and > > therefore can cause significant damage which the IETF > will have to > > clean up later. For things in this category, darwinism > may not be > a > > satisfactory solution, since the host may not know they are sick > > until they have spread the problem to a significant population. > > In general, I think we need to be more strongly discouraging > > such things rather than hoping they will go away. An example of > > this would be attempting to use an unreliable AAA accounting > > protocol for usage-based billing. > > 3 = Garden variety abuse -- there are better ways to do this, > > but one could conceive of it working. This category is like a > > chronic condition in that in the long term these kind of > > mediocre ideas can degrade the quality of the Internet > experience, > > and lead to shortened lifespan for adopters, so that education > > and discouragement is appropriate. > > 4 = An appropriate use with lots of potential security > > vulnerabilties. Things in this category can be fixed, but > > implementers will undoubtedly take the easy way out. > The original > > RADIUS RFCs [RFC2865]-[RFC2869] fall into this category. 5 = An > > appropriate use of where there is some evidence of > > real thought about security. In AAA, I unfortunately > > cannot think of an example that fits in this category :) > > > In terms of this draft, portions appear to be a 2 > (Discovery) and some > > > parts would be a 4 (authentication and configuration). Note that > > Section 2 attempts to update RFC 2486, which is not good. There is > > currently an effort to do an RFC 2486bis (talk to > > jari.arkko@piuha.net) so I'd recommend piggybacking on that > instead. > > Use of RADIUS for service discovery is a bad idea for many reasons, > > not the least of which is that RADIUS security presumes a > pre-existing > > > security association between the RADIUS client and server. > > > Use of RADIUS for authentication and configuration of (PP)VPNs is > > within the scope of things envisaged in RFC 2867-68. Similar things > > were done in draft-congdon with respect to dynamic configuration of > > VLANs as well so there is some precedent. > > > Section 5.1 puts constraints on the implementation of the RADIUS > > backend database, and appears to require that RADIUS servers be > > stateful (which most current implementations are not). So > this rates > > a 2. > > > In Section 5.4 Interim Accounting is misused for failure detection. > > This is level 2 protocol abuse. > > > Section 7 is a largely empty security considerations section so it > > contains no bad ideas and therefore rates a 4 :) > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 04:53:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03322 for ; Tue, 20 May 2003 04:53:16 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4K8tpN13917 for ; Tue, 20 May 2003 04:55:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4K8tmR25159 for ; Tue, 20 May 2003 04:55:48 -0400 (EDT) X-Origination-Site: X-InterScan: Passed Message-ID: <3EC9ECFF.8A54FEE8@alcatel.com> Date: Tue, 20 May 2003 01:53:19 -0700 From: "Bharadwaj Kalahasti" Organization: Alcatel X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ppvpn@nortelnetworks.com Subject: Question regarding inter-AS L2 VPNs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: ind.alcatel.com X-SMTP-MAIL-FROM: Bharadwaj.Kalahasti@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: postal.xylan.com [208.8.0.248] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi, If a L2 VPN needs to be setup with multiple point-to-point pseudo-wires signalled by LDP, all tunnelled on one RSVP-TE PSN tunnel and if the pseudo-wire endpoints are in different ASs, can LDP with the extensions for the pseudo-wire setup be still used? Also, can RSVP-TE tunnels be inter-AS for this purpose? Thanks, Kalahasti From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 10:22:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15338 for ; Tue, 20 May 2003 10:22:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KEPAN14200 for ; Tue, 20 May 2003 10:25:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KEP6V27837 for ; Tue, 20 May 2003 10:25:06 -0400 (EDT) Message-Id: <200305201420.h4KEKskL017265@rtp-core-1.cisco.com> To: Juha Heinanen cc: "Rick Wilder" , PPVPN@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-reply-to: Your message of Tue, 20 May 2003 08:33:13 +0300. <16073.48665.490529.628432@harjus.eng.song.fi> 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, 20 May 2003 10:20:53 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: I'm no radius expert, but I think what Bernard Aboba is objecting to is the proposed procedure by which PEs seem to register and unregister themselves dynamically in RADIUS as supporters of a particular VPN instance. This is what he means by "service discovery", I think. Juha> my draft doesn't use radius for service discovery. the service type Juha> in the radius request that the pe makes is VPN-Login. so the pe Juha> already knows what service to ask for. "Service discovery" doesn't mean figuring out what service to ask for, it means finding, from a dynamically changing list of servers, the servers to connect to at some given time. I think that using RADIUS to get a preconfigured list of PEs attaching to a given VPN is probably unproblematic, but trying to use it to maintain dynamically learned PE/VPN associations is probably overextending it, as it is something that RADIUS is not typically used for. Richard> The RADIUS discovery draft is the only one that includes CE Richard> authentication I'm not sure that having the CE authenticated by the SP is that interesting in this context, as such authentication could be done by the PE. If the authentication could be proxied to a radius server controlled by the customer, that might be more interesting, as it would be immune to SP misconfigurations. Richard> and meets all the discovery requirements identified within the Richard> PPVPN WG so far including "Limits VPN information to only those PEs Richard> involved in that VPN", "Extendible to provide information in Richard> additional to VPN endpoint IP address" and "Supports inter-provider Richard> VPNs". The BGP-based discovery procedure meets these requirements. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 10:25:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15442 for ; Tue, 20 May 2003 10:25:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KESCN18140 for ; Tue, 20 May 2003 10:28:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KES8V02531 for ; Tue, 20 May 2003 10:28:09 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Cc: Subject: RE: vpls scaling question Date: Tue, 20 May 2003 10:22:08 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200305121754.h4CHsNH9017727@rtp-core-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp1g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp1g.bellsouth.com [139.76.165.196] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > How many households contain more than one site, and want > those sites to > appear to be on a common LAN? consider: one VLAN for internet access (consumer service) one VLAN for telecommuting (business service) > > Surely for residential households, you want to treat each one > as a single IP > subnet, and connect them to a router. I don't see where > VPLS even comes > into it. Am I missing something? > > the VLAN ID may be used to identify traffic of a customer within a particular service provider's network. the IP service(s) may be provided by a different service provider(s) From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 10:30:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15606 for ; Tue, 20 May 2003 10:30:14 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KEWnN22416 for ; Tue, 20 May 2003 10:32:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KEWkL09939 for ; Tue, 20 May 2003 10:32:46 -0400 (EDT) Reply-To: From: "Steven.Wright" To: "'Joris wils'" Cc: Subject: RE: vpls scaling question Date: Tue, 20 May 2003 10:24:39 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp1g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp1g.bellsouth.com [139.76.165.196] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Joris wils [mailto:jwils@coriolisnet.com] > Sent: Monday, May 12, 2003 2:16 PM > To: 'Wright, Steven'; 'Loa Andersson' > Cc: 'ppvpn@nortelnetworks.com' > Subject: RE: vpls scaling question > > > Steve, > > Questions for you: > a) Why does each household need its own VLAN? Why can a set > of household > not share a vlan, each household with its own, possibly > statically assigned, > MAC addresses? > isolate each customer in their own VLAN > b) If each household must have its own VLAN, then are such > VLANs usually > point2point Ethernet circuits to an Internet router? It is > far easier to > handle very large numbers of point2point circuits, than very > large numbers > of multipoint VLANs. > I expect mostly pt-pt but not all pt-pt > Cheers, > Joris > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 10:33:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15735 for ; Tue, 20 May 2003 10:33:02 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KEZcN26239 for ; Tue, 20 May 2003 10:35:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KEZZL14594 for ; Tue, 20 May 2003 10:35:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16074.15029.958275.568736@harjus.eng.song.fi> Date: Tue, 20 May 2003 17:24:53 +0300 To: erosen@cisco.com Cc: "Rick Wilder" , PPVPN@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: <200305201420.h4KEKskL017265@rtp-core-1.cisco.com> References: <16073.48665.490529.628432@harjus.eng.song.fi> <200305201420.h4KEKskL017265@rtp-core-1.cisco.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric Rosen writes: > I think that using RADIUS to get a preconfigured list of PEs attaching to a > given VPN is probably unproblematic, but trying to use it to maintain > dynamically learned PE/VPN associations is probably overextending it, as it > is something that RADIUS is not typically used for. radius is very typically used to check dynamically changing information, e.g., allowed simultaneous user limits. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 10:58:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16679 for ; Tue, 20 May 2003 10:58:41 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KF1HN03899 for ; Tue, 20 May 2003 11:01:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KF1E812309 for ; Tue, 20 May 2003 11:01:14 -0400 (EDT) Message-Id: <200305201457.h4KEvku13344@merlot.juniper.net> To: Thomas Narten cc: "Bilel Jamoussi" , "'PPVPN@nortelnetworks.com'" , "'Scott Bradner'" Subject: Re: PPVPN - In-Reply-To: Your message of "Tue, 13 May 2003 12:11:51 EDT." <200305131611.h4DGBp8X006204@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89163.1053442666.1@juniper.net> Date: Tue, 20 May 2003 07:57:46 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com,jamoussi@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Thomas, > Bilel, > > > It has been more than a week since the "PPVPN Strategy" discussion > > started on this mailing list. To date, we have not seen any > > clarification on why the AD thinks there is a problem that warrants > > the WG split > > Disagree. There have been reasons given. I think it is fair to say > that some agree with the proposed split, while others do not see a > need, and still others have raised concerns about coordination for > documents that deal with both L2 and L3 in the same document. That > input is being considered by the ADs. I'll also note that in the end, > the ADs will make the decision on whether the split is to take > place. That's why we get paid the big bucks. > > > Marco has been the PPVPN WG Co-chair since the WG has been > > chartered. Scott has been his AD for several years. Looking at > > archives of the PPVPN mailing list, the outgoing AD and the WG > > members did not voice any issues with the WG. > > Need I point out that Rick Wilder is also a co-chair of the WG? > > Also, I do not think it is constructive to have a detailed public > discussion about issues people may have with the WG operation. When > people are unhappy with the way a WG is making progress, they contact > the ADs privately. The public mailing list is the last place I'd > expect people would raise such issues. I disagree. The IETF is an open process. That means (among other things) that the discussion should happen in the open (means public). This includes issues with the WG operation as well. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 11:17:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17345 for ; Tue, 20 May 2003 11:17:45 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KFKLN11536 for ; Tue, 20 May 2003 11:20:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KFKHL17828 for ; Tue, 20 May 2003 11:20:17 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: erosen@cisco.com, jh@lohi.eng.song.fi Cc: rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Tue, 20 May 2003 16:13:24 +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" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Eric > Richard> The RADIUS discovery draft is the only one > that includes CE > Richard> authentication > > I'm not sure that having the CE authenticated by the SP is > that interesting > in this context, as such authentication could be done by > the PE. If the > authentication could be proxied to a radius server > controlled by the > customer, that might be more interesting, as it would > be immune to SP > misconfigurations. RS> What is not considered to be interesting to some parties, may well be interesting to others. I do consider the idea of VPN site authentication being an integral part of a VPN site discovery mechanism to be an interesting feature. > Richard> and meets all the discovery requirements > identified within the > Richard> PPVPN WG so far including "Limits VPN information > to only those PEs > Richard> involved in that VPN", "Extendible to provide > information in > Richard> additional to VPN endpoint IP address" and > "Supports inter-provider > Richard> VPNs". > > The BGP-based discovery procedure meets these requirements. RS> I think how well the BGP discovery mechanism is perceived to meet the above requirements depends on how the requirements are interpreted. In the case of limiting VPN information to only those PEs involved in the VPN, in the BGP discovery process PEs broadcast VPN membership information for all the VPNs that they are members of, to all the other PEs in the network. This is done regardless of whether the other PEs in the network are members of the VPN or not and is a receiver based filtering process in which receiving PEs have to filter out the relevant information for the VPNs that they belong to. Information for VPNs that a receiving PE is not a member of can be discarded (or retained for future use). The point being that the *distribution* of VPN information is not limited to those PEs involved in a particular VPN, although the storing of this information can be. In the 'Extendible to provide information in addition to VPN endpoint IP address' case, in BGP the L2 information TLV includes information about the encapsulation type and the L2 Maximum Transmission Unit (MTU) and could be extended (or new TLVs defined) to provide further information. However, distribution of p2p information is not supported as all VPN information must be broadcast to all PEs. This issue has been discussed already on the mailing list but I do not believe any vital pieces of information that must be distributed on a p2p basis were identified. I would just like to point out that this is something that perhaps should be taken into consideration when selecting a discovery mechanism. Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 11:27:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17593 for ; Tue, 20 May 2003 11:26:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KFTZN16150 for ; Tue, 20 May 2003 11:29:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KFTWL28950 for ; Tue, 20 May 2003 11:29:32 -0400 (EDT) Message-Id: <200305201523.h4KFNcu14898@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-Reply-To: Your message of "Tue, 13 May 2003 10:41:18 PDT." <45165142272.20030513104118@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98518.1053444218.1@juniper.net> Date: Tue, 20 May 2003 08:23:38 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Monday, May 12, 2003, 9:43:57 AM, Yakov Rekhter wrote: > > Assume that there is a (rough) consensus on splitting the PPVPN WG > > into two (which is yet TBD), I'd like the following to be added to > > the L2 VPN charter: > > > The effort will produce a small number of approaches that are based > > on collections of individual technologies. The goal is to foster > > interoperability among implementations of a specific approach. > > Standardization of specific approaches will be gauged on (I)SP support. > > Please state why you believe this should be in the charter and what > exactly your proposed text would mean. This should be in the charter for exactly the same reason(s) it is in the current PPVPN charter. It means exactly the same as it means in the current PPVPN charter. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 11:45:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18605 for ; Tue, 20 May 2003 11:45:44 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KFmJN26479 for ; Tue, 20 May 2003 11:48:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KFmGx26317 for ; Tue, 20 May 2003 11:48:17 -0400 (EDT) Message-ID: <3ECA4CFD.9040607@cs.columbia.edu> Date: Tue, 20 May 2003 08:42:53 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: steven.wright@BellSouth.com CC: ppvpn@nortelnetworks.com Subject: Re: vpls scaling question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: smtp802.mail.sc5.yahoo.com X-SMTP-MAIL-FROM: pingpan@cs.columbia.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp802.mail.sc5.yahoo.com [66.163.168.181] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Steven.Wright wrote: > > >>Surely for residential households, you want to treat each one >>as a single IP >>subnet, and connect them to a router. I don't see where >>VPLS even comes >>into it. Am I missing something? >> >> > > the VLAN ID may be used to identify traffic of a customer within a > particular service provider's network. > the IP service(s) may be provided by a different service provider(s) > But there are only 4000 VLAN values altogether. There is no high-speed MAC chip available that supports stacked-VLAN last time I look into it. Am I missing something here? - Ping From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 11:49:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18765 for ; Tue, 20 May 2003 11:49:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KFqRN00169 for ; Tue, 20 May 2003 11:52:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KFqOx02288 for ; Tue, 20 May 2003 11:52:25 -0400 (EDT) Message-Id: <200305201548.h4KFmlu16485@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: Your message of "Tue, 13 May 2003 10:37:52 PDT." <66164936526.20030513103752@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8179.1053445727.1@juniper.net> Date: Tue, 20 May 2003 08:48:47 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Summarizing a bit: > > Monday, May 12, 2003, 8:36:43 AM, Yakov Rekhter wrote: > > To avoid disappointing you the WG immediately needs to start the > > discussion on whether to use L2TPv3 encapsulation or MPLS or MPLS > > over GRE, or MPLS over IPSec. > > > Likewise the WG immediately needs to start the discussion on L2TPv3 > > vs LDP based signaling. > > > Likewise, the WG immediately needs to start the discussion on BGP > > vs Radius based auto-discovery. > > If the goal of the WG is to produce the IETF Standards for L2 VPNs, I > think the WG should indeed be discussing which mechanisms should be > chosen as mandatory to implement. Not requiring a mandatory one will > affect interoperability, and more than one mandatory mechanism per > function are just not needed--one is enough. If folks believe other > (optional to implement) mechanisms would really add value, I don't > think anyone would object. The key point here is if we want > implementations of the IETF standard to interoperate, we need to > define the minimal function set to be supported. > > Monday, May 12, 2003, 10:08:22 AM, Yakov Rekhter wrote: > > Agreed. In fact, I don't quite understand why some folks on this > > list insist that the IETF should be in the business of making > > business decisions... > > I don't think anyone is trying to insist on that, quite on the > contrary. I think there's a general agreement that the IETF should NOT > be making business decisions, and the disagreement is in which > decisions are business and which are technical. > > If we come here believing that the IETF is nothing but a market > battlefield, then we can call any situation where more than one > existing implementation is available a "business issue", and agree > that trying to resolve it would cost too much blood, so "the market" > should pick the one that they like more. > > If instead we believe that the IETF is an engineering organization, > where we come to work together on something we can later use to > interoperate in SP networks (even though we may have our own existing > implementations), I think we should be ready to sit down, talk to each > other and try to build consensus on what should that IETF Standard be. > > Which mindset do we choose? The one that reflects reality, and not the one that reflects wishful thinking. With this in mind the following from Ross' e-mail answers your question. The reality is that neither the IETF nor any other standards body is good at choosing between major approaches. When we have tried to do this (or when any other standards group has tried this) we have failed more often than succeeded. Where we have let more than one major approach be progressed, we have succeeded most of the time (although usually most of the approaches eventually go away). Standards groups such as the IETF are very good at taking any one well defined solution and working out all of the details. If there are two main approaches, then we are very good at having two groups of people progress the two approaches. This allows vendors to build interoperable solutions. This is essential for data communications networks to progress and to work well. Where there have been more than one approach progressed, the competition between approaches have made the proponents of each approach improve their approach as much as possible and has given us better standards. If we look at some examples from history, there is a very clear trend that progressing two or slightly more approaches works out okay. Bad approaches go away because they don't work well when deployed (for example, scaling might be difficult, or stability might be lacking). Trying to pick one winner in a heavily politicized large group just doesn't work. Committees aren't very good at figuring out where there are going to be problems. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 11:53:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18962 for ; Tue, 20 May 2003 11:53:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KFtiN01774 for ; Tue, 20 May 2003 11:55:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KFtex04259 for ; Tue, 20 May 2003 11:55:41 -0400 (EDT) Message-Id: <200305201537.h4KFbQu15726@merlot.juniper.net> To: richard.spencer@bt.com cc: erosen@cisco.com, jh@lohi.eng.song.fi, rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: Your message of "Tue, 20 May 2003 16:13:24 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3628.1053445046.1@juniper.net> Date: Tue, 20 May 2003 08:37:26 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Richard, [clipped...] > > Richard> and meets all the discovery requirements > > identified within the > > Richard> PPVPN WG so far including "Limits VPN information > > to only those PEs > > Richard> involved in that VPN", "Extendible to provide > > information in > > Richard> additional to VPN endpoint IP address" and > > "Supports inter-provider > > Richard> VPNs". > > > > The BGP-based discovery procedure meets these requirements. > > RS> I think how well the BGP discovery mechanism is perceived to meet the > above requirements depends on how the requirements are interpreted. > > In the case of limiting VPN information to only those PEs involved in the > VPN, in the BGP discovery process PEs broadcast VPN membership information > for all the VPNs that they are members of, to all the other PEs in the > network. This is done regardless of whether the other PEs in the network are > members of the VPN or not and is a receiver based filtering process in which > receiving PEs have to filter out the relevant information for the VPNs that > they belong to. Information for VPNs that a receiving PE is not a member of > can be discarded (or retained for future use). The point being that the > *distribution* of VPN information is not limited to those PEs involved in a > particular VPN, although the storing of this information can be. This is incorrect. Please read section 7 of draft-ietf-ppvpn-bgpvpn-auto-05.txt. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 13:21:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21981 for ; Tue, 20 May 2003 13:21:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KHLQN19989 for ; Tue, 20 May 2003 13:21:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KHLLt19393 for ; Tue, 20 May 2003 13:21:22 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: yakov@juniper.net Cc: erosen@cisco.com, jh@lohi.eng.song.fi, rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Tue, 20 May 2003 18:15:56 +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" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Yakov I stand corrected, yes ORF could be used to filter outbound VPN advertisements and therefore limit the distribution of VPN information. However, what happens when BGP peers first establish sessions with each other, won't they exchange NLRIs containing VPN discovery information before they receive route-refresh messages containing ORF entries? In which case the VPN information will already have been received, although once sessions are established and route-refresh messages received, ORF can be used to filter future VPN advertisements. Also, the actual exchange of ORF entries between peers could be considered to be a VPN discovery process in itself. After all, the remote PE is effectively saying 'Here is a list of VPNs that I belong to, only send me updates for these VPNs'. I'm not saying these are issues, just observations. The point I was trying to make is that the PEs in the RADIUS discovery draft only ever receive information about the PEs that belong to a particular VPN, and do not have to perform any filtering. Again, I'm not saying that this is an issue, merely an observation. Richard > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: 20 May 2003 16:37 > To: Spencer,R,Richard,XGH5 R > Cc: erosen@cisco.com; jh@lohi.eng.song.fi; rwilder@masergy.com; > PPVPN@nortelnetworks.com > Subject: Re: call for discussion on > draft-heinanen-radius-pe-discovery-03. txt > > > Richard, > > [clipped...] > > > > Richard> and meets all the discovery requirements > > > identified within the > > > Richard> PPVPN WG so far including "Limits VPN information > > > to only those PEs > > > Richard> involved in that VPN", "Extendible to provide > > > information in > > > Richard> additional to VPN endpoint IP address" and > > > "Supports inter-provider > > > Richard> VPNs". > > > > > > The BGP-based discovery procedure meets these requirements. > > > > RS> I think how well the BGP discovery mechanism is > perceived to meet the > > above requirements depends on how the requirements are > interpreted. > > > > In the case of limiting VPN information to only those PEs > involved in the > > VPN, in the BGP discovery process PEs broadcast VPN > membership information > > for all the VPNs that they are members of, to all the > other PEs in the > > network. This is done regardless of whether the other PEs > in the network are > > members of the VPN or not and is a receiver based > filtering process in which > > receiving PEs have to filter out the relevant information > for the VPNs that > > they belong to. Information for VPNs that a receiving PE > is not a member of > > can be discarded (or retained for future use). The point > being that the > > *distribution* of VPN information is not limited to those > PEs involved in a > > particular VPN, although the storing of this information can be. > > This is incorrect. Please read section 7 of > draft-ietf-ppvpn-bgpvpn-auto-05.txt. > > Yakov. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 13:40:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22495 for ; Tue, 20 May 2003 13:40:09 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KHdaN26492 for ; Tue, 20 May 2003 13:39:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KHdXr08964 for ; Tue, 20 May 2003 13:39:33 -0400 (EDT) Message-Id: <200305201735.h4KHZ3u24344@merlot.juniper.net> To: richard.spencer@bt.com cc: erosen@cisco.com, rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: Your message of "Tue, 20 May 2003 18:15:56 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53521.1053452103.1@juniper.net> Date: Tue, 20 May 2003 10:35:03 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Richard, > Yakov > > I stand corrected, yes ORF could be used to filter outbound VPN > advertisements and therefore limit the distribution of VPN information. > However, what happens when BGP peers first establish sessions with each > other, won't they exchange NLRIs containing VPN discovery information before > they receive route-refresh messages containing ORF entries? In which case > the VPN information will already have been received, although once sessions > are established and route-refresh messages received, ORF can be used to > filter future VPN advertisements. You are incorrect again. Please read section 8 of ORF spec (draft-ietf-idr-route-filter-08.txt). Yakov. > Also, the actual exchange of ORF entries > between peers could be considered to be a VPN discovery process in itself. > After all, the remote PE is effectively saying 'Here is a list of VPNs that > I belong to, only send me updates for these VPNs'.I'm not saying these are > issues, just observations. > > The point I was trying to make is that the PEs in the RADIUS discovery draft > only ever receive information about the PEs that belong to a particular VPN, > and do not have to perform any filtering. Again, I'm not saying that this is > an issue, merely an observation. > > Richard > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: 20 May 2003 16:37 > > To: Spencer,R,Richard,XGH5 R > > Cc: erosen@cisco.com; jh@lohi.eng.song.fi; rwilder@masergy.com; > > PPVPN@nortelnetworks.com > > Subject: Re: call for discussion on > > draft-heinanen-radius-pe-discovery-03. txt > > > > > > Richard, > > > > [clipped...] > > > > > > Richard> and meets all the discovery requirements > > > > identified within the > > > > Richard> PPVPN WG so far including "Limits VPN information > > > > to only those PEs > > > > Richard> involved in that VPN", "Extendible to provide > > > > information in > > > > Richard> additional to VPN endpoint IP address" and > > > > "Supports inter-provider > > > > Richard> VPNs". > > > > > > > > The BGP-based discovery procedure meets these requirements. > > > > > > RS> I think how well the BGP discovery mechanism is > > perceived to meet the > > > above requirements depends on how the requirements are > > interpreted. > > > > > > In the case of limiting VPN information to only those PEs > > involved in the > > > VPN, in the BGP discovery process PEs broadcast VPN > > membership information > > > for all the VPNs that they are members of, to all the > > other PEs in the > > > network. This is done regardless of whether the other PEs > > in the network are > > > members of the VPN or not and is a receiver based > > filtering process in which > > > receiving PEs have to filter out the relevant information > > for the VPNs that > > > they belong to. Information for VPNs that a receiving PE > > is not a member of > > > can be discarded (or retained for future use). The point > > being that the > > > *distribution* of VPN information is not limited to those > > PEs involved in a > > > particular VPN, although the storing of this information can be. > > > > This is incorrect. Please read section 7 of > > draft-ietf-ppvpn-bgpvpn-auto-05.txt. > > > > Yakov. > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 14:16:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23824 for ; Tue, 20 May 2003 14:16:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KIG7N20318 for ; Tue, 20 May 2003 14:16:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KIG3L04324 for ; Tue, 20 May 2003 14:16:04 -0400 (EDT) X-Origination-Site: X-InterScan: Passed Message-ID: <3ECA6FAF.5691DEE2@alcatel.com> Date: Tue, 20 May 2003 11:10:55 -0700 From: "Bharadwaj Kalahasti" Organization: Alcatel X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ppvpn@nortelnetworks.com Subject: Re: Question regarding inter-AS L2 VPNs References: <3EC9ECFF.8A54FEE8@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: ind.alcatel.com X-SMTP-MAIL-FROM: Bharadwaj.Kalahasti@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: postal.xylan.com [208.8.0.248] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I am aware that LDP RFC 3036 states that FEC elements are reachable across AS-boundaries. And the ERO Object in RSVP-TE messages can have sub-object 32 representing the AS#. But, the L2 VPN Framework document only indicates that the inter-AS L2 VPNs should be supported as well without specfying the authentication mechanisms end-to-end. Does security not matter in this case since the VPN is across SP networks of different carriers? If it does, what do the authors have in mind for such VPNs? I appreciate any insights. Regards, Kalahasti Bharadwaj Kalahasti wrote: > Hi, > If a L2 VPN needs to be setup with multiple point-to-point > pseudo-wires signalled by LDP, all tunnelled on one RSVP-TE PSN tunnel > and if the pseudo-wire endpoints are in different ASs, can LDP with the > extensions for the pseudo-wire setup be still used? Also, can RSVP-TE > tunnels be inter-AS for this purpose? > Thanks, > Kalahasti From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 14:55:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24986 for ; Tue, 20 May 2003 14:55:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KIsgN29903 for ; Tue, 20 May 2003 14:54:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KIsdB03439 for ; Tue, 20 May 2003 14:54:40 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: yakov@juniper.net Cc: erosen@cisco.com, rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Tue, 20 May 2003 19:44:13 +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" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Yakov I stand corrected regarding my session establishment observation, again. However, one could still consider the exchange of ORF entries to be a discovery process in its own right, in which peering PEs will receive VPN membership information for VPNs that they do not belong to. Obviously PE's do not use this VPN membership information in the context of VPN discovery, but they receive the information nonetheless. Again, I'm not saying this is an issue, just an observation. Richard > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: 20 May 2003 18:35 > To: Spencer,R,Richard,XGH5 R > Cc: erosen@cisco.com; rwilder@masergy.com; PPVPN@nortelnetworks.com > Subject: Re: call for discussion on > draft-heinanen-radius-pe-discovery-03. txt > > > Richard, > > > Yakov > > > > I stand corrected, yes ORF could be used to filter outbound VPN > > advertisements and therefore limit the distribution of VPN > information. > > However, what happens when BGP peers first establish > sessions with each > > other, won't they exchange NLRIs containing VPN discovery > information before > > they receive route-refresh messages containing ORF > entries? In which case > > the VPN information will already have been received, > although once sessions > > are established and route-refresh messages received, ORF > can be used to > > filter future VPN advertisements. > > You are incorrect again. Please read section 8 of ORF spec > (draft-ietf-idr-route-filter-08.txt). > > Yakov. > > > Also, the actual exchange of ORF entries > > between peers could be considered to be a VPN discovery > process in itself. > > After all, the remote PE is effectively saying 'Here is a > list of VPNs that > > I belong to, only send me updates for these VPNs'.I'm not > saying these are > > issues, just observations. > > > > The point I was trying to make is that the PEs in the > RADIUS discovery draft > > only ever receive information about the PEs that belong to > a particular VPN, > > and do not have to perform any filtering. Again, I'm not > saying that this is > > an issue, merely an observation. > > > > Richard > > > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > Sent: 20 May 2003 16:37 > > > To: Spencer,R,Richard,XGH5 R > > > Cc: erosen@cisco.com; jh@lohi.eng.song.fi; rwilder@masergy.com; > > > PPVPN@nortelnetworks.com > > > Subject: Re: call for discussion on > > > draft-heinanen-radius-pe-discovery-03. txt > > > > > > > > > Richard, > > > > > > [clipped...] > > > > > > > > Richard> and meets all the discovery requirements > > > > > identified within the > > > > > Richard> PPVPN WG so far including "Limits VPN information > > > > > to only those PEs > > > > > Richard> involved in that VPN", "Extendible to > provide > > > > > information in > > > > > Richard> additional to VPN endpoint IP address" and > > > > > "Supports inter-provider > > > > > Richard> VPNs". > > > > > > > > > > The BGP-based discovery procedure meets these > requirements. > > > > > > > > RS> I think how well the BGP discovery mechanism is > > > perceived to meet the > > > > above requirements depends on how the requirements are > > > interpreted. > > > > > > > > In the case of limiting VPN information to only those PEs > > > involved in the > > > > VPN, in the BGP discovery process PEs broadcast VPN > > > membership information > > > > for all the VPNs that they are members of, to all the > > > other PEs in the > > > > network. This is done regardless of whether the other PEs > > > in the network are > > > > members of the VPN or not and is a receiver based > > > filtering process in which > > > > receiving PEs have to filter out the relevant information > > > for the VPNs that > > > > they belong to. Information for VPNs that a receiving PE > > > is not a member of > > > > can be discarded (or retained for future use). The point > > > being that the > > > > *distribution* of VPN information is not limited to those > > > PEs involved in a > > > > particular VPN, although the storing of this > information can be. > > > > > > This is incorrect. Please read section 7 of > > > draft-ietf-ppvpn-bgpvpn-auto-05.txt. > > > > > > Yakov. > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 15:23:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26946 for ; Tue, 20 May 2003 15:23:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KJMSN21137 for ; Tue, 20 May 2003 15:22:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KJMPt12783 for ; Tue, 20 May 2003 15:22:25 -0400 (EDT) Message-ID: <3ECA7F4B.D95455EA@cisco.com> Date: Tue, 20 May 2003 21:17:31 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: richard.spencer@bt.com CC: yakov@juniper.net, erosen@cisco.com, rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Richard, > discovery process in its own right, in which peering PEs will receive VPN > membership information for VPNs that they do not belong to. Not necessarily ;) Once BGP session comes up and all capabilities are exchanged and matched one could easily implement filtering based on default being "Don't send anything unless explicitly asked for it" ... see draft-marques-ppvpn-rt-constrain-00.txt section 6 paragraph 1 where in the lack of explicit request no information is propagated to the peer at all. R. > richard.spencer@bt.com wrote: > > Yakov > > I stand corrected regarding my session establishment observation, again. > However, one could still consider the exchange of ORF entries to be a > discovery process in its own right, in which peering PEs will receive VPN > membership information for VPNs that they do not belong to. Obviously PE's > do not use this VPN membership information in the context of VPN discovery, > but they receive the information nonetheless. Again, I'm not saying this is > an issue, just an observation. > > Richard > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: 20 May 2003 18:35 > > To: Spencer,R,Richard,XGH5 R > > Cc: erosen@cisco.com; rwilder@masergy.com; PPVPN@nortelnetworks.com > > Subject: Re: call for discussion on > > draft-heinanen-radius-pe-discovery-03. txt > > > > > > Richard, > > > > > Yakov > > > > > > I stand corrected, yes ORF could be used to filter outbound VPN > > > advertisements and therefore limit the distribution of VPN > > information. > > > However, what happens when BGP peers first establish > > sessions with each > > > other, won't they exchange NLRIs containing VPN discovery > > information before > > > they receive route-refresh messages containing ORF > > entries? In which case > > > the VPN information will already have been received, > > although once sessions > > > are established and route-refresh messages received, ORF > > can be used to > > > filter future VPN advertisements. > > > > You are incorrect again. Please read section 8 of ORF spec > > (draft-ietf-idr-route-filter-08.txt). > > > > Yakov. > > > > > Also, the actual exchange of ORF entries > > > between peers could be considered to be a VPN discovery > > process in itself. > > > After all, the remote PE is effectively saying 'Here is a > > list of VPNs that > > > I belong to, only send me updates for these VPNs'.I'm not > > saying these are > > > issues, just observations. > > > > > > The point I was trying to make is that the PEs in the > > RADIUS discovery draft > > > only ever receive information about the PEs that belong to > > a particular VPN, > > > and do not have to perform any filtering. Again, I'm not > > saying that this is > > > an issue, merely an observation. > > > > > > Richard > > > > > > > -----Original Message----- > > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > > Sent: 20 May 2003 16:37 > > > > To: Spencer,R,Richard,XGH5 R > > > > Cc: erosen@cisco.com; jh@lohi.eng.song.fi; rwilder@masergy.com; > > > > PPVPN@nortelnetworks.com > > > > Subject: Re: call for discussion on > > > > draft-heinanen-radius-pe-discovery-03. txt > > > > > > > > > > > > Richard, > > > > > > > > [clipped...] > > > > > > > > > > Richard> and meets all the discovery requirements > > > > > > identified within the > > > > > > Richard> PPVPN WG so far including "Limits VPN information > > > > > > to only those PEs > > > > > > Richard> involved in that VPN", "Extendible to > > provide > > > > > > information in > > > > > > Richard> additional to VPN endpoint IP address" and > > > > > > "Supports inter-provider > > > > > > Richard> VPNs". > > > > > > > > > > > > The BGP-based discovery procedure meets these > > requirements. > > > > > > > > > > RS> I think how well the BGP discovery mechanism is > > > > perceived to meet the > > > > > above requirements depends on how the requirements are > > > > interpreted. > > > > > > > > > > In the case of limiting VPN information to only those PEs > > > > involved in the > > > > > VPN, in the BGP discovery process PEs broadcast VPN > > > > membership information > > > > > for all the VPNs that they are members of, to all the > > > > other PEs in the > > > > > network. This is done regardless of whether the other PEs > > > > in the network are > > > > > members of the VPN or not and is a receiver based > > > > filtering process in which > > > > > receiving PEs have to filter out the relevant information > > > > for the VPNs that > > > > > they belong to. Information for VPNs that a receiving PE > > > > is not a member of > > > > > can be discarded (or retained for future use). The point > > > > being that the > > > > > *distribution* of VPN information is not limited to those > > > > PEs involved in a > > > > > particular VPN, although the storing of this > > information can be. > > > > > > > > This is incorrect. Please read section 7 of > > > > draft-ietf-ppvpn-bgpvpn-auto-05.txt. > > > > > > > > Yakov. > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 15:38:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27703 for ; Tue, 20 May 2003 15:38:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KJbpN26588 for ; Tue, 20 May 2003 15:37:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KJbmO23740 for ; Tue, 20 May 2003 15:37:48 -0400 (EDT) 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="utf-8" Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Tue, 20 May 2003 15:34:00 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C499@m-va-bsod03.add0.masergy.com> Thread-Topic: call for discussion on draft-heinanen-radius-pe-discovery-03. txt thread-index: AcMelbPLGZkVEuFIRQG7+7hba+4KngAbob5l From: "Rick Wilder" To: , Cc: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA27703 Richard and Juha, Please note this input is not from me, but from outside the WG. Generally it's a better thing to get these issues at this stage of the process and answer them now rather than later on. We should be able to get together a summary response to Bernard and advance the dialogue. Juha, would you be willing to incorporate points from other posters into your response to create that summary? Rick -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tue 5/20/2003 2:04 AM To: jh@lohi.eng.song.fi; Rick Wilder Cc: PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Rick I wonder what the results would be if the other discovery and signalling drafts defined by PPVPN so far were evaluated using a "Protocol Abuse Rating Scale (PARSE)"? I suspect that most of them (if not all) would also receive 2's and 3's. The RADIUS discovery draft is the only one that includes CE authentication and meets all the discovery requirements identified within the PPVPN WG so far including "Limits VPN information to only those PEs involved in that VPN", "Extendible to provide information in additional to VPN endpoint IP address" and "Supports inter-provider VPNs". It seems to me the main issues raised so far are: 1) Presumption of pre-existing security (which is more relevant in the inter-AS case) 2) Requirement that RADIUS databases be stateful 3) Use of interim accounting for failure detection Considering Juha's replies below, can we get further clarification on what the *actual implications* of the above issues are, and on what the 'many reasons' are that makes RADIUS a bad idea for PE (not service) discovery? Thanks, Richard -----Original Message----- From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] Sent: 20 May 2003 06:33 To: Rick Wilder Cc: PPVPN@nortelnetworks.com Subject: call for discussion on draft-heinanen-radius-pe-discovery-03.txt Rick Wilder writes: > > Note that > > Section 2 attempts to update RFC 2486, which is not good. this was already fixed in 04 that i announced to the list a few weeks ago. the terms conflicting 2486 are gone. > > Use of RADIUS for service discovery is a bad idea for many reasons, > > not the least of which is that RADIUS security presumes a pre-existing > > security association between the RADIUS client and server. my draft doesn't use radius for service discovery. the service type in the radius request that the pe makes is VPN-Login. so the pe already knows what service to ask for. what comes to the security issue, it is not at all unreasonable to assume that there exists a security relationship between pes of a provider and the radius servers of the same provider. it is in the same category than assuming that there is a security association between pes and their snmp management system. > > Section 5.1 puts constraints on the implementation of the RADIUS > > backend database, and appears to require that RADIUS servers be > > stateful (which most current implementations are not). So this rates > > a 2. it is very common that radius requests have side effects. any reasonable radius server on the market supports configuration of pre and post authentication hooks. otherwise routine things like checking of simultaneous use would not be possible. > > In Section 5.4 Interim Accounting is misused for failure detection. > > This is level 2 protocol abuse. i don't see the use of Interim Accounting for failure detection a big protocol abuse. that request is normally used to keep accounting information as accurate as possible in case the nas fails and is not able to send stop accounting request. its use here is close to that purpose. > > Section 7 is a largely empty security considerations section so it > > contains no bad ideas and therefore rates a 4 :) thanks for the "joke". now that you have proved your superiority, could you please send another email that would include some "concerns" regarding the draft, because the one i now replied to was empty of them. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 16:02:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28422 for ; Tue, 20 May 2003 16:02:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KK1eN16408 for ; Tue, 20 May 2003 16:01:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KK1av20539 for ; Tue, 20 May 2003 16:01:37 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16074.34674.614501.471876@harjus.eng.song.fi> Date: Tue, 20 May 2003 22:52:18 +0300 To: "Rick Wilder" Cc: , Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C499@m-va-bsod03.add0.masergy.com> References: <6B25E083A064374CA3D2FAB305CFAF7A03C499@m-va-bsod03.add0.masergy.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: lohi.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: lohi.eng.song.fi [195.10.149.18] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick Wilder writes: > Juha, would you be willing to incorporate points from other posters > into your response to create that summary? i'll answer issues as they surface. i don't have time for summaries. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 16:31:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29128 for ; Tue, 20 May 2003 16:31:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KKV5N29034 for ; Tue, 20 May 2003 16:31:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KKV2U04601 for ; Tue, 20 May 2003 16:31:02 -0400 (EDT) Date: Tue, 20 May 2003 12:57:46 -0700 (PDT) From: Bernard Aboba To: ppvpn@nortelnetworks.com cc: zinin@psg.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: >this was already fixed in 04 that i announced to the list a few weeks >ago. the terms conflicting 2486 are gone. [BA] Good. If there is a need to update 2486 for some reason, this can be accomplished within the RFC 2486bis effort. >my draft doesn't use radius for service discovery. the service type in >the radius request that the pe makes is VPN-Login. so the pe already >knows what service to ask for. [BA] My error, sorry. Use of RADIUS for discovering VPN endpoints is OK, and is described in RFC 2868. It is not even necessary to know what type of VPN is desired, since this is returned in the Access-Accept. >what comes to the security issue, it is not at all unreasonable to >assume that there exists a security relationship between pes of a >provider and the radius servers of the same provider. it is in the same >category than assuming that there is a security association between pes >and their snmp management system. [BA] Preconfiguration may not necessarily be required but there are some pitfalls. For example, it possible for the RADIUS server to return a Tunnel-Password attribute as indicated in RFC 2868. However, the security of that mechanism is somewhat suspect, so it would be better if it was not necessary to use it. >it is very common that radius requests have side effects. any >reasonable radius server on the market supports configuration of pre and >post authentication hooks. otherwise routine things like checking of >simultaneous use would not be possible. [BA] The point is that there should not be an expectation that existing RADIUS servers can be implement this specification merely by making changes to the RADIUS Dictionary. That needs to be stated clearly. It's also worth mentioning that most RADIUS Dictionaries only support attributes of types defined in RFC 2865. That means that Attribute structures are typically only supported within the "String" type, and inherent server support for that is limited. The major problem with stateful application of RADIUS (such as simultaneous usage checks) is the unreliability of RADIUS accounting traffic. That implies that the state on the RADIUS server can easily get out of sync, and a mechanism needs to be provided to resynchronize. In the case of simultaneous usage checks, the accounting info is typically supplemented by telnet-based access or a proprietary SNMP MIB. The end result is that stateful uses typically have implementation-dependent components, and therefore don't interoperate well. This could be addressed either by specifying the required transport behavior or by providing an interoperable resynchronization mechanism. >i don't see the use of Interim Accounting for failure detection a big >protocol abuse. that request is normally used to keep accounting >information as accurate as possible in case the nas fails and is not >able to send stop accounting request. its use here is close to that >purpose. [BA] This is problematic because RADIUS Accounting retransmission behavior is not specified -- and therefore the loss of an interim packet may not indicate a "failure" at all -- but just ordinary packet loss. In any case, the proper behavior of a RADIUS client not receiving a Response is to initiate failover. So the packet may just have been sent to an alternative RADIUS Accounting server and received there. >thanks for the "joke". [BA] RADIUS security problems are not a joke. The security of RADIUS was marginal at the time it was proposed, but by now it has become quite easy to crack if the implementation or deployment configuration has even the slightest weakness. This includes known plaintext attacks similar to those which can be carried out on WEP, dictionary attacks on the RADIUS shared secret, and even brute force attacks on the (sub-standard) ciphers used to hide attributes. My advice is to consider the security weaknesses present in RFC 2868 and include potential mitigating measures in the Security Considerations section. An example of such a section is available here: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-22.txt >that would include some "concerns" regarding the draft, because the one >i now replied to was empty of them. [BA] Overall, I think that the draft has value and its purpose is within the precedent established in RFC 2867-2868. Given that RADIUS already supports configuration of VPNs and VLANs, it is not much of a stretch to see it being used for PPVPN configuration. However, there are things that RADIUS implementations cannot be guaranteed to do well, primarily because of the lack of a transport and failover specification, and limitations in the original security design. The question is whether potential implementors will be ok with the changes that might be necessary to address these issues. An example would be use of IPsec to protect the RADIUS exchanges, or the specification of required retransmission behavior. These changes will inevitably make the implementations more complex and expensive -- but will also make them more reliable and secure. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 16:32:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29146 for ; Tue, 20 May 2003 16:32:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KKVsN00059 for ; Tue, 20 May 2003 16:31:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KKVoU05909 for ; Tue, 20 May 2003 16:31:51 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: raszuk@cisco.com Cc: yakov@juniper.net, erosen@cisco.com, rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Tue, 20 May 2003 21:23:49 +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" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hi Robert, Based on your reply, I don't think I explained myself very clearly. To use an example, lets say that PE1 belongs to VPNs A, B, C, and D, and that PE2 belongs to VPNs C, D, E, and F. Now if I understand correctly (which I may not as I am not a BGP expert by any stretch of the imagination!) using ORF: - PE1 and PE2 establish a BGP session and exchange capabilities - PE1 sends ORF entries to PE2 saying "Only send me updates for VPNs A, B, C, and D." - PE2 sends ORF entries to PE1 saying "Only send me updates for VPNs C, D, E, and F." This happens before the actual BGP discovery process takes place, i.e. before the PE's exchange NLRIs. Now, by implication, PE1 knows that PE2 belongs to VPNs C, D, E, and F, and PE2 knows that PE1 belongs to VPNs A, B, C, and D. However, PE1 didn't need to receive any information about VPN E or F as it is not a member of these VPNs, and likewise PE2 in the case of VPNs A and B. The PEs do not use this information in the VPN discovery context, but they do receive it. Regards, Richard > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: 20 May 2003 20:18 > To: Spencer,R,Richard,XGH5 R > Cc: yakov@juniper.net; erosen@cisco.com; rwilder@masergy.com; > PPVPN@nortelnetworks.com > Subject: Re: call for discussion on > draft-heinanen-radius-pe-discovery-03.txt > > > Hi Richard, > > > discovery process in its own right, in which peering PEs > will receive VPN > > membership information for VPNs that they do not belong to. > > Not necessarily ;) > > Once BGP session comes up and all capabilities are exchanged > and matched > one could easily implement filtering based on default being > "Don't send > anything unless explicitly asked for it" ... see > draft-marques-ppvpn-rt-constrain-00.txt section 6 paragraph > 1 where in > the lack of explicit request no information is propagated to > the peer at > all. > > R. > > > > > richard.spencer@bt.com wrote: > > > > Yakov > > > > I stand corrected regarding my session establishment > observation, again. > > However, one could still consider the exchange of ORF > entries to be a > > discovery process in its own right, in which peering PEs > will receive VPN > > membership information for VPNs that they do not belong > to. Obviously PE's > > do not use this VPN membership information in the context > of VPN discovery, > > but they receive the information nonetheless. Again, I'm > not saying this is > > an issue, just an observation. > > > > Richard > > > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > Sent: 20 May 2003 18:35 > > > To: Spencer,R,Richard,XGH5 R > > > Cc: erosen@cisco.com; rwilder@masergy.com; > PPVPN@nortelnetworks.com > > > Subject: Re: call for discussion on > > > draft-heinanen-radius-pe-discovery-03. txt > > > > > > > > > Richard, > > > > > > > Yakov > > > > > > > > I stand corrected, yes ORF could be used to filter > outbound VPN > > > > advertisements and therefore limit the distribution of VPN > > > information. > > > > However, what happens when BGP peers first establish > > > sessions with each > > > > other, won't they exchange NLRIs containing VPN discovery > > > information before > > > > they receive route-refresh messages containing ORF > > > entries? In which case > > > > the VPN information will already have been received, > > > although once sessions > > > > are established and route-refresh messages received, ORF > > > can be used to > > > > filter future VPN advertisements. > > > > > > You are incorrect again. Please read section 8 of ORF spec > > > (draft-ietf-idr-route-filter-08.txt). > > > > > > Yakov. > > > > > > > Also, the actual exchange of ORF entries > > > > between peers could be considered to be a VPN discovery > > > process in itself. > > > > After all, the remote PE is effectively saying 'Here is a > > > list of VPNs that > > > > I belong to, only send me updates for these VPNs'.I'm not > > > saying these are > > > > issues, just observations. > > > > > > > > The point I was trying to make is that the PEs in the > > > RADIUS discovery draft > > > > only ever receive information about the PEs that belong to > > > a particular VPN, > > > > and do not have to perform any filtering. Again, I'm not > > > saying that this is > > > > an issue, merely an observation. > > > > > > > > Richard > > > > > > > > > -----Original Message----- > > > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > > > Sent: 20 May 2003 16:37 > > > > > To: Spencer,R,Richard,XGH5 R > > > > > Cc: erosen@cisco.com; jh@lohi.eng.song.fi; > rwilder@masergy.com; > > > > > PPVPN@nortelnetworks.com > > > > > Subject: Re: call for discussion on > > > > > draft-heinanen-radius-pe-discovery-03. txt > > > > > > > > > > > > > > > Richard, > > > > > > > > > > [clipped...] > > > > > > > > > > > > Richard> and meets all the discovery requirements > > > > > > > identified within the > > > > > > > Richard> PPVPN WG so far including "Limits > VPN information > > > > > > > to only those PEs > > > > > > > Richard> involved in that VPN", "Extendible to > > > provide > > > > > > > information in > > > > > > > Richard> additional to VPN endpoint IP address" and > > > > > > > "Supports inter-provider > > > > > > > Richard> VPNs". > > > > > > > > > > > > > > The BGP-based discovery procedure meets these > > > requirements. > > > > > > > > > > > > RS> I think how well the BGP discovery mechanism is > > > > > perceived to meet the > > > > > > above requirements depends on how the requirements are > > > > > interpreted. > > > > > > > > > > > > In the case of limiting VPN information to only those PEs > > > > > involved in the > > > > > > VPN, in the BGP discovery process PEs broadcast VPN > > > > > membership information > > > > > > for all the VPNs that they are members of, to all the > > > > > other PEs in the > > > > > > network. This is done regardless of whether the other PEs > > > > > in the network are > > > > > > members of the VPN or not and is a receiver based > > > > > filtering process in which > > > > > > receiving PEs have to filter out the relevant information > > > > > for the VPNs that > > > > > > they belong to. Information for VPNs that a receiving PE > > > > > is not a member of > > > > > > can be discarded (or retained for future use). The point > > > > > being that the > > > > > > *distribution* of VPN information is not limited to those > > > > > PEs involved in a > > > > > > particular VPN, although the storing of this > > > information can be. > > > > > > > > > > This is incorrect. Please read section 7 of > > > > > draft-ietf-ppvpn-bgpvpn-auto-05.txt. > > > > > > > > > > Yakov. > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 16:40:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29357 for ; Tue, 20 May 2003 16:40:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KKdXN04922 for ; Tue, 20 May 2003 16:39:33 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KKdUU13335 for ; Tue, 20 May 2003 16:39:30 -0400 (EDT) Date: Tue, 20 May 2003 13:14:51 -0700 (PDT) From: Bernard Aboba To: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: >I'm no radius expert, but I think what Bernard Aboba is objecting to is >the proposed procedure by which PEs seem to register and unregister >themselves dynamically in RADIUS as supporters of a particular VPN >instance. This is what he means by "service discovery", I think. >"Service discovery" doesn't mean figuring out what service to ask for, >it means finding, from a dynamically changing list of servers, the >servers to connect to at some given time. >I think that using RADIUS to get a preconfigured list of PEs attaching >to a given VPN is probably unproblematic, but trying to use it to >maintain dynamically learned PE/VPN associations is probably >overextending it, as it is something that RADIUS is not typically used >for. I think this is a reasonable statement of my concern. RFC 2868 allows a PE to obtain a preconfigured list of potential VPN endpoints and associated configuration. However, the PE then needs to choose between those potential endpoints, and can only bring them up and down within the context of a session. Now it is possible to do dynamic authorization and disconnection, as specified in draft-chiba-radius-dynamic-authorization-20.txt. But this is under the control of the RADIUS server, not the PE or CE. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 18:14:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03230 for ; Tue, 20 May 2003 18:14:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KMDUN13255 for ; Tue, 20 May 2003 18:13:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KMDRD29000 for ; Tue, 20 May 2003 18:13:28 -0400 (EDT) Message-ID: <82F679A6A377F84B8F665D8F90D12B8DD8F35A@sc-msexch-05.extremenetworks.com> From: Olen Stokes To: "'lidefeng'" , ppvpn@nortelnetworks.com Cc: mpls@UU.NET, pwe3@ietf.org Subject: RE: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt Date: Tue, 20 May 2003 14:47:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="gb2312" X-SMTP-HELO: mail3.extremenetworks.com X-SMTP-MAIL-FROM: ostokes@extremenetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sc-f100-01.extremenetworks.com [63.251.106.30] X-LYRIS-Message-Id: It was simply set up that way to allow for future flexibility. Cheers, Olen > -----Original Message----- > From: lidefeng [mailto:lidefeng@huawei.com] > Sent: Monday, May 19, 2003 10:02 PM > To: ppvpn@nortelnetworks.com > Cc: mpls@UU.NET; pwe3@ietf.org > Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > > Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are > "Encapsulation Type" field and " L2 specific Sub-TLV > (Optional)" field in > the proposed Hierarchical L2 Circuit,while,in the "L2 > specific Sub-TLV > (Optional)" field, there is "Type (0x000B)" field in it,I want to know > what's the difference between the "Encapsulation Type" in the > Hierarchical > L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" > ? If they are > both used,isn't one of them is redundant? Isn't reasonable > use only one of > them? > > The relevant format is copied to the following. > > Hierarchical L2 Circuit: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VC ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Encapsulation Type | Must Be Zero > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | L2 specific Sub-TLV (Optional) > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > L2 specific Sub-TLV : > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (0x000B) | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Target Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 18:31:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03780 for ; Tue, 20 May 2003 18:31:09 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KMUcN16691 for ; Tue, 20 May 2003 18:30:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KMUZ008043 for ; Tue, 20 May 2003 18:30:35 -0400 (EDT) X-Original-Recipient: Message-ID: <3ECAAAB2.3000004@pi.se> Date: Wed, 21 May 2003 00:22:42 +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: PPVPN Subject: new wg co-chair Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailg.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailg.telia.com [194.22.194.26] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit PPVPN WG, as has been anounced by Alex I will try to step in and fill the space after Marco, I'm still reading through all the relevant mails on the list and trying to catch up. I view this as an interesting chanllenge and will do my best to help the working group progress. There are several chanllenging and necessary things that need to happen very shortly, e.g. I would like the l2vpn requirment and framework to become stable enough to send them to an iesg review. I will also continue as co-chair for the mpls group, though this is two very large tasks I think that the overlap (at least in the solutions space) is so great that the synergies might very well compensate for the extra work. It is my sincere hope that we can focus and rapidly develop the needed protocol specifications. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 20 19:24:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05485 for ; Tue, 20 May 2003 19:24:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KNNnN04205 for ; Tue, 20 May 2003 19:23:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4KNNkX17600 for ; Tue, 20 May 2003 19:23:47 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6C5B@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Rick Wilder'" , Loa Andersson Cc: PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Tue, 20 May 2003 19:22:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31F26.A0326482" X-LYRIS-Message-Id: 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_01C31F26.A0326482 Content-Type: text/plain Rick, Loa Below are my answers to your questions. Vasile -----Original Message----- From: Rick Wilder [mailto:rwilder@masergy.com] Sent: Thursday, May 15, 2003 6:34 PM To: Loa Andersson; Ould-Brahim, Hamid [CAR:1A00:EXCH] Cc: PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Agreed, Loa. Here are the questions/requests-for-clarification that came up. a) how do the discovery and signaling parts of the document relate to those described in the other solutions documents and which of them are suggested to be mandatory to implement > vasile There are couple of assumptions that need to be taken in consideration: 1) The GVPLS model, as a distributed model, needs to have a signaling mechanism that allows PW to be identified by VPN-ID, and the End Points together. The pwe3-control-protocol-02.txt draft, with Rosen's extensions to the PW Signaling mechanism address this problem. 2) The GVPLS model is defined as an extension of the VPLS model, as HVPLS is defined as an extension of it in order to optimize some of the parameters (e.g. VC-Label) There are two ways to mitigate these two elements: a) the lasserre-vkompella-vpls draft includes the Rosen's signaling model, but it used only for non-distributed model. In this case, GVPLS would be built using Rosen's mechanism b) extends the current vpls signaling mechanism to include the components needed for the distributed model We had intensive discussions between the authors of vpls, gvpls and rosen's proposals to achieve a reasonable compromise. Unfortunately, at this point in time, the authors of the lasserre-vkompella draft didn't consider to include Rosen's signaling mechanism. As such, based on assumption 2) we decided for GVPLS to extend the current vpls signaling mechanism. However, the model is transparent to such extensions, should a decision would be taken in favor of Rosen's signaling, then GVPLS solution can accommodate it. Regarding the signaling protocol: the current draft has a default model, the LDP protocol. However, the BGP signaling is presented as an alternative. Our current resolution is the following: LDP is mandatory for GVPLS. The BGP signaling option would be defined in a separate draft. We would try to see how we can accommodate our BGP signaling with draft-kompella-ppvpn-vpls-01 bgp model. Regarding the discovery process: We recognize that an auto-discovery mechanism is needed for 3 VPLS components: - VPLS core [N-PE devices] - VPLS access [U-PE devices] - VPN Members/VPN End Points However, the M2P PW model has a very nice property: the U-PE and VPN Members auto-discovery processes can be combined with LDP signaling protocol. While the M2P is not mandatory, we considered that it is worth to present such property and allow vendors to implement and interop. b) what is the status of the MAC-in-MAC encapsulation work in IEEE? > vasile A distributed model needs to have an access protocol that must comply with the Service address scheme presented in GVPLS. There are two models that can be used: PW (splice PW) or Mac-in-Mac. Mac-in-Mac protocol is not mandatory. However, regarding it's status in IETF, the solution was socialized, and Nortel together with other vendors/SPs are looking to present a solution draft in the next IEEE sessions. From GVPLS perspective, Mac-in-Mac is just an option - it's shows that GVPLS is flexible enough to adopt different access protocols, if the assumptions are respected. Probable the best resolution for GVPLS would be to adopt the splice PW as the default model. Mac-in-Mac model would be explained in a separate draft [ex. informational rfc] until a specific resolution would take place in IEEE. c) for the case where the U-PE network is a completely ethernet switched network, and encapsulation like MAC-in-MAC is used, what part of the architecture belongs to the IETF? > vasile definitively, the architecture of such access networks should belong to IEEE. However, regardless of Mac-in-Mac or PW models, a control protocol should be employed in such access networks - we are considering to submit a GVPLS companion proposal for such control protocol. In addition, such control protocol can be used also for Q-in-Q and HVPLS models c) definition of M2P PWs is outside the scope of this WG and probably should go to PWE3 > vasile we are considering to get the M2P PW topic in the PWE3 agenda. The M2P PW can be used in other contexts than VPLS. The M2P PW is an option that can fit nicely with the multipoint nature of the VPLS service - d) how does the definition of semantics of the PW CW given in the document relate to those defined in the PWE3 WG? > vasile the CW, is optional in both pwe3-ethernet-encap-01.txt and in gvpls drafts. In GVPLS we use the format that was presented in the version mentioned above, where the sequence number was replaced with the SRC-ID indication. In the new GVPLS version we would use the new format presented in the version pwe3-ethernet-encap-02.txt, where there are 16 bits reserved and 16 bits used for the sequence number. The 16 bits reserved "for further extension" would be used in the VPLS context as SRC-ID indication. We understand that such proposal needs to be discussed also in the PWE3 group. However, a PW P2P used in the context of the VPLS can have a mechanism to indicate the SP source address from where it's originating, without breaking the original PW model. In the current solutions there are two ways to indicate the SP Source address: a) using the Control Plane [ex.VC-label ] or using the Data Plane [ex. CW]. In our current experiments by far, the Data Plane model scale and perform better than the Control plane model. IF we use PW P2P with Source indication, in the control plane, then the natural evolution is to combine the LSPs that have the same destination into a M2P PW. Some conclusions: As we understand the questions, I think there are ways to move forward, and to see GVPLS as an extension of the vpls non-distributed model [draft-lasserre-vkomeplla-vpls], and worth to be continued as working document. However, a revised version would be taken in consideration for the next IETF meeting; some components as BGP signaling and MAC-in-MAC would be presented in separate drafts. The interoperability aspects between vpls and gvpls would still be maintained in the draft, if there are not other opinions. Cheers Vasile -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, May 15, 2003 4:08 PM To: Hamid Ould-Brahim Cc: Rick Wilder; PPVPN@nortelnetworks.com Subject: Re: decisions on L2 solutions documents Rick, the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the wg support from the mailing list at the time, which I don't know), that the issues the AD / wg chair discussion should be made available to the list/wg. Review results may change how you feel about making things wg doc or not, even if they come form ADs :) Mailing list discussion of those review results may lift or confirm those conserns. /Loa Hamid Ould-Brahim wrote: > Rick, > > > > > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is > not > made a WG document at this time. Several questions have > come up > regarding this document during discussions between > the ADs and WG > chairs. In order to make an informed decision, > these questions will > be posted shortly to begin a discussion. > > > In your opinion as ppvpn chair was there consensus on the mailing list > that this draft should advance to WG doc status? > > Hamid. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se ------_=_NextPart_001_01C31F26.A0326482 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: decisions on L2 solutions documents

Rick, Loa

 Below are my answers to your questions.

Vasile

-----Original Message-----
From: Rick Wilder [mailto:rwilder@masergy.com] =
Sent: Thursday, May 15, 2003 6:34 PM
To: Loa Andersson; Ould-Brahim, Hamid = [CAR:1A00:EXCH]
Cc: PPVPN@nortelnetworks.com
Subject: RE: decisions on L2 solutions = documents



Agreed, Loa.

Here are the questions/requests-for-clarification = that came up.

    a) how do the discovery and = signaling parts of the document
       relate to those = described in the other solutions documents and which
       of them are = suggested to be mandatory to implement

> vasile
There are couple of assumptions that need to be = taken in consideration:
1)
The GVPLS model, as a distributed model, needs to = have a signaling mechanism that allows PW to be identified by VPN-ID, = and the End Points together. The pwe3-control-protocol-02.txt draft, = with Rosen's extensions to the PW Signaling mechanism address this = problem.

2)
The GVPLS model is defined as an extension of the = VPLS model, as HVPLS is defined as an extension of it in order to = optimize some of the parameters (e.g. VC-Label)

There are two ways to mitigate these two = elements:
a) the lasserre-vkompella-vpls draft includes the = Rosen's signaling model, but it used only for non-distributed model. In = this case, GVPLS would be built using Rosen's mechanism

b) extends the current vpls signaling mechanism to = include the components needed for the distributed model

We had intensive discussions between the authors of = vpls, gvpls and rosen's proposals to achieve a reasonable compromise. = Unfortunately, at this point in time, the authors of the = lasserre-vkompella draft didn't consider to include Rosen's signaling = mechanism. As such, based on assumption 2) we decided for GVPLS to = extend the current vpls signaling mechanism. However, the model is = transparent to such extensions, should a decision would be taken in = favor of Rosen's signaling, then GVPLS solution can accommodate = it.

Regarding the signaling protocol: the current draft = has a default model, the LDP protocol. However, the BGP signaling is = presented as an alternative. Our current resolution is the following: = LDP is mandatory for GVPLS.

          &nb= sp;           &nb= sp;           &nb= sp;    
The BGP signaling option would be defined in a = separate draft. We would try to see how we can accommodate our BGP = signaling with draft-kompella-ppvpn-vpls-01 bgp model.

Regarding the discovery process: We recognize that an = auto-discovery mechanism is needed for 3 VPLS components:
- VPLS core [N-PE devices]
- VPLS access [U-PE devices]
- VPN Members/VPN End Points

However, the M2P PW model has a very nice property: = the U-PE and VPN Members auto-discovery processes can be combined with = LDP signaling protocol. While the M2P is not mandatory, we considered = that it is worth to present such property and allow vendors to = implement and interop.


    b) what is the status of the = MAC-in-MAC encapsulation work in IEEE?

> vasile
A distributed model needs to have an access protocol = that must comply with the Service address scheme presented in GVPLS. =

There are two models  that can be used: PW = (splice PW) or Mac-in-Mac. Mac-in-Mac protocol is not mandatory. = However, regarding  it's status in IETF, the solution was = socialized, and Nortel together with other vendors/SPs are looking to = present  a solution draft in the next IEEE sessions.

From GVPLS perspective, Mac-in-Mac is just an option = - it's shows that GVPLS is flexible enough to adopt different access = protocols, if the assumptions are respected.

Probable the best resolution for GVPLS would be to = adopt the splice PW as the default model. Mac-in-Mac model would be = explained in a separate draft [ex. informational rfc] until a specific = resolution would take place in IEEE.

 


    c) for the case where the U-PE = network is a completely ethernet
       switched = network, and encapsulation like MAC-in-MAC is used,
       what part of = the architecture belongs to the IETF?
> vasile
definitively, the architecture of such access = networks should belong to IEEE. However, regardless of Mac-in-Mac or PW = models, a control protocol should be employed in such access networks - = we are considering to submit a GVPLS companion proposal for such = control protocol. In addition, such control protocol can be used also = for Q-in-Q and HVPLS models


    c) definition of M2P PWs is = outside the scope of this WG and
       probably should = go to PWE3
> vasile
we are considering to get the M2P PW topic in the = PWE3 agenda. The M2P PW can be used in other contexts than VPLS.
The M2P PW is an option that can fit nicely with the = multipoint nature of the VPLS service -

    d) how does the definition of = semantics of the PW CW given
       in the document = relate to those defined in the PWE3 WG?
> vasile
the CW, is optional in both = pwe3-ethernet-encap-01.txt and in gvpls drafts. In GVPLS we use the = format that was presented in the version mentioned above, where the = sequence number was replaced with the SRC-ID indication.

In the new GVPLS version we would use the new format = presented in the version pwe3-ethernet-encap-02.txt, where there are 16 = bits reserved and 16 bits used for the sequence number. The 16 bits = reserved "for further extension" would be used in the VPLS = context as SRC-ID indication. We understand that such proposal needs to = be discussed also in the PWE3 group.

However, a PW P2P used in the context of the VPLS can = have a mechanism to indicate the SP source address from where it's = originating, without breaking the original PW model. In the current = solutions there are two ways to indicate the SP Source address: a) = using the Control Plane [ex.VC-label ] or using the Data Plane [ex. = CW]. In our current experiments by far, the Data Plane model scale and = perform better than the Control  plane model.

IF we use PW P2P with Source indication, in the = control plane, then the natural evolution is to combine the LSPs that = have the same destination into a M2P PW.


Some conclusions:
As we understand the questions, I think there are = ways to move forward, and to see GVPLS as an extension of the  = vpls non-distributed model [draft-lasserre-vkomeplla-vpls], and worth = to be continued as working document. However, a revised version would = be taken in consideration for the next IETF meeting; some components as = BGP signaling and MAC-in-MAC would be presented in separate drafts. The = interoperability aspects between vpls and gvpls would still be  = maintained in the draft, if there are not other opinions.

Cheers
   Vasile



-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, May 15, 2003 4:08 PM
To: Hamid Ould-Brahim
Cc: Rick Wilder; PPVPN@nortelnetworks.com
Subject: Re: decisions on L2 solutions = documents

Rick,

the question from Hamid is what I should call = "loaded". The real issue here is (evn if you felt you had the = wg support from the mailing list at the time, which I don't know), that = the issues the AD / wg chair discussion should be made available to the = list/wg.

Review results may change how you feel about making = things wg doc or not, even if they come form ADs :)

Mailing list discussion of those review results may = lift or confirm those conserns.

/Loa

Hamid Ould-Brahim wrote:
> Rick,
>
>  >
>  > - GVPLS/LPE = draft-radoaca-ppvpn-gvpls-01.txt : This draft is  > not
> made a WG document at this time. Several = questions have  > come up
> regarding this document during discussions = between  > the ADs and WG
> chairs. In order to make an informed = decision,  > these questions will
> be posted shortly to begin a discussion.  = >
>
> In your opinion as ppvpn chair was there = consensus on the mailing list
> that this draft should advance to WG doc = status?
>
> Hamid.
>


--
/Loa

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


------_=_NextPart_001_01C31F26.A0326482-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 21 01:39:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12884 for ; Wed, 21 May 2003 01:39:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4L5cpk11810 for ; Wed, 21 May 2003 01:38:52 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4L5cmt27485 for ; Wed, 21 May 2003 01:38:48 -0400 (EDT) From: "Mark Seery" To: "Yakov Rekhter" , "Alex Zinin" Cc: Subject: RE: Single vs many solution(s) Date: Tue, 20 May 2003 22:36:26 -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: <200305201548.h4KFmlu16485@merlot.juniper.net> Importance: Normal X-SMTP-HELO: smtp017.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: smtp017.mail.yahoo.com [216.136.174.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, [SNIPPED] >> The one that reflects reality, and not the one that reflects wishful thinking. With this in mind the following from Ross' e-mail answers your question. << As I have stated before I am generally sympathetic to the idea that there are very different service providers with very different requirements; and therefore perhaps multiple standards are called for. But, some comments. I did think Ross's email was excellent, but some further color to his comments might be beneficial. In the case of developing RIP, OSPF, BGP4, etc. we kind of lucked out (or perhaps it was good intentions) in the sense that all three could be used easily in the same network - and together - because it was relatively simple to export/import routes (where applicable and advisable) because they all used the same addressing structure, so a route was a route was route which could be imported into the kernel (or its equivalent). So things worked out nicely. But what if they had all used different addressing structures, or where othewise incompatible? In the case of the Ethernet example, things actually did not work out so well. First it has to be noted that even the IEEE recognized the need for some level of interoperability, so IEEE 802.2 was defined for all (Standardized by the IEEE) Ethernet MACs. But even this did not produce good results. Bridging between Ethernet, TR, and FDDI was **very** painful. There are many reasons, some related to some interesting layer 3 encapsulations, in the case of IPX, the old canonical/non-canonical issue, function points, blah, blah, blah.....etc. Now we can argue that eventually it all worked out well because the industry trended in one direction, but for the peroid where vendors had to support all three, it was extremely painful; on both an interoperability and chip level (in the case of TR); and all three had to be supported because their vendors could claim the legitimcay of being standards. So at a minimum, it would be nice to see obvious (meaning it may be occuring but not visible) evidence of cooperation between competing proposals to identify areas of commonality, and seek interoperability. More generally, such a process may lead to other levels of cooperation. To date we have asked the binary question of single or many. Is there also some intermediate states? Best, Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 21 02:42:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09797 for ; Wed, 21 May 2003 02:42:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4L6frk27219 for ; Wed, 21 May 2003 02:41:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4L6fnN26122 for ; Wed, 21 May 2003 02:41:50 -0400 (EDT) Reply-To: From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= To: Subject: unsubscribe Date: Wed, 21 May 2003 08:39:45 +0200 Message-ID: <000201c31f63$c50d6a80$0201a8c0@windowxp> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-SMTP-HELO: smtp06.ya.com X-SMTP-MAIL-FROM: gibanezfer@jazzfree.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp06.ya.com [62.151.11.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 21 15:44:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06253 for ; Wed, 21 May 2003 15:44:21 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LJhnk02551 for ; Wed, 21 May 2003 15:43:50 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4LJhkD09040 for ; Wed, 21 May 2003 15:43:46 -0400 (EDT) X-Original-Recipient: PPVPN@nortelnetworks.com Message-ID: <3ECBD527.7090605@pi.se> Date: Wed, 21 May 2003 21:36:07 +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: richard.spencer@bt.com CC: PPVPN@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03. txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: maile.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: maile.telia.com [194.22.190.16] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Richard, richard.spencer@bt.com wrote: > Rick > > I wonder what the results would be if the other discovery and signalling > drafts defined by PPVPN so far were evaluated using a "Protocol Abuse Rating > Scale (PARSE)"? I suspect that most of them (if not all) would also receive > 2's and 3's. I hope this is not true, but if you think it is it would be helpful to do that evaluaion, cuase we would need it. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 21 15:51:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06571 for ; Wed, 21 May 2003 15:51:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LJojk07932 for ; Wed, 21 May 2003 15:50:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4LJohk15865 for ; Wed, 21 May 2003 15:50:43 -0400 (EDT) X-Original-Recipient: PPVPN@nortelnetworks.com Message-ID: <3ECBD697.3070609@pi.se> Date: Wed, 21 May 2003 21:42:15 +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: neil.2.harrison@bt.com CC: rwilder@masergy.com, PPVPN@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03. txt References: <0536FC9B908BEC4597EE721BE6A35389025D6880@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: maila.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: maila.telia.com [194.22.194.231] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Neil, neil.2.harrison@bt.com wrote: > All, > > I agree with the remarks of Richard Spencer on this thread which > (paraphrased) stated that a test of protocol abuse should be applied to all > candidates being proposed for this purpose. But why is this 'abuse' test > suddenly being applied here and in a restricted sense? I can see far more > serious layered network architecture abuse happening, but I'll refrain from > going into this on this thread. > Bernard is one of the main contributors to the RADIUS development, from his ppoint of view this is not limited, it is applying a tool when RADIUS is proposed to be used in a new context, which I would think is highly appropriate. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 21 18:17:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11636 for ; Wed, 21 May 2003 18:17:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LMH0k16708 for ; Wed, 21 May 2003 18:17:01 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4LMFjR18145 for ; Wed, 21 May 2003 18:15:45 -0400 (EDT) Message-Id: <5.2.0.9.0.20030521170733.00b14f78@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 21 May 2003 17:30:07 -0400 To: ppvpn@nortelnetworks.com, "Paul Knight" From: Mark Duffy Subject: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,paknight@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: Hi, here are comments on draft-ietf-ppvpn-vpn-vr-04.txt. General comment: Use of the VR approach in significant scale will require the use of tunneling mechanisms that efficiently support many tunnel links between a given pair of PEs, with some provision for binding a VPN-ID to each tunnel link. This document reasonably leaves that to other documents. However, the wg has no effort underway to produce any such documents. :-( In the Abstract, and similar text in the Introduction: Virtual routers can be deployed in different VPN configurations, direct VR to VR connectivity through layer-2 or by aggregating multiple VRs into a single VR combined with IP or MPLS based tunnels. [md] This idea of "aggregating multiple VRs ..." seems confusing at the least. (More comments on this below re sect 5.) How about "... through layer-2 or by tunneling over a shared IP or MPLS based network." 1. Introduction That is, the routing protocol between the VRs may be the same or it might be different than the routing mechanism used between the CE and VR. [md] "... or it may be a different instance of the same protocol" (The point being that if ospf is used CE-VR and VR-VR, they may be the same instance, or separate instances with only reachability (not topology) information redistributed between them.) Likewise, since the VR-to-VR connectivity can use tunnels, the inter-VR routing protocol can be independent of the routing used in the backbone network(s) over which the VR-based VPN runs. [md] I think it is a fundamental part of the VR model that the routing within the VPN is independent of that in the shared backbone. So I'd suggest rephrasing the above more strongly: Likewise, since the VR-to-VR connectivity uses tunnels or independent L2 links, the inter-VR routing is independent of the network layer routing used in the backbone network(s) over which the VR-based VPN runs. There are two fundamental architectures for implementing network- based VPNs: virtual routers (VR) and piggybacking. The main [md] s/network-based VPNs/network-based L3 VPNs/ 2.1 Membership All virtual routers that are members of a specific VPN MUST share the same VPN identifier (VPN-ID). This should be the Globally Unique Identifier (GID) defined in [VPN-GID] or the VPN-ID format defined in [VPN-RFC2685]. [md] Accommodating two mechanisms here just muddies the water. Can we please choose one? 2.2 Scalability The use of the "backbone VR" (Section 5.3) improves the scalability of the PE, since many VRs on the PE may use the backbone VR for connectivity to other VPN sites. [md] s/to other VPN sites/to other routers or VRs within the VPN/ 2.4 Auto-discovery It is required that the auto- discovery mechanism take into consideration the case where the VPNs are implemented across administrative domains. We assume in this document that an auto-discovery mechanism which provides services similar to BGP (as described in [VPN-BGP]) is used as the mechanism to distribute membership, topology, and tunnel information among VRs which are members of the same VPN. [md] I don't see anything in this document that actually assumes that a BGP-based discovery mechanism is used. The server-based approach of draft-heinanen-radius-pe-discovery-04.txt seems to me at least as attractive for use with VRs. In fact, I think that for those service providers who chose a VR approach over a 2547 approach, not wanting to use BGP for VPN support may be one of their primary motivations! I urge to reference draft-heinanen in here also. 2.5.1 Routing between PE and CE The routing protocol between the PE and the CE can be independent of the PE-to-PE routing. [md] s/PE-to-PE/VR-to-VR/ 2.5.3 Routing between PEs Any existing routing protocol can be used between PEs. The routing protocol between the PEs can be independent of the CE-to-PE routing. As with any network design, care must be taken when multiple routing protocols are used, due to differences in metrics, detail of information, etc. [md] s/PEs/VRs/ (3 places in the above section, including the title) 2.6 Security The architecture MUST accommodate different levels of security for data, routing, and other control information. [md] I hope this is intended to mean that different levels of security must be accommodated, not that it must be possible to accommodate one level for data and another level for routing. How about: The architecture MUST accommodate security for VPN data, routing, and other control information. Different levels of security must be possible. 2.7 Topology For example, in the case where the internal nodes (P devices) are also VR aware (NOTE this is not required - see section 2.2) then it is possible to have either tunnels from the PE or the CE connecting to these internal VRs. This type of VPN deployment can be useful when the internal nodes are geographically suitable to be a VPN hub. [md] I would argue that VR aware P devices are actually not Ps at all but PEs. So I suggest removing the above paragraph. 2.8 Tunneling It should be possible to use IPSec, GRE [RFC-1701], IP in IP, and MPLS tunnels. [md] RFC 1701 is obsolescent. This should reference RFC 2784 (proposed standard). It should also be possible to allow multiple VPNs to share a tunnel across a backbone. Therefore within a single VPN, different types of tunnels can be used. [md] I agree with the second sentence but I don't think it follows from the first sentence. So s/Therefore//. I think the first sentence is misleading. What matters to the VPN architecture is the virtual "links" seen by the VRs. These cannot be shared across multiple VPNs! The virtual links (aka tunnel links) are facilitated by some tunnelling mechanism. Some tunnelling mechanisms support one or more levels of multiplexing within the tunnelling mechanism itself (e.g. MPLS with multiple-label stacks, L2TP). Other tunnelling mechanisms do not themselves provide multiplexing (e.g. IP-in-IP). The fact that the tunnelling mechanism may use the word "tunnel" to refer to an outer aggregate (outer LSP, L2TP tunnel) containing multiple virtual links (inner label, L2TP session) is just a distraction. I propose deleting the first sentence. 3. Network Reference Model A VPN customer site is connected to the provider backbone by means of a connection between a Customer Edge (CE) device, (which can be a bridge or a router) and a virtual router (VR). [md] s/can be a bridge or a router/can be one or more hosts or and\/or routers/ Bridges and other layer 2 things should be transparent to the VR scheme. (See the 4th and 5th paragraph of section 1.2 of draft-ietf-ppvpn-rfc2547bis-03.txt. I think it is equally applicable to this.) 3.1 Backbone Not all VPNs existing on the same PE are necessarily connected to the same backbone. A single VPN can be built from multiple transport technologies. [md] in general the VPNs are not "connected to" the backbone. I would s/connected to the same backbone/using the same backbone/ 4. Virtual Router Definition A given VR holds the routes only for the specific VPN configured for that VR. [md] s/configured for that VR/of which that VR is a member/ 5. How VPNs are built and deployed using VRs Three main VR deployment scenarios can be used for building virtual private networks: 1) VR to VR connectivity over a layer 2 connection. 2) VR to VR connectivity tunneled over an IP or MPLS network. 3) Aggregating multiple virtual routers over a "backbone virtual router," which will provide connectivity over a layer 2, IP, or MPLS network. [md] I believe that #2 and #3, as discussed in the following sections, are one and the same thing and #3 should be dropped. More comments below. The above VR deployment scenarios can coexist on a single PE and they are not mutually exclusive. [md] s/on a single PE/ on a single PE and\/or within a single VPN/ 5.2 VR to VR Connectivity through IP or MPLS tunnels Although it is clearly possible to use a topology similar to the layer-2 model over an IP or MPLS backbone, the VR capability can support a different network deployment besides full mesh tunnels between VRs. [md] By "layer-2 model" I presume you are referring to "VR to VR Connectivity over Layer 2 Connections" as described in the preceding section. There is nothing in that approach that requires a full mesh of tunnels between VRs. The full mesh of tunnels may be used but is not required, whether layer 2 connections or tunnelling over an IP or MPLS backbone are used. This is the creation (on each PE) of another VR facing into the backbone network, which is used to build a kind of backbone VPN that may be shared among multiple customer VPNs. This is described below as the "backbone VR." [md] I do not understand the above text, nor section 5.3 "Virtual Router Backbone Aggregation" which follows. I think they are talking about the same approach as 5.2 "VR to VR Connectivity through IP or MPLS tunnels" which is to say, the VPN packets are tunneled across a shared (i.e. used by more than just one particular VPN) IP or MPLS backbone. Presumably the "outer packets" formed by the tunnel encapsulation are sent and received in the routing context, supported by the PE, that is the native routing context of the backbone. We can call this the "default router", "public router", "backbone VR" or whatever. But, this should all be true anytime tunneling is used. I.e. 5.2 and 5.3 are actually about the same approach. No? 5.3.1 Tunneling A tunnel can be established per VPN or shared among many VPNs (VRs). [md] I do not believe the tunnel can be shared, unless you're taking advantage of the ambiguity in the term "tunnel" and using it here to refer to an aggregate entity containing multiple 'tunnel links'. See my comment above at sect. 2.8. The backbone VR makes it appear as if each VR within a VPN is directly connected (full and partial mesh configurations supported). Each VR within the VPN exchanges routing information directly with the other VRs in the VPN. [md] s/with the other VRs/with the adjacent VRs/ Further work is needed to determine the requirements and usage of the VPN-ID exchange within IPsec-based tunneling scenarios. [md] actually within any tunneling scenarios, not just IPsec-based. 5.3.1.1 MPLS Tunnels MPLS tunneling can be used in different forwarding scenarios. A hierarchy of two labels can be used. One simple forwarding scenario is where the inner label identifies the VR intended to receive the private packet (to be forwarded to the CE). [md] ok so far, although no one has so much as written a draft about how the labels would be distributed and bound to VPN-IDs for this case... Another forwarding scenario is to distribute the inner label on a per-VPN basis across the tunnel. In this case the label distribution process can be achieved using BGP or an existing label distribution protocol on a per-VPN basis. The inner label relates to the private VPN prefix. The label and reachability distribution is done through the tunnels. On the egress side traffic will be directed to the egress interface by looking up the inner label. [md] I cannot tell if this is talking about distributing 1 inner label per VPN context, or one inner label per VPN route -- it seems to say both. And how is the label distribution done through the tunnels? If MPLS is being used to create the tunnels, they cannot exist until after the label has been distributed. [md] I think this section needs some rewriting. The key point in my mind would be that MPLS technology is used to create tunnel links, whose endpoints appear as logical IP interfaces to the routers (VRs) the tunnel links terminate on. 5.3.2 Routing VPN sites exchange routing information through the tunnels over the backbone. [md] That isn't correct. VPN sites exchange routing information with VRs across CE-VR links, and VRs exchange routing information with adjacent VRs in the same VPN across VR-VR links. (Though I'm not sure if all of that is relevant in this section - maybe it is only trying to talk about the VR-VR routing.) 6. VPN Auto-Discovery [md] the above heading would tie better to the text if we s/VPN Auto-Discovery/VPN Membership and Topology Auto-Discovery/ VPN topology represents the set of PEs and their interconnectivity within the VPN. The topology can be a full-mesh of PEs, a hub and spoke, or anything in between. [md] s/PEs/VRs/ (2 occurrences) VPN discovery can be achieved through different mechanisms, for example: - Directory server approach, in which VRs query a server to determine their neighbors. [md] draft-heinanen-radius-pe-discovery-04.txt would be good to reference here. In this document it is assumed that a mechanism that provides services similar to BGP is used to achieve auto-discovery of VPN members. As described in [VPN-BGP], VR addresses are exchanged, along with the information needed to enable the PEs to determine which VRs are in the same VPN ("membership"), and which of those VRs are to have VPN connectivity ("topology"). [md] I don't think the document "assumes" BGP-based discovery in the sense that anything else in the document depends on that. Please see my comment at sect. 2.4. It is important to note that, for the VR architecture, the auto- discovery mechanism is only used to automatically exchange VPN control information between VRs. [md] shouldn't that be s/between VRs/between PEs/ ? 8. VPNs across Domains The main requirement on the service provider in order to achieve end-to-end cross-domain VPN connectivity is the ability for both domains to support a common tunnel technology. [md] ... plus the ability to support a common membership and topology discovery technology. Once the tunnel is established, private data (e.g., routing information, and private customer data) can flow from one domain to the other with the same level of security as is provided in a single service provider network. [md] s/security/isolation/ ? Another possible scenario is to use two virtual routers configured on each PE at the interconnection point. [md] I would clarify that as follows: Another possible scenario is to deploy PE devices at each side of the interconnection point, with a virtual router configured on each PE for each VPN that spans the interconnection point. [md] I think this section (8) should also contain something along the lines of: An important consideration for VPNs spanning multiple administrative domains is whether the domains involved are always adjacent or whether there may be intervening domains that are unaware of the VPN. Transitive techniques such as deploying VPN-aware PE devices at the domain boundaries will not work in the latter type of case. The ability to use a standard VPN-ID format also allows unambiguous VPN identification across domains. [md] s/standard/standard, globally unique/ 9. Internet Access There are a number of ways to provide Internet access to a VPN using the VR model. One way of providing VPN Internet access is to configure the backbone VR to steer private traffic to the VPN VR, and Internet traffic to the normal backbone/Internet forwarding table. [md] I don't understand that. My understanding of the backbone router concept is that the relationship between a tunnel link within a VPN and the backbone is an overlay one -- VPN packets only enter the backbone after being encapsulated in a backbone-context packet and vice versa for packets in the other direction. See my comment at sect. 5.2. [md] An important way to provide Internet access, which I don't think is included in the descriptions in this section, is simply to create a link (real or virtual or internal or whatever) between the VPN-context VR and any router (or virtual router) that is in the Internet context. Note that this would be a routing adjacency relationship between the VPN and Internet (virtual) routers as opposed to the overlay relationship used to tunnel packets across the Internet (or SP backbone). 10. Carrier's Carrier Case [md] It is very difficult to understand this section. I think this is because it is difficult to tell whether each use of the terms (VPN, CE, VPN service, etc.) refers to entities in the carrier's network or the carrier's carrier's network. 11. Operations and Management In some implementations, it may be possible for a VR to be "rebooted" by a customer without affecting other VRs. [md] I suggest removing the words "by a customer", since it might just as well be the service provider or an attacker :-) that would reboot the VR. 11.2 Troubleshooting This access may provide only the privilege to monitor (with no privilege to change) the layer 3 status of the customer's VPN. [md] s/VPN/VR/ ? 13. Scalability Only the PEs are handling the VPN type information. The internal backbone routers (the P routers) are usually not VPN aware. [md] s/usually// (If it is VPN-aware than it _is_ a PE router.) ================================================ From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 21 19:27:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12886 for ; Wed, 21 May 2003 19:27:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LNRAk04925 for ; Wed, 21 May 2003 19:27:10 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4LNQLJ24168 for ; Wed, 21 May 2003 19:26:22 -0400 (EDT) Message-Id: <5.2.0.9.0.20030521183705.01fe3de8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 21 May 2003 18:44:13 -0400 To: ppvpn@nortelnetworks.com, ananth.nagarajan@mail.sprint.com From: Mark Duffy Subject: WG LAST CALL on draft-ietf-ppvpn-as-vr-01.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: Hi, here are comments on draft-ietf-ppvpn-as-vr-01.txt. 1. Introduction [md] I would suggest adding the following to the list of situations for which VR-based PPVPNs are well suited: - The VPN service provider does not own a backbone network but wishes to provide PPVPN services over a backbone obtained from some other provider. - Several cooperating SPs desire to offer PPVPN service at points that span multiple administrataive domains of the backbone, perhaps over the public Internet. 2.1. Auto Discovery In the VR-based PPVPNS, various auto discovery mechanisms are supported. VPN discovery can be achieved through directory servers, [md] This should reference draft-heinanen-radius-pe-discovery-04.txt BGP-based auto-discovery is described in [VPN-BGP], and is used for membership, topology and reachability discovery. [md] s/membership, topology and reachability/membership and topology/ (As discussed even in the following paragraph, BGP is not used for reachability in this case.) 5. Access Control and Authentication CE-PE authentication has not been specified for VR-based VPNs and is for further study. The customer must provide appropriate mechanisms for CE-PE authentication. [md] This could go a little further by saying the same thing as the 2547 applic statement. From draft-ietf-ppvpn-as2547-01.txt sect. 5: No particular means of PE/CE authentication is specified for 2547- style VPNs. PE/CE mutual authentication may be done via any mechanism supported by the routing protocol in which the CE and PE are peers (e.g., use of the TCP MD5 authentication when the CE/PE protocol is BGP), or by any other mechanism that may be desired. Even with the use of IPsec, the security level offered is dependent on the scope of the IPsec security associations: encrypting on a CE- to-CE basis (as in CE-based VPNs) will offer a wider scope of protection than only encrypting on a PE-to-PE basis (as in PE-based VPNs), since the CE-PE link remains unencrypted in the latter case. [md] ... However, PE-PE IPsec offers substantial offsetting advantages in efficiency, outsourcing, and integration with the dynamic membership and dynamic routing nature of the PPVPN. CE-PE IPsec can also be used to protect traffic on the CE-PE section of the network. In this case the traffic is only unprotected by IPsec within the PE device. 11. SP Routing VR-based PPVPNs do not impose any additional requirements on the IGP used in the service provider core network. However, the PE must implement the IGP used in the customer VPN. [md] I presume this refers to the PE implementing this IGP for use on the CE-VR adjacency? This should be clarified if possible. Also, It may not use an IGP there at all (could be BGP or static). Maybe the 2nd sentence there can just be removed. >From the customers viewpoint of routing topology, the SPs network topology appears much simpler than it may actually be. Depending on the VR implementation, the SPs service offering, and the SPs physical topology, it may appear as either a single large router with interfaces for each VPN site, as a full mesh, with two routers between any two sites, as a hub-and spoke topology (when the customer wants all inter-site traffic to pass through one or more specific sites, for application of services such as security filtering), or other arbitrary topology. [md] This topology may be hidden from the customer or not, depending on what routing protocols are used Vr-VR and VR-CE. In general, the customer will see the VPN backbone topology (i.e. the topology of VRs operated by the provider) ONLY in the case where a link-state IGP is used on the CE-VR adjacency, and the same link-state IGP is used within the VPN backbone, and the same instance of the IGP is used within the VPN backbone. So, except under those special circumstances, the CE device will see only reachability information, and not topology information. 14. QoS/SLA QoS mechanisms developed for physical routers can be used with VRs, on a per-VR basis. e.g., classification, policing, drop policies, traffic shaping and scheduling/bandwidth reservation. The architecture allows separate quality of service engineering of the VPNs and the backbone. [md] The above text appears twice in this section (paragraph 2 and paragraph 3). 16.3. Customer Management of VR Customer network management and troubleshooting systems will generally have less ability to gather information from the VRs than from the customers own routers, and will also have little or no ability to directly change VR configurations. The customers systems should be planned so as to accommodate the restricted capabilities of the VRs to respond to customer network management processes. [md] This above text is repeated in sect. 11 on p. 10. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 22 07:58:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10020 for ; Thu, 22 May 2003 07:58:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4MBvxv07174 for ; Thu, 22 May 2003 07:58:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4MBvu510350 for ; Thu, 22 May 2003 07:57:56 -0400 (EDT) Reply-To: From: "Ole Lindum" To: "ppvpn@nortelnetworks.co" Subject: subscribe ppvpn Date: Thu, 22 May 2003 13:55:59 +0200 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: mail.tpack.net X-SMTP-MAIL-FROM: oli@tpack.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: 0x50a3d1f2.unknown.tele.dk [80.163.209.242] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit subscribe ppvpn From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 22 10:25:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16098 for ; Thu, 22 May 2003 10:25:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4MEOcv04154 for ; Thu, 22 May 2003 10:24:39 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4MEOat20675 for ; Thu, 22 May 2003 10:24:36 -0400 (EDT) Message-ID: <3ECCDC99.9050408@oceansemi.com> Date: Thu, 22 May 2003 16:20:09 +0200 From: Rich User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, pt-br MIME-Version: 1.0 To: "ppvpn@nortelnetworks.co" Subject: subscribe ppvpn Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: basicbox5.server-home.net X-SMTP-MAIL-FROM: rich@oceansemi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: basicbox5.server-home.net [62.208.70.144] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit
--
Richard Schildberg

Richard Schildberg

Marketing & Business Development

Ocean Semiconductor

From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 22 14:23:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23608 for ; Thu, 22 May 2003 14:23:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4MIN6v18129 for ; Thu, 22 May 2003 14:23:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4MIN3R23511 for ; Thu, 22 May 2003 14:23:03 -0400 (EDT) Date: Thu, 22 May 2003 10:57:00 -0700 (PDT) From: Bernard Aboba To: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: >Bernard is one of the main contributors to the RADIUS development, from >his point of view this is not limited, it is applying a tool when RADIUS >is proposed to be used in a new context, which I would think is highly >appropriate. Given what has already been done in RFC 2867-2868, use of RADIUS for VPN configuration and setup isn't new. Such an application is well established. So I don't really see anything intrinsically wrong with using RADIUS to authenticate and configure (PP)VPNs. I'm just trying to understand what changes to the RADIUS protocol are required to meet *all* the requirements for this application, not just configuration and authentication of (PP)VPNs. If configuration and authentication of (PP)VPNs were all we are talking about then this might be supported by just allocating some new values of the attributes defined in RFC 2868 (e.g. new Tunnel-Type, etc.), without adding any new protocol messages or even attributes. That's all we had to do in order to support RADIUS-configured VLANs. So by nature this discussion is going to focus on the "fringe" areas of the proposal -- since the core of it is well within established uses of RADIUS. The goal is to see if *all* the requirements can easily be accomodated within existing facilities or not -- and if not, how far we have to go in order to accomodate the needs. To that end, it would be helpful for people to take a look at some of the latest RADIUS drafts, in particular: http://www.ietf.org/internet-drafts/draft-chiba-radius-dynamic-authorization-20.txt http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-29.txt http://www.ietf.org/internet-drafts/draft-aboba-radius-iana-07.txt In draft-chiba, dynamic authorization facilities are added that allow the RADIUS server to reprovision a session. This is a bit tricky in that the user may not necessarily know that their session has been reprovisioned -- if the VLAN or VPN were changed in mid-stream, for example. So there needs to be some user-NAS signalling in some cases and that may be media dependent. In draft-congdon, RADIUS is used to provision VLANs. This can be used to provide layer 2 mobility, or perhaps just to allow centralized MAC-address, user or port-based VLAN administration. The RADIUS IANA considerations draft outlines the procedures necessary for allocation of RADIUS packet types, attributes and values. This has been tightened up somewhat compared to what was in RFC 2865. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 22 14:52:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24488 for ; Thu, 22 May 2003 14:52:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4MIpuv25335 for ; Thu, 22 May 2003 14:51:56 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4MIprM20938 for ; Thu, 22 May 2003 14:51:53 -0400 (EDT) Date: Thu, 22 May 2003 11:10:30 -0700 (PDT) From: Bernard Aboba To: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > I wonder what the results would be if the other discovery and signalling > drafts defined by PPVPN so far were evaluated using a "Protocol Abuse > Rating Scale (PARSE)"? I suspect that most of them (if not all) would > also receive 2's and 3's. Please note that I do not consider use of RADIUS to authenticate and configure (PP)VPNs to constitute protocol abuse. RFC 2868 describes the use of RADIUS to configure and authenticate VPNs. So such a use is well established. My issues were with other parts of the proposal, such as modifying RFC 2486, using Interim Accounting as a failure detection mechanism, and attempting to do dynamic re-authorization in a manner not supported within draft-chiba-radius-dynamic-authorization-20.txt. I'd hope that discussion in this forum will focus on figuring out how to meet the requirements given existing facilities (RFC 2865-2869 + 3162, 2869bis, draft-congdon and draft-chiba). >I hope this is not true, but if you think it is it would be helpful to >do that evaluation, cause we would need it. If you really think that completed specifications in this WG are unlikely to work reliably or securely in practice (that's a "2") or could be done better using an alternative mechanism (that's a "3") then I'd certainly hope that the problems will be identified and fixed *prior* to sending them off to the IESG. Otherwise, you shouldn't be surprised to receiving the predictable response -- "fix it". From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 22 15:48:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27434 for ; Thu, 22 May 2003 15:48:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4MJm9v23057 for ; Thu, 22 May 2003 15:48:09 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4MJm6403397 for ; Thu, 22 May 2003 15:48:07 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com Cc: Ali Sajassi , Himanshu Shah , PPVPN@nortelnetworks.com Subject: IPLS & VPLS... Date: Thu, 22 May 2003 15:39:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32099.E1E740E0" X-LYRIS-Message-Id: 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_01C32099.E1E740E0 Content-Type: text/plain; charset="iso-8859-1" Eric, [Catching up on my emails...] > > > > Ali's point is that once you have deployed a PE which > can do the MAC > learning in the data plane, you can always shut off the > other unnecessary > parts of the VPLS service (e.g., bridging control > protocols, sequencing), > and you have the equivalent of an IPLS service. > > This assumes that all the PEs on which you want to provide > the IPLS service > also provide the VPLS service. It also assumes that the MAC > learning in the > data plane comes "for free", so that there is no advantage > to shutting it > off on certain ports and on certain pseudowires. > Sure. > It also overlooks the fact that the IPLS is a true > multipoint service; like > L3VPN, but unlike VPLS, when you receive a packet from a > pseudowire, you > don't care where it came from because you don't have to do > any MAC address > learning from the packet. Since there is no > point-to-point state to > maintain, the overhead is less and the service should be more > scalable. > > If you think that the main requirement is providing an > ethernet service > which allows you to transparently connect bridged ethernet > networks, then > you'll tend to think VPLS solves the problem and IPLS is > just a niche which > doesn't really merit its own architecture. If, on the other > hand, you think > that the main requirement is providing a lan-like > intetrconnect for IP > routers, and that the generalized ethernet service is just > a niche, then > IPLS seems much more important, as VPLS is really overkill. > Okay. The argument looks more that since VPLS and IPLS provides the same service (for IP/host/routers), there should be only one service that needs to be developed, and since VPLS interconnects as well switches, then VPLS is the right service to follow for all cases. While in the IPLS case, the assumption is that if the intent is really to interconnect routers, then VPLS functionality may not all be needed and IPLS can do the job. Maybe the questions should be: a) How many service providers will be deploying VPLS with the intent to just interconnect IP host/routers? b) How many service providers that intent/prefer to deploy first IPLS for IP host/routers and then later on VPLS for interconnecting switches/IP host/routers (on the same or different PEs)? c) How many SP will be deploying VPLS with the exclusive intent to interconnect switches? No sure we can have all the answers, it will be good to have an idea for what deployment scenario VPLS service will be used in general. > I also don't see any reason why IPLS and "VPLS as restricted > to interconnect > of IP routers" cannot be made interoperable. > > Yes, and I don't see why a provider that needs to deploy both IPLS and VPLS (for whatever reasons) needs necessarily two distinct PEs. Hamid. ------_=_NextPart_001_01C32099.E1E740E0 Content-Type: text/html; charset="iso-8859-1" IPLS & VPLS...

Eric,

[Catching up on my emails...]

>
>
>
> Ali's  point is  that once  you have  deployed  a PE  which
> can  do the  MAC
> learning in  the data plane, you  can always shut off  the
> other unnecessary
> parts of  the VPLS service  (e.g., bridging control 
> protocols, sequencing),
> and you have the equivalent of an IPLS service.
>
> This assumes that all the PEs on  which you want to provide
> the IPLS service
> also provide the VPLS service.  It also assumes that the MAC
> learning in the
> data plane  comes "for free", so that  there is no advantage 
> to shutting it
> off on certain ports and on certain pseudowires.
>

Sure.

> It also overlooks the fact that  the IPLS is a true
> multipoint service; like
> L3VPN, but  unlike VPLS, when  you receive a  packet from a 
> pseudowire, you
> don't care where it  came from because you don't have to  do
> any MAC address
> learning  from  the packet.   Since  there  is  no
> point-to-point  state  to
> maintain, the overhead is less and the service should be more
> scalable.
>
> If  you think that  the main  requirement is  providing an 
> ethernet service
> which allows  you to transparently  connect bridged ethernet 
> networks, then
> you'll tend to think VPLS solves the  problem and IPLS is
> just a niche which
> doesn't really merit its own architecture.  If, on the other
> hand, you think
> that  the main  requirement is  providing  a lan-like 
> intetrconnect for  IP
> routers, and  that the  generalized ethernet service  is just
> a  niche, then
> IPLS seems much more important, as VPLS is really overkill.
>

Okay. The argument looks more that since VPLS and IPLS provides
the same service (for IP/host/routers), there should be
only one service that needs to be developed, and since VPLS
interconnects as well switches, then VPLS is the right service to
follow for all cases. While in the IPLS case, the assumption is
that if the intent is really to interconnect routers, then VPLS
functionality may not all be needed and IPLS can do the job.

Maybe the questions should be:

a) How many service providers will be deploying VPLS with
   the intent to just interconnect IP host/routers?

b) How many service providers that intent/prefer to deploy first
   IPLS for IP host/routers and then later on VPLS for interconnecting
   switches/IP host/routers (on the same or different PEs)?

c) How many SP will be deploying VPLS with the exclusive intent
   to interconnect switches?

No sure we can have all the answers, it will be good to have an
idea for what deployment scenario VPLS service will be used
in general.

> I also don't see any reason why IPLS and "VPLS as restricted
> to interconnect
> of IP routers" cannot be made interoperable.
>
>

Yes, and I don't see why a provider that needs to deploy
both IPLS and VPLS (for whatever reasons) needs necessarily two
distinct PEs.

Hamid.

------_=_NextPart_001_01C32099.E1E740E0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 22 15:48:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27451 for ; Thu, 22 May 2003 15:48:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4MJmHv23186 for ; Thu, 22 May 2003 15:48:17 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4MJmE403599 for ; Thu, 22 May 2003 15:48:14 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Mark Seery , Yakov Rekhter , Alex Zinin Cc: PPVPN@nortelnetworks.com Subject: RE: Single vs many solution(s) Date: Thu, 22 May 2003 15:40:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3209A.062DA836" X-LYRIS-Message-Id: 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_01C3209A.062DA836 Content-Type: text/plain; charset="iso-8859-1" Mark, [clipped]... > > To date we have asked the binary question of single or many. > Is there also > some intermediate states? > Yes! In fact the term 'solution' is misleading and can be over-simplified to "one vs many protocols doing exactly the same thing" which is, in my view, not the case here. The situation today in l2vpns is a mixture between three competing approaches in solving the l2vpn problem: a) Developing a set of mechanisms as building blocks that can be used in multiple network scenarios for a given l2vpn service. In that context a 'solution' becomes a selection of a given set of mechanisms (specified independently). b) Developing a set of independent vertical solutions that meet a list of requirements (not all shared by all the solutions) for a given l2vpn service. In that context a 'solution' is the approach that meets specific requirements important for *that* solution (whether the solution is built from architecturally decoupled mechanisms, etc is secondary as long as it meets the solution requirements). c) Day one, select a set of mechanisms (with their protocol choices and standardize on one vertical solution). Currently, the service requirements and framework documents, and some mechanisms are more inline with a) while the existing solutions are more inline with their specific problem/requirement space - since they were developed *outside* (for most of them) the framework&requirements drafts- (and we don't have *solution requirements* besides the metric draft which btw has expired!). There were attempts in ppvpn to do a) instead of starting with b) but it didn't work out for many reasons (not to mention here). Option c) was just recently introduced. The problem with it is the fact we already have many vertical solutions that are equivalent and address the problem from different angles. And we don't have completely a set of clear, decoupled mechanisms to use - I am not saying option c is not achievable for some l2vpn services but I doubt if this is achievable for all l2vpn services. Personally I think given the current stage of l2vpn work, we may need both a and b approaches. When possible, one or many mechanisms should be developed to be used for one or many reduced number of solutions while at the same time 'solutions' should be able to address requirements not necessarily shared by all solutions and be open to accommodate/adapted to common mechanisms. Hamid. ------_=_NextPart_001_01C3209A.062DA836 Content-Type: text/html; charset="iso-8859-1" RE: Single vs many solution(s)

Mark,

[clipped]...

>
> To date we have asked the binary question of single or many.
> Is there also
> some intermediate states?
>

Yes! In fact the term 'solution' is misleading and can be
over-simplified to "one vs many protocols doing exactly
the same thing" which is, in my view, not the case here.

The situation today in l2vpns is a mixture between
three competing approaches in solving the l2vpn problem:

a) Developing a set of mechanisms as building blocks that
  can be used in multiple network scenarios for a given
  l2vpn service. In that context a 'solution' becomes
  a selection of a given set of mechanisms (specified
  independently).

b) Developing a set of independent vertical solutions that
   meet a list of requirements (not all shared by all the
   solutions) for a given l2vpn service. In that context a
   'solution' is the approach that meets specific
   requirements important for *that* solution (whether the
   solution is built from architecturally decoupled
   mechanisms, etc is secondary as long as it meets
   the solution requirements).

c) Day one, select a set of mechanisms (with their protocol
   choices and standardize on one vertical solution).

Currently, the service requirements
and framework documents, and some mechanisms are more
inline with a) while the existing solutions are more inline
with their specific problem/requirement space - since
they were developed *outside* (for most of them)
the framework&requirements drafts- (and we don't
have *solution requirements* besides the metric draft
which btw has expired!).

There were attempts in ppvpn to do a) instead of
starting with b) but it didn't work out for many reasons
(not to mention here). 

Option c) was just recently introduced. The problem with it
is the fact we already have many vertical solutions that are
equivalent and address the problem from different angles.
And we don't have completely a set of clear,
decoupled mechanisms to use - I am not saying option c
is not achievable for some l2vpn services but I doubt
if this is achievable for all l2vpn services.

Personally I think given the current stage
of l2vpn work, we may need both a and b approaches. When possible,
one or many mechanisms should be developed to be used for one or many
reduced number of solutions while at the same time 'solutions'
should be able to address requirements not necessarily shared
by all solutions and be open to accommodate/adapted to
common mechanisms.

Hamid.


------_=_NextPart_001_01C3209A.062DA836-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 02:38:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25816 for ; Fri, 23 May 2003 02:38:44 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4N6cCw25542 for ; Fri, 23 May 2003 02:38:13 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4N6cA519566 for ; Fri, 23 May 2003 02:38:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16077.49504.628040.94146@harjus.eng.song.fi> Date: Fri, 23 May 2003 09:36:16 +0300 To: Bernard Aboba Cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > My issues were with other parts of the proposal, such as > modifying RFC 2486, using Interim Accounting as a failure detection > mechanism, and attempting to do dynamic re-authorization in a manner not > supported within draft-chiba-radius-dynamic-authorization-20.txt. i'm not proposing any modifications to the protocols described in RFC 2486 and RFC 2866. all packets and procedures remain as it. i'm simply describing how those protocols are used in a pe discovery application. neither is this application requiring any dynamic changes to user sessions as covered by draft-chiba-radius-dynamic-authorization-20.txt. in particular, the pe discovery application described in my draft does not require or need the radius server to send any unsolicited messages for any purpose to the pes. > hope that discussion in this forum will focus on figuring out how to > meet the requirements given existing facilities (RFC 2865-2869 + 3162, > 2869bis, draft-congdon and draft-chiba). i don't see any conflict with my draft and rfc 2486 and rfc 2866. if you do, please describe what that are. in particular, those rfcs do allow the ras to send re-authentication and interim accounting requests at any time. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 02:51:58 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26202 for ; Fri, 23 May 2003 02:51:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4N6pQw29380 for ; Fri, 23 May 2003 02:51:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4N6pNH25423 for ; Fri, 23 May 2003 02:51:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16077.50281.832157.636279@harjus.eng.song.fi> Date: Fri, 23 May 2003 09:49:13 +0300 To: Bernard Aboba Cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > I'm just trying to understand what changes to the RADIUS protocol are > required to meet *all* the requirements for this application, not just > configuration and authentication of (PP)VPNs. If configuration and > authentication of (PP)VPNs were all we are talking about then this might > be supported by just allocating some new values of the attributes defined > in RFC 2868 (e.g. new Tunnel-Type, etc.), without adding any new protocol > messages or even attributes. That's all we had to do in order to support > RADIUS-configured VLANs. as i said in my previous message, the pe discovery application does not require any changes to radius protocols nor do i propose any changes. of course radius protocols could be improved in various ways, but those improvements are not mandatory in order to make pe discovery work. > So by nature this discussion is going to focus on the "fringe" areas of > the proposal -- since the core of it is well within established uses of > RADIUS. The goal is to see if *all* the requirements can easily be > accomodated within existing facilities or not -- and if not, how far we > have to go in order to accomodate the needs. i have tried to meet all requirements using existing facilities. since radius protocol does not include any keepalive mechanism between the nas and the server, the pe discovery application uses interim accounting requests for that purpose. that is, however, just a particular application of the radius accounting protocol that doesn't change the protocol itself. if you have a better means to achieve the same goal, i'm more than happy to change the draft accordingly. > In draft-chiba, dynamic authorization facilities are added that allow the > RADIUS server to reprovision a session. there is no such need in the pe discovery application that i have described. > The RADIUS IANA considerations draft outlines the procedures necessary for > allocation of RADIUS packet types, attributes and values. This has been > tightened up somewhat compared to what was in RFC 2865. the latest version of my draft ftp://lohi.eng.song.fi/tmp/draft-heinanen-radius-pe-discovery-04.txt which details the protocol, defines one new service type (VPN-Login) and one new attribute (PE-List) that of course need to get assigned code points according to the iana procedures. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 03:21:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26909 for ; Fri, 23 May 2003 03:21:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4N7LJw14756 for ; Fri, 23 May 2003 03:21:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4N7LHX25151 for ; Fri, 23 May 2003 03:21:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16077.51976.764524.898335@harjus.eng.song.fi> Date: Fri, 23 May 2003 10:17:28 +0300 To: Bernard Aboba Cc: ppvpn@nortelnetworks.com, zinin@psg.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > [BA] Preconfiguration may not necessarily be required but there > are some pitfalls. For example, it possible for the RADIUS server to > return a Tunnel-Password attribute as indicated in RFC 2868. However, > the security of that mechanism is somewhat suspect, so it would be > better if it was not necessary to use it. there is no need to return a tunnel-password attribute in the pe discovery application. > [BA] The point is that there should not be an expectation that existing > RADIUS servers can be implement this specification merely by making > changes to the RADIUS Dictionary. That needs to be stated clearly. i'll state that in the next version. > It's also worth mentioning that most RADIUS Dictionaries only support > attributes of types defined in RFC 2865. That means that Attribute > structures are typically only supported within the "String" type, and > inherent server support for that is limited. the pe-list attribute is of type "string". > The major problem with stateful application of RADIUS (such as > simultaneous usage checks) is the unreliability of RADIUS accounting > traffic. radius accounting packets are acknowledged. so the pe knows if the radius server has received the message and, if not, it can keep on trying. if connectivity is broken between the pe and radius server for a long period of time, the keepalive mechanism will cause the sites of the pe to be flushed from radius database. > [BA] This is problematic because RADIUS Accounting retransmission behavior > is not specified -- and therefore the loss of an interim packet may not > indicate a "failure" at all -- but just ordinary packet loss. In any > case, the proper behavior of a RADIUS client not receiving a Response is > to initiate failover. So the packet may just have been sent to an > alternative RADIUS Accounting server and received there. that is what my draft specifies so i don't see any conflict there. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 04:09:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28048 for ; Fri, 23 May 2003 04:09:43 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4N89Bw21831 for ; Fri, 23 May 2003 04:09:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4N898K06054 for ; Fri, 23 May 2003 04:09:08 -0400 (EDT) Message-ID: <16077.54911.316908.915982@harjus.eng.song.fi> Date: Fri, 23 May 2003 11:06:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba Cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit if using radius accounting messages as pe keepalive messages is something that people don't like in the draft then we can easily get rid of the whole pe keepalive business by requiring that each pe must re-authenticate each of its vpn sites every N hours. if i remember correctly, this is how it was in the first version of the draft, but then introduced the pe keepalive concept in order to improve scalability. if a provider has 3,600 vpn sites in its network and N=1, radius server would get on the average one authentication message per second from the pes. that may still be acceptable. but if the number of vpn sites grows to, say, 36,000, then most likely N would need to be made bigger, e.g., 10 or 24. to me even N=24 would be acceptable, since in vpn application getting rid of a pe that no longer contains any sites of a vpn is not usually that urgent matter. if it in some case is an urgent matter, then the network management application could be used to trigger valid pes to immediately re-authenticate the sites of a vpn and thus learn the currently valid pe list. if this sounds better to people, i can edit the draft accordingly. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 08:12:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03196 for ; Fri, 23 May 2003 08:12:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NCCNw28917 for ; Fri, 23 May 2003 08:12:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NCCJH07831 for ; Fri, 23 May 2003 08:12:19 -0400 (EDT) Date: Fri, 23 May 2003 08:08:51 -0400 From: jamesakpakaj@netscape.net To: suzuki@nal.ecl.net Subject: very urgent MIME-Version: 1.0 Message-ID: <12E03D99.551B8D46.7CA75CF7@netscape.net> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: imo-r01.mx.aol.com X-SMTP-MAIL-FROM: jamesakpakaj@netscape.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: imo-r01.mx.aol.com [152.163.225.97] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit STRICTLY CONFIDENTIAL & URGENT Dear Sir, I am Mr.James Akpaka,A native of cape town in south africa and I am an Executive Accountant with the south africa ministry of mineral resources and energy. I have decided to seek a confidential co-operation with you in the execution of a deal discribed here under for the benefit of all parties and I hope you we keep it as a top secret because of the nature of this transaction. Within the derpartment of mining and natural resources where I work as an accountant and with the co-operation of four other top officials we have in our possession an over due payment bills totally twenty million five hundred thousand united state dollars ($20.5m) which we want to transfer abroad with the assistance and co-operation of a foreign company/individual to receive such funds, also we are handicapped in the circumstances as the south africa civil code of conduct does not allow us to operate off-shore account hence your importance in the whole transaction. This amount represent the balance of the total contract value executed on behalf of my department contraction firm which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractors, leaving the balances in the tune of the said amount which we have in principles gotten approval to remit by Key Tested Telegraphic Transfer (K .T.T) to any foreign bank you we provide by filling an application through the justice ministry here in south africa for the transfer of rights and privileges of former contractors to you. I have the authority of my partners involved to proposed that, should you be willing to assist us in the transaction, your share of the sum we be 25% of the total sum, 70% for us and 5% for taxation and other expenses .I we like to inform you that the transaction of this deal is save there is nothing to fear about.Provided you treat it with utmost secrecy and confidentiality on your part. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have all my confidence and trust in you and I hope you we not disappoint me. I am on a year study leave here in Amsterdam holland. Contact me if you are in interested in this deal and also if you are not to enable me know my stand. I and my partners are in possession to make the payment of this funds possible provided you can assure us the safety of our share. Please remember to treat matter confidentially because we are still in service and remember once again that time is important in this business. I wait in anticipation for your full co-operation. Accept my special regards. James Akpaka,(Acct. __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 08:23:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03366 for ; Fri, 23 May 2003 08:23:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NCMRw03230 for ; Fri, 23 May 2003 08:22:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NCMPO13602 for ; Fri, 23 May 2003 08:22:25 -0400 (EDT) Date: Fri, 23 May 2003 04:58:30 -0700 (PDT) From: Bernard Aboba To: Juha Heinanen cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: <16077.54911.316908.915982@harjus.eng.song.fi> Message-ID: References: <16077.54911.316908.915982@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > if using radius accounting messages as pe keepalive messages is > something that people don't like in the draft then we can easily get rid > of the whole pe keepalive business by requiring that each pe must > re-authenticate each of its vpn sites every N hours. Re-authentication can be accomplished by sending a Session-Time attribute with Termination-Action=1. However, there is also work underway (for prepaid) to support re-authorization via the "Authorize Only" Service-Type supported in draft-chiba. > if i remember > correctly, this is how it was in the first version of the draft, but > then introduced the pe keepalive concept in order to improve > scalability. Not sure why using Interim Accounting would improve scalability as compared with re-authorization. > if a provider has 3,600 vpn sites in its network and N=1, radius server > would get on the average one authentication message per second from the > pes. that may still be acceptable. but if the number of vpn sites > grows to, say, 36,000, then most likely N would need to be made bigger, > e.g., 10 or 24. With this many sites you will definitely need to require some improvements in RADIUS client retransmission behavior. I've seen situations with 3K+ RADIUS clients where the network could not come up again after a power failure, due to overload on the RADIUS server. Exponential backoff + jittering would have helped, and we'll be putting together a document to provide guidelines on how RADIUS client should behave. > to me even N=24 would be acceptable, since in vpn application getting > rid of a pe that no longer contains any sites of a vpn is not usually > that urgent matter. if it in some case is an urgent matter, then the > network management application could be used to trigger valid pes to > immediately re-authenticate the sites of a vpn and thus learn the > currently valid pe list. You can use draft-chiba to send a CoA-Request with Service-Type="Authorize Only" in order to make this happen. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 08:39:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03674 for ; Fri, 23 May 2003 08:39:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NCdHw08258 for ; Fri, 23 May 2003 08:39:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NCdD523956 for ; Fri, 23 May 2003 08:39:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16078.5630.600249.283183@harjus.eng.song.fi> Date: Fri, 23 May 2003 15:37:18 +0300 To: Bernard Aboba Cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: <16077.54911.316908.915982@harjus.eng.song.fi> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > Re-authentication can be accomplished by sending a Session-Time attribute > with Termination-Action=1. However, there is also work underway (for > prepaid) to support re-authorization via the "Authorize Only" Service-Type > supported in draft-chiba. yes, that way the pe would know when it needs to re-authenticate its sites. > Not sure why using Interim Accounting would improve scalability as > compared with re-authorization. as it is currently written, the pe is not required to authenticate all its sites, but just to send any message to the radius server at least every N minutes. i proposed to use an accounting message for that purpose, but it could as well be re-authentication message. > With this many sites you will definitely need to require some improvements > in RADIUS client retransmission behavior. I've seen situations > with 3K+ RADIUS clients where the network could not come up again after a > power failure, due to overload on the RADIUS server. Exponential backoff > + jittering would have helped, and we'll be putting together a document to > provide guidelines on how RADIUS client should behave. the text mentions that pes should use exponential backoff. i guess that it is standard practice in any protocol. > You can use draft-chiba to send a CoA-Request with Service-Type="Authorize > Only" in order to make this happen. yes, perhaps so. however, i would not like to make mandatory anything that is beyond current standards. optional recommendations based on drafts are ok. so where are we now? are people happy if i make another version of the draft, where the pes always re-authenticate all their sites every N minutes and accounting keepalives are not used? if so i can do it and publish the new version as wg document. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 09:23:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04307 for ; Fri, 23 May 2003 09:23:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NDN1w08535 for ; Fri, 23 May 2003 09:23:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NDMvN18658 for ; Fri, 23 May 2003 09:22:58 -0400 (EDT) Message-ID: <20030523131754.28648.qmail@web41813.mail.yahoo.com> Date: Fri, 23 May 2003 06:17:54 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Participation (June 22-24, 2003) To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1426179900-1053695874=:28307" X-SMTP-HELO: web41813.mail.yahoo.com X-SMTP-MAIL-FROM: info@caitr.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41813.mail.yahoo.com [66.218.93.147] X-LYRIS-Message-Id: --0-1426179900-1053695874=:28307 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 =================================================================== http://www.caitr.org/internetworking03/index.htm =================================================================== You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials. Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and are valid till June 1, 2003. To register, go to: http://www.caitr.org/internetworking03/registration.htm Important Dates: --------------------- - Early Registration Rates Cut-Off Date: June 1 - Tutorials: June 22, 8:00am - 6:00 pm - Conference sessions: June 23-24, 8:30am-6:00pm Program: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details) Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - A new routing architecture: Atomised Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and P erformance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - Mobile Handoff Technologies Tuesday June 24 Session: Inter-Domain Routing - Optimizing Route Convergence - Traceroute and BGP AS Path Incongruities - Domain Constrained Multicast: A New Approach for IP Multicast Routing Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: QoS Based Routing - QoS Routing in Networks with Non-Deterministic Information - Active Dynamic Routing - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks - Fluid flow network modeling for hop-by-hop feedback control design and analysis We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs : - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-1426179900-1053695874=:28307 Content-Type: text/html; charset=us-ascii

     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
===================================================================
    http://www.caitr.org/internetworking03/index.htm
===================================================================
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.

Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and are valid till June 1, 2003. To register, go to:

 http://www.caitr.org/internetworking03/registration.htm

Important Dates:
---------------------
- Early Registration Rates Cut-Off Date: June 1
- Tutorials: June 22, 8:00am - 6:00 pm
- Conference sessions: June 23-24, 8:30am-6:00pm

Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)

Sunday June 22
    Tutorial-1: MPLS VPNs
    Tutorial-2: IPv6
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet

Monday June 23
    Welcome and Keynote

    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing
      - Network Processing Building Blocks: Enabling the Routers of the Future

    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - A new routing architecture: Atomised Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network

    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and P erformance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations

    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
  &n! bsp;   - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS
      - Mobile Authentication and QoS
      - Mobile Handoff Technologies

 
Tuesday June 24
    Session: Inter-Domain Routing
      - Optimizing Route Convergence
      - Traceroute and BGP AS Path Incongruities
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing

    Session: Applications & Services
     - Securing the Web with Next Generation Encryption Technologies
     - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21
     - A novel EAC semantic for the RTSP protocol
     - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet

    Session: Network Management & Planning
     - Pseudowir! e OAM: A Mandatory Yet Often Overlooked Feature
     - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems
     - Design Of Fast Fault Restoration System For WDM Networks
     - Cross-domain multimedia service provisioning, the EVOLUTE solution

    Session: QoS Based Routing
     - QoS Routing in Networks with Non-Deterministic Information
     - Active Dynamic Routing
     - QoS routing for Differentiated Services: simulations and prototype experiments
     - Probabilistic routing for QoS improvement in GPS networks
     - Fluid flow network modeling for hop-by-hop feedback control design and analysis

We look forward to seeing you at the Conference.

Regards,
 Conference Technical Co-chairs :
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM
--0-1426179900-1053695874=:28307-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 09:41:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04769 for ; Fri, 23 May 2003 09:41:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NDf2w13246 for ; Fri, 23 May 2003 09:41:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NDevH26207 for ; Fri, 23 May 2003 09:40:57 -0400 (EDT) Date: Fri, 23 May 2003 06:01:50 -0700 (PDT) From: Bernard Aboba To: Juha Heinanen cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: <16078.5630.600249.283183@harjus.eng.song.fi> Message-ID: References: <16077.54911.316908.915982@harjus.eng.song.fi> <16078.5630.600249.283183@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > as it is currently written, the pe is not required to authenticate all > its sites, but just to send any message to the radius server at least > every N minutes. i proposed to use an accounting message for that > purpose, but it could as well be re-authentication message. Or re-authorization (no authentication required) as in pre-paid. > the text mentions that pes should use exponential backoff. i guess that > it is standard practice in any protocol. Yes, but unfortunately not in RADIUS. We'll be producing a separate document to provide details on how that is done. > yes, perhaps so. however, i would not like to make mandatory anything > that is beyond current standards. optional recommendations based on > drafts are ok. draft-chiba is going to RFC soon. Support can be optional. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 10:50:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08062 for ; Fri, 23 May 2003 10:50:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NEnxw14346 for ; Fri, 23 May 2003 10:49:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NEnum13746 for ; Fri, 23 May 2003 10:49:56 -0400 (EDT) Message-ID: <3ECE343D.3030709@cisco.com> Date: Fri, 23 May 2003 16:46:21 +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: Bernard Aboba CC: Juha Heinanen , ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt References: <16077.54911.316908.915982@harjus.eng.song.fi> <16078.5630.600249.283183@harjus.eng.song.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>as it is currently written, the pe is not required to authenticate all >>its sites, but just to send any message to the radius server at least >>every N minutes. i proposed to use an accounting message for that >>purpose, but it could as well be re-authentication message. > > > Or re-authorization (no authentication required) as in pre-paid. > > >>the text mentions that pes should use exponential backoff. i guess that >>it is standard practice in any protocol. > > > Yes, but unfortunately not in RADIUS. We'll be producing a separate > document to provide details on how that is done. In any case, I would suspect that for some period of time the number of typical PPVPN nodes will lag behind the state of the art in number of access nodes hitting a radius server. If not, then PPVPN will simply become an additional driver for making these improvements (improvements that of course need to be done anyway). > > >>yes, perhaps so. however, i would not like to make mandatory anything >>that is beyond current standards. optional recommendations based on >>drafts are ok. > > > draft-chiba is going to RFC soon. Support can be optional. > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 19:25:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00209 for ; Fri, 23 May 2003 19:25:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NNP0w22755 for ; Fri, 23 May 2003 19:25:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NNOv714162 for ; Fri, 23 May 2003 19:24:57 -0400 (EDT) Date: Fri, 23 May 2003 16:22:25 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1931049485390.20030523162225@psg.com> To: PPVPN@nortelnetworks.com CC: Yakov Rekhter Subject: Re: Single vs many solution(s) In-Reply-To: <200305201548.h4KFmlu16485@merlot.juniper.net> References: <200305201548.h4KFmlu16485@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, >> If we come here believing that the IETF is nothing but a market >> battlefield, then we can call any situation where more than one >> existing implementation is available a "business issue", and agree >> that trying to resolve it would cost too much blood, so "the market" >> should pick the one that they like more. >> >> If instead we believe that the IETF is an engineering organization, >> where we come to work together on something we can later use to >> interoperate in SP networks (even though we may have our own existing >> implementations), I think we should be ready to sit down, talk to each >> other and try to build consensus on what should that IETF Standard be. >> >> Which mindset do we choose? > The one that reflects reality, and not the one that reflects wishful > thinking. My approach (which you may call "wishful thinking") is the second one above--to treat IETF as an engineering organization and expect people (vendors, users, researchers) to talk and work together on IETF standards. I don't know what your "reality"-based one is. > With this in mind the following from Ross' e-mail answers > your question. Not really. A key notion in Ross'es explanation is a "major approach". If we apply the "major approach" argument to every situation where more than one direction is possible, we will end up with exploration of the solution space. Therefore, it is important to distinguish between a "major approach" and a "mechanism performing a specific function within a major approach". Within the VPN context, it seems reasonable to say that L3 VPNs and L2 VPNs are fundamentally different major approaches. Within L2 VPNs, it also seems reasonable to say that VPLS and VPWS are two different major approaches as they are used to provide different services. On the other hand, can we call LDP-based and BGP-based VPLS signalling "major approaches", or are they rather two possible variants for a quite narrow-scoped signalling function? Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 19:28:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00271 for ; Fri, 23 May 2003 19:28:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NNRTw25687 for ; Fri, 23 May 2003 19:27:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NNRQ717648 for ; Fri, 23 May 2003 19:27:27 -0400 (EDT) Date: Fri, 23 May 2003 16:24:31 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1691049611791.20030523162431@psg.com> To: PPVPN@nortelnetworks.com CC: Yakov Rekhter Subject: Re: Draft charter for L2VPN In-Reply-To: <200305201523.h4KFNcu14898@merlot.juniper.net> References: <200305201523.h4KFNcu14898@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, >> > The effort will produce a small number of approaches that are based >> > on collections of individual technologies. The goal is to foster >> > interoperability among implementations of a specific approach. >> > Standardization of specific approaches will be gauged on (I)SP support. >> >> Please state why you believe this should be in the charter and what >> exactly your proposed text would mean. > This should be in the charter for exactly the same reason(s) it is > in the current PPVPN charter. It means exactly the same as it > means in the current PPVPN charter. Many people on this list (including me) were not intimately involved in writing of the PPVPN WG charter. Therefore, I believe you should explain your reasoning (i.e. why you think the text is useful, how, and what it really means) before we can consider putting this phrase in the proposed charter. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 19:31:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00320 for ; Fri, 23 May 2003 19:31:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4NNUfw29645 for ; Fri, 23 May 2003 19:30:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4NNUcf22425 for ; Fri, 23 May 2003 19:30:38 -0400 (EDT) Date: Fri, 23 May 2003 16:23:12 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1561049532698.20030523162312@psg.com> To: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN: Perfect LAN emulation In-Reply-To: <200305161338.h4GDcXkL027396@rtp-core-1.cisco.com> References: <200305161338.h4GDcXkL027396@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit 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 bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 20:09:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01104 for ; Fri, 23 May 2003 20:09:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4O09Ow15883 for ; Fri, 23 May 2003 20:09:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4O09Lm25273 for ; Fri, 23 May 2003 20:09:21 -0400 (EDT) Date: Fri, 23 May 2003 17:07:14 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <871052174567.20030523170714@psg.com> To: PPVPN@nortelnetworks.com Subject: Decision on work split MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- I would like to thank everyone for a useful discussion on this topic. Thomas, Bert, and I have reviewed the discussion and made the decision that we still need to proceed with splitting the work in two WGs, as this has a good potential for improving the WG focus and progress. Therefore, the discussions on the draft charters of the proposed WGs will be continued with the goal of completing this process two weeks from now the latest. To minimize interference of charter-related discussions with ongoing activities within the PPVPN WG, the former will be taken to the following mailing lists: l2vpn@ietf.org -- for the L2VPN proposed WG l3vpn@ietf.org -- for the L3VPN proposed WG Please subscribe to these mailing lists using the following links: https://www1.ietf.org/mailman/listinfo/l2vpn https://www1.ietf.org/mailman/listinfo/l3vpn The web archives will be available once there's some traffic there. Based on the feedback on the list, there is one question that I'd like us to discuss on this mailing list--which perspective WG the common (L2+L3) work should go to. I will send a message to the list enumerating the drafts and starting this discussion shortly. Finally, to ensure proper coordination of VPN-related work (between proposed new WGs, PWE3, L2TP, Routing and Transport area), we will be creating the VPN directorate. It will be explicitly announced when formed. Regards. -- Alex Zinin IETF SUB-IP Area Co-Director From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 23 23:07:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05281 for ; Fri, 23 May 2003 23:07:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4O373w01386 for ; Fri, 23 May 2003 23:07:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4O370L23660 for ; Fri, 23 May 2003 23:07:00 -0400 (EDT) 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 X-SMTP-HELO: smtp012.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: smtp012.mail.yahoo.com [216.136.173.32] X-LYRIS-Message-Id: 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 bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 24 03:21:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21253 for ; Sat, 24 May 2003 03:21:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4O7L4826637 for ; Sat, 24 May 2003 03:21:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4O7L1a26492 for ; Sat, 24 May 2003 03:21:01 -0400 (EDT) Date: Sat, 24 May 2003 03:19:13 -0400 Message-Id: <200305240719.h4O7JDmj018268@starter4.aitcom.net> To: ppvpn@nortelnetworks.com Subject: urgent reply From: IFEJIKA OSSY Reply-To: ifejikaossy@sify.com MIME-Version: 2.0 X-Mailer: automailer 1.1 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-SMTP-HELO: starter4.aitcom.net X-SMTP-MAIL-FROM: starter4@starter4.aitcom.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: nameservices.net [216.117.139.1] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit From the Desk of: MR.IFEJIKA OSSY. ACCOUNT DEPARTMENT CITY EXPRESS BANK PLC. MARINA- BRANCH, LAGOS. FAX:234-1-759 3339 DIRECT. EMAIL:ifejikaossy@sify.com TO: THE MANAGING DIRECTOR/CEO DEAR SIR, RE:TRANSFER OF THE SUM OF US$30.5M DOLLARS INTO YOUR ACCOUNT FIRST,I MUST SOLICIT YOUR CONFIDENCE IN THIS TRANSACTION.THIS IS BY VIRTUE OF IT'S NATURE AS BEING UTTERLY CONFIDENTIAL AND TOP SECRET.THOUGH I KNOW THAT A TRANSACTION OF THIS MAGNITUDE WILL MAKE ANYONE APPREHENSIVE AND WORRIED.BUT I AM ASSURING YOU THAT ALL WILL BE WELL AT THE END OF THE DAY.WE HAVE DECIDED TO CONTACT YOU THROUGH THIS MEDIUM DUE TO THE URGENCY OF THIS TRANSACTION AS WE HAVE BEEN RELIABLY INFORMED OF YOUR DISCRETENESS AND ABILITY. LET ME START BY INTRODUCING MYSELF TO YOU. I AM MR. IFEJIKA OSSY,AN ACCOUNTANT WITH THE CITY EXPRESS BANK PLC BRANCH OFFICE LAGOS.I CAME TO KNOW ABOUT YOU IN MY PRIVATE SEARCH FOR A RELIABLE AND REPUTABLE PERSON TO HANDLE THIS CONFIDENTIAL TRANSACTION AS WE ARE STILL IN ACTIVE SERVICE. THE PROPOSITION. AN AUSTRALIAN NATIONAL,LATE ENGINEER BUTCH .R.MIGUEL,AN OIL MERCHANT/CONTRACTOR WITH THE FEDERAL GOVERNMENT OF NIGERIA,UNTIL HIS DEATH THREE YEARS AGO IN A GHASTLY AIR CRASH IN AN EGYPT AIR, FLIGHT 990 WHICH OCCURED ON 2ND NOVEMBER 1999,BANKED WITH US HERE AT CITY EXPRESS BANK PLC . MARINA BRANCH LAGOS,AND HAD A CLOSSING BALANCE OF US$30.5M(THIRTY MILLION FIVE HUNDRED THOUSAND UNITED STATES DOLLARS)IN A FIXED DEPOSIT ACCOUNT,WHICH THE BANK UNQUESTIONABLY EXPECTS IT TO BE CLAIMED BY ANY AVAILABLE FOREIGN NEXT-OF-KIN TO THE LATE BENEFICIARY OR ALTERNATIVELY BE DONATED TO A DISCREDITED TRUST FUND FOR THE PURCHASE OF ARMS AND AMMUNITIONS AT THE MILITARY WAR COLLEGE IN KADUNA STATE HERE IN NORTHERN NIGERIA. SEQUEL TO THIS,FERVENT VALUABLE EFFORTS WERE MADE BY CITY EXPRESS BANK TO GET IN TOUCH WITH ANY OF THE MIGUEL'S FAMILY OR RELATIVES BUT PROVED TO NO AVAIL.IT IS BECAUSE OF THE PERCEIVED POSIBILITY OF NOT BEING ABLE TO LOCATE ANY OF THE LATE ENGR.BUTCH R. MIGUEL'S NEXT-OF-KIN(HE HAD NO KNOWN WIFE AND CHILDREN) THAT THE MANAGEMENT UNDER THE INFLUENCE OF OUR HONOURABLE CHAIRMAN AND MEMBERS OF THE BOARD OF DIRECTORS,MAJOR-GENERAL KALU UKE KALU(Rtd), THAT AN ARRANGEMENT BE MADE FOR THE FUND TO BE DECLARED"UN-CLAIMABLE" AND SUBSIQUENTLY BE DONATED TO THE TRUST FUND FOR THE PURCHASE OF ARMS AND AMMUNITON TO FURTHER ENHANCE THE COURSE OF WAR IN AFRICA AND THE WORLD IN GENERAL.IN ORDER TO AVERT THIS CRUDE AND NEGATIVE DEVELOPMENT,SOME OF MY TRUSTED COLLEAGUES AND I NOW SEEK YOUR PERMISSION TO HAVE YOU STAND AS THE NEXT-OF-KIN TO LATE ENGR. BUTCH R.MIGUEL,SO THAT THE FUND US$30.5M WOULD BE RELEASED AND PAID INTO YOUR ACCOUNT AS THE BENEFICIARY'S NEXT-OF KIN.ALL DOCUMENTS AND PROVES TO ENABLE YOU RECIEVE THIS FUND WILL BE CAREFULLY WORKED OUT AND MORESO AS PROFESSIONAL BANKERS, WE ARE ASSURING YOU OF 100% RISK-FREE INVOLVEMENT. YOUR SHARE STAYS WHILE THE REST WILL BE FOR MYSELF AND MY COLLEAGUES FOR INVESTMENT PURPOSES IN YOUR COUNTRY. NOTE THAT THIS TRANSACTION WILL STRICTLY BE BASED ON THE FOLLOWING TERMS AND CONDITIONS AS I HAVE STATED BELOW, AS WE HAVE HEARD CONFIRMED CASES OF BUSINESS ASSOCIATES RUNNING AWAY WITH FUNDS KEPT IN THEIR CUSTODY WHEN IT IS FINALLY REMITTED INTO THIER BANK ACCOUNTS.A VERY GOOD EXAMPLE IS THE ONE OF MR. PETER HOPWOOD,THE PRESIDENT OF MILEAGE TRADING AND INVESTMENT COMPANY AT NUMBER 121, WEST 55TH STREET,21st FLOOR,NEW YORK 10022, AND THE FORMER CHAIRMAN OF OMPADEC(MR PATRICK OPIA)WHOM WE WERE RELIABLY INFORMED THAT AFTER THE AGREEMENT BETWEEN BOTH PARTNERS IN WHICH HE WAS TO TAKE 15% OF THE MONEY WHILE THE REMAINING 85% FOR THE NIGERIAN OFFICIALS.WITH ALL THE REMAINING DOCUMENTS SIGNED,THE MONEY WAS DULY TRANSFERED INTO MR HOPWOOD'S ACCOUNT, ONLY TO BE DISAPPOINTED ON THEIR ARRIVAL IN NEW YORK AND WERE INFORMED THAT MR PETER HOPWOOD WAS NO LONGER ON THAT ADDRESS,WHILE HIS TELEPHONE AND FAX NUMBERS HAD BEEN RE-ALLOCATED TO SOME BODY ELSE. THIS WAS HOW THEY LOST US$18.5M TO MR HOPWOOD.THIS IS A VERY RECENT STORY HERE IN MY COUNTRY AND EVERYBODY IS AWARE OF THIS.SOME OF THE OFFICIALS DECIDED TO CRY OUT AND FACE THE LAW,BECAUSE THEY FELT THEY HAD LOST SO MUCH TO A STRANGER,WHILE THE CHAIRMAN OF OMPADEC(MR PATRICK OPIA)IS NOW HIDDING IN A FORIEGN COUNTRY.SO RIGHT NOW, I AM TAKING ALL PRECAUTIONARY MEASURES TO GUARD AGAINST RE-OCCURENCE OF SUCH ACT IN OUR CASE.THIS IS WHY WE HAVE DECIDED THAT THIS TRANSACTION WILL BE BASED ON THE FOLLOWING:- (a) OUR CONVICTION OF YOUR TRANSPARENCY, HONESTY AND DILIGENCE. (b) THAT YOU WILL TREAT THIS TRANSACTION WITH UTMOST SECRECY AND CONFIDENTIALITY. (c) YOU MUST BE READY TO PRODUCE US WITH ENOUGH INFORMATION ABOUT YOURSELF TO PUT OUR MINDS AT REST. (d) THAT UPON RECIEPT OF THE FUND,YOU WILL PROMPTLY RELEASE OUR SHARE ON DEMAND AFTER YOU HAVE DEDUCTED YOUR 20%.YOUR URGENCY WILL BE HIGHLY APPRECIATED AS WE ARE ALREADY BEHIND SCHEDULE FOR THIS FINANCIAL QUATER. IF THIS PROPOSAL IS ALRIGHT BY YOU,THEN KINDLY GET TO ME IMMEDIATELY ON MY CELLULAR PHONE NUMBER:234-802-338-3499 FOR CONFIDENTIALITY OR REPLY TO EMAIL:ifejikaossy@anfmail.com THANK YOU IN ANTICIPATON OF YOUR COOPERATION. YOURS FAITHFULLY, MR. IFEJIKA OSSY (Chief Accountant) CITY EXPRESS BANK PLC. MARINA BRANCH LAGOS From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 24 03:43:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21502 for ; Sat, 24 May 2003 03:43:54 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4O7hM800613 for ; Sat, 24 May 2003 03:43:22 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4O7hJE01848 for ; Sat, 24 May 2003 03:43:19 -0400 (EDT) Message-ID: <3ECF2214.7050902@cisco.com> Date: Sat, 24 May 2003 08:41:08 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ppvpn@nortelnetworks.com Subject: Re: Draft charter for L2VPN: Perfect LAN emulation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: stbryant@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit If the plan is still to run the L2VPN over PWE3, then you should note the PWE3 charter does not curently require us to provide perfect emulation: "PWE3 will not strive for pseudo wires to perfectly emulate the characteristics of the native service. For each type of pseudo wire, an applicability statement will describe the degree of similarity of a pseudo wire to the native service it emulates." However Mark's criteria for L2VPN seems the right benchmark: "as long as people are comfortable that standards compliant "Ethernet devices are able to attach to the service and use it." Stewart From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun May 25 03:19:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25588 for ; Sun, 25 May 2003 03:19:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4P7JMv09920 for ; Sun, 25 May 2003 03:19:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4P7JJx05551 for ; Sun, 25 May 2003 03:19:19 -0400 (EDT) Message-Id: <200305250717.h4P7Hgf23673@zcars0jk.ca.nortel.com> From: KAKUDU BENSON To: ppvpn@lyris.nortelnetworks.com Reply-To: kakuduben2000@netscape.net Subject: URGENT ASSISTANCE Date: Sun, 25 May 2003 09:16:59 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="afa84283-16ba-4bde-938b-d597b19e0475" X-SMTP-HELO: netscape2075.com X-SMTP-MAIL-FROM: kakuduben200@netscape.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [62.194.86.49] X-LYRIS-Message-Id: This is a multi-part message in MIME format --afa84283-16ba-4bde-938b-d597b19e0475 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM:KAKUDU BENSON TEL:+31-630-140-801 REQUEST FOR A BUSINESS RELATIONSHIP This E-mail may come to you as a surprise but it was out of my sincere desire to share a mutual business relationship with you. I am a solicitor by name KAKUDU BENSON, a personal lawyer to the KABILA family and consequently represent their interest with respect to their monetary affairs. The family has $20.000.000.00 (Twenty Million United State Dollars) currently in a security company vault, this huge sum of money is in a coded form.The present president of The Democratic Republic of Congo JOSEPH KABILA intends to use this money for investment purposes without the consent of any foreign body outside the family. To come staight to the point, this money has been moved from Congo through Switzerland to Amsterdam The Netherlan! ds, and the Kabila's need you as a reliable investor that could be trusted with the PIN and CERTIFICATE OF DEPOSIT to enable us use the funds outside The Democratic of Congo. After lots of deliberation and consideration I as the family lawyer with the authority invested in me to immediately work on ways and means of transferring this sum of money to a reliable and trust worthy foreign partner that will be able to help and assist us secure the funds in a suitable account. Moreover, the personal identification Number/ Certificate of Deposit and The Letter of Authorityfrom my Law firm that will facilitate transfer of the funds is in my possession. Since no name was used in securing the funds in the vault, your name will be passed and tagged on the consignment of funds as the beneficiary.The family have reached an agreement with me that 25% of the total sum of the funds will be for your assistance towards this transaction.5% for eventual expences hat might be incurred on the course of this transaction if any, and 70% will be invested by you in a viable business for the family.I am presently in The Netherlands for the execution of this proposal and if the proposal is acceptable to you please call me on this number +31-630-140-801. E-mail meyour response includingyour telephone and fax number, for immediate commencement of this transaction. Finally, I wish to assure you that this transaction will not attract any risk on your behalf. Your response is required in other to speed up the process. Thanks in advance. KAKUDU BENSON, Esq, (Barrister) --afa84283-16ba-4bde-938b-d597b19e0475-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 26 04:48:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06034 for ; Mon, 26 May 2003 04:48:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4Q8lx703770 for ; Mon, 26 May 2003 04:48:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4Q8lua28828 for ; Mon, 26 May 2003 04:47:57 -0400 (EDT) Date: Mon, 26 May 2003 17:42:11 +0900 (JST) Message-Id: <20030526.174211.18266631.suzuki.muneyoshi@lab.ntt.co.jp> Cc: PPVPN@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Draft charter for L2VPN: Perfect LAN emulation From: Muneyoshi Suzuki In-Reply-To: <1561049532698.20030523162312@psg.com> References: <200305161338.h4GDcXkL027396@rtp-core-1.cisco.com> <1561049532698.20030523162312@psg.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > 2. Should the charter say that the WG will work with IEEE 802.1 > to ensure proper interworking. > I didn't see a discussion on the second issue, but it seems like a > reasonable proposal to me. I support this. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 26 10:07:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13039 for ; Mon, 26 May 2003 10:07:09 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4QE6a729069 for ; Mon, 26 May 2003 10:06:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4QE6Xu25284 for ; Mon, 26 May 2003 10:06:33 -0400 (EDT) Reply-To: From: "mark seery" To: "Muneyoshi Suzuki" Cc: Subject: RE: Draft charter for L2VPN: Perfect LAN emulation Date: Mon, 26 May 2003 07:02:00 -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: <20030526.174211.18266631.suzuki.muneyoshi@lab.ntt.co.jp> Importance: Normal X-SMTP-HELO: smtp809.mail.sc5.yahoo.com X-SMTP-MAIL-FROM: mseery@ix.netcom.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: [66.163.168.188] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit if we do, then some discussion about whether we specify service or network interworking, or whether it is left open, would be useful. personally would like to see a service interworking capability as I think a) it is more scalable b) is less likely to create conflict between IEEE and IETF and c) better leverages the underlying PSN technology. mark -----Original Message----- From: Muneyoshi Suzuki [mailto:suzuki.muneyoshi@lab.ntt.co.jp] Sent: Monday, May 26, 2003 1:42 AM Cc: PPVPN@nortelnetworks.com; suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Draft charter for L2VPN: Perfect LAN emulation > 2. Should the charter say that the WG will work with IEEE 802.1 > to ensure proper interworking. > I didn't see a discussion on the second issue, but it seems like a > reasonable proposal to me. I support this. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 26 14:27:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20260 for ; Mon, 26 May 2003 14:27:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4QIQd721201 for ; Mon, 26 May 2003 14:26:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4QIQar24464 for ; Mon, 26 May 2003 14:26:36 -0400 (EDT) From: "Mark Seery" To: Subject: RE: Draft charter for L2VPN: Perfect LAN emulation Date: Mon, 26 May 2003 11:24:18 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-SMTP-HELO: smtp011.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: smtp011.mail.yahoo.com [216.136.173.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit referring to multipoint only, not P2P. and guess I shouldn;t just throw the scalable flag out there. concerned about the complexities of running an Ethernet control plane over a PSN control plane: do we end up having to solve Ethernet issues, what will be the interaction between the two layers, ethernet is not just a simple data link layer - it is a protocol that spans multiple data links - it is in a sense approaching a network layer protocol...... Mark -----Original Message----- From: mark seery [mailto:mseery@ix.netcom.com] Sent: Monday, May 26, 2003 7:02 AM To: Muneyoshi Suzuki Cc: PPVPN@nortelnetworks.com Subject: RE: Draft charter for L2VPN: Perfect LAN emulation if we do, then some discussion about whether we specify service or network interworking, or whether it is left open, would be useful. personally would like to see a service interworking capability as I think a) it is more scalable b) is less likely to create conflict between IEEE and IETF and c) better leverages the underlying PSN technology. mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 26 18:27:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01543 for ; Mon, 26 May 2003 18:27:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4QMQt709607 for ; Mon, 26 May 2003 18:26:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4QMQq107443 for ; Mon, 26 May 2003 18:26:52 -0400 (EDT) Message-ID: <3ED29413.10C8A258@alcatel.com> Date: Mon, 26 May 2003 18:24:19 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN: Perfect LAN emulation References: <200305161338.h4GDcXkL027396@rtp-core-1.cisco.com> <1561049532698.20030523162312@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alex, Alex Zinin wrote: > > 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? I think a definition of the service being specified in the WG would be needed. Wrt level of transparency, I think the minimal requirement is any non-transparent characteristics must not affect the operation of these higher layer protocols. For VPLS, a definition of the service being specified in the WG would be helpful. Here's one suggestion : An emulated LAN service allows the inter-connection of (geographically) dispersed devices, not connected over a LAN segment, as if they were attached to a single LAN. Hence standard compliant devices (e.g. bridges, routers, hosts) would be able to work as if they are connected to a LAN when connected to the emulated LAN service. An emulated LAN service operates below the MAC Service Boundary, and is transparent to protocols operating above this boundary. The emulation may be imperfect in terms of QoS (limitation should be documented in solution specifications), compared to operation over a LAN, as long as the differences/degradation in the emulated service does not prevent standard compliant devices from functioning. However, the emulated LAN service must not introduce artifacts which break the operation of standard compliant devices. > 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 think a definition of the desired LAN emulation service is useful. I am not clear if there is agreement on this or what is "perfect emulation". > I didn't see a discussion on the second issue, but it seems like a > reasonable proposal to me. Yes. Thanks Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 26 19:03:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03336 for ; Mon, 26 May 2003 19:03:52 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4QN3L720071 for ; Mon, 26 May 2003 19:03:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4QN3IG00678 for ; Mon, 26 May 2003 19:03:18 -0400 (EDT) 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: call fo discussion on draft-heinamen-radius-pe-discovery-03.txt Date: Mon, 26 May 2003 19:01:21 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA399714E5F755@mailserv.hatteras.com> Thread-Index: AcMj2OWXsh8kaReQQ4mRgVObTEpzFwAALI/w From: "Matt Squire" To: "Juha Heinanen (E-mail)" Cc: , X-SMTP-HELO: mailserv.hatterasnetworks.com X-SMTP-MAIL-FROM: MSquire@HatterasNetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailserv.hatterasnetworks.com [63.89.58.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA03336 > > > You can use draft-chiba to send a CoA-Request with > Service-Type="Authorize > > Only" in order to make this happen. > > yes, perhaps so. however, i would not like to make mandatory anything > that is beyond current standards. optional recommendations based on > drafts are ok. > > so where are we now? are people happy if i make another > version of the > draft, where the pes always re-authenticate all their sites every N > minutes and accounting keepalives are not used? if so i can do it and > publish the new version as wg document. > I'd like to see the comments addressed and the draft re-submitted. I think there's ample precedent for RADIUS being used for such a discovery process, and examples have been given by both Bernard and Juha. The draft doesn't impose any new requirements or protocol elements on the existing standards, and improvements underway apply to many RADIUS applications. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 26 19:15:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03913 for ; Mon, 26 May 2003 19:15:43 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4QNFC724078 for ; Mon, 26 May 2003 19:15:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4QNF7P06051 for ; Mon, 26 May 2003 19:15:07 -0400 (EDT) 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: Perfect LAN emulation Date: Mon, 26 May 2003 19:12:54 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA399714E5F756@mailserv.hatteras.com> Thread-Index: AcMj20M9EvpDUywiQ5WU7Qp2bjs4kQAAAo4w From: "Matt Squire" To: "Alex Zinin" Cc: X-SMTP-HELO: mailserv.hatterasnetworks.com X-SMTP-MAIL-FROM: MSquire@HatterasNetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailserv.hatterasnetworks.com [63.89.58.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA03913 > > 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 - I (nor anyone else that I saw) never asked for perfect emulation, I don't even know what perfect emulation is. What I think is important, and what I think we need to have in the charter, is transparency. Standard Ethernet devices and existing protocols must be able to operate over a L2VPN without alteration. My suggested wording on the issue was (from previous email) was: "The WG will drive for solutions that are transparent to higher layer protosols such as 802.1D bridging and IP. Optimizations to a basic transparent architecture may be developed to foster more efficient transport in special cases (such as IP only transport). " That's transparency. Perfect emulation wasn't on my radar. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon May 26 22:12:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11533 for ; Mon, 26 May 2003 22:12:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4R2Be714330 for ; Mon, 26 May 2003 22:11:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4R2Bc109585 for ; Mon, 26 May 2003 22:11:38 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , PPVPN@nortelnetworks.com Subject: RE: Draft charter for L2VPN: Perfect LAN emulation Date: Mon, 26 May 2003 22:09:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C323F5.128A8B18" X-LYRIS-Message-Id: 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_01C323F5.128A8B18 Content-Type: text/plain; charset="iso-8859-1" Alex, > > 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? > It looks one of the implications of such addition to the charter is the ability to support services and solutions related to IPLS (or IP-only interworking). Maybe instead of debating the level of transparency or trying to define it, why not just include in the charter a statement that allows the wg to develop "IP-only" or "IP-optimized" L2VPNs services in addition to basic l2vpn services. > 2. Should the charter say that the WG will work with IEEE 802.1 > to ensure proper interworking. > Not sure what you mean by "interworking" here but if you mean coordinate with ieee, the answer is yes. Hamid. ------_=_NextPart_001_01C323F5.128A8B18 Content-Type: text/html; charset="iso-8859-1" RE: Draft charter for L2VPN: Perfect LAN emulation

Alex,

>
> 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?
>

It looks one of the implications of such addition to
the charter is the ability to support services and
solutions related to IPLS (or IP-only interworking).

Maybe instead of debating the level of transparency
or trying to define it, why not just include in the charter a statement
that allows the wg to develop "IP-only" or "IP-optimized" L2VPNs
services in addition to basic l2vpn services.

>  2. Should the charter say that the WG will work with IEEE 802.1
>     to ensure proper interworking.
>

Not sure what you mean by "interworking" here but if you
mean coordinate with ieee, the answer is yes.

Hamid.

------_=_NextPart_001_01C323F5.128A8B18-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 04:08:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03435 for ; Tue, 27 May 2003 04:08:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4R87Tf14012 for ; Tue, 27 May 2003 04:07:30 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4R87Qb03594 for ; Tue, 27 May 2003 04:07:26 -0400 (EDT) Date: Tue, 27 May 2003 15:56:32 +0800 From: lidefeng Subject: Please review: The updation of the draft about hierarchy of PE in BGP/MPLS VPN To: internet-drafts@ietf.org Cc: ppvpn@nortelnetworks.com, erosen@cisco.com Message-id: <006001c32425$7d827f40$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: multipart/mixed; boundary="Boundary_(ID_HfOQV4gT/yJ0/VGMfluCzQ)" X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_HfOQV4gT/yJ0/VGMfluCzQ) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi,all, The latest version of draft about hierarchy of PE in BGP/MPLS VPN(draft-libin-Hierarchy-pe-bgp-mpls-vpn-02.txt) is attached,and the updation from last version is as following: a. Add the interoperability statement of HoPE and [2547bis]; b. Add the section to resolve the scalability of BGP/MPLS VPN in access the customer in the lower layer network. c. Correct some typo error. The HoPE solution and the HoPE based solution can resolve the scalability problem in access the lower layer customer to BGP/MPLS VPN. This draft is presented on the 56th IETF PPVPN WG meeting,which was not carefully reviewed,I think,however,access to different layer customer is a very important problem for Service Provider and customer,which can't be resolved by normal 2547bis VPN. Regards Defeng Li --Boundary_(ID_HfOQV4gT/yJ0/VGMfluCzQ) Content-type: text/plain; name=draft-libin-hierarchy-pe-bgp-mpls-vpn-02.txt Content-disposition: attachment; filename=draft-libin-hierarchy-pe-bgp-mpls-vpn-02.txt Content-Transfer-Encoding: 7BIT Network Working Group Li Bin Internet Draft Dong Weisi Expires: November 2003 Huawei Technologies Chen Yunqing China Telecom Beijing Research Institute Li Defeng Huawei Technologies MAY 27, 2003 Hierarchy of Provider Edge Device in BGP/MPLS VPN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should maintain all the VPN routes of the VPNs which it belong to.If there are many VPNs attaches to a PE,and the capacity of PE is somewhat limited,then the bottleneck will be encountered.Another problem is that the current BGP/MPLS VPN model is something of a "Plane Modle" where the demand of the performance of the PE device are all the same no matter which layer the PE device is belongs to.However,the typical network is "Core-Convergence-Access(Edge)" layered model,and the performance of the device is high in Core Layer and low in Access Layer,and the scale of network is large in Access Layer and small in Core Layer,the routes are converged in every layer,so in current "Plane Modle",when PE device extend to the edge layer,it has to maintain more VPN routes,which makes it difficult to extend the PE device to edge layer.This document defines an model of Hierarchy of Provider Edge Device in BGP/MPLS VPN,where Hierarchy of Provider Edge Device can be composed of several PE and each PE plays the different part,partake the function of the normal RFC 2547 PE,we call this model "Hierarchy Model",In this model,the demand of performance in Routing and Switching is strict to the PE device in higher layer,loose to the PE device in edge layer. One HoPE can be composed of an SPE and UPES connected with the SPE, or be composed of a high-level SPE and HoPEs connected and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connects with the high-level SPE act as a role of UPE,and the new HoPE can connect a single UPE too. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 1] Draft November 2002 Table of Contents 1. Introduction ...................................................3 2. Working Principle ..............................................4 2.1 VPN routes ....................................................4 2.2 Control Flow(Route Advertising and Label Distribution).........5 2.3 Data Flow(Label Operation and Packet Forwarding) ..............6 3. Interface between UPE and SPE...................................7 4. Nesting of HoPE.................................................7 5. Multi-Homing UPE................................................9 6. Backdoor link between UPEs......................................9 7. UPE/CE routing protocol ........................................9 7.1 Sham-link in HoPE..............................................9 8. The Forwarding Procedure in Some Special Cases..................9 9. Layered BGP/MPLS VPN with HoPE.................................10 10. Interoperability..............................................11 11. Security Consideration........................................11 12. Updation from last version....................................11 10. Acknowledge...................................................12 11. References....................................................12 12. Authors' Addresses............................................12 Full Copyright Statement .........................................12 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 2] Draft November 2002 1. Introduction This document defines an model of Hierarchy of Provider Edge Device in BGP/MPLS VPN,where Hierarchy of Provider Edge Device can be composed of several PE device and every PE play the different part,partake the function of the normal concentrative PE,we call this model "Hierarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in higher layer,loose to the PE device in edge layer. PE device can connect with not only the Customer Edge(CE) device,but also a PE device,or even more generally an IP/MPLS VPN network,and the connected PE devices formed the "Hierarchy of PE",and the PE device which replace the former position of CE device in "Plane Model" is called Under-layer PE(UPE),and the PE device which UPE is connected with is called Superstratum PE(SPE),this architiecture is called Hierarchy of PE(HoPE).and the architecture figure is as follows(figure 1): +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ +---+ +----------+ +----+ figure 1: Hierarchy of PE Architecture Several UPE and SPE formed the Hierarchy of PE,which provide the conventional function of PE in "Plane Model"(rfc 2547),and their respective functions are as follows: UPE maintains only the routes of the VPN sites which is directly connected with UPE,it doesn't maintain the specific routes of the remote VPN sites or only maintain the aggregate routes,SPE maintains the routes of all the VPNs attached to the SPE or the UPEs connected with the SPE.UPE distributes the inner MPLS labels for the routes in the sites directly connected with it,and advertise the labels concomitant with the VPN routes through MP-BGP to SPE ,SPE doesn't advertise the routes in the remote VPN sites to UPE,it only advertises the VRF default route or aggregate routes to UPE,and the routes is concomitant with the MPLS labels. MP-IBGP or MP-EBGP can be applied between UPE and SPE,while MP-IBGP is applied,SPE should act as the Route Reflector(RR) for all the UPEs collected to it,and UPE plays the role of Client of this RR,but SPE doesn't act as the RR for other PEs. If MP-EBGP is applied between MP-EBGP,the AS number of the UPEs should be the private AS number(64512~65535).In fact,the Hierarchy of PE can be handles with the rules of Confederation,in which case every confederation AS is composed of only one BGP Speaker, that is the UPE collected with the SPE. The packet forwarding between SPE and UPE is based on the labels,so only one interface is needed between them,this interface can be a physical interface,or sub-interface,such as VLAN,PVC,tunnel such as GRE or LSP.When tunnel is applied between UPE and SPE,an IP/MPLS network can be deployed between them. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 3] Draft November 2002 Hierarchy of PE plays all the functions of the normal PE, there is no difference between them when looked outside,so this "special" PE can coexist with other PEs in the MPLS network to build BGP/MPLS VPN. 2. Working Principle This section specifies the working principle of HoPE including the maintaining and advertising of VPN routes,distribution of MPLS labels,and packet forwarding. 2.1 VPN routes SPE can establish MP-BGP neighborship with UPE,if they are administered by the same service provider(SP),they can be MP-IBGP neighborship,otherwise should establish the MP-EBGP neighorship. In the MP-IBGP case,if there exists several UPEs collected with an SPE belong to the same VPN,SPE acts as the Route Reflector for the connected UPEs,otherwise SPE act as the convergent PE for all the UPEs collected with it.Route-Target lists are used to select the right VPN routes from other PEs as the normal "Plane Modle" BGP/MPLS VPN(RFC 2547bis),while only SPE will exchange the route information with other PEs,UPE should send the import route target list to SPE,SPE converges the route target lists and derives the HoPE-wide import route target list,with this HoPE-wide import route target,SPE can select the right VPN routes which belong to the VPNs which have the sites attached to the SPE directly or through UPE. This HoPE-wide import route target list can be configured manually or derived dynamically between SPE and UPEs.The dynamic mechanism is as follows: UPE advertises the ORF(Outbound Route Filter)[BGP-ORF] to SPE through Route Refresh(RFC 2918) message,and an extended community list is included in the ORF item,the content of the extended community list is the aggregation of the import route target lists of all the VRFs in the UPE,and SPE converges all the import route target lists received from the UPEs connected with SPE and derive the HoPE-wide import route target list. In MP-EBGP case,SPE should derive the HoPE-wide import route target list all the same with the mechanism as above.In general,UPE should adopt the private AS number in VPN routes advertised to SPE.When SPE advertised the routes to other PEs,it should omit the private AS. The scheme in which SPE connected with part of UPEs through MP-IBGP, and to the other part UPEs through MP-EBGP is permitted,then SPE acts as RR and convergent PE at the same time. UPE selects its own VPN routes by match its own import route target list with the export route target list attached with VPN routes respectively. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 4] Draft November 2002 SPE advertises the VRF default route or aggregate routes(according to which UPE transfers the VPN packet to SPE) to UPE,this default VRF route can be formed dynamically or configured manually.When formed dynamically,it can be filtered by the ORF mechanism mentioned above. 2.2 Control Flow(Route Advertising and Label Distribution) This section specifies the mechanism the network distributing the labels for the routes in the VPN sites.The following figure (Figure 2) signifies the control flow between VPN1 site1 and VPN1 SITE2,the control flows(route and label distribution) in the two directions are different,there are four steps in every direction, labeled (1) through (4) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (5) through (8) in the direction from VPN1 site1 to VPN1 SITE2. | (4) | (3) | (2) | (1) | |<-------|<------|<--------------|<-----| v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE |---|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ | (5) | (6) | (7) | (8 ) | |------->|------>|-------------->|----->| Figure 2: The control flow(route and label distribution) In Figure 2,the meanings of (1) through (8) are as follows: Label (1) through (4) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (1) CE2 advertises a route in the VPN1 SITE2 to PE; (2) PE distributes an inner MPLS label for this route;PE advertises this route concomitant with the inner label to SPE through MP-BGP , and the relevant export route target list attached with the route; (3.a) SPE matches the export route target list in the received route with the HoPE-wide import route target list to decide whether or not import the VPN route,in this case,they can be matched,then SPE will import the received VPN route. (3.b)At the same time SPE will match the export route target list in the received route with the import route target list advertised by VRF in UPEs connected with SPE,in this case, the import route target list of the VRF in UPE corresponding to VPN1 Site1(called VRF1) will match,then SPE will advertise the default VRF1 route to UPE,with the inner MPLS label distributed by PE attached; (4) UPE advertise this route to CE1 through the route protocol(RIP, OSPF,BGP,or default route) between CE1 and UPE. Label (5) through (8) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (5) CE1 advertises a route in the VPN1 site1 to UPE; Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 5] Draft November 2002 (6) UPE distributes an inner label for this route;UPE advertises this route to SPE through MP-BGP with the inner label; (7) SPE replaces the inner label distributed by UPE with another inner label distributed by SPE,then advertises this route to PE through MP-BGP with the new inner label attached; (8) PE distributes the route to CE2 with no label attached. Of course,the LSP should be established between SPE and PE in two directions respectively,This mechanism is the same as RFC 2547bis. The procedure of forwarding VPN packet with the two labels detailed in section 2.3. 2.3 Data Flow(Label Operation and Packet Forwarding) This section specifies the mechanism of forwarding the VPN packets in the network with the route and label information derived by section 2.2. The following figure(Figure 3) signifies the data flows between VPN1 site1 and VPN1 SITE2,the data flows(Label Operation and Packet Forwarding) in the two directions are different,there are five steps in every direction,labeled (1) through (5) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (6) through (10) in the direction from VPN1 site1 to VPN1 SITE2. | (10) | (9) | (8) | (7) | (6) | |<-------|<------|<--------|<-----|<-----| v v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE |--|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ ^ | (1) | (2) | (3) | (4) | (5) | |------->|------>|--------|----->|----->| Figure 3: Data Flow(Label Operation and Packet Forwarding) In Figure 3,the meanings of (1) through (10) are as follows: Label (1) through (5) specifies the forwarding procedure in the direction of VPN1 Site1 visit VPN1 SITE2: (1) When the VPN packet of VPN1 Site1 visit VPN1 SITE2 arrived to CE1,CE1 forward the packet to UPE based on the default route or the route derive from dynamic route protocol between CE1 and UPE specified in the (4) of section 2.2. (2) UPE push the inner label based on the default VRF route,forward the VPN packet to SPE,the inner label and the default VRF route are specified in the (3) of section 2.2. (3) SPE POP the inner label pushed by UPE specified in (2) above,and look up the VRF route,push the new inner label which distributed by PE specified by (2) of section 2.2,then push the outer label distributed by P and forward the VPN packet to P,in backbone network, all the P router in the path of LSP from SPE to PE swap the outer label and forward the VPN packet through this LSP until the packet arrived to PE,or optionally the P router pen-ultimate-hop pop the label. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 6] Draft November 2002 (4) The P router pen-ultimate hop to PE POP the outer label,forward the VPN packet to PE. (5) PE POPs the inner label,and forwards the VPN packet to CE2,then CE2 forwards the VPN packet to the VPN1 SITE2. Label (6) through (10) specifies the forwarding procedure in the direction of VPN1 SITE2 visit VPN1 Site1: (6) When the VPN packet of VPN1 SITE2 visiting VPN1 Site1 arrives to CE2, CE2 forwards the packet to PE based on the default route or the route derived from dynamic route protocol between CE2 and PE specified in the (8) of section 2.2. (7) PE PUSHes the inner label distributed by SPE specified in (7) of section 2.2 based on the VRF route,then PUSHes the outer label distributed by P and forwards the VPN packet to P,in backbone network,all the P router in the path of LSP from PE to SPE swaps the outer label and forwards the VPN packet through this LSP until the P router pen-ultimate hop to SPE. (8) The P router optioanlly pen-ultimate hop to SPE POP the outer label,forward the VPN packet to SPE. (9) SPE swaps the inner label in the VPN packet with the inner label distributed by SPE with the new inner label distributed by UPE specified in (6) of section 2.2,then forward the VPN packet to UPE. (10) UPE POPs the new inner label,forwards the VPN packet to CE1,then CE1 forwards the VPN packet to the VPN1 Site1. 3. Interface between UPE and SPE UPE can connect with SPE with any type of interface and sub-interface,even with tunnel interface,in this case,UPE can connect with SPE through an IP/MPLS network,and because SPE and UPE are MP-BGP peers,the routes can be advertised directly through TCP connection.In MP-EBGP case,UPE and SPE can set up EBGP peers across the IP network or MPLS network by Multi-hop EBGP,when UPE or SPE forwarding the VPN packets with the label,they must pass a tunnel, if the tunnel is GRE,MPLS encapsulation must be supported;If the tunnel is LSP,the network between UPE ang SPE must be MPLS network, LDP/CR-LDP or RSVP-TE must be supported in UPE and SPE. 4. Nesting of HoPE One HoPE can be composed of a SPE and UPEs connected with the SPE, or be composed of a high-level SPE and HoPEs connected with it and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect with the high-level SPE acts as a role of UPE,and the new HoPE can connect with a single UPE too.Figure 4 in the following signifies a three-layer HoPE,and call the PE in the middle layer as MPE(Middle-level PE). Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 7] Draft November 2002 +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ | | +----------+ +----+ | | | | +----------+ +----+ +----+ | | |VPN1 Site4|--|UPE3|--|MPE |------| | +----------+ +----+ +----+ +---+ (Nesting of HoPE) figure 4: Nesting of HoPE Between SPE and MPE,and between MPE and UPE run MP-BGP,if run MP-IBGP,then SPE worked as the route reflector for all the MPEs,and MPEs worked as the route reflector for all the UPEs which connected with it,and MP-BGP advertises all the VPN routes of the underlayer PEs to the upperlayer PE,and advertise the default VRF route or the aggregate route of the upperlayer to the underlayer PE. So SPE maintains all the VPN routes of VPNs attached to the whole HoPE,and the MPE maintains the VPN routes of UPEs connected with this MPE.UPE maintains the VPN routes of sites connected with this UPE. SPE advertises the default VRF routes with the label attached to MPE,MPE replaces this label with the new label,and advertises this route with the new label attached to UPE. The upperlayer PE should create a HoPE-wide global import route target list,filter the VPN routes that don't belong to the VPNs connected with this upperlayer PE.MPE converge all the import route target lists of the UPEs connected with this MPE,and SPE converge all the converged import route target lists of the MPEs connected with this SPE.And this convergence can be configured statically or derived dynamically,in the latter case,MPE should forward the import route target list of MPE to SPE through ORF. When the VPN packet from the local site of HoPE is forwarded to UPE, UPE look up the relevant default VRF route,push the label and forward the packet to MPE,MPE POP the label,look up the default VRF route or aggregate route to SPE,PUSH a new label forward the packet to SPE,SPE POP this label,look up the VRF forwarding table,PUSH the inner label,and the outer label the P router distribute for this route,then follow the RFC 2547bis forwarding procedure. Because MPE has distributes the inner label for the destination address of the VPN packet from the remote site,when the remote VPN packet is forwarded to SPE through the MPLS network following the RFC 2547bis forwarding procedure. SPE swap the inner label,forward this packet to MPE following the similar procedure,MPE swaps the inner label and forwards this packet to UPE,then UPE POP the inner label and forwards this packet to the local site. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 8] Draft November 2002 5. Multi-Homing UPE One UPE can connects with several SPEs,in this case UPE is called Multi-Homing UPE,all the SPEs advertise the default VRF routes to this UPE,and UPE selects the best one or treat them as ECMP(Equal Cost Multi-Path) and share the load among them.UPE advertised the VPN routes to all the SPEs,it can advertise all the VPN routes to all the SPEs,or it can advertise one part of VPN routes to one SPE, the other part to the other and share the load among the SPEs. 6. Backdoor link between UPEs A kind of backdoor link can be setup between UPEs,so that the sites connected with these two UPEs can communicate with each other directly without passing through the SPE.And these UPEs can be those connect to the same SPE,or can be those connect with the different SPE,these UPEs advertise the VPN routes to each other through MP-BGP,The control flow and data flow are the same with RFC 2547bis Procedures,and even they can cross a ip/mpls network,and the packet can pass through a tunnel such as GRE or LSP. 7. UPE/CE routing protocol As specified in RFC 2547bis,RIP/OSPF/ISIS/EBGP can be routing protocol between UPE/CE.If RIP/OSPF/ISIS runs between UPE and CEs, UPE should run each routing instance for every site.Especially,if OSPF/ISIS runs between UPE/CE,the procedure following [VPN-OSPF] except that the sham-link end-point is different. 7.1 Sham-link in HoPE If OSPF/ISIS runs between UPE and CE,and the backdoor link exists between a VPN site attached to HoPE and a VPN site attached to the remote PE,and OSPF runs on the backdoor link,the above mentioned two sites belong to the same OSPF area,then Sham Link shoud be created between the UPE in the HoPE and the remote PE.The site attached to HoPE can access the routes in the remote sites without traverse the SP backbone,if it can only get the default routes or aggregated routes through UPE,the routes through the backdoor link is preferred to the routes through UPE,and at most time it is not desirable.To address the problem,you can select one of the following two alternatives: --Aggregate the routes throught the backdoor at the same granularity,and make the CE-UPE link to be preferred by configuring the metric. --Remote PE distribute the routes in the remote sites to UPE through sham-link,and configure the larger metric to the backdoor link,then the CE-UPE link will be preferred. 8. The Forwarding Procedure in Some Special Cases In one case that SPE connects with two UPEs called UPE1 and UPE2,and these two UPEs connect with two sites called site1 and site2 respectively,and site1 and site2 belong to the same VPN and visit to each other through SPE.The forwarding procedure is as follows:When Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 9] Draft November 2002 the packet sent from site1 arrived to UPE,UPE pushes the label based on the default route and forwards it to SPE,SPE POPs this label,then looks up the VRF route table,PUSHes the label distributed by UPE2 and forwards it to UPE2,and UPE2 POPs the label,forwards it to site2,and in the opposite direction,vice versa. In another case that SPE connects with one UPE and one CE,CE connect with site1,UPE connect with site2,site1 and site2 belong to the same VPN.The forwarding procedure is as follows: (1)When the packet with no label sent from site1 arrives to SPE through CE, SPE looks up VRF route table,and pushes the label distributed by UPE,forwards it to UPE,UPE POPs this label,forwards it to Site2. (2)When the packet originated from Site2 arrives to UPE,UPE forwards the packet to SPE on the basis of default or aggregate route,SPE then looks up the VRF route table,POPs the label,forwards it to Site1 as an IP packet. 9. Layered BGP/MPLS VPN with HoPE In [2547bis],all the PEs of the whole BGP/MPLS VPN is in the same layer(though in the Route Reflector situation,the VPN structure is somewhat layered,but it is hierarchy of RR and PE,not that of PEs), which is a plane structure.This VPN structure is difficult to attach to the VPN customer in the different layer of network,If a customer would like to access the existing VPN with a large amount of VPN routes,his CE router must be attached to the PE which can accomodate the whole VPN routes,if this customer is situated in the lowest layer of network,where is faraway from the nearest PE,then maybe the only way to attach this customer to PE is laying the long leased line between the CE and PE.If there are many different customer who want to access this VPN,then such long leased line to connect the CEs and the PEs,not to speak the expensive cost,these long leased lines make the network structure more complicated and scalability difficult. In investigation of the BGP/MPLS VPN deployment situation,the desire of the lower layer network customer to access in the BGP/MPLS VPN is universal,such as subbranch offices of the different Government department of nationwide corporation.To address this problem,it is desirable to organize the whole VPN with the different sub-VPN at different domain or different layer,the PEs in the different sub-VPN only maintain the VPN routes of that sub-VPN,with the exception in the PE connects to the higher layer sub-VPN,by which PE the lower layer sub-VPN connect to the higher layer sub-VPN with the aggregated routes and advertise the default VRF routes to the higher layer sub-VPN,and the higher layer sub-VPN gets to the lower layer sub-VPN with such default VRF routes.Then the different sub-VPN can attach the customer at different network layer to the nearest PE which only needs to maintain the VPN routes of that sub-VPN,and only one of such PEs connect to the higher layer sub-VPN with aggregated routes,and this particular PE takes on the part of Route Reflector for the whole PEs in the sub-VPN it belongs to.This can be illustrated as following figure(Figure 5). Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 10] Draft November 2002 ____ ___ ____ _/ \___/ \ _/ \__ / \__/ \_ / \ / BGP/MPLS VPN (core Network) | \ suv-VPN / \ ___ ___ __ _/ \_/ \____/ \___/ \____/ |PE| |PE| |__| |__| ________ \ \ ________ _/ \__ _\_ \____/ \__ /suv-VPN \_|PE|(RR for sub-VPN) |PE| suv-VPN \____ / |__| |__| \ /BGP/MPLS VPN \\ ^||/(Convergence Layer)| \(Convergence Layer)|\ Aggregated |||\ BGP/MPLS VPN __/ \ ___ ____/ \ routes ||| \ ___ _/ \_/ \____/ \ ||| \_/ \____/ \__ |||Default VRF route ________|PE| __|V ______ _/ |__| |PE| _/ \__ / \__ |__|/ \ / suv-VPN \ / suv-VPN \ /(Access Layer) | /(Access Layer) | \ BGP/MPLS VPN __/ \ BGP/MPLS VPN __/ \ ___ _/ \ ___ _/ \_/ \____/ \_/ \____/ Figure 5. Layered BGP/MPLS VPN with nesting of HoPE The requirement of performance and capacity for the PEs belong to the core network sub-VPN can be different from that for the PEs belong to the convergence layer sub-VPN and that for the PEs belong to the access layer sub-VPN,so this solution can address the bottleneck of scalability of BGP/MPLS VPN in the lower layer network,and this problem is not touched at all in [2547BIS]. The work principle of control plane and data plane between sub-VPNs follows the procedure detailed in section 2 through section 8,with the nesting of HoPE involved. 10. Interoperability This solution doesn't introduce any backward compatibility problem with [2547BIS],the only difference in the label processing in SPE is that when it receive the labeled packet from UPE or MPE(in nesting of HoPE situation),SPE will swap the outer label with the label the remote PE advertised to it,so the solution can operate with [2547BIS] without any difficulty.You can deploy some PEs of the whole BGP/MPLS VPN with HoPE,and the other PEs with [2547BIS]. This deployment is verified as efficiently in the Service Provider. 11. Security Consideration The level of security provided by this architecture is identical to that provided by the RFC 2547bis,there is no security problem introduced by HoPE. 12. Updation from last version a. Add the interoperability statement of HoPE and [2547bis]; b. Add the section to resolve the scalability of BGP/MPLS VPN in access the customer in the lower layer network. c. Correct some typo error. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 11] Draft November 2002 13. Acknowledgements The authors would like to thank Li Hejun, Cao Xuegui,Chang Wenjun, We are very appreciated for their support 14. References [RFC2026] Bradner, S., "The Internet Standards Process--Revision 3", BCP 9, RFC 2026, October 1996. [BGP-ORF] Enke Chen,Yakov Rekhter,"Cooperative Route Filtering Capability for BGP-4",draft-ietf-idr-route-filter-06.txt. [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, September 2000 [RFC2547] E. Rosen, Y. Rekhter, BGP/MPLS VPNs, RFC 2547,March 1999. [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work in progress. [VPN-OSPF] Rosen, Psenak and Pillay-Esnault, "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", February 2003, draft-rosen-vpns-ospf-bgp- mpls-06.txt 15. Author's Address Li Bin D201 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : l.b@huawei.com Dong Weisi C401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : dongws@huawei.com Chen Yunqing China Telecom Beijing Research Institute No.52,Hua Yuan North Road, Haidian District,Beijing,100083,China Tel:+86-10-62304554 Fax:+86-10-62304157 E-mail:chenyunqing@vip.sina.com Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 12] Draft November 2002 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 13] --Boundary_(ID_HfOQV4gT/yJ0/VGMfluCzQ)-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 05:23:58 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05627 for ; Tue, 27 May 2003 05:23:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4R9NQf03002 for ; Tue, 27 May 2003 05:23:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4R9NNl15414 for ; Tue, 27 May 2003 05:23:24 -0400 (EDT) X-Original-Recipient: PPVPN@nortelnetworks.com Message-ID: <3ED32CD4.6020802@pi.se> Date: Tue, 27 May 2003 11:16:04 +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: Ross Callon CC: Yakov Rekhter , Juha Heinanen , Alex Zinin , PPVPN@nortelnetworks.com, l3vpn@ietf.org Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider References: <4.3.2.20030516140719.028fab60@zircon.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailb.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailb.telia.com [194.22.194.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ross, thinking about this I believe that there are four different scenarios: - single provider / single AS - single provider / multiple AS - multiple co-operating providers / multiple AS - Internet I would like any solution for the L3 VPN to work in all these scenarions. Having said this I also recognize that there is a difference on possible level of service in the different scenarios. While an L3VPN across the Internet will be a best effort service, the same service in the single provider / single AS might give you absolute QoS guarantees. So I my take is that we need to be open recognize all these scenarios in the charter, but would like to see i clear priority. My personal priority today would be: 1. Internet 2. single provider / single AS 3. multiple co-operating providers / multiple AS 4. single provider / multiple AS Where priority 1 and 2 is a photo finish decision. /Loa Ross Callon wrote: > At 10:02 AM 5/12/2003 -0700, Yakov Rekhter wrote: > >>... The inter-AS >>solution must has enough details from the very beginning to >>demonstrate that there is a a backwards compatible migration path > >>from intra-provider to inter-provider. > >>Yakov. > > > My understanding is that this discussion is still related to what goes into > the proposed charter for the Layer 3 VPN working group. In this context > we don't have to solve the problem right now, we just need to decide > what goes into the charter. > > My personal view is that multi-AS one-provider is important enough that > it is worth mentioning in the charter. Multi-AS, multi-provider is probably > also something that we want to have as a possible option. Thus I think > that we might as well mention these in the charter. > > I am not so sure about slowing down the base documents in order to > get the multi-AS cases fully fleshed out. We have already slowed down > the base documents to wait to finish the Framework and Requirements > documents, and there is the possibility of slowing them down to wait > for a security document. > > To me whether to insist on the inter-AS case being solved and fully > documented before progressing the solutions documents comes down > to three things: (i) How important are the multi-AS cases; and (ii) How > confident are we that if we postpone the multi-AS work, that we > won't end up with a situation where we wish that we had changed the > base documents; and (iii) How long will it take to fully document the > inter-AS cases? > > A question for Alex and Thomas Narten: Suppose hypothetically that > there is consensus to work on the inter-AS cases, and suppose that > we don't want to slow down the base documents to wait for this to > complete. In this case, the L3 VPN working group might work on > progressing existing documents (the long list from the proposed > charter that Alex sent out) as a high priority item, and work on the > inter-AS cases as a lower priority. In this case, would we want to > explicitly mention the Inter-AS cases in the charter? > > Ross > > > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 05:42:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05918 for ; Tue, 27 May 2003 05:42:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4R9fvf07697 for ; Tue, 27 May 2003 05:41:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4R9ftw26409 for ; Tue, 27 May 2003 05:41:55 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: rwilder@masergy.com Cc: jh@lohi.eng.song.fi, aboba@internaut.com, PPVPN@nortelnetworks.com Subject: RADIUS Discovery Discussion Summary Date: Tue, 27 May 2003 10:38:37 +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" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Rick Where do we stand with things regarding the RADIUS discovery draft (draft-heinanen-radius-pe-discovery) becoming a WG document? A number of issues have been raised by Bernard and have been resolved either through further explanation from Juha, or through agreed amendments to the next version of the draft. I believe a summary of the issues resolved to date is as follows: 1. Section 2 attempts to update RFC 2486. - This was fixed in version 4, the terms conflicting RFC2486 are gone. 2. Use of RADIUS for service discovery is a bad idea. - Agreed that the draft does not use service discovery and that the use of RADIUS for discovering VPN endpoints is OK. 3. Requires that RADIUS servers be stateful. - Agreed to add a statement to this effect in the next version of the draft. 4. Include potential mitigating measures in the Security Considerations section. - Security considerations such as those in RFC2868 and draft-aboba-radius-rfc2869bis-22.txt could be incorporated or referenced in the next version of the draft. 5. Exponential backoff is required to support a large number of VPN sites. - The draft currently states that PEs should use exponential backoff. Future versions of the discovery draft could reference the new AAA draft described by Bernard that will provide details of exponential backoff behaviour in RADIUS. 6. Use of interim accounting. - Agreed to replace interim accounting with re-authentication in the next version of the draft. The use of re-authorisation (as described in draft-chiba) for this purpose could also be investigated as work progresses. There seems to be rough consensus from the few people that have offered an opinion, that using RADIUS as a discovery protocol is a viable solution, as Bernard says "Overall, I think that the draft has value and its purpose is within the precedent established in RFC 2867-2868. Given that RADIUS already supports configuration of VPNs and VLANs, it is not much of a stretch to see it being used for PPVPN configuration." Thanks, Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 08:44:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10215 for ; Tue, 27 May 2003 08:44:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RCi3f10805 for ; Tue, 27 May 2003 08:44:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RCi0n16073 for ; Tue, 27 May 2003 08:44:00 -0400 (EDT) X-Original-Recipient: ppvpn@nortelnetworks.com 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 X-SMTP-HELO: mailg.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailg.telia.com [194.22.194.26] X-LYRIS-Message-Id: 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 bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 09:31:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11114 for ; Tue, 27 May 2003 09:31:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RDUlf05899 for ; Tue, 27 May 2003 09:30:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RDUjL05762 for ; Tue, 27 May 2003 09:30:45 -0400 (EDT) Message-ID: <20030527132850.99936.qmail@web9504.mail.yahoo.com> Date: Tue, 27 May 2003 06:28:50 -0700 (PDT) From: Mpls Routing Subject: Query regarding BGP on CE-PE link. To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web9504.mail.yahoo.com X-SMTP-MAIL-FROM: mpls_programmer@yahoo.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web9504.mail.yahoo.com [216.136.129.134] X-LYRIS-Message-Id: Hi All, I would like to get a point clarified. How many BGP sessions are active between the CE and PE router, if I use only one interface (physical) between CE-PE but three sub-interfaces (using VLAN ID). TIA and best regards, Riz. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 09:38:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11260 for ; Tue, 27 May 2003 09:38:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RDcLf10845 for ; Tue, 27 May 2003 09:38:22 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RDcIL13509 for ; Tue, 27 May 2003 09:38:19 -0400 (EDT) Date: Tue, 27 May 2003 06:12:53 -0700 (PDT) From: Bernard Aboba To: Juha Heinanen cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: <16077.49504.628040.94146@harjus.eng.song.fi> Message-ID: References: <16077.49504.628040.94146@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > neither is this application requiring any dynamic changes to user > sessions as covered by draft-chiba-radius-dynamic-authorization-20.txt. > in particular, the pe discovery application described in my draft does > not require or need the radius server to send any unsolicited messages > for any purpose to the pes. My question is how dynamic changes to user sessions are being handled. The draft states that: In addition to the above manually configured information, Radius keeps dynamically track of the PEs of the VPN as described below (Protocol Operation)." Typically, once the attributes described in RFC 2868 are sent, the RADIUS server does not monitor the resulting tunnels. So I'm not clear exactly what the RADIUS server is expected to do to "dynamically track". I'm also still unclear about whether the CEs also use RADIUS. For example, the draft states "It is envisioned that a similar Radius based mechanism can be used by CEs of a CE-based VPN to discover the other CEs of the VPN." The problem is that RADIUS is not a protocol in which users (CEs) participate directly to discover other users. With respect to the following paragraph: " When a CE is to be connected to a VPN at a PE, the PE issues a Radius Access-Request using the user name and password of the CE. The PE has either learned this information from the CE via an authentication protocol, for example, 802.1x/EAP, or it has been configured in the PE." RADIUS either assumes that the user (CE) performs authentication, or that a Service-Type="Call Check" is being performed where the user (CE) is authorized based on attributes such as Called-Station-Id and Calling-Station-Id (e.g. telephone number or MAC address identification). Is the "configured in the PE" case equivalent to a Call Check, and if so, how is the CE identified? In the following paragraph: If a PE wants for some reason to get from Radius an up-to-date list of PEs in a particular VPN, it can at any time issue a new Access- Request for any one of its CEs that belongs to the VPN. This seems like it is describing a re-authorization request. Is the intent for the CE to re-authenticate as part of this Access-Request? In terms of the attributes necessary to implement this draft, I'd suggest reuse of the RFC 2868 Tunnel Attributes, if possible. Of the top of my head, I'd recommend the following: a. Definition of new Tunnel-Type values as appropriate. b. Reuse of existing Tunnel-Medium-Type values. c. Transmission of the VPNID in the Tunnel-Private-Group-Id Attribute. The question with RFC 2868 attributes is if they can be extended to allow for multiple tunnels to be set up. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 09:59:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11786 for ; Tue, 27 May 2003 09:59:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RDwYf18088 for ; Tue, 27 May 2003 09:58:36 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RDwV329732 for ; Tue, 27 May 2003 09:58:32 -0400 (EDT) Message-Id: <200305271355.h4RDtbu13686@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: Your message of "Tue, 13 May 2003 10:40:37 PDT." <79165100742.20030513104037@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50738.1054043737.1@juniper.net> Date: Tue, 27 May 2003 06:55:37 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > Monday, May 12, 2003, 7:52:48 AM, Yakov Rekhter wrote: > > If the IESG is so much concerned, then it is the IESG's responsibility > > to substantiate their concerns with *solid* technical arguments > > that are of practical significance, and not just say that "the IESG > > is very concerned". So far the IESG clearly failed to do so, as > > what you put in the rest of this message either lacks solid technical > > justification (see Pedro's replies to you) or practical significance, > > or both. > > Clarification: in case I didn't make it clear in my message, those are > _my_ concerns, not a statement from the IESG as a body. Quoting from your original message (May 2): First of all, let me remind you the message Scott and I brought to the WG in Yokohama--the IESG is very concerned about the tendency of using routing protocols (and BGP in particular) as a universal transport mechanism, and a _very_ strong case would need to be made if the WG decided to go with such a proposal. So, in your original message you made it quite clear that these are the *IESG* concerns. Yet now you are saying that these are just *your* concerns. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 10:26:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14051 for ; Tue, 27 May 2003 10:26:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4REQ5f19000 for ; Tue, 27 May 2003 10:26:05 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4REQ2W01516 for ; Tue, 27 May 2003 10:26:02 -0400 (EDT) Message-Id: <200305271423.h4RENGu15093@merlot.juniper.net> To: Alex Zinin cc: PPVPN@nortelnetworks.com Subject: Re: Draft charter for L2VPN In-Reply-To: Your message of "Fri, 23 May 2003 16:24:31 PDT." <1691049611791.20030523162431@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59548.1054045396.1@juniper.net> Date: Tue, 27 May 2003 07:23:16 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Alex, > >> > The effort will produce a small number of approaches that are based > >> > on collections of individual technologies. The goal is to foster > >> > interoperability among implementations of a specific approach. > >> > Standardization of specific approaches will be gauged on (I)SP support. > >> > >> Please state why you believe this should be in the charter and what > >> exactly your proposed text would mean. > > > This should be in the charter for exactly the same reason(s) it is > > in the current PPVPN charter. It means exactly the same as it > > means in the current PPVPN charter. > > Many people on this list (including me) were not intimately involved > in writing of the PPVPN WG charter. Therefore, I believe you should > explain your reasoning (i.e. why you think the text is useful, how, > and what it really means) before we can consider putting this phrase > in the proposed charter. I would suggest that the folks who wrote the PPVPN WG charter (the IESG ADs + the WG chairs) should do this. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 10:37:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14482 for ; Tue, 27 May 2003 10:37:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4REanf24037 for ; Tue, 27 May 2003 10:36:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4REakO08841 for ; Tue, 27 May 2003 10:36:46 -0400 (EDT) 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 X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: 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 bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 10:55:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15409 for ; Tue, 27 May 2003 10:55:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4REswf00283 for ; Tue, 27 May 2003 10:54:58 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4REstV25675 for ; Tue, 27 May 2003 10:54:55 -0400 (EDT) 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="utf-8" Subject: RE: RADIUS Discovery Discussion Summary Date: Tue, 27 May 2003 10:51:07 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C4A6@m-va-bsod03.add0.masergy.com> Thread-Topic: RADIUS Discovery Discussion Summary thread-index: AcMkM/fEjyiZTcUyQFyAKWzvE+uvXgAKZ7ds From: "Rick Wilder" To: Cc: , , X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA15409 Richard, I agree that the changes described below will strengthen the document. Modulo any adjustments from the latest round of comments, I think a new version with these changes should be reviewed for WG status. Rick -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: Tue 5/27/2003 5:38 AM To: Rick Wilder Cc: jh@lohi.eng.song.fi; aboba@internaut.com; PPVPN@nortelnetworks.com Subject: RADIUS Discovery Discussion Summary Rick Where do we stand with things regarding the RADIUS discovery draft (draft-heinanen-radius-pe-discovery) becoming a WG document? A number of issues have been raised by Bernard and have been resolved either through further explanation from Juha, or through agreed amendments to the next version of the draft. I believe a summary of the issues resolved to date is as follows: 1. Section 2 attempts to update RFC 2486. - This was fixed in version 4, the terms conflicting RFC2486 are gone. 2. Use of RADIUS for service discovery is a bad idea. - Agreed that the draft does not use service discovery and that the use of RADIUS for discovering VPN endpoints is OK. 3. Requires that RADIUS servers be stateful. - Agreed to add a statement to this effect in the next version of the draft. 4. Include potential mitigating measures in the Security Considerations section. - Security considerations such as those in RFC2868 and draft-aboba-radius-rfc2869bis-22.txt could be incorporated or referenced in the next version of the draft. 5. Exponential backoff is required to support a large number of VPN sites. - The draft currently states that PEs should use exponential backoff. Future versions of the discovery draft could reference the new AAA draft described by Bernard that will provide details of exponential backoff behaviour in RADIUS. 6. Use of interim accounting. - Agreed to replace interim accounting with re-authentication in the next version of the draft. The use of re-authorisation (as described in draft-chiba) for this purpose could also be investigated as work progresses. There seems to be rough consensus from the few people that have offered an opinion, that using RADIUS as a discovery protocol is a viable solution, as Bernard says "Overall, I think that the draft has value and its purpose is within the precedent established in RFC 2867-2868. Given that RADIUS already supports configuration of VPNs and VLANs, it is not much of a stretch to see it being used for PPVPN configuration." Thanks, Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 11:11:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16153 for ; Tue, 27 May 2003 11:11:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RFATf26158 for ; Tue, 27 May 2003 11:10:30 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RFAQh16235 for ; Tue, 27 May 2003 11:10:26 -0400 (EDT) Message-ID: <710197BD5AF9D4119E4400508BCFA136053E9318@zcard04u.ca.nortel.com> From: "Dinesh Mohan" To: "'Rick Wilder'" , Loa Andersson Cc: PPVPN@nortelnetworks.com, "Vasile Radoaca" Subject: RE: decisions on L2 solutions documents Date: Tue, 27 May 2003 11:08:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32460.CCD945FC" X-LYRIS-Message-Id: 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_01C32460.CCD945FC Content-Type: text/plain; charset="iso-8859-1" Rick, Loa, Based on the following comments, are there still any other issues that should be considered in the next version which then could be considered for WG status? Dinesh -----Original Message----- From: Radoaca, Vasile [BL60:X624:EXCH] Sent: Tuesday, May 20, 2003 7:22 PM To: 'Rick Wilder'; Loa Andersson Cc: PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Rick, Loa Below are my answers to your questions. Vasile -----Original Message----- From: Rick Wilder [ mailto:rwilder@masergy.com ] Sent: Thursday, May 15, 2003 6:34 PM To: Loa Andersson; Ould-Brahim, Hamid [CAR:1A00:EXCH] Cc: PPVPN@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Agreed, Loa. Here are the questions/requests-for-clarification that came up. a) how do the discovery and signaling parts of the document relate to those described in the other solutions documents and which of them are suggested to be mandatory to implement > vasile There are couple of assumptions that need to be taken in consideration: 1) The GVPLS model, as a distributed model, needs to have a signaling mechanism that allows PW to be identified by VPN-ID, and the End Points together. The pwe3-control-protocol-02.txt draft, with Rosen's extensions to the PW Signaling mechanism address this problem. 2) The GVPLS model is defined as an extension of the VPLS model, as HVPLS is defined as an extension of it in order to optimize some of the parameters (e.g. VC-Label) There are two ways to mitigate these two elements: a) the lasserre-vkompella-vpls draft includes the Rosen's signaling model, but it used only for non-distributed model. In this case, GVPLS would be built using Rosen's mechanism b) extends the current vpls signaling mechanism to include the components needed for the distributed model We had intensive discussions between the authors of vpls, gvpls and rosen's proposals to achieve a reasonable compromise. Unfortunately, at this point in time, the authors of the lasserre-vkompella draft didn't consider to include Rosen's signaling mechanism. As such, based on assumption 2) we decided for GVPLS to extend the current vpls signaling mechanism. However, the model is transparent to such extensions, should a decision would be taken in favor of Rosen's signaling, then GVPLS solution can accommodate it. Regarding the signaling protocol: the current draft has a default model, the LDP protocol. However, the BGP signaling is presented as an alternative. Our current resolution is the following: LDP is mandatory for GVPLS. The BGP signaling option would be defined in a separate draft. We would try to see how we can accommodate our BGP signaling with draft-kompella-ppvpn-vpls-01 bgp model. Regarding the discovery process: We recognize that an auto-discovery mechanism is needed for 3 VPLS components: - VPLS core [N-PE devices] - VPLS access [U-PE devices] - VPN Members/VPN End Points However, the M2P PW model has a very nice property: the U-PE and VPN Members auto-discovery processes can be combined with LDP signaling protocol. While the M2P is not mandatory, we considered that it is worth to present such property and allow vendors to implement and interop. b) what is the status of the MAC-in-MAC encapsulation work in IEEE? > vasile A distributed model needs to have an access protocol that must comply with the Service address scheme presented in GVPLS. There are two models that can be used: PW (splice PW) or Mac-in-Mac. Mac-in-Mac protocol is not mandatory. However, regarding it's status in IETF, the solution was socialized, and Nortel together with other vendors/SPs are looking to present a solution draft in the next IEEE sessions. From GVPLS perspective, Mac-in-Mac is just an option - it's shows that GVPLS is flexible enough to adopt different access protocols, if the assumptions are respected. Probable the best resolution for GVPLS would be to adopt the splice PW as the default model. Mac-in-Mac model would be explained in a separate draft [ex. informational rfc] until a specific resolution would take place in IEEE. c) for the case where the U-PE network is a completely ethernet switched network, and encapsulation like MAC-in-MAC is used, what part of the architecture belongs to the IETF? > vasile definitively, the architecture of such access networks should belong to IEEE. However, regardless of Mac-in-Mac or PW models, a control protocol should be employed in such access networks - we are considering to submit a GVPLS companion proposal for such control protocol. In addition, such control protocol can be used also for Q-in-Q and HVPLS models c) definition of M2P PWs is outside the scope of this WG and probably should go to PWE3 > vasile we are considering to get the M2P PW topic in the PWE3 agenda. The M2P PW can be used in other contexts than VPLS. The M2P PW is an option that can fit nicely with the multipoint nature of the VPLS service - d) how does the definition of semantics of the PW CW given in the document relate to those defined in the PWE3 WG? > vasile the CW, is optional in both pwe3-ethernet-encap-01.txt and in gvpls drafts. In GVPLS we use the format that was presented in the version mentioned above, where the sequence number was replaced with the SRC-ID indication. In the new GVPLS version we would use the new format presented in the version pwe3-ethernet-encap-02.txt, where there are 16 bits reserved and 16 bits used for the sequence number. The 16 bits reserved "for further extension" would be used in the VPLS context as SRC-ID indication. We understand that such proposal needs to be discussed also in the PWE3 group. However, a PW P2P used in the context of the VPLS can have a mechanism to indicate the SP source address from where it's originating, without breaking the original PW model. In the current solutions there are two ways to indicate the SP Source address: a) using the Control Plane [ex.VC-label ] or using the Data Plane [ex. CW]. In our current experiments by far, the Data Plane model scale and perform better than the Control plane model. IF we use PW P2P with Source indication, in the control plane, then the natural evolution is to combine the LSPs that have the same destination into a M2P PW. Some conclusions: As we understand the questions, I think there are ways to move forward, and to see GVPLS as an extension of the vpls non-distributed model [draft-lasserre-vkomeplla-vpls], and worth to be continued as working document. However, a revised version would be taken in consideration for the next IETF meeting; some components as BGP signaling and MAC-in-MAC would be presented in separate drafts. The interoperability aspects between vpls and gvpls would still be maintained in the draft, if there are not other opinions. Cheers Vasile -----Original Message----- From: Loa Andersson [ mailto:loa@pi.se ] Sent: Thursday, May 15, 2003 4:08 PM To: Hamid Ould-Brahim Cc: Rick Wilder; PPVPN@nortelnetworks.com Subject: Re: decisions on L2 solutions documents Rick, the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the wg support from the mailing list at the time, which I don't know), that the issues the AD / wg chair discussion should be made available to the list/wg. Review results may change how you feel about making things wg doc or not, even if they come form ADs :) Mailing list discussion of those review results may lift or confirm those conserns. /Loa Hamid Ould-Brahim wrote: > Rick, > > > > > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is > not > made a WG document at this time. Several questions have > come up > regarding this document during discussions between > the ADs and WG > chairs. In order to make an informed decision, > these questions will > be posted shortly to begin a discussion. > > > In your opinion as ppvpn chair was there consensus on the mailing list > that this draft should advance to WG doc status? > > Hamid. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se ------_=_NextPart_001_01C32460.CCD945FC Content-Type: text/html; charset="iso-8859-1" RE: decisions on L2 solutions documents
Rick, Loa,
 
Based on the following comments, are there still any other issues that should be considered in the next version which then could be considered for WG status?
 
Dinesh
-----Original Message-----
From: Radoaca, Vasile [BL60:X624:EXCH]
Sent: Tuesday, May 20, 2003 7:22 PM
To: 'Rick Wilder'; Loa Andersson
Cc: PPVPN@nortelnetworks.com
Subject: RE: decisions on L2 solutions documents

Rick, Loa

 Below are my answers to your questions.

Vasile

-----Original Message-----
From: Rick Wilder [mailto:rwilder@masergy.com]
Sent: Thursday, May 15, 2003 6:34 PM
To: Loa Andersson; Ould-Brahim, Hamid [CAR:1A00:EXCH]
Cc: PPVPN@nortelnetworks.com
Subject: RE: decisions on L2 solutions documents



Agreed, Loa.

Here are the questions/requests-for-clarification that came up.

    a) how do the discovery and signaling parts of the document
       relate to those described in the other solutions documents and which
       of them are suggested to be mandatory to implement

> vasile
There are couple of assumptions that need to be taken in consideration:
1)
The GVPLS model, as a distributed model, needs to have a signaling mechanism that allows PW to be identified by VPN-ID, and the End Points together. The pwe3-control-protocol-02.txt draft, with Rosen's extensions to the PW Signaling mechanism address this problem.

2)
The GVPLS model is defined as an extension of the VPLS model, as HVPLS is defined as an extension of it in order to optimize some of the parameters (e.g. VC-Label)

There are two ways to mitigate these two elements:
a) the lasserre-vkompella-vpls draft includes the Rosen's signaling model, but it used only for non-distributed model. In this case, GVPLS would be built using Rosen's mechanism

b) extends the current vpls signaling mechanism to include the components needed for the distributed model

We had intensive discussions between the authors of vpls, gvpls and rosen's proposals to achieve a reasonable compromise. Unfortunately, at this point in time, the authors of the lasserre-vkompella draft didn't consider to include Rosen's signaling mechanism. As such, based on assumption 2) we decided for GVPLS to extend the current vpls signaling mechanism. However, the model is transparent to such extensions, should a decision would be taken in favor of Rosen's signaling, then GVPLS solution can accommodate it.

Regarding the signaling protocol: the current draft has a default model, the LDP protocol. However, the BGP signaling is presented as an alternative. Our current resolution is the following: LDP is mandatory for GVPLS.

                                       
The BGP signaling option would be defined in a separate draft. We would try to see how we can accommodate our BGP signaling with draft-kompella-ppvpn-vpls-01 bgp model.

Regarding the discovery process: We recognize that an auto-discovery mechanism is needed for 3 VPLS components:
- VPLS core [N-PE devices]
- VPLS access [U-PE devices]
- VPN Members/VPN End Points

However, the M2P PW model has a very nice property: the U-PE and VPN Members auto-discovery processes can be combined with LDP signaling protocol. While the M2P is not mandatory, we considered that it is worth to present such property and allow vendors to implement and interop.


    b) what is the status of the MAC-in-MAC encapsulation work in IEEE?

> vasile
A distributed model needs to have an access protocol that must comply with the Service address scheme presented in GVPLS.

There are two models  that can be used: PW (splice PW) or Mac-in-Mac. Mac-in-Mac protocol is not mandatory. However, regarding  it's status in IETF, the solution was socialized, and Nortel together with other vendors/SPs are looking to present  a solution draft in the next IEEE sessions.

From GVPLS perspective, Mac-in-Mac is just an option - it's shows that GVPLS is flexible enough to adopt different access protocols, if the assumptions are respected.

Probable the best resolution for GVPLS would be to adopt the splice PW as the default model. Mac-in-Mac model would be explained in a separate draft [ex. informational rfc] until a specific resolution would take place in IEEE.


    c) for the case where the U-PE network is a completely ethernet
       switched network, and encapsulation like MAC-in-MAC is used,
       what part of the architecture belongs to the IETF?
> vasile
definitively, the architecture of such access networks should belong to IEEE. However, regardless of Mac-in-Mac or PW models, a control protocol should be employed in such access networks - we are considering to submit a GVPLS companion proposal for such control protocol. In addition, such control protocol can be used also for Q-in-Q and HVPLS models


    c) definition of M2P PWs is outside the scope of this WG and
       probably should go to PWE3
> vasile
we are considering to get the M2P PW topic in the PWE3 agenda. The M2P PW can be used in other contexts than VPLS.
The M2P PW is an option that can fit nicely with the multipoint nature of the VPLS service -

    d) how does the definition of semantics of the PW CW given
       in the document relate to those defined in the PWE3 WG?
> vasile
the CW, is optional in both pwe3-ethernet-encap-01.txt and in gvpls drafts. In GVPLS we use the format that was presented in the version mentioned above, where the sequence number was replaced with the SRC-ID indication.

In the new GVPLS version we would use the new format presented in the version pwe3-ethernet-encap-02.txt, where there are 16 bits reserved and 16 bits used for the sequence number. The 16 bits reserved "for further extension" would be used in the VPLS context as SRC-ID indication. We understand that such proposal needs to be discussed also in the PWE3 group.

However, a PW P2P used in the context of the VPLS can have a mechanism to indicate the SP source address from where it's originating, without breaking the original PW model. In the current solutions there are two ways to indicate the SP Source address: a) using the Control Plane [ex.VC-label ] or using the Data Plane [ex. CW]. In our current experiments by far, the Data Plane model scale and perform better than the Control  plane model.

IF we use PW P2P with Source indication, in the control plane, then the natural evolution is to combine the LSPs that have the same destination into a M2P PW.


Some conclusions:
As we understand the questions, I think there are ways to move forward, and to see GVPLS as an extension of the  vpls non-distributed model [draft-lasserre-vkomeplla-vpls], and worth to be continued as working document. However, a revised version would be taken in consideration for the next IETF meeting; some components as BGP signaling and MAC-in-MAC would be presented in separate drafts. The interoperability aspects between vpls and gvpls would still be  maintained in the draft, if there are not other opinions.

Cheers
   Vasile



-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, May 15, 2003 4:08 PM
To: Hamid Ould-Brahim
Cc: Rick Wilder; PPVPN@nortelnetworks.com
Subject: Re: decisions on L2 solutions documents

Rick,

the question from Hamid is what I should call "loaded". The real issue here is (evn if you felt you had the wg support from the mailing list at the time, which I don't know), that the issues the AD / wg chair discussion should be made available to the list/wg.

Review results may change how you feel about making things wg doc or not, even if they come form ADs :)

Mailing list discussion of those review results may lift or confirm those conserns.

/Loa

Hamid Ould-Brahim wrote:
> Rick,
>
>  >
>  > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is  > not
> made a WG document at this time. Several questions have  > come up
> regarding this document during discussions between  > the ADs and WG
> chairs. In order to make an informed decision,  > these questions will
> be posted shortly to begin a discussion.  >
>
> In your opinion as ppvpn chair was there consensus on the mailing list
> that this draft should advance to WG doc status?
>
> Hamid.
>


--
/Loa

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


------_=_NextPart_001_01C32460.CCD945FC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 11:18:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16480 for ; Tue, 27 May 2003 11:18:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RFHxf00890 for ; Tue, 27 May 2003 11:17:59 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RFHv622537 for ; Tue, 27 May 2003 11:17:57 -0400 (EDT) Message-ID: From: richard.spencer@bt.com 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" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: 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 bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 11:24:58 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16686 for ; Tue, 27 May 2003 11:24:57 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RFOSf05202 for ; Tue, 27 May 2003 11:24:28 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RFOP628174 for ; Tue, 27 May 2003 11:24:25 -0400 (EDT) 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" X-LYRIS-Message-Id: 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 bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 11:54:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17932 for ; Tue, 27 May 2003 11:54:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RFrxf12961 for ; Tue, 27 May 2003 11:54:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RFruY16653 for ; Tue, 27 May 2003 11:53:57 -0400 (EDT) Subject: unsubscribe To: ppvpn@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Christophe.Gouleau@Equant.Com Date: Tue, 27 May 2003 17:48:13 +0200 X-MIMETrack: Serialize by Router on LONH01/Equant(Release 5.0.9a |January 7, 2002) at 05/27/2003 04:48:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SMTP-HELO: mx1.sita.int X-SMTP-MAIL-FROM: Christophe.Gouleau@Equant.Com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mx1.sita.int [57.250.224.237] X-LYRIS-Message-Id: UNSUBSCRIBE ppvpn From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 13:08:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19880 for ; Tue, 27 May 2003 13:08:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RH86f00442 for ; Tue, 27 May 2003 13:08:09 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RH83e19272 for ; Tue, 27 May 2003 13:08:03 -0400 (EDT) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16083.39624.280716.200879@lohi.eng.song.fi> Date: Tue, 27 May 2003 20:05:12 +0300 To: Bernard Aboba Cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: <16077.49504.628040.94146@harjus.eng.song.fi> X-Mailer: VM 6.97 under Emacs 20.7.2 X-SMTP-HELO: lohi.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lohi.eng.song.fi [195.10.149.18] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > My question is how dynamic changes to user sessions are being handled. > > The draft states that: > > In addition to the above manually configured information, Radius > keeps dynamically track of the PEs of the VPN as described below > (Protocol Operation)." > > Typically, once the attributes described in RFC 2868 are sent, the RADIUS > server does not monitor the resulting tunnels. So I'm not clear > exactly what the RADIUS server is expected to do to "dynamically track". by keeping dynamically track i mean that radius server keeps state based on access requests and stop accounting requests about which pes currently have members in which vpns. radius server does not and should not know anything about the resuiting tunnels. the procedure on how this keeping track takes place has been defined in the draft. > I'm also still unclear about whether the CEs also use RADIUS. in the protocol described in the draft the ces have nothing to do with radius. > For example, the draft states "It is envisioned that a similar Radius > based mechanism can be used by CEs of a CE-based VPN to discover the other > CEs of the VPN." that is a referral to a possible other schenario which is not covered nor is within the scope of the draft. i agree that it is confusing and will remove the sentence from the next version. > With respect to the following paragraph: > > " When a CE is to be connected to a VPN at a PE, the PE issues a Radius > Access-Request using the user name and password of the CE. The PE > has either learned this information from the CE via an authentication > protocol, for example, 802.1x/EAP, or it has been configured in the > PE." > > RADIUS either assumes that the user (CE) performs authentication, or > that a Service-Type="Call Check" is being performed where the user (CE) is > authorized based on attributes such as Called-Station-Id and > Calling-Station-Id (e.g. telephone number or MAC address identification). > Is the "configured in the PE" case equivalent to a Call Check, and if so, > how is the CE identified? no, it is not equivalent to call check. the pe simply performs the authentication of the ce on behalf of the ce if the ce itself doesn't support an authentication protocol like 802.1x, i.e., the username and password are in that case configured in the pe instead of the ce. > In the following paragraph: > > If a PE wants for some reason to get from Radius an up-to-date list > of PEs in a particular VPN, it can at any time issue a new Access- > Request for any one of its CEs that belongs to the VPN. > > This seems like it is describing a re-authorization request. Is the intent > for the CE to re-authenticate as part of this Access-Request? yes. > In terms of the attributes necessary to implement this draft, I'd suggest > reuse of the RFC 2868 Tunnel Attributes, if possible. Of the top of my > head, I'd recommend the following: > > a. Definition of new Tunnel-Type values as appropriate. > b. Reuse of existing Tunnel-Medium-Type values. > c. Transmission of the VPNID in the Tunnel-Private-Group-Id Attribute. > > The question with RFC 2868 attributes is if they can be extended to > allow for multiple tunnels to be set up. the pe needs from radius a list of ip addresses of other pes. if there is an existing attribute that can return that, it is fine with me to use it. i have been oin vacation a few days and will issue a new version of the draft during the coming weekend. i do not claim that the new draft would be ready to be published as an rfc but it should be ready enough to be published as working groupo document. then detailed work on it can beging. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 13:11:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20024 for ; Tue, 27 May 2003 13:11:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RHACf03422 for ; Tue, 27 May 2003 13:10:22 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RHA8e22692 for ; Tue, 27 May 2003 13:10:09 -0400 (EDT) Date: Tue, 27 May 2003 09:42:52 -0700 (PDT) From: Bernard Aboba To: Juha Heinanen cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: Message-ID: References: <16077.49504.628040.94146@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > If a PE wants for some reason to get from Radius an up-to-date list > of PEs in a particular VPN, it can at any time issue a new Access- > Request for any one of its CEs that belongs to the VPN. > > This seems like it is describing a re-authorization request. Is the intent > for the CE to re-authenticate as part of this Access-Request? I should also mention that RADIUS clients do not initiate re-authentication or re-authorization requests "at any time". They only do so under direction of the server. For example, re-authentication can occur after expiry of the time indicated in Session-Time, assuming that Termination-Action=1 (RADIUS). Alternatively, a server-initiated message (CoA-Request) can result in the RADIUS client (PE) sending an Access-Request. So I'm curious as to whether these existing mechanisms can be reused or whether something different is needed. > In terms of the attributes necessary to implement this draft, I'd suggest > reuse of the RFC 2868 Tunnel Attributes, if possible. There is an RFC 2868bis effort underway, so it might make sense to contact the authors and see if the needs described in the draft can be met: http://www.watersprings.org/pub/id/draft-zorn-rfc2868bis-01.txt For example, Section 5 of this draft says: "If the RADIUS server returns attributes describing multiple tunnels then the tunnels SHOULD be interpreted by the tunnel initiator as alternatives and the server SHOULD include an instance of the Tunnel- Preference Attribute in the set of Attributes pertaining to each alternative tunnel. Similarly, if the RADIUS client includes multiple sets of tunnel Attributes in an Access-Request packet, all the Attributes pertaining to a given tunnel SHOULD contain the same value in their respective Tag fields and each set SHOULD include an appropriately valued instance of the Tunnel-Preference Attribute." So one question in my mind is under what conditions multiple tunnels will not be interpreted by the tunnel initiator as alternatives, but rather as distinct VPNs, which is what you want. > Off the top of my > head, I'd recommend the following: > > a. Definition of new Tunnel-Type values as appropriate. > b. Reuse of existing Tunnel-Medium-Type values. > c. Transmission of the VPNID in the Tunnel-Private-Group-Id Attribute. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 13:14:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20091 for ; Tue, 27 May 2003 13:14:13 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RHDhf07440 for ; Tue, 27 May 2003 13:13:43 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RHDee27162 for ; Tue, 27 May 2003 13:13:41 -0400 (EDT) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16083.40014.127171.479776@lohi.eng.song.fi> Date: Tue, 27 May 2003 20:11:42 +0300 To: Bernard Aboba Cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: <16077.49504.628040.94146@harjus.eng.song.fi> X-Mailer: VM 6.97 under Emacs 20.7.2 X-SMTP-HELO: lohi.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lohi.eng.song.fi [195.10.149.18] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > I should also mention that RADIUS clients do not initiate > re-authentication or re-authorization requests "at any time". They only do > so under direction of the server. For example, re-authentication can > occur after expiry of the time indicated in Session-Time, assuming that > Termination-Action=1 (RADIUS). Alternatively, a server-initiated message > (CoA-Request) can result in the RADIUS client (PE) sending an > Access-Request. So I'm curious as to whether these existing mechanisms > can be reused or whether something different is needed. the intention is to use these existing mechanisms. next version of the draft will include session-time/termination-action stuff. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 13:30:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20661 for ; Tue, 27 May 2003 13:30:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RHUCf13429 for ; Tue, 27 May 2003 13:30:12 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RHU7h10008 for ; Tue, 27 May 2003 13:30:08 -0400 (EDT) Date: Tue, 27 May 2003 10:05:41 -0700 (PDT) From: Bernard Aboba To: Juha Heinanen cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: <16083.39624.280716.200879@lohi.eng.song.fi> Message-ID: References: <16077.49504.628040.94146@harjus.eng.song.fi> <16083.39624.280716.200879@lohi.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > no, it is not equivalent to call check. the pe simply performs the > authentication of the ce on behalf of the ce if the ce itself doesn't > support an authentication protocol like 802.1x, i.e., the username and > password are in that case configured in the pe instead of the ce. Having the PE fabricate a User-Name and Password exchange where in fact no such exchange is occurring is not a good idea. Clearly the PE must be identifying the CE in some manner so that it is confident it is the correct CE, no? Since there is no username and password exchange, is there is some means for identifying the CE (a MAC address? a port number?) Otherwise you really have no idea who the CE is, or even who should be billed for the service. The Call-Check Service is designed for these kind of situations, where the CE is identified in some way (e.g. by MAC address) but no authentication is done. > > This seems like it is describing a re-authorization request. Is the intent > > for the CE to re-authenticate as part of this Access-Request? > > yes. OK. You might go ahead and say that explicitly. > the pe needs from radius a list of ip addresses of other pes. if there > is an existing attribute that can return that, it is fine with me to use > it. Yes, there is. There is Tunnel-Client-Endpoint and Tunnel-Server Endpoint. If used with a Tunnel-Medium-Type of 1 (IPv4) or 2 (IPv6) these Attributes can contain IP addresses. Have a look at RFC 2868. > i have been oin vacation a few days and will issue a new version of the > draft during the coming weekend. i do not claim that the new draft > would be ready to be published as an rfc but it should be ready enough > to be published as working groupo document. then detailed work on it > can begin. You might also want to chat with the authors of RFC 2868bis to see if they can accomodate your need for multiple tunnels. That seems like the major extension that is required to enable what you want to do. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 13:34:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20892 for ; Tue, 27 May 2003 13:34:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RHYIf17392 for ; Tue, 27 May 2003 13:34:18 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RHYEh14531 for ; Tue, 27 May 2003 13:34:15 -0400 (EDT) Message-Id: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> To: ppvpn@nortelnetworks.com Subject: VPLS model for L2VPN Framework document 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, 27 May 2003 13:32:28 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Ali's been trying to help me understand just what Mick and Norm have been objecting to with respect to the VPLS model in the framework. Let's see if I've improved my understanding of the issue. In a pure bridged environment, a set of bridges is connected via a LAN. Each bridge has a single port to a particular LAN. Each LAN can contain a set of VLANs, and a packet on that LAN belongs to a particular VLAN by virtue of carrying a .1Q tag. The LAN can also contain untagged packets, which do not belong to any of the VLANs. A multi-VLAN spanning tree protocol can be run using untagged packets. This protocol will determine, for each VLAN, whether a particular port is blocked FOR THAT VLAN. If we want to allow the PE bridges to be part of a larger bridged network, it would be desirable for this model to be supported by the VPLS framework. This would require: - the PE contains a single bridge entity - that bridge entity contains a single "port" to the emulated LAN - each distinct VLAN on the emulated LAN is replaced by a distinct VPLS instance (an "emulated VLAN") - a further distinct VPLS instance is used to carry the "untagged packets" of the emulated LAN. The VPLS instance used to carry the untagged packets would, from the perspective of discovery and setup, be an independent VPLS instance. It is only the use of this VPLS instance that makes it any different than any other VPLS instance. Let's call this VPLS instance the "control VPLS instance". Then we need to allow a PE bridge to attach, via a single emulated LAN port, to one control VPLS instance and to an arbitrary number of additional VPLS instances. A set of PEs that attach to a common VPLS control instance may be termed an "island". Note that there is no requirement that two PE bridges in the same island support the same set of VPLS instances, nor is there any requirement that a VPLS instance (other than the control instance) stay within an island. The framework model, on the other hand, suggests that a PE may contain multiple bridges, each with a port to a single VPLS instance. This would seem to rule out the possibility of using a single spanning tree for multiple VLANs. To eliminate this problem, we could state that a PE may contain one or more bridges, each of which has a single emulated LAN port. Further, each emulated LAN port may attach to one or more VPLS instances. When a single emulated LAN port attaches to more than one VPLS instance, the VPLS instances may be thought of as "emulated VLANs", and no more than one of the VPLS instances may be used to carry traffic that would be "untagged traffic" if the emulated LAN port were a real LAN port. We could also add the "island" stuff from two paragraphs back. Should we go further, and state that a PE must contain a single bridge with a single emulated port that attaches to all the VPLS instances? The "one bridge" model seems to be required if and only if the PEs are to be part of a larger bridged network. Since this won't always be the case, I'm reluctant to make the "multiple bridges" model illegal unless it can be shown that there are no conceivable advantages to it. Comments? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 13:53:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21673 for ; Tue, 27 May 2003 13:53:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RHr3f24004 for ; Tue, 27 May 2003 13:53:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RHr0M25729 for ; Tue, 27 May 2003 13:53:00 -0400 (EDT) X-Original-Recipient: hbrahim@nortelnetworks.com Message-ID: <3ED3A497.50803@pi.se> Date: Tue, 27 May 2003 19:47:03 +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: "Hamid Ould-Brahim" , PPVPN@nortelnetworks.com Subject: Re: Single vs many solution(s) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: maile.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: maile.telia.com [194.22.190.16] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks, Haid is right charter discussion goes to the l3vpn and l2vpn lists, rest of the ppvpn discussion goes to the ppvpn-list, sorry I misread. /Loa Hamid Ould-Brahim wrote: > > If I am not mistaken, I think the debate on l2vpn mailing list is on > the charter only. > > Hamid. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 14:01:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22025 for ; Tue, 27 May 2003 14:01:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RI0Xf04910 for ; Tue, 27 May 2003 14:00:34 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RI0UT09835 for ; Tue, 27 May 2003 14:00:31 -0400 (EDT) X-Original-Recipient: hbrahim@nortelnetworks.com Message-ID: <3ED3A650.2060001@pi.se> Date: Tue, 27 May 2003 19:54:24 +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: "Hamid Ould-Brahim" CC: ppvpn@nortelnetworks.com Subject: Re: Single vs many solution(s) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailg.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailg.telia.com [194.22.194.26] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hamid, I think that is wishful thinking. I know that there are issues with using bgp (kkompella) from several ADs including at least Alex. Also, being adopted as a wg document is no gurantee that it will go all the way to become an RFC much less a PS. If I read your mail correctly you don't seem to think the is a difference in the problem space they [v,k]kompella address, if this is the case you'll have to make a very convincing argument to me as a wg-chair to send both to IESG requesting that they are reviewed to become PS. I don't see that argument, and I don't even see an attempt to make that argument. Note: I haven't discussed this with Rick or the ADs, so their opionions might differ. /Loa Hamid Ould-Brahim wrote: > Loa, > > > 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. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 14:26:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22845 for ; Tue, 27 May 2003 14:26:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RIPTf04771 for ; Tue, 27 May 2003 14:25:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RIPQv28667 for ; Tue, 27 May 2003 14:25:26 -0400 (EDT) Message-Id: <200305271823.h4RINPu32099@merlot.juniper.net> To: Loa Andersson cc: "Hamid Ould-Brahim" , ppvpn@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: Your message of "Tue, 27 May 2003 19:54:24 +0200." <3ED3A650.2060001@pi.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <49871.1054059805.1@juniper.net> Date: Tue, 27 May 2003 11:23:25 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Loa, > Hamid, > > I think that is wishful thinking. I know that there are issues with > using bgp (kkompella) from several ADs including at least Alex. Just saying that "there are issues" isn't enough - "the several ADs" who have these issues need to document them, and then discuss it in an open forum (WG mailing list) to see whether these "issues" are of any practical significance. Yakov. P.S. So far we've seen Alex raising the issues he has with using BGP, and Pedro addressing them... From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 15:15:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26468 for ; Tue, 27 May 2003 15:15:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RJF6f04393 for ; Tue, 27 May 2003 15:15:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RJF2l22156 for ; Tue, 27 May 2003 15:15:03 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Loa Andersson Cc: ppvpn@nortelnetworks.com Subject: RE: Single vs many solution(s) Date: Tue, 27 May 2003 15:09:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32483.8F45821E" X-LYRIS-Message-Id: 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_01C32483.8F45821E Content-Type: text/plain; charset="iso-8859-1" Loa, > > I think that is wishful thinking. I know that there are issues with > using bgp (kkompella) from several ADs including at least Alex. > > Also, being adopted as a wg document is no gurantee that it will > go all the way to become an RFC much less a PS. > Sure. This is applicable to all wg docs. I indicated that the fact the draft has now a wg doc status I concluded that the chairs and ADs do not see *serious* issues *stopping* the wg to work on the proposal (otherwise they would have requested more debate before making the draft wg doc as was the case for radius proposal)....Am I missing something here? > If I read your mail correctly you don't seem to think the is a > difference in the problem space they [v,k]kompella address, if this > is the case you'll have to make a very convincing argument to me > as a wg-chair to send both to IESG requesting that they are reviewed > to become PS. I don't see that argument, and I don't even see an > attempt to make that argument. > I am not sure what is really expected from this debate. Are you (chairs and/or ADs) concerned that because we are dealing with multiple approaches therefore we should address *now* the final status for the drafts, and to do that we need to either: a) Highlight that these are in fact distinct approaches for distinct problems? or b) These approaches are solving the same problem (aka service) then there are no convincing arguments to send them all to PS? Assume the situation is b). What do you suggest the wg to do? (drop one of the proposal now, etc). Honestly, it will be good to articulate what is the objective of this debate...(given all the arguments presented). Hamid. ------_=_NextPart_001_01C32483.8F45821E Content-Type: text/html; charset="iso-8859-1" RE: Single vs many solution(s)

Loa,

>
> I think that is wishful thinking. I know that there are issues with
> using bgp (kkompella) from several ADs including at least Alex.
>
> Also, being adopted as a wg document is no gurantee that it will
> go all the way to become an RFC much less a PS.
>

Sure. This is applicable to all wg docs. I indicated that the
fact the draft has now a wg doc status I concluded that the chairs
and ADs do not see *serious* issues *stopping* the wg to work on the
proposal (otherwise they would have requested
more debate before making the draft wg doc as was the case
for radius proposal)....Am I missing something here?

> If I read your mail correctly you don't seem to think the is a
> difference in the problem space they [v,k]kompella address, if this
> is the case you'll have to make a very convincing argument to me
> as a wg-chair to send both to IESG requesting that they are reviewed
> to become PS. I don't see that argument, and I don't even see an
> attempt to make that argument.
>

I am not sure what is really expected from this debate.

Are you (chairs and/or ADs) concerned that because we are
dealing with multiple approaches therefore we should address
*now* the final status for the drafts, and to do that we need
to either:

a) Highlight that these are in fact distinct approaches for distinct
   problems? or

b) These approaches are solving the same problem (aka service)
   then there are no convincing arguments to send them all to
   PS?

Assume the situation is b). What do you suggest the wg to do?
(drop one of the proposal now, etc).

Honestly, it will be good to articulate what is the objective
of this debate...(given all the arguments presented).

Hamid.
 

------_=_NextPart_001_01C32483.8F45821E-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 15:25:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27145 for ; Tue, 27 May 2003 15:25:54 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RJPMf08372 for ; Tue, 27 May 2003 15:25:22 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RJPJl28634 for ; Tue, 27 May 2003 15:25:19 -0400 (EDT) X-Original-Recipient: hbrahim@nortelnetworks.com Message-ID: <3ED3BA3C.2040209@pi.se> Date: Tue, 27 May 2003 21:19:24 +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: "Hamid Ould-Brahim" CC: ppvpn@nortelnetworks.com Subject: Re: Single vs many solution(s) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: maild.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: maild.telia.com [194.22.190.101] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hamid, yes - the decision on making docs are made by the wg-chairs based on how we see consensus in the wg group. In this case, we did know there were issues, but wanted that discussion based on wg documents, we know we need at least one solution for the l2vpn space. making docs wg docs is to make them available for wg actions/decissions /Loa Hamid Ould-Brahim wrote: > > Sure. This is applicable to all wg docs. I indicated that the > fact the draft has now a wg doc status I concluded that the chairs > and ADs do not see *serious* issues *stopping* the wg to work on the > proposal (otherwise they would have requested > more debate before making the draft wg doc as was the case > for radius proposal)....Am I missing something here? -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 15:37:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27749 for ; Tue, 27 May 2003 15:37:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RJbLf13722 for ; Tue, 27 May 2003 15:37:22 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RJbIe05450 for ; Tue, 27 May 2003 15:37:19 -0400 (EDT) Date: Tue, 27 May 2003 12:22:28 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <171319249176.20030527122228@psg.com> To: Yakov Rekhter CC: Loa Andersson , "Hamid Ould-Brahim" , Subject: Re: Single vs many solution(s) In-Reply-To: <200305271823.h4RINPu32099@merlot.juniper.net> References: <200305271823.h4RINPu32099@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, >> I think that is wishful thinking. I know that there are issues with >> using bgp (kkompella) from several ADs including at least Alex. > Just saying that "there are issues" isn't enough - "the several > ADs" who have these issues need to document them, and then discuss > it in an open forum (WG mailing list)... Agreed. This indeed needs to happen. > to see whether these "issues" are of any practical significance. > Yakov. > P.S. So far we've seen Alex raising the issues he has with using BGP, > and Pedro addressing them... I wouldn't call that "addressing". We rather have different opinions. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 15:40:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28031 for ; Tue, 27 May 2003 15:40:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RJeGf17696 for ; Tue, 27 May 2003 15:40:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RJeCe10004 for ; Tue, 27 May 2003 15:40:12 -0400 (EDT) Date: Tue, 27 May 2003 12:24:15 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5319356129.20030527122415@psg.com> To: Loa Andersson CC: "Hamid Ould-Brahim" , ppvpn@nortelnetworks.com Subject: Re: Single vs many solution(s) In-Reply-To: <3ED3A650.2060001@pi.se> References: <3ED3A650.2060001@pi.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Loa, I think we are in agreement. -- Alex Tuesday, May 27, 2003, 10:54:24 AM, Loa Andersson wrote: > Hamid, > I think that is wishful thinking. I know that there are issues with > using bgp (kkompella) from several ADs including at least Alex. > Also, being adopted as a wg document is no gurantee that it will > go all the way to become an RFC much less a PS. > If I read your mail correctly you don't seem to think the is a > difference in the problem space they [v,k]kompella address, if this > is the case you'll have to make a very convincing argument to me > as a wg-chair to send both to IESG requesting that they are reviewed > to become PS. I don't see that argument, and I don't even see an > attempt to make that argument. > Note: I haven't discussed this with Rick or the ADs, so their opionions > might differ. > /Loa From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 16:01:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28908 for ; Tue, 27 May 2003 16:01:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RK0pf02184 for ; Tue, 27 May 2003 16:00:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RK0mn02072 for ; Tue, 27 May 2003 16:00:48 -0400 (EDT) Date: Tue, 27 May 2003 12:45:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <62320639064.20030527124538@psg.com> To: Yakov Rekhter CC: PPVPN@nortelnetworks.com Subject: Re: On BGP and VPLS In-Reply-To: <200305271355.h4RDtbu13686@merlot.juniper.net> References: <200305271355.h4RDtbu13686@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov- Tuesday, May 27, 2003, 6:55:37 AM, Yakov Rekhter wrote: ... > So, in your original message you made it quite clear that these are > the *IESG* concerns. Yet now you are saying that these are just > *your* concerns. Friday, May 2, 2003, 7:14:39 PM, Alex Zinin wrote: > First of all, let me remind you the message Scott and I brought to > the WG in Yokohama--the IESG is very concerned about the tendency of > using routing protocols (and BGP in particular) as a universal > transport mechanism, and a _very_ strong case would need to be made > if the WG decided to go with such a proposal. > > More specifically, below I tried to put together a list of concerns > I have about the approach described in draft-kompella-ppvpn-vpls, ^^^^^^ > that I would like the WG to consider. > > 1. Use of the NLRI field Hope this is clear now. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 17:10:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02702 for ; Tue, 27 May 2003 17:10:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4RL9rf12443 for ; Tue, 27 May 2003 17:09:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4RL9og08080 for ; Tue, 27 May 2003 17:09:50 -0400 (EDT) X-Original-Recipient: hbrahim@nortelnetworks.com Message-ID: <3ED3D2AE.4070306@pi.se> Date: Tue, 27 May 2003 23:03:42 +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: Yakov Rekhter , iesg@ietf.org, The IESG CC: "Hamid Ould-Brahim" , ppvpn@nortelnetworks.com Subject: Re: Single vs many solution(s) References: <200305271823.h4RINPu32099@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailc.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailc.telia.com [194.22.190.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, I don't have the power to require that IESG do or don't do anything. What I can do is to send a specification to the IESG asking them to review it and publish as an RFC, that is what any wg chair can do. But I can send an humble request ;) IESG, the ppvpn wg group has an ID describing a solution for the L2VPN space based on MP-BGP as a signaling protocol, and also an ID describing a VPN membership discovery mechanism based on BGP. We have been informed by our ADs that IESG have concerns relating to the use of BGP in this context. To simplify the future work in the wg it would be useful to have those concerns documented. /Loa PS Is this "enough"? Yakov Rekhter wrote: > Loa, > > >>Hamid, >> >>I think that is wishful thinking. I know that there are issues with >>using bgp (kkompella) from several ADs including at least Alex. > > > Just saying that "there are issues" isn't enough - "the several > ADs" who have these issues need to document them, and then discuss > it in an open forum (WG mailing list) to see whether these "issues" > are of any practical significance. > > Yakov. > > P.S. So far we've seen Alex raising the issues he has with using BGP, > and Pedro addressing them... > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue May 27 20:26:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11185 for ; Tue, 27 May 2003 20:26:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S0Pcf24187 for ; Tue, 27 May 2003 20:25:39 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S0PZD23315 for ; Tue, 27 May 2003 20:25:36 -0400 (EDT) Date: Tue, 27 May 2003 20:23:50 -0400 (EDT) From: schultz@io.iol.unh.edu To: Matt Squire cc: Alex Zinin , ppvpn@nortelnetworks.com Subject: RE: Draft charter for L2VPN: Perfect LAN emulation In-Reply-To: <8052E2EA753D144EB906B7A7AA399714E5F756@mailserv.hatteras.com> Message-ID: References: <8052E2EA753D144EB906B7A7AA399714E5F756@mailserv.hatteras.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: io.iol.unh.edu X-SMTP-MAIL-FROM: schultz@io.iol.unh.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: io.iol.unh.edu [132.177.123.82] X-LYRIS-Message-Id: Hello, I agree with Matt. I would say "IEEE 802.1 bridging" instead of saying "802.1D bridging" so it can encompass Q, s, w, etc. Thanks, -Ben --------------------- > What I think is important, and what I think we need to have in the > charter, is transparency. Standard Ethernet devices and existing > protocols must be able to operate over a L2VPN without alteration. My > suggested wording on the issue was (from previous email) was: > > "The WG will drive for solutions that are transparent to higher layer > protocols such as 802.1D bridging and IP. Optimizations to a basic > transparent architecture may be developed to foster more efficient > transport in special cases (such as IP only transport). " > > That's transparency. Perfect emulation wasn't on my radar. > > - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 00:45:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20339 for ; Wed, 28 May 2003 00:45:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S4id821715 for ; Wed, 28 May 2003 00:44:39 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S4iaS05656 for ; Wed, 28 May 2003 00:44:37 -0400 (EDT) Message-Id: <200305280442.h4S4goV14182@zrtps06u.us.nortel.com> From: DR MIKE FAVOUR To: ppvpn@lyris.nortelnetworks.com Reply-To: mikefavour9@ecplaza.net Subject: MY SINCERE REQUEST Date: Tue, 27 May 2003 05:29:11 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1ac8c2c6-f178-4f65-9fea-f3de8331b4ee" X-SMTP-HELO: 25.29.03.27 X-SMTP-MAIL-FROM: mikefavour9@ecplaza.ne X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.110.8.7] X-LYRIS-Message-Id: This is a multi-part message in MIME format --1ac8c2c6-f178-4f65-9fea-f3de8331b4ee Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable BRANCH MANAGER, UNITED BANK FOR AFRICA PLC ILUPEJU BRANCH LAGOS NIGERIA ATTN: PRESIDENT/C.E.O I am pleased to get across to you for a very urgent and profitable business proposal, though I don't know you neither have I seen you before but my confidence was reposed on you when the Chief Executive of Lagos State chamber of Commerce and Industry handed me your contact for a confidential business. I am the manager of United Bank for Africa Plc (UBA), Ilupeju branch, Lagos Nigeria. The intended business is thus; We had a customer, a Foreigner (a Turkish) resident in Nigeria, he was a Contractor with one of the Government Parastatals.He has in his Account in my branch the sum of US 38.6 Million (Thirty Eight Million, Six Hundred Thousand U.S. Dollars). Unfortunately, the man died four years ago until today non-of his next of kin has come forward to claim the money. Having noticed this, I in collaboration with two other top Officials of the bank have covered up the account all this while. Now we want you (being a foreigner) to be fronted as one of his next of kin and forward your account and other relevant documents to be advised to you by us to attest to the Claim. We will use our positions to get all internal documentations to back up the claims .The whole procedures will last only five working days to get the fund retrieved successfully without trace even now or in future. Your response is only what we are waiting for as we have arranged all necessary things. As soon as this message comes to you kindly get back to me indicating your interest, then I will furnish you with the whole procedures to ensure that the deal is successfully concluded. For your assistance we have agreed to give you twenty five percent (25%) of the Total sum at the end of the transaction while 65% would be for my colleagues and I and the remaining 10% would be for any form of expenses that may be incurred during the course of the transaction which would be given to us when the money is transferred into your account before splitting the balance on the agreed percentage of 65% to 25%. In order to get all the legal documents from the court, kindly send the following information to us immediately. Your full name,telephone,mobile and fax numbers as well as your resident or company address. I await your earliest response. Thanks, Yours Sincerely DR MIKE FAVOUR --1ac8c2c6-f178-4f65-9fea-f3de8331b4ee-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 02:03:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26069 for ; Wed, 28 May 2003 02:03:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S635811433 for ; Wed, 28 May 2003 02:03:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S633Y14547 for ; Wed, 28 May 2003 02:03:03 -0400 (EDT) Message-ID: From: Edmund Kueh / ICN Malaysia To: ppvpn@nortelnetworks.com Subject: unsubscribe Date: Wed, 28 May 2003 14:02:30 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: pljy103a.siemens.com.my X-SMTP-MAIL-FROM: Edmund.Kueh@siemens.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [203.121.32.11] X-LYRIS-Message-Id: UNSUBSCRIBE ppvpn Greetings Edx ##################################################################################### Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. SIEMENS MALAYSIA SDN BHD and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. ##################################################################################### From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 03:02:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19250 for ; Wed, 28 May 2003 03:02:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S71b821220 for ; Wed, 28 May 2003 03:01:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S71Yf13819 for ; Wed, 28 May 2003 03:01:34 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: aboba@internaut.com, jh@lohi.eng.song.fi Cc: ppvpn@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Wed, 28 May 2003 07:59:26 +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" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Bernard > RADIUS either assumes that the user (CE) performs authentication, or > that a Service-Type="Call Check" is being performed where > the user (CE) is > authorized based on attributes such as Called-Station-Id and > Calling-Station-Id (e.g. telephone number or MAC address > identification). > Is the "configured in the PE" case equivalent to a Call > Check, and if so, > how is the CE identified? RS> Although I think it is useful feature, I think it should be left up to the service provider to decide whether CE authentication should be carried out by RADIUS or not. For example, the RADIUS discovery protocol might be used across an RFC2547 VPN network, and a particular CE-PE link might be running OSPF with MD5, in which case the service provider may not feel it necessary to carry out any further authentication. The PPVPN WG has not defined a requirement that the actual discovery protocol itself MUST authenticate CEs, although it is obviously an attractive option. > In terms of the attributes necessary to implement this > draft, I'd suggest > reuse of the RFC 2868 Tunnel Attributes, if possible. Of > the top of my > head, I'd recommend the following: > > a. Definition of new Tunnel-Type values as appropriate. > b. Reuse of existing Tunnel-Medium-Type values. > c. Transmission of the VPNID in the Tunnel-Private-Group-Id > Attribute. RS> There is a difference between attributes that should be signalled using a signalling mechanism, and attributes that should be discovered using a discovery mechanism. The PPVPN group is yet to agree on exactly which attributes should be signalled and which should be discovered. However, the PPVPN WG has not identified the need to use the discovery mechanism to identify the tunnel type or the PSN type, and therefore none of the discovery mechanisms defined to date include these attributes in the discovery process. In my opinion the discovery mechanism should discover the minimum amount of information required to allow signalling to take place, i.e. a list of PE IP addresses belonging to the same VPN. Re-using some of the attributes from RFC2868 such as Tunnel-Client-Endpoint and Tunnel-Assignment-ID (which looks more appropriate than the Tunnel-Private-Group-Id you suggested as multiple tunnels may exists between endpoints) is probably a good idea. However, I don't think one should expect to be able to make some changes to RFC2868 and use that instead of Juha's draft. RFC2868 describes attributes for setting up different types of tunnels across different PSNs, Juha's draft is intended to be a simple mechanism for discovering VPN endpoints only. Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 03:05:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19369 for ; Wed, 28 May 2003 03:05:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S74w824815 for ; Wed, 28 May 2003 03:04:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S74tf18289 for ; Wed, 28 May 2003 03:04:56 -0400 (EDT) Subject: unsubscribe To: ppvpn@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Lakshmi Thampi" Date: Wed, 28 May 2003 12:33:02 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 05/28/2003 12:33:03 PM, Itemize by SMTP Server on POWAISMTP/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 05/28/2003 12:38:24 PM, Serialize by Router on POWAISMTP/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 05/28/2003 12:38:50 PM, Serialize complete at 05/28/2003 12:38:50 PM Content-type: text/plain; charset=us-ascii X-SMTP-HELO: powaismtp.lntinfotech.com X-SMTP-MAIL-FROM: Lakshmi.Thampi@lntinfotech.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [203.199.54.36] X-LYRIS-Message-Id: UNSUBSCRIBE ppvpn From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 03:34:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19753 for ; Wed, 28 May 2003 03:34:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S7Y4829157 for ; Wed, 28 May 2003 03:34:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S7Y1H03751 for ; Wed, 28 May 2003 03:34:01 -0400 (EDT) Date: Wed, 28 May 2003 00:31:56 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <102363016730.20030528003156@psg.com> To: Loa Andersson CC: Yakov Rekhter , iesg@ietf.org, The IESG , "Hamid Ould-Brahim" , Subject: Re: Single vs many solution(s) In-Reply-To: <3ED3D2AE.4070306@pi.se> References: <200305271823.h4RINPu32099@merlot.juniper.net> <3ED3D2AE.4070306@pi.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Loa, I think it is indeed the right thing to ask the IESG to come up with clear formulation of the concerns. Consider me the token holder. Thanks. -- Alex http://www.psg.com/~zinin/ Tuesday, May 27, 2003, 2:03:42 PM, Loa Andersson wrote: > Yakov, > I don't have the power to require that IESG do or don't do anything. > What I can do is to send a specification to the IESG asking them to > review it and publish as an RFC, that is what any wg chair can do. > But I can send an humble request ;) > IESG, > the ppvpn wg group has an ID describing a solution for the L2VPN space > based > on MP-BGP as a signaling protocol, and also an ID describing a VPN > membership > discovery mechanism based on BGP. > We have been informed by our ADs that IESG have concerns relating to the > use of > BGP in this context. To simplify the future work in the wg it would be > useful to have those concerns documented. > /Loa > PS > Is this "enough"? > Yakov Rekhter wrote: >> Loa, >> >> >>>Hamid, >>> >>>I think that is wishful thinking. I know that there are issues with >>>using bgp (kkompella) from several ADs including at least Alex. >> >> >> Just saying that "there are issues" isn't enough - "the several >> ADs" who have these issues need to document them, and then discuss >> it in an open forum (WG mailing list) to see whether these "issues" >> are of any practical significance. >> >> Yakov. >> >> P.S. So far we've seen Alex raising the issues he has with using BGP, >> and Pedro addressing them... >> >> >> >> From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 03:37:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19833 for ; Wed, 28 May 2003 03:37:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S7au802723 for ; Wed, 28 May 2003 03:36:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S7aqH08358 for ; Wed, 28 May 2003 03:36:53 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 Subject: unsubscribe Date: Wed, 28 May 2003 09:34:07 +0200 Message-ID: <1FB136FD10CE33409C882630E299F5BEBBEDFD@lanmhs30.rd.francetelecom.fr> Thread-Topic: unsubscribe Thread-Index: AcMkaD94NB+NmpH1RNGMrBC0JebR5wAgyWrg From: "LE NORMENT Philippe DvSI/SIReS/LAN" To: X-OriginalArrivalTime: 28 May 2003 07:34:08.0416 (UTC) FILETIME=[8636D200:01C324EB] X-SMTP-HELO: parsmtp2.rd.francetelecom.com X-SMTP-MAIL-FROM: philippe.lenorment@rd.francetelecom.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: parsmtp2.rd.francetelecom.com [194.167.105.14] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA19833 UNSUBSCRIBE ppvpn From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 05:03:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22526 for ; Wed, 28 May 2003 05:03:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S933827430 for ; Wed, 28 May 2003 05:03:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S930D26205 for ; Wed, 28 May 2003 05:03:01 -0400 (EDT) Message-Id: <200305280900.h4S90Jc15648@zcars1ky.ca.nortel.com> From: "Micheal Sankoh" Reply-To: msankoh@zwallet.com To: ppvpn@nortelnetworks.com Date: Wed, 28 May 2003 09:59:26 +0100 Subject: Re: Please assist X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: afzhg2381.com X-SMTP-MAIL-FROM: m-sankoh@zwallet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [208.164.180.82] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA22526 From: Micheal Sankoh (Junior). Dear, Urgent assistance needed:- With absolute trust in God and due respect to you, I write you this letter which I believe you would be of great assistance to me and would keep the information confidential and private. I am Micheal Sankoh, a son to Foday sankoh, the rebel leader in Sierra Leone warring factions, I am absolutely against the unending political crises in my country that has resulted to massive destruction of human lives and property which is currently in the world news. On this last assault by the forces. I escaped to cotonou Benin Republic through the help of united nations soldiers who are there on a peace mission. On arrival in Cotonou, I went directly to the assylum camp, to seek for political assylum, I was accepted, before the war my father deposited the total sum $15.5 million usd in a reputable security company in Cotonou, as family valuables. take note that the funds were deposited as family valuables for safe keeping in my name. I am looking for a reliable and trust worthy partner from a different country rather than Benin Republic who will assist me in the management and investment of this funds in a viable and profitable business ventures . take note that the laws of Benin Republic prohibit a refugee (assylum seeker) to open account or to be involved in any financial transaction whatsoever, the benin foreign exchange policy does not allow such investment from asylum seekers.i am faced with the problem of investing this amount of money in benin for the fear of going through the same experience like my father in future since both countries have similar history. I humbly solicit for your assistance in the following: 1) Pay a short working day visit to Cotonou, Benin Republic so that we see face to face, have a table talk that would create confidence in me that the fund would be safe in your hands and have an agreement from a advocate, which will be duly and legally sign in his chambers before taken any step in this transaction. 2) Get all the necessary document regarding this transaction and claim the boxes from the security company, open an account in your name with a local bank here and deposit the money for onward transfer to your designated accounts overseas. 3) Make a good arrangement for investment and do invest the money for me. I am willing to give you some percentage for your assistance on this, I offer you 15%. 5% would be used to offset every expenses to be incurred and taxes or charges to be paid in the course of this transaction while 80% would be invested and you get your wage monthly for managing the 80%. I assure you that the transaction is risk free and could be completed within the next seven days if you give me your total and absolute cooperation/assistance. Please forward your reply through my private email address: msankoh@zwallet.com and endeavour to furnish me with your comprehensive and confidential telephone numbers for easier and faster communication and remember confidential, trust and absolute cooperation is needed for the smooth and immediate conclusion of this mutual beneficial transaction, since I am still with the Benin government.I will appeciate you can call me +229 074287 for further discussion. Awaiting your prompt response, Thanks and stay blessed. Micheal Sankoh Junior. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 05:04:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22550 for ; Wed, 28 May 2003 05:04:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S93U828057 for ; Wed, 28 May 2003 05:03:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S93QD26921 for ; Wed, 28 May 2003 05:03:27 -0400 (EDT) Reply-To: From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= To: Subject: unsubscribe Date: Wed, 28 May 2003 10:55:12 +0200 Message-ID: <000201c324f6$d9e0a9c0$0201a8c0@windowxp> 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 CWS, Build 9.0.2416 (9.0.2910.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-SMTP-HELO: smtp2.yaonline.es X-SMTP-MAIL-FROM: gibanezfer@jazzfree.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [62.151.11.132] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 05:10:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22653 for ; Wed, 28 May 2003 05:10:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4S9A1801649 for ; Wed, 28 May 2003 05:10:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4S8xvb08366 for ; Wed, 28 May 2003 04:59:57 -0400 (EDT) Reply-To: From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= To: Subject: unsubscribe Date: Wed, 28 May 2003 10:56:13 +0200 Message-ID: <000301c324f6$fe4b7a60$0201a8c0@windowxp> 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 CWS, Build 9.0.2416 (9.0.2910.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-SMTP-HELO: smtp2.yaonline.es X-SMTP-MAIL-FROM: gibanezfer@jazzfree.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [62.151.11.132] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe ppvpn From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 07:48:44 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25952 for ; Wed, 28 May 2003 07:48:43 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SBmB824473 for ; Wed, 28 May 2003 07:48:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4SBm8u02632 for ; Wed, 28 May 2003 07:48:08 -0400 (EDT) Message-Id: <200305281146.HAA25669@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-vpls-bgp-00.txt Date: Wed, 28 May 2003 07:46:10 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Virtual Private LAN Service Author(s) : K. Kompella et al. Filename : draft-ietf-ppvpn-vpls-bgp-00.txt Pages : 17 Date : 2003-5-26 Virtual Private LAN Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offered is a Layer 2 VPN; however, in the case of VPLS, the customers in the VPN are connected by a multipoint network, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, and proposes a mechanism for signaling a VPLS, as well as for forwarding VPLS frames across a packet switched network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-bgp-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-ietf-ppvpn-vpls-bgp-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-ietf-ppvpn-vpls-bgp-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-5-27145409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-vpls-bgp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-vpls-bgp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-27145409.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 08:09:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26723 for ; Wed, 28 May 2003 08:09:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SC92805319 for ; Wed, 28 May 2003 08:09:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4SC8xA05015 for ; Wed, 28 May 2003 08:08:59 -0400 (EDT) Date: Wed, 28 May 2003 04:31:34 -0700 (PDT) From: Bernard Aboba To: richard.spencer@bt.com cc: jh@lohi.eng.song.fi, ppvpn@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > Although I think it is useful feature, I think it should be left up to > the service provider to decide whether CE authentication should be carried > out by RADIUS or not. For example, the RADIUS discovery protocol might be > used across an RFC2547 VPN network, and a particular CE-PE link might be > running OSPF with MD5, in which case the service provider may not feel it > necessary to carry out any further authentication. The PPVPN WG has not > defined a requirement that the actual discovery protocol itself MUST > authenticate CEs, although it is obviously an attractive option. That's fine. A RADIUS "Call Check" assumes that the user is authenticated by another means (e.g. OSPF MD5), so there are no authentication attributes in the Access-Request. But it *does* require that the CE be identified in some way. That typically is via an L2 address, but it could be something else. I'm just asking what uniquely identifies the CE in this case. Given that there is no authentication exchange occurring, it is probably not appropriate for the PE to "forge" an authentication as through the CE really did authenticate when in fact it didn't. Since RADIUS doesn't require authentication (that's what "Call Check" and "Authorize Only" Service-Type values are for) there's no need to forge an authentication just to be compliant with the protocol. > > > In terms of the attributes necessary to implement this > > draft, I'd suggest > > reuse of the RFC 2868 Tunnel Attributes, if possible. Of > > the top of my > > head, I'd recommend the following: > > > > a. Definition of new Tunnel-Type values as appropriate. > > b. Reuse of existing Tunnel-Medium-Type values. > > c. Transmission of the VPNID in the Tunnel-Private-Group-Id > > Attribute. > > There is a difference between attributes that should be signalled using > a signalling mechanism, and attributes that should be discovered using a > discovery mechanism. The PPVPN group is yet to agree on exactly which > attributes should be signalled and which should be discovered. However, the > PPVPN WG has not identified the need to use the discovery mechanism to > identify the tunnel type or the PSN type, and therefore none of the > discovery mechanisms defined to date include these attributes in the > discovery process. In my opinion the discovery mechanism should discover the > minimum amount of information required to allow signalling to take place, > i.e. a list of PE IP addresses belonging to the same VPN. I think that's ok. The Tunnel-Type could just be "PPVPN". > Re-using some of the attributes from RFC2868 such as Tunnel-Client-Endpoint > and Tunnel-Assignment-ID (which looks more appropriate than the > Tunnel-Private-Group-Id you suggested as multiple tunnels may exists between > endpoints) is probably a good idea. Tunnel-Assignment-ID is used to allow multiple connections to be carried over the same tunnel. That is not quite the same thing as having multiple tunnels between two endpoints. > RFC2868 describes attributes for setting up different types of > tunnels across different PSNs, Juha's draft is intended to be a simple > mechanism for discovering VPN endpoints only. I agree that RFC 2868 is a superset of what you're trying to do. I don't think that the document necessarily requires the use of all the capabilities, though. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 08:28:44 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27890 for ; Wed, 28 May 2003 08:28:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SCS3810434 for ; Wed, 28 May 2003 08:28:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4SCS0U14979 for ; Wed, 28 May 2003 08:28:01 -0400 (EDT) Message-ID: <3ED4AADC.1080703@cisco.com> Date: Wed, 28 May 2003 14:26:04 +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: Bernard Aboba CC: richard.spencer@bt.com, jh@lohi.eng.song.fi, ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03. txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>Although I think it is useful feature, I think it should be left up to >>the service provider to decide whether CE authentication should be carried >>out by RADIUS or not. For example, the RADIUS discovery protocol might be >>used across an RFC2547 VPN network, and a particular CE-PE link might be >>running OSPF with MD5, in which case the service provider may not feel it >>necessary to carry out any further authentication. The PPVPN WG has not >>defined a requirement that the actual discovery protocol itself MUST >>authenticate CEs, although it is obviously an attractive option. > > > That's fine. A RADIUS "Call Check" assumes that the user is authenticated > by another means (e.g. OSPF MD5), so there are no authentication > attributes in the Access-Request. But it *does* require that the CE be > identified in some way. That typically is via an L2 address, but it > could be something else. I'm just asking what uniquely identifies the CE > in this case. Given that there is no authentication exchange occurring, > it is probably not appropriate for the PE to "forge" an > authentication as through the CE really did authenticate when > in fact it didn't. Since RADIUS doesn't require authentication (that's > what "Call Check" and "Authorize Only" Service-Type values are for) > there's no need to forge an authentication just to be compliant with the > protocol. > > >> > In terms of the attributes necessary to implement this >> > draft, I'd suggest >> > reuse of the RFC 2868 Tunnel Attributes, if possible. Of >> > the top of my >> > head, I'd recommend the following: >> > >> > a. Definition of new Tunnel-Type values as appropriate. >> > b. Reuse of existing Tunnel-Medium-Type values. >> > c. Transmission of the VPNID in the Tunnel-Private-Group-Id >> > Attribute. >> >>There is a difference between attributes that should be signalled using >>a signalling mechanism, and attributes that should be discovered using a >>discovery mechanism. The PPVPN group is yet to agree on exactly which >>attributes should be signalled and which should be discovered. However, the >>PPVPN WG has not identified the need to use the discovery mechanism to >>identify the tunnel type or the PSN type, and therefore none of the >>discovery mechanisms defined to date include these attributes in the >>discovery process. In my opinion the discovery mechanism should discover the >>minimum amount of information required to allow signalling to take place, >>i.e. a list of PE IP addresses belonging to the same VPN. > > > I think that's ok. The Tunnel-Type could just be "PPVPN". > > >>Re-using some of the attributes from RFC2868 such as Tunnel-Client-Endpoint >>and Tunnel-Assignment-ID (which looks more appropriate than the >>Tunnel-Private-Group-Id you suggested as multiple tunnels may exists between >>endpoints) is probably a good idea. > > > Tunnel-Assignment-ID is used to allow multiple connections to be carried > over the same tunnel. That is not quite the same thing as having multiple > tunnels between two endpoints. I think we are in danger of getting mired in the semantics of what is and is not a "tunnel" here. Juha, (without using the word "tunnel") all you care about here is that multiple pseudowires be possible between the same endpoints, correct? - Mark > > >>RFC2868 describes attributes for setting up different types of >>tunnels across different PSNs, Juha's draft is intended to be a simple >>mechanism for discovering VPN endpoints only. > > > I agree that RFC 2868 is a superset of what you're trying to do. I don't > think that the document necessarily requires the use of all the > capabilities, though. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 14:45:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16189 for ; Wed, 28 May 2003 14:45:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SIis805895 for ; Wed, 28 May 2003 14:44:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4SIip326152 for ; Wed, 28 May 2003 14:44:52 -0400 (EDT) Message-Id: <200305281841.h4SIfpe11555@zcars0mt.ca.nortel.com> From: "ENGINEER AUSTIN JACOB" Reply-To: eng_jacob@engineer.com To: ppvpn@nortelnetworks.com Date: Wed, 28 May 2003 19:41:09 +0100 Subject: URGENT RELPY NEENED X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: emztd1374.com X-SMTP-MAIL-FROM: engjacob@zwallet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [192.116.85.126] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16189 DEAR, I am ENGINEER AUSTIN JACOB,i work with the Nigerian National Petroleum Corporation,NNPC,Federal Republic of Nigeria. I have been opportune to be appointed as the Director of the Foreign Contract awarding committee of the Nigerian National Petroleum Corporation,NNPC. Now by virtue of my present office and position, it is an opportunity for me to have a share of the huge oil money which many top military personel of the past regime has been using me to achieve based on their Personal interest without any benefit toward me. Following this development, I now have an accord with a top officer of the Federal Ministry of Petroleum Resource to remit the sum of US$35.5Million (Thirty Million Five Hundred Thousand United State Dollars) to your nominated foreign account for the smooth remittance of this funds,hence we as civil servants do not own the right to acquire foreign account while in service and also my present financial resources as a civil servant will not be sufficient for me to handle the transfer alone successfully without assistance from a good partner abroad. I therefore request you to kindly allocate any account of your choice with all necessary particulars to enable me forward same to the Ministires here in Nigeria for onward release of the fund transfer approvals on your favour as the beneficiary. We have fourteen(14) working days to conclude this deal on commencement, and I shall join you at the account base for sharing and further discussion on my investment plan in your Country. BENEFIT: For providing the account where the paying bank shall remit the funds, you will be entitled to 20% of the fund,80% will be for me and my partners.You will assure me once more that you will protect the funds as soon as it is in your account.What we need is your Foreign Bank Account Particulars,The Bank Swift and Telex, The Bank Address, The Bank Telephone and Fax Number, Your Telephone and Fax Number and your Private Mailing Address,so that we can use it to make formal application as a matter of procedures. ON SECURITY: - We demand absolute secrecy and confidentiality from both parties hence we assure you that the transaction is hundred percent risk free.All modalities of this fund transfer has been worked out. Please confirm your interest by immediate response on this Private E-mail: eng_jacob@engineer.com Thanking you in anticipation and i will give you a telephone number where to reach me as soon as i confirm your serious interest. Yours faithfully, ENG.AUSTIN JACOB PRIVATE E-mail: eng_jacob@engineer.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 22:16:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03179 for ; Wed, 28 May 2003 22:16:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4T2Fv810542 for ; Wed, 28 May 2003 22:15:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4T2FsL00476 for ; Wed, 28 May 2003 22:15:54 -0400 (EDT) Message-ID: <3ED56CAF.3080609@acm.org> Date: Wed, 28 May 2003 22:13:03 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en, pdf MIME-Version: 1.0 To: erosen@cisco.com CC: ppvpn@nortelnetworks.com, Norman Finn Subject: Re: VPLS model for L2VPN Framework document References: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> In-Reply-To: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > > If we want to allow the PE bridges to be part of a larger bridged network, > it would be desirable for this model to be supported by the VPLS framework. > This would require: > > - the PE contains a single bridge entity > > - that bridge entity contains a single "port" to the emulated LAN > > - each distinct VLAN on the emulated LAN is replaced by a distinct VPLS > instance (an "emulated VLAN") > > - a further distinct VPLS instance is used to carry the "untagged packets" > of the emulated LAN. > So this is where I may (or may not) offer a different opinion from Norm and/or Ali. I continue to be of the opinion that the "emulated LAN" (e.g. VPLS) should look like a LAN to the bridge function, which implies (to me anyway) that a) if that VPLS is provisioned as a trunk port to the bridge, then there are multiple VLANs per VPLS (not one VPLS/vlan) - this is after all how a bridge views a non-emulated trunk port b) if that VPLS is provisioned as an access port to the bridge, then there is only one VLAN per VPLS (though as with tag stacking, one "carrier" VLAN may not equal one "customer" VLAN). To me, this keeps the terminology and model incredibly consistent to the existing briding models. Using a separate VPLS instance for discovery and setup (as discussed below) creates a likely opportunity of the 'discovery' VPLS being in a different state than the 'data' VPLS, which of course would screw everything up. It also creates the necessity for some VPLS coordination so that the bridge sees multiple VPLSs as a single LAN port. E.g. if the "untagged" VPLS does not come up (not enough labels or whatever), do the others go down? What of some of the others don't come up, should the untagged VPLS go down? I get the willies thinking about the possibilities. Would you do this with real Ethernet segments? E.g. use one LAN to control the status of all collection of other LANs connected to the same bridges? I would guess not. So I think its dangerous to try that approach here for those very same reasons. > The VPLS instance used to carry the untagged packets would, from the > perspective of discovery and setup, be an independent VPLS instance. It is > only the use of this VPLS instance that makes it any different than any > other VPLS instance. Let's call this VPLS instance the "control VPLS > instance". Then we need to allow a PE bridge to attach, via a single > emulated LAN port, to one control VPLS instance and to an arbitrary number > of additional VPLS instances. > > A set of PEs that attach to a common VPLS control instance may be termed an > "island". Note that there is no requirement that two PE bridges in the same > island support the same set of VPLS instances, nor is there any requirement > that a VPLS instance (other than the control instance) stay within an > island. > > The framework model, on the other hand, suggests that a PE may contain > multiple bridges, each with a port to a single VPLS instance. This would > seem to rule out the possibility of using a single spanning tree for > multiple VLANs. > Exactly, which is one of the critiques of the framework model. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed May 28 22:51:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03970 for ; Wed, 28 May 2003 22:51:50 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4T2pJ815556 for ; Wed, 28 May 2003 22:51:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4T2pGV10460 for ; Wed, 28 May 2003 22:51:16 -0400 (EDT) Date: Thu, 29 May 2003 11:47:48 +0900 (JST) Message-Id: <20030529.114748.71129538.suzuki.muneyoshi@lab.ntt.co.jp> To: erosen@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: VPLS model for L2VPN Framework document From: Muneyoshi Suzuki In-Reply-To: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> References: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > The framework model, on the other hand, suggests that a PE may contain > multiple bridges, each with a port to a single VPLS instance. This would > seem to rule out the possibility of using a single spanning tree for > multiple VLANs. I thought the framework model was that the PE contain a single Bridge. Certainly, if it contains multiple Bridges, it is impossible to run an MSTP instance among the Bridges. However, why multiple Bridges are needed in a single PE? If it is single, I think there is no problem. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 07:36:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27724 for ; Thu, 29 May 2003 07:36:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TBaOK17109 for ; Thu, 29 May 2003 07:36:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TBaLh26307 for ; Thu, 29 May 2003 07:36:21 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: erosen@cisco.com, ppvpn@nortelnetworks.com Subject: RE: VPLS model for L2VPN Framework document Date: Thu, 29 May 2003 12:34: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" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Eric > If we want to allow the PE bridges to be part of a larger > bridged network, > it would be desirable for this model to be supported by the > VPLS framework. > This would require: > > - the PE contains a single bridge entity > > - that bridge entity contains a single "port" to the emulated LAN > > - each distinct VLAN on the emulated LAN is replaced by a distinct VPLS instance (an "emulated VLAN") > > - a further distinct VPLS instance is used to carry the "untagged packets" of the emulated LAN. Is the intention here to create 1 VPLS control instance (i) per customer or (ii) per service provider network? If the answer is (i) per customer, then this does not sound very scalable or attractive from a provisioning perspective. If the answer is (ii) per service provider network, then what traffic will be carried over the control VPLS? Untagged customer frames or untagged service provider frames, either way this sounds like it may lead to security concerns. Thanks, Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 08:24:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00520 for ; Thu, 29 May 2003 08:24:16 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TCNiK05477 for ; Thu, 29 May 2003 08:23:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TCNf612695 for ; Thu, 29 May 2003 08:23:41 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: mattsquire@acm.org, erosen@cisco.com Cc: ppvpn@nortelnetworks.com, nfinn@cisco.com Subject: RE: VPLS model for L2VPN Framework document Date: Thu, 29 May 2003 13:19:37 +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" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: > So this is where I may (or may not) offer a different > opinion from Norm > and/or Ali. I continue to be of the opinion that the "emulated LAN" > (e.g. VPLS) should look like a LAN to the bridge function, > which implies > (to me anyway) that > a) if that VPLS is provisioned as a trunk port to the bridge, then > there are multiple VLANs per VPLS (not one VPLS/vlan) - this > is after > all how a bridge views a non-emulated trunk port > b) if that VPLS is provisioned as an access port to the > bridge, then > there is only one VLAN per VPLS (though as with tag stacking, one > "carrier" VLAN may not equal one "customer" VLAN). > To me, this keeps the terminology and model incredibly > consistent to the > existing briding models. [RS] This seems to me to be a more attractive option. However, if a single VPLS instance is allowed to carry multiple VLANs then customer frames must carry a VLAN ID so that the receiving PE can determine which VLAN a frame belongs to. I seem to remember a debate about whether customer frames should have their VLAN information stripped of or not. Can anyone tell me if there was a conclusion to that debate and what the reason was for removing the VLAN tag was? Was it simply to save bandwidth? The only complication I can see here is that the service provider must ensure trunk ports only connect to other trunk ports and access ports only connect to other access ports. However, this is true in any Ethernet switched network. Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 09:19:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02618 for ; Thu, 29 May 2003 09:19:48 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TDJFK27778 for ; Thu, 29 May 2003 09:19:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TDJCn04640 for ; Thu, 29 May 2003 09:19:12 -0400 (EDT) From: "Mark Seery" To: Subject: RE: VPLS model for L2VPN Framework document Date: Thu, 29 May 2003 06:16:44 -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) Importance: Normal In-Reply-To: <3ED56CAF.3080609@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: smtp013.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp013.mail.yahoo.com [216.136.173.57] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Some questions: 1) Is a VPLS subscriber not allowed to send frames that are already formatted as a "stacked VLAN"? 2) In the model where the SP only has one VPLS, and each subscriber is a VLAN, how many VLANs can be supported? 3) What are the scaling limitations/determinants of the model where the SP has one VPLS for all subscribers? Thanks, Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 09:50:52 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03549 for ; Thu, 29 May 2003 09:50:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TDoGK05642 for ; Thu, 29 May 2003 09:50:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TDoDS27133 for ; Thu, 29 May 2003 09:50:13 -0400 (EDT) Message-Id: <200305291347.JAA03419@ietf.org> To: Internet Architecture Board , ppvpn@nortelnetworks.com From: The IESG Subject: Document Action: A Framework for Layer 3 Provider Provisioned Virtual Private Networks to Informational Date: Thu, 29 May 2003 09:47:24 -0400 Sender: mlee@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: mlee@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: The IESG has approved 'A Framework for Layer 3 Provider Provisioned Virtual Private Networks' as an Informational RFC. This document is the product of the Provider Provisioned Virtual Private Networks Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. ======== Alex: Generally, I liked this document _much_ better than the requirements doc, Ross did a great job, still it needs more work, I believe. A meta meta issue: M0: why is this work in SUB area? It is all about routing and hopefully not MPLS-specific... Randy would have another chance to say that a more experienced person would his mouth shut, and it is not that we don't have enough stuff to deal with in RTG, but really... Meta issues: M1: In many, many places the document talks about a SP's network as opposed to edge-to-edge through the Internet. I don't know if this is intentional or not, but it seems to me that we should want the WG to develop a solution that is able to work very well across the Internet as well as within a single SP as a special case... So far what I've seen is something like "we'll deal with this later". Specifically section 5 talking about this is really weak... M2: In some places, a PE-based scenario is implicitly assumed M3: I would like the doc to be more careful in places where it talks about using RPs to make sure this does not sound like a permission to use RPs that we're signing off on. More detailed comments follow below. Alex > 1.2 Overview of Virtual Private Networks > > ............ ................. ............ > . . . . . . > . +---+ +-------+ +-------+ +---+ . > . r3---| | | | | |----|CE2|---r5 . > . | | | | | | +---+ . > . |CE1|----| PE2 | | PE2 | : . ^^^ PE1? > . | | | | | | +---+ . > . r4---| | | | | |----|CE3|---r6 . > . +---+ +-------+ +-------+ +---+ . > . Customer . . Service . . Customer . > . site 1 . . provider(s) . . site 2 . > ............ ................. ............ > > Figure 1.1: VPN interconnecting two sites. > > > In general Provider Edge (PE) and Customer Edge (CE) devices may be > either routers, LSRs, or IP switches. Some approaches may limit the ^^^^^^^^^^^ What is this? > type of PE and/or CE device that can be used. For example, in some > approaches the PE devices may be required to be routers. > > In this document, scope of the SP network is an IP or MPLS network. > It is desired to interconnect the customer network sites via the SP > network. > > In many cases, customer networks will make use of private IP > addresses [RFC1918] or non-unique IP address (e.g., unregistered > addresses). This implies that there is no guarantee that the IP > addresses used in the customer network are globally unique. In the > case that a single PE device provides services to multiple different > customer networks, this implies that the addresses used in the > different customer networks may overlap. The internal operation of > the PE device needs to maintain a level of isolation between the > packets from different customer networks. M2 above. > 2.1 Reference Model for Layer 3 PE-based VPN > > This subsection describes functional components and their > relationship for implementing layer 3 PE-based VPN. > > Figure 2.1 shows the reference model for layer 3 PE-based VPNs and > Figures 2.2 and 2.3 show relationship between entities in the > reference model. Minor: looking at 2.3 from this place, some things (like hierarchical tunnel) have not yet been introduced. > 2.1.1 Entities in the reference model ... > o P router > > A router within a provider network which is used to interconnect PE > devices, but which does not have any VPN state and does not have ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ it was great to see this--very important and very correct. ... > o VPN forwarding instance (VFI) > > A VFI is a logical entity that resides in a PE, that includes the > router information base and forwarding information base for a VPN. > A VFI enables router functions dedicated to serving a particular > VPN. In general a VFI terminates VPN tunnels for interconnection > with other VFIs and also terminates access connections for > accommodating CEs. The interaction between routing and VFIs is > discussed in section 4.4.2. This definition does not really give the reader any idea about why we need VFIs, such as overlapping addressing schemes. ... > 3.1.2 Layer 3 provider provisioned CE-based VPN > > In the context of layer 3 provider provisioned CE-based VPNs, the PE > devices have no knowledge of the establishment of VPNs at their > customer interface. > > CE devices have IP/MPLS connectivity via a connection to a PE device. ^^^^^^^ can we make this "IP or MPLS" from here on? some can read this as "IP MPLS", i.e., "MPLS for IP" > The IP connectivity may be via a static binding, or via some kind of > dynamic binding. > > The establishment of the VPNs is done at the CE devices, making use > of the IP/MPLS connectivity to the SP network. ^^^^^^^^^^ M1 ... > 3.2.2 Layer 3 provider provisioned CE-based VPN > > The data exchanged at the customer interface are always normal IP > packets that are routable in the SP's network or MPLS frames that can ^^^^^^^^^^^^ M1 > be label-switched across the SP network. ^^^^^^^^^^ M1 > The PE device does not > assign any VPN meaning to IP or MPLS packets on the access > connection; all VPN meaning is confined to the CE devices. > ... > 3.3.1.2 Routing for extranets > > In the extranet case the sites to be interconnected belong to > multiple different administrations. In this case IGPs (such as OSPF, > IS-IS, or RIP) are normally not used across the interface between > organizations. Either static routes or BGP may be used between > sites. If the customer network administration wishes to maintain > control of routing between its site and other networks, then either > static routing or BGP may be used across the customer interface. If > the customer wants to outsource all such control to the provider, > then an IGP or static routes may be used at this interface. > > The use of BGP between sites allows for policy based routing between > sites. This is particularly useful in the extranet case. No consideration on overlapping address spaces here? It's definitely more complicated than just policing the route exchange. > 3.3.1.3 CE and PE devices for layer 3 PE-based VPNs > > When using a single IGP area across an intranet, the entire customer > network participates in a single area of an IGP. In this case, for > layer 3 PE-based VPNs both CE and PE devices participate as normal > routers within the area. > > > > > Design Team Expires October 2002 [Page 27] > > INTERNET-DRAFT A Framework for L3 PPVPNs April 2002 > > > The other options make a distinction between routing within a site, > and routing between sites. In this case, the CE devices would > normally be considered as part of the site where they are located. > However, there is an option regarding how the PE devices should be > considered. > > In some cases, from the perspective of routing within the customer > network, the PE devices (or more precisely the VFI within a PE > device) may be considered to be internal to the same area or routing > domain as the site to which they are attached. This simplifies the > management responsibilities of the customer network administration, > since inter-area routing would be handled by the provider. > > For example, suppose that either static routes or BGP are used > between sites. With this approach each site could operate as a > single IGP area, and the access connection would simply be configured > as internal links within that area. Static routes or BGP for inter- > site routing can be handled by the provider. What about IGPs used for inter-site? > > In other cases, from the perspective of routing within the customer > network, the CE devices may be the "edge" routers of the IGP area. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What is this? > In this case, static routing, BGP, or whatever routing is used in the > backbone, may be used across the customer interface. > > 3.3.2 Customer view of routing for layer 3 provider provisioned CE-based > VPNs > > For layer 3 provider provisioned CE-based VPNs, the PE device and P > router are not aware of the reachability within the customer sites. > The CE and PE devices don't exchange customer's routing information. > The routing in the customer VPN is transparent to the SP's network. > > This means no VPN routes need to be maintained in any of the SP's > PE/P devices. > > Customer sites that belong to the same VPN may exchange routing > information through the VPN tunnels that are seen as CE to CE > interconnecting links from the customer's perspective. > Alternatively, instead of exchanging routing information through the > VPN tunnels, the SP's management system may take care of the > distribution of the routing information of one site towards the other > sites in the VPN. Management system taking care about routing... Should probably be more specific and say that static routes are meant, not that we'll inject dynamic info from VPN sites into whatever management system the SP uses. ... > 4. Network Interface and SP Support of VPNs > > 4.1 Functional Components of a VPN > > The basic functional components of an implementation of a VPN are: > > o A mechanism to acquire VPN membership/capability information > > o A mechanism to tunnel traffic between VPN sites > > o For layer 3 PE-based VPNs, a means to learn customer routes, > distribute them across the provider network, and to advertise ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ M1 + can we be more specific here and say between PEs? > reachable destinations to customer sites. ... > VPN membership and capability information can be distributed via > routing protocols such as BGP, M3 > central management system such as LDAP > or manual configuration. Manual configuration does not scale and is > error prone, and therefore is discouraged. ... > 4.2.1 VPN discovery > ... > A number of different approaches are possible for VPN discovery. One > scheme uses the network management system to configure and provision > the PEs (or CEs for layer 3 provider provisioned CE-based VPN). This > approach can also be used to distribute VPN discovery information, > either using proprietary protocols or using standard management > protocols and MIBs. Another approach is where the PEs (or CEs) act > as clients of a centralized directory or database server that > > > > Design Team Expires October 2002 [Page 33] > > INTERNET-DRAFT A Framework for L3 PPVPNs April 2002 > > > contains VPN discovery information. Another is where VPN discovery > information is piggybacked onto a routing protocol running between > the PEs (or CEs) [VPN-DISC]. M3. ... > 4.2.1.1 Network management for membership information > > SPs use network management extensively to configure and monitor > various devices in their network, which may be distributed across > geographically separate sites. The same approach could be used for > distributing VPN related information as well. A network management > system (either centralized or distributed) could be used by the SP to > configure and provision VPNs on PE devices (or CEs devices for layer > 3 provider provisioned CE-based VPN) at various locations. VPN > configuration information could be entered into the network > management application and distributed via SNMP, XML, CLI, or other > means to the remote sites. This approach can be very effectively > used within an SP network, since the SP has access to all PEs (or > CEs) in its domain. Security and access control are important, and > could be achieved for example using SNMPv3, SSH, or IPsec tunnels. > Standardized MIBs will need to be developed before this approach can > be used to configure PEs (or CEs) across SP boundaries. Hmmm.. does this implicitly assume that one SP would configure a PE in another SP's network? ... > 4.2.1.2 Directory servers > > An SP typically needs to maintain a database of its customer's > configuration/membership information regardless of the mechanisms > used to distribute it. LDAP [RFC1777] is a standard directory > protocol which makes it possible to use a common mechanism for both > storing such information and distributing it. > > LDAP defines a schema, which is a standard format for representing I though schemas were defined independently _for_ LDAP, not by it, might be wrong though, not an LDAP expert. > information that will be stored in an LDAP server. Having a standard > schema ensures interoperability between different implementations of > LDAP servers and clients. Moreover, LDAPv3 [RFC2251] supports > authentication of messages and associated access control, which can > be used to limit access to VPN information to authorized entities. > > 4.2.1.3 Augmented routing for membership information > > BGP supports extensions which allows it to carry VPN information. > This allows the VPN discovery information and routing information to > be combined in a single protocol. BGP is also widely deployed by SPs > [VPN-2547BIS]. > > > > > > Design Team Expires October 2002 [Page 34] > > INTERNET-DRAFT A Framework for L3 PPVPNs April 2002 > > > BGP also contains mechanisms to control route distribution. Route > filters can be used to constraining the distribution of routing > information. Information needed to establish per-VPN tunnels can > also be carried by this routing instance. > > Augmented routing may be done in combination with aggregated routing, > as discussed in section 4.4.4. M3 in this section. Also, more considerations are necessary for Inet edge-to-edge scenarios. > 4.2.1.4 Multi-SP VPNs > > When two sites of a VPN are connected to different SP networks, there > must be a common mechanism for exchanging membership/capability > information. At least one mechanism for VPN information discovery > must be standardized and supported across multiple SPs. Inter-SP > trust relationships will need to be established that will allow for > exchange of membership information across SP boundaries. Also, some > mechanisms will be needed to control which membership information is > exchanged between SPs. M3. Seems a bit too weak. What about amount of info, scaling distribution of it, its growth and dynamics, its uniqueness? > 4.2.2 Constraining distribution of VPN routing information > > With layer 3 provider provisioned CE-based VPNs, the VPN service > provides tunnels between CE devices. In this case, distribution of > IP routing information occurs between CE devices on the customer > sites and is therefore outside of the scope of the provider aspects > of VPN support. > A possibility for layer 3 provider provisioned CE- > based VPNs though, is that the SP takes care of the inter-site > distribution of routing information, while the intra-site > distribution remains outside of the scope of the provider's control. I stumbled here... So, how does this fit within the global picture of PE/CE separation? What is the management model? Another instances of M3, btw. ... > 4.2.3 Controlling VPN topology > ... > The selection of a topology for a VPN is an administrative choice, > but it is useful to examine protocol mechanisms that can be used to > automate the construction of the desired topology, and thus reduce > the amount of configuration needed. To this end it is useful for a > PE (or CE) to be able to advertise per-VPN topology information to > other PEs (or CEs). Typically this per-VPN topology information is > advertised using the same mechanism that is used to advertise > membership information. > The topology information may be associated > with a PE (or CE), or with subsets of routes reachable via that PE > (or CE). Huh? Topology associated with routes??? ... > For layer 3 provider provisioned CE-based VPNs, as it is not common > to have inter-CE distribution protocols, the VPN topology is > restricted by configuring every CE only with the other CEs it has to > establish tunnels to. As such, when a new CE is added to an existing > VPN, the VPN topology will dictate which other CEs need to be > notified. What's wrong with CE-based VPNs from this perspective? If I have a bunch of CEs in a VPN, I still want to control the topology of tunnels between them... > 4.3 VPN Tunneling > > VPN solutions use tunneling in order to transport VPN packets across > the SP network. M1 ! > There are different types of tunneling protocols, ... > One motivation for the use of tunneling is that the packet addressing > used in a VPN may have no relation to the packet addressing used > across the SP network. M1 > For example the customer VPN traffic could ... > forwarding the packet across the SP network. M1 ... > > The specific tunneling protocols considered in this section are MPLS, > GRE, IPsec, and IP-in-IP as these are the most suitable for carrying Nice ordering ;) Let's make it alphabetic ;) > VPN traffic across an SP backbone. M1 > Other tunneling protocols, such > as L2TP [RFC2661], are used primarily to tunnel users across an > access network to a PE or access server, or are used in a CE-based > VPN. As the tunneling protocol used across the SP network between M1 > PEs is orthogonal to how sites and subscribers access the VPN, these > access side tunneling protocols are not discussed here. So, I don't get it. The sentence above says L2TP is used in CE-based VPNs, but then it says it is not considered here... Hmmm... > 4.3.1 Tunnel encapsulations > > All tunneling protocols use an encapsulation that adds additional > information to the packet that is used for forwarding across the SP > network. Examples are provided in section 4.3.6. M1 > One characteristic of a tunneling protocol is whether per-tunnel > state is needed in the SP network in order to forward the tunneled > packets. For IP tunneling schemes (GRE, IPsec, and IP-in-IP) no such > per-tunnel state is needed since forwarding is carried out using the > outer IP header. When forwarding packets core routers make no > distinction between tunneled and non-tunneled packets. ^^^^^^^^^^^^^^^^^^^^^^^^^ maybe what is really meant here is "encapsulating and non-encapsulating" packets? > For MPLS, > per-tunnel state is needed, since the top label in the label stack > must be examined and swapped by intermediate LSRs. The amount of > state required can be minimized by hierarchical multiplexing, and by > use of multi-point to point tunnels, as discussed below. > > Another characteristic is the tunneling overhead introduced. With > IPsec the overhead may be considerable as it may include, for > example, an ESP header, ESP trailer and an additional IP header. The > other mechanisms listed use less overhead, with MPLS being the most > lightweight. The overhead inherent in any tunneling mechanism may > result in additional IP packet fragmentation, if the resulting packet > is too large to be carried by the underlying link layer. As such it > is important to report any reduced MTU sizes via mechanisms such as > path MTU discovery in order to avoid fragmentation wherever possible. Other considerations here, such as transparency to the Internet? ... > 4.3.3 Tunnel establishment ... > Multiplexing field values can also be exchanged without the use of an > explicit signaling protocol. For example MPLS labels can be > piggybacked on the protocol used for the distribution of VPN routes, > or on a protocol used for VPN membership. GRE and IP-in-IP have no > associated signaling protocol, and thus by necessity the multiplexing > values are distributed via some other mechanism, such as via > configuration, control protocol, or piggybacked in some manner on a > VPN membership or VPN routing protocol. ^^^^^^^^^^^^^^^^^^^^ I thought we were talking about _tunnel_ mux'ing, not route mux'ing. > The resources used by the different tunneling establishment > mechanisms may vary. With a full mesh VPN topology, and explicit > signaling, each PE (or CE for layer 3 provider provisioned CE-based > VPNs) has to establish a tunnel to all the other PEs (or CEs) for > every VPN. The resources needed for this on a PE (or CE) may be > significant and issues such as the time needed to recover following a > device failure may also be taken into account, due to the need to > have to reestablish a large number of tunnels. Looks like we need more thought put into this part. For example, scaling characteristics of signalling devices in PE- and CE-based scenarios will vary, as CEs are normally busy with one VPN. > 4.3.4 Scaling and hierarchical tunnels > ... > One example using hierarchical tunnels is the use of an MPLS label > stack. A single PE-PE LSP is used to carry all the per-VPN LSPs. > The mechanisms used for label establishment are typically different. > The PE-PE LSP could be established using LDP, as part or normal > backbone operation, with the per-VPN LSP labels established by > piggybacking on VPN routing (e.g., using BGP). Has "VPN routing" been defined? M3 as well. > 4.3.5 Tunnel maintenance ... > A tunneling protocol may have a built-in keep alive mechanism that > can be used to detect loss connectivity. The base IPsec standard > does not contain such a mechanism but there are proposals to extended > IPsec in this manner. GRE and IP-in-IP tunneling have no such > mechanism. ^ and usually rely on IGP hello mechanisms. > MPLS detects failures as part of the signaling protocols. > > With hierarchical tunnels it may suffice to only monitor the > outermost tunnel for loss of connectivity. However there may be > failure modes in a device where the outermost tunnel is up but one of > the inner tunnels is down. > > 4.3.6 Survey of tunneling techniques > > Tunneling mechanisms provide isolated and secure communication ^^^^^^ hmmm... in what sense? > between two CE/PE devices. Available tunneling mechanisms include > (but are not limited to): MPLS [RFC3031] [RFC3035], GRE [RFC2784] > [RFC2890], IPsec [RFC2401] [RFC2402], and IP-in-IP encapsulation > [RFC2003] [RFC2473]. Should we stick with the alphabetic order here and below? > 4.3.6.1 MPLS [RFC3031] [RFC3035] > > Multiprotocol Label Switching (MPLS) is a method for forwarding > packets through a network. Routers at the edge of a network apply > simple labels to packets. A label may be inserted between the data > link and network headers, or may be carried in the data link header > (e.g., the VPI/VCI field in an ATM header). Routers in the network > > > > Design Team Expires October 2002 [Page 42] > > INTERNET-DRAFT A Framework for L3 PPVPNs April 2002 > > > switch packets according to the labels with minimal lookup overhead. > A path, or a tunnel in the PPVPN, is called a "label switched path > (LSP)." Here and onwards for other tunneling mechanisms, I'd like to see another two characteristics: o State maintained by tunnel end points and intermediated routers o Internet transparency and requirements for contiguous support > o Multiplexing > > LSPs may be multiplexed into another LSP. > > o Multiprotocol transport > > MPLS can carry data packets other than IP. Let's be frank and admit that only one protocol per LSP is allowed. > 4.3.6.2 GRE [RFC2784] [RFC2890] ... > o Multiprotocol transport > > GRE is assumed to support any type of payload protocol. ^^^^^^^^^^ ? why so unsure compared to "MPLS can carry"? > 4.3.6.4 IP-in-IP encapsulation [RFC2003] [RFC2473] ... > o Multiprotocol transport > > IP-in-IP needs extensions to carry packets other than IP. Can we still call it "IP-in-IP" then? :) ... > 4.4 Routing for VPNs Across the SP Network M1 is a meta meta issue for this section.... ... > The SP network needs to carry two types of information: (i) Routing > information about the public network (including routes to the public > Internet); (ii) Routing information about routes within the customer > networks served by the VPNs. Routing for the Internet or for public > IP networks are outside of the scope of this document. In this para above, I don't see why the SP network as whole needs to know this data, not just PEs... ... > 4.4 Routing for VPNs Across the SP Network Hmmm.. I see scalability considerations in the previous section talking about tunneling, but not in this one, which has more potential problems... We need it here. > 4.4.1 Options for VPN routing in the SP ^^^^^^^^^^^ defined? > The following technologies can be used for exchanging routing > information within an SP network: which "routing info" SP's or VPN? M1. > o Static routing (see section 3.3.3) > > o RIP (see section 3.3.3) > > o OSPF (see section 3.3.3) > 3.3.3 talks about customer-visible routing. what is it doing here? > o BGP (see section 3.3.3) > > o Multiprotocol BGP-4 [RFC2858] > > BGP-4 has been extended to support IPv6, IPX, and others as well as > IPv4 [RFC2283]. Multiprotocol BGP-4 carries routes from multiple > "address families," such as the "VPN-IPv4 address family" discussed > in [VPN-2547BIS]. I would suggest that we do not separate "BGP" and "Multiprotocol BGP". It is still one protocol--our dear BGP, which we use for Internet routing, not a separate piece of code running on a separate set of boxes... > 4.4.2 VPN forwarding instances (VFIs) > ... > In general, a routing protocol instance may populate multiple VFIs, > or a single VFI. Also, a VFI may be populated by a single routing > protocol, or multiple routing protocols. Therefore there is not > necessarily a one to one correspondence between VFI and routing > protocol instance. M3 Please be more specific here, what is meant by populating VFIs? I don't see any considerations on the drawbacks that this approach induces. > There are several options for how VPN routes are carried across the > SP network, as discussed below. > > 4.4.3 Per-VPN routing ... > This approach minimizes the interactions between multiple different > VPNs as well as with the SP's backbone and the Internet routing system. > , in that routing is done independently for each VPN. However, > with this approach each PE device implements the capabilities of > multiple different routers. This implies that some sharing of > resources may occur within the PE device. ... > 4.4.4 Aggregated routing model > > Another option is to use one single instance of a routing protocol > for carrying VPN routing information across the SP network. With > this method the routing information for multiple different VPNs is > aggregated into a single routing protocol. This implies that > whichever routing protocol is used in the SP network needs to be > enhanced to allow routes from different VPNs to be distinguished. M3 No. This implies that routes from VPNs can be distributed together, but this does not mean that the SP's routing system should be used for this purpose. > In this approach, the number of routing protocol instances in a PE > device does not depend on the number of CEs supported by the PE > device, if the routing between PE and CE devices is static or BGP-4. > However, CE and PE devices in a VPN exchange route information inside > a VPN using a routing protocol except for BGP-4, the number of > routing protocol entities in a PE device depends on the number of CEs > supported by the PE device. > > In principle it is possible for routing to be aggregated using either > BGP or on an IGP. I'd like to see more detailed analysis on this particular approach (aggregated routing). Specifically, please explore the topics of scalability, stability, and transparency to the Internet routing system. > 4.4.4.1 Aggregated routing with OSPF or IS-IS ... > broadcast to all routers in the area, even routers which don't want > to know about any one particular VPN. > Given the potential magnitude > of the total routing information required for supporting a large > number of VPNs, this broadcast may have unfortunate scaling > implications. Remember this one. Magically, this potential magnitude does not bother us when we talk about BGP... ... > 4.4.4.2 Aggregated routing with BGP M3 in this whole section... Needs considerations on Inet edge-to-edge scenarios, potential impact on SP's and Internet BGP infrastructure... ... > 5. Interworking Interface This section is quite weak. It does not talk about scenarios where no end-to-end service required for a specific VPN solution (such MPLS/BGP) is provided. No considerations on exchanging of VPN membership info, etc... --the end--- Randy: > M0: why is this work in SUB area? It is all about routing > and hopefully not MPLS-specific... Randy would have > another chance to say that a more experienced person > would his mouth shut, and it is not that we don't have > enough stuff to deal with in RTG, but really... what are the routing aspects of ipsec and other L3 tunneling technologies? of course, they're not very sub-ip either, are they? > M1: In many, many places the document talks about a SP's network > as opposed to edge-to-edge through the Internet. I don't know > if this is intentional or not, but it seems to me that we > should want the WG to develop a solution that is able to > work very well across the Internet as well as within a single > SP as a special case... So far what I've seen is something like > "we'll deal with this later". Specifically section 5 talking > about this is really weak... and it continues to confuse provider PROVISIONED with provider PROVIDED. i.e. providers provision cpe-based L2 and L3 vpn kit. > M2: In some places, a PE-based scenario is implicitly assumed 'zactly > M3: I would like the doc to be more careful in places where it > talks about using RPs to make sure this does not sound like > a permission to use RPs that we're signing off on. i was 1/3 through this one when your message came in. thank you for saving me from the other 2/3. RFC Editor Note: Section 4.2.1.1, 1st paragraph Replace OLD: VPN configuration information could be entered into the network management application and distributed via SNMP, XML, CLI, or other means to the remote sites. With NEW: VPN configuration information could be entered into a network management application and distributed to the remote sites via the same means used to distribute other network management information. ---------------------------------------------- Section 4.3.6.2, 6th paragraph (5th item) Replace OLD: An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. With NEW: An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. ---------------------------------------------- Section 4.7.1, 4th paragraph Replace OLD: Use of proprietary command-line interfaces is highly undesirable for this task, as they do not lend themselves to standard representations of managed objects. With NEW: Use of proprietary command-line interfaces has the disadvantage that proprietary interfaces do not lend themselves to standard representations of managed objects. ---------------------------------------------- Section 5.2, 3rd paragraph DELETE OLD: With layer 3 VPNs it is normal for PEs to have a physical link per VPN. In this case the PEs which terminate the interworking interface have a tunnel per VPN. ---------------------------------------------- Intellectual Property, 1st paragraph Replace OLD: The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. With NEW: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 10:15:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05262 for ; Thu, 29 May 2003 10:15:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TEFGK27109 for ; Thu, 29 May 2003 10:15:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TEFDb29686 for ; Thu, 29 May 2003 10:15:13 -0400 (EDT) Message-Id: <200305291412.h4TEC3FV011191@rtp-core-1.cisco.com> To: Muneyoshi Suzuki cc: ppvpn@nortelnetworks.com Subject: Re: VPLS model for L2VPN Framework document In-reply-to: Your message of Thu, 29 May 2003 11:47:48 +0900. <20030529.114748.71129538.suzuki.muneyoshi@lab.ntt.co.jp> 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: Thu, 29 May 2003 10:12:03 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: > I thought the framework model was that the PE contain a single Bridge. > Certainly, if it contains multiple Bridges, it is impossible to run > an MSTP instance among the Bridges. However, why multiple Bridges are > needed in a single PE? If it is single, I think there is no problem. I didn't have the MSTP stuff clear in my mind when I wrote up the model, which is why the text is subject to different interpretations. The way the framework document is written, it seems to suggest that an "emulated LAN" is the as a "VPLS instance", which in turn suggests that a single MSTP instance cannot govern multiple VPLS instances. So I just wanted to make it clearer that an emulated LAN could consist of a set of VPLS instances plus an MSTP instance; I think this would remove Mick's and Norm's objection. But I didn't want to require that if there is an MSTP instance, it must govern all the VPLS instances; this seems to me to be a deployment decision which need not be mandated by the framework. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 10:29:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05678 for ; Thu, 29 May 2003 10:29:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TET1K01526 for ; Thu, 29 May 2003 10:29:01 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TESwb15006 for ; Thu, 29 May 2003 10:28:58 -0400 (EDT) Message-Id: <200305291426.h4TEQkFV015392@rtp-core-1.cisco.com> To: mattsquire@acm.org cc: ppvpn@nortelnetworks.com, Norman Finn Subject: Re: VPLS model for L2VPN Framework document In-reply-to: Your message of Wed, 28 May 2003 22:13:03 -0400. <3ED56CAF.3080609@acm.org> 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: Thu, 29 May 2003 10:26:45 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Matt> So this is where I may (or may not) offer a different opinion from Matt> Norm and/or Ali. Well, trying to figure out when the bridge experts are agreeing and when they are disagreeing is one of the challenges we face ;-) Matt> Using a separate VPLS instance for discovery and setup (as discussed Matt> below) creates a likely opportunity of the 'discovery' VPLS being in a Matt> different state than the 'data' VPLS, which of course would screw Matt> everything up. I think the vision here is that a service provider's network might consist of several Q-in-Q islands, where some VPLS instances are intra-island, some are inter-island, and some are inter-provider. However, an MSTP instance would always be intra-island, by definition. I'm not sure how your model handles this. However, I don't think anything in my proposed writeup prevents you from setting up a single VPLS instance which contains multiple VLANs, though there is the question of how the encapsulation would distinguish the VLANs. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 10:32:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05786 for ; Thu, 29 May 2003 10:32:22 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TEVpK05408 for ; Thu, 29 May 2003 10:31:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TEVlJ19538 for ; Thu, 29 May 2003 10:31:48 -0400 (EDT) Message-Id: <200305291429.h4TETMFV016069@rtp-core-1.cisco.com> To: richard.spencer@bt.com cc: ppvpn@nortelnetworks.com Subject: Re: VPLS model for L2VPN Framework document In-reply-to: Your message of Thu, 29 May 2003 12:34:22 +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: Thu, 29 May 2003 10:29:21 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Richard> Is the intention here to create 1 VPLS control instance (i) per Richard> customer No. Richard> or (ii) per service provider network? Not necessarily limited to one per service provider network. However, this would be a deployment consideration, I think. Richard> what traffic will be carried over the control VPLS? Untagged Richard> customer frames or untagged service provider frames, either way Richard> this sounds like it may lead to security concerns. I think "untagged service provider frames" is the answer. What is the security concern? From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 10:44:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06070 for ; Thu, 29 May 2003 10:44:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TEi0K10630 for ; Thu, 29 May 2003 10:44:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TEhvJ00990 for ; Thu, 29 May 2003 10:43:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16086.7216.901317.907490@harjus.eng.song.fi> Date: Thu, 29 May 2003 17:41:52 +0300 To: Bernard Aboba Cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: References: <16077.49504.628040.94146@harjus.eng.song.fi> <16083.39624.280716.200879@lohi.eng.song.fi> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > Having the PE fabricate a User-Name and Password exchange where in fact > no such exchange is occurring is not a good idea. this is how most vpn implementations work today, i.e., the vpn site information is only configured in the pe. > Clearly the PE must be identifying the CE in some manner so that it is > confident it is the correct CE, no? as i said in above, in most vpn implementations today, the ces doen't identify them selfes at all. in that respect my proposal in a big improvement, because if the ce is 802.1x capable, it can identify itself. > > the pe needs from radius a list of ip addresses of other pes. if there > > is an existing attribute that can return that, it is fine with me to use > > it. > > Yes, there is. There is Tunnel-Client-Endpoint and Tunnel-Server Endpoint. > If used with a Tunnel-Medium-Type of 1 (IPv4) or 2 (IPv6) these Attributes > can contain IP addresses. Have a look at RFC 2868. i'll take a look at it. which attribute to use is a minor issue can be decided later. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 11:03:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06524 for ; Thu, 29 May 2003 11:03:02 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TF2VK05711 for ; Thu, 29 May 2003 11:02:31 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TF2RC06078 for ; Thu, 29 May 2003 11:02:28 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16086.8319.405397.909653@harjus.eng.song.fi> Date: Thu, 29 May 2003 18:00:15 +0300 To: "W. Mark Townsley" Cc: Bernard Aboba , richard.spencer@bt.com, ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: <3ED4AADC.1080703@cisco.com> References: <3ED4AADC.1080703@cisco.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit W. Mark Townsley writes: > I think we are in danger of getting mired in the semantics of what is > and is not a "tunnel" here. > > Juha, (without using the word "tunnel") all you care about here is > that multiple pseudowires be possible between the same endpoints, > correct? the pe receives from radius a set of ip addresses of other pes. how it uses them is up to the vpn protocol that the pes implement. for example, in my vpls proposal the pe would create a single l2tp tunnel to each of the other pes (unless one already exists) and then within each tunnel create any number of l2tp sessions, one per vpn. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 11:33:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07425 for ; Thu, 29 May 2003 11:33:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TFWeK15906 for ; Thu, 29 May 2003 11:32:40 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TFWae10424 for ; Thu, 29 May 2003 11:32:37 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: aboba@internaut.com Cc: jh@lohi.eng.song.fi, ppvpn@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt Date: Thu, 29 May 2003 16:27:53 +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" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: > That's fine. A RADIUS "Call Check" assumes that the user is > authenticated > by another means (e.g. OSPF MD5), so there are no authentication > attributes in the Access-Request. But it *does* require that > the CE be > identified in some way. That typically is via an L2 address, but it > could be something else. I'm just asking what uniquely > identifies the CE > in this case. Given that there is no authentication exchange > occurring, > it is probably not appropriate for the PE to "forge" an > authentication as through the CE really did authenticate when > in fact it didn't. Since RADIUS doesn't require > authentication (that's > what "Call Check" and "Authorize Only" Service-Type values are for) > there's no need to forge an authentication just to be > compliant with the > protocol. RS> I think it is important to recognise that the sole purpose of a PPVPN discovery mechanism is to discover VPN endpoints. There have been other suggestions that the discovery mechanism may distribute QoS and perhaps topology information, but these requirements have not been properly defined (and could also be distributed using a signalling mechanism). As the protocol being used for discovery in Juha's draft is RADIUS, it has the added bonus of being able to authenticate CEs. However, there is no requirement for a discovery mechanism to authenticate or to distribute/store any information whatsoever about CEs routers. To join a VPN, a PE just needs to know that it is connected to at least one CE that is a member of a particular VPN. This is a local matter, information about that particular CE does not need to be distributed. Once a PE knows it has at least one CE in a particular VPN it can request information about other PEs in the same VPN, or filter out the relevant information if the discovery mechanism is receiver based (i.e. BGP). However, having said that in Juha's draft the PEs do send CE information to the RADIUS server (for authentication), which is a very valuable feature. In the draft, currently CEs are identified by a name, rather than MAC address or port number, which is configured on the customer interface. As CE authentication is not a requirement, how CEs should be identified (i.e. port, Mac address, name) has not been discussed. Although the CE identifier issue is something that needs to be resolved, CE authentication is an extra feature and should not hold up the draft becoming a WG document. > Tunnel-Assignment-ID is used to allow multiple connections > to be carried > over the same tunnel. That is not quite the same thing as > having multiple > tunnels between two endpoints. RS> This is OK for MPLS as each LSP can be described as being a separate tunnel. However, in L2TP does the Tunnel-Private-Group-Id refer to the L2TP tunnel or to an individual session? In L2TP each tunnel can have multiple sessions, with each session corresponding to a different VPN. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 12:20:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08855 for ; Thu, 29 May 2003 12:20:13 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TGJgK12303 for ; Thu, 29 May 2003 12:19:43 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TGJdI02477 for ; Thu, 29 May 2003 12:19:40 -0400 (EDT) Date: Thu, 29 May 2003 09:17:20 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <114480941146.20030529091720@psg.com> To: PPVPN@nortelnetworks.com Subject: L2VPN/L3VPN charter discussions 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 X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit This is a reminder that charter-related threads are being redirected to the l2vpn and l3vpn specific mailing list. See my message "Decision on work split" on May 23rd, 2003 for more info on the mailing lists. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 12:42:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09680 for ; Thu, 29 May 2003 12:42:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TGg7K18100 for ; Thu, 29 May 2003 12:42:07 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TGg4Q12564 for ; Thu, 29 May 2003 12:42:04 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: erosen@cisco.com Cc: ppvpn@nortelnetworks.com Subject: RE: VPLS model for L2VPN Framework document Date: Thu, 29 May 2003 17:33:31 +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" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Eric Is the sole purpose of the untagged VPLS instance to carry service provider BPDUs? If so there aren't any security concerns as all other untagged frames can simply be dropped. However, I think the general term "untagged packets" is misleading: - a further distinct VPLS instance is used to carry the "untagged packets" of the emulated LAN. Perhaps replacing "untagged packets" with "Service provider BPDUs" would provide clarification on exactly what traffic can be carried using this VPLS instance? Richard > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 29 May 2003 15:29 > To: Spencer,R,Richard,XGH5 R > Cc: ppvpn@nortelnetworks.com > Subject: Re: VPLS model for L2VPN Framework document > > > > Richard> Is the intention here to create 1 VPLS control > instance (i) per > Richard> customer > > No. > > Richard> or (ii) per service provider network? > > Not necessarily limited to one per service provider network. > > However, this would be a deployment consideration, I think. > > Richard> what traffic will be carried over the control > VPLS? Untagged > Richard> customer frames or untagged service provider > frames, either way > Richard> this sounds like it may lead to security concerns. > > I think "untagged service provider frames" is the > answer. What is the > security concern? > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 12:59:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10032 for ; Thu, 29 May 2003 12:59:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TGwbK23364 for ; Thu, 29 May 2003 12:58:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TGwYK23922 for ; Thu, 29 May 2003 12:58:34 -0400 (EDT) Date: Thu, 29 May 2003 09:34:04 -0700 (PDT) From: Bernard Aboba To: richard.spencer@bt.com cc: jh@lohi.eng.song.fi, ppvpn@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > currently CEs are identified by a name, rather than MAC address > or port number, which is configured on the customer interface. OK. That name could then go into the User-Name attribute (along with other potential identification information) when an "Authorize Only" or "Call Check" service is requested. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 13:03:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10222 for ; Thu, 29 May 2003 13:03:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TH36K13062 for ; Thu, 29 May 2003 13:03:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TH33h17334 for ; Thu, 29 May 2003 13:03:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16086.15530.629006.825510@harjus.eng.song.fi> Date: Thu, 29 May 2003 20:00:26 +0300 To: Bernard Aboba Cc: richard.spencer@bt.com, ppvpn@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bernard Aboba writes: > OK. That name could then go into the User-Name attribute (along with > other potential identification information) when an > "Authorize Only" or "Call Check" service is requested. my opinion is that security is improved when pe must know both the name and password of the ce also in the case when they are configured in the pe rather than learned from the ce. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 13:23:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10930 for ; Thu, 29 May 2003 13:23:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4THN3K18434 for ; Thu, 29 May 2003 13:23:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4THN1p21414 for ; Thu, 29 May 2003 13:23:01 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: richard.spencer@bt.com, erosen@cisco.com Cc: ppvpn@nortelnetworks.com Subject: RE: VPLS model for L2VPN Framework document Date: Thu, 29 May 2003 18:21: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" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Eric, The security concern I was thinking of is the possibility of a customer injecting untagged frames into the SP network via a trunk port. In an Ethernet switch all untagged frames arriving on a trunk port can either be dropped or forwarded on the native VLAN (where the forward or drop action is dependant on the implementation and configuration). If untagged customer frames are not dropped by default, then access lists would have to be used to ensure untagged customer frames were not forwarded on the untagged VPLS instance. This is probably an implementation issue rather than something that would need to be defined in the draft. Richard > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: 29 May 2003 17:34 > To: erosen@cisco.com > Cc: ppvpn@nortelnetworks.com > Subject: RE: VPLS model for L2VPN Framework document > > > Eric > > Is the sole purpose of the untagged VPLS instance to carry > service provider > BPDUs? If so there aren't any security concerns as all other > untagged frames > can simply be dropped. However, I think the general term > "untagged packets" > is misleading: > > - a further distinct VPLS instance is used to carry the > "untagged packets" > of the emulated LAN. > > Perhaps replacing "untagged packets" with "Service provider > BPDUs" would > provide clarification on exactly what traffic can be carried > using this VPLS > instance? > > Richard > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: 29 May 2003 15:29 > > To: Spencer,R,Richard,XGH5 R > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: VPLS model for L2VPN Framework document > > > > > > > > Richard> Is the intention here to create 1 VPLS control > > instance (i) per > > Richard> customer > > > > No. > > > > Richard> or (ii) per service provider network? > > > > Not necessarily limited to one per service provider network. > > > > However, this would be a deployment consideration, I think. > > > > Richard> what traffic will be carried over the control > > VPLS? Untagged > > Richard> customer frames or untagged service provider > > frames, either way > > Richard> this sounds like it may lead to security concerns. > > > > I think "untagged service provider frames" is the > > answer. What is the > > security concern? > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 13:32:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11293 for ; Thu, 29 May 2003 13:32:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4THWAK23211 for ; Thu, 29 May 2003 13:32:10 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4THW7c00905 for ; Thu, 29 May 2003 13:32:07 -0400 (EDT) Date: Thu, 29 May 2003 10:06:17 -0700 (PDT) From: Bernard Aboba To: Juha Heinanen cc: ppvpn@nortelnetworks.com Subject: Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt In-Reply-To: <16086.7216.901317.907490@harjus.eng.song.fi> Message-ID: References: <16077.49504.628040.94146@harjus.eng.song.fi> <16083.39624.280716.200879@lohi.eng.song.fi> <16086.7216.901317.907490@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > as i said in above, in most vpn implementations today, the ces doen't > identify them selves at all. in that respect my proposal in a big > improvement, because if the ce is 802.1x capable, it can identify > itself. In RADIUS "Call Check" or "Authorize Only" exchanges, the PE need not have an identification exchange with the CE. However, the PE still needs to identify the CE somehow in the RADIUS Access-Request. So even if there is no identity exchange, you still need to put something into the User-Name attribute. In a "Call Check" service that could be an L2 address (phone # or MAC address) or it could be a user name. Ideally it's the identity that you determine somehow by the alternative auth mechanism (e.g. OSPF MD5). From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 13:35:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11356 for ; Thu, 29 May 2003 13:35:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4THYnK26929 for ; Thu, 29 May 2003 13:34:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4THYkc05219 for ; Thu, 29 May 2003 13:34:46 -0400 (EDT) Date: Thu, 29 May 2003 10:08:17 -0700 (PDT) From: Bernard Aboba To: Juha Heinanen cc: richard.spencer@bt.com, ppvpn@nortelnetworks.com Subject: RE: call for discussion on draft-heinanen-radius-pe-discovery-03. txt In-Reply-To: <16086.15530.629006.825510@harjus.eng.song.fi> Message-ID: References: <16086.15530.629006.825510@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: internaut.com X-SMTP-MAIL-FROM: aboba@internaut.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.38.134.99] X-LYRIS-Message-Id: > my opinion is that security is improved when pe must know both > the name and password of the ce also in the case when they are > configured in the pe rather than learned from the ce. Not necessarily. The KDC model is to keep the secrets in a single well guarded place. Storing passwords on PEs around the network may not be the best way to guard against compromise. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 15:31:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16561 for ; Thu, 29 May 2003 15:31:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TJVQK10794 for ; Thu, 29 May 2003 15:31:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TJVMP03160 for ; Thu, 29 May 2003 15:31:22 -0400 (EDT) Reply-To: From: "Steven.Wright" To: , Cc: Subject: RE: VPLS model for L2VPN Framework document Date: Thu, 29 May 2003 15:28:55 -0400 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-SMTP-HELO: aismtp3g.bls.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp3g.bellsouth.com [139.76.165.193] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I'm not sure these are implementation only issues - I suspect most service providers have requirements to (i) use network assigned services instances for their own network management purposes and (ii) inject & remove OAM traffic for diagnostic purposes into vpls service instances Steven Wright > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Thursday, May 29, 2003 1:21 PM > To: richard.spencer@bt.com; erosen@cisco.com > Cc: ppvpn@nortelnetworks.com > Subject: RE: VPLS model for L2VPN Framework document > > > Eric, > > The security concern I was thinking of is the possibility of > a customer > injecting untagged frames into the SP network via a trunk port. In an > Ethernet switch all untagged frames arriving on a trunk port > can either be > dropped or forwarded on the native VLAN (where the forward or > drop action is > dependant on the implementation and configuration). If > untagged customer > frames are not dropped by default, then access lists would > have to be used > to ensure untagged customer frames were not forwarded on the > untagged VPLS > instance. This is probably an implementation issue rather > than something > that would need to be defined in the draft. > > Richard > > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: 29 May 2003 17:34 > > To: erosen@cisco.com > > Cc: ppvpn@nortelnetworks.com > > Subject: RE: VPLS model for L2VPN Framework document > > > > > > Eric > > > > Is the sole purpose of the untagged VPLS instance to carry > > service provider > > BPDUs? If so there aren't any security concerns as all other > > untagged frames > > can simply be dropped. However, I think the general term > > "untagged packets" > > is misleading: > > > > - a further distinct VPLS instance is used to carry the > > "untagged packets" > > of the emulated LAN. > > > > Perhaps replacing "untagged packets" with "Service provider > > BPDUs" would > > provide clarification on exactly what traffic can be carried > > using this VPLS > > instance? > > > > Richard > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: 29 May 2003 15:29 > > > To: Spencer,R,Richard,XGH5 R > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: VPLS model for L2VPN Framework document > > > > > > > > > > > > Richard> Is the intention here to create 1 VPLS control > > > instance (i) per > > > Richard> customer > > > > > > No. > > > > > > Richard> or (ii) per service provider network? > > > > > > Not necessarily limited to one per service provider network. > > > > > > However, this would be a deployment consideration, I think. > > > > > > Richard> what traffic will be carried over the control > > > VPLS? Untagged > > > Richard> customer frames or untagged service provider > > > frames, either way > > > Richard> this sounds like it may lead to security concerns. > > > > > > I think "untagged service provider frames" is the > > > answer. What is the > > > security concern? > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 17:24:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20566 for ; Thu, 29 May 2003 17:24:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TLNlK00759 for ; Thu, 29 May 2003 17:23:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TLNjA02752 for ; Thu, 29 May 2003 17:23:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20030529132331.01fae910@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 May 2003 14:21:38 -0700 To: mattsquire@acm.org, erosen@cisco.com From: Ali Sajassi Subject: Re: VPLS model for L2VPN Framework document Cc: ppvpn@nortelnetworks.com, Norman Finn In-Reply-To: <3ED56CAF.3080609@acm.org> References: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-3.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-3.cisco.com [171.68.223.137] X-LYRIS-Message-Id: > > >So this is where I may (or may not) offer a different opinion from Norm >and/or Ali. I continue to be of the opinion that the "emulated LAN" (e.g. >VPLS) should look like a LAN to the bridge function, which implies (to me >anyway) that > a) if that VPLS is provisioned as a trunk port to the bridge, then there > are multiple VLANs per VPLS (not one VPLS/vlan) - this is after all how a > bridge views a non-emulated trunk port Considering a VPLS as an "emulated LAN" with respect to the bridge, is certainly another model. However, the issue of handling inter-island and inter-provider loop prevention as well as scalability of expanding # of VLANs across different islands and providers become much more challenging (e.g., running STP between different islands and different providers for tens of thousands of customers). In the model that considers a VPLS as emulated VLANs, the L3 connection of the PE to the core is considered as a single trunk port and thus split-horizon mechanism serves as a loop prevention mechanism for the emulated VLANs. > b) if that VPLS is provisioned as an access port to the bridge, then > there is only one VLAN per VPLS (though as with tag stacking, one > "carrier" VLAN may not equal one "customer" VLAN). A PW can certainly be considered as a trunk or access port >To me, this keeps the terminology and model incredibly consistent to >the existing briding models. If you consider, the L3 connectivity of a PE to the core as a trunk port with each VPLS instance as a VLAN over this trunk port, then the operation of this model would be consistent as well with the existing bridging model. >Using a separate VPLS instance for discovery and setup (as discussed >below) creates a likely opportunity of the 'discovery' VPLS being in a >different state than the 'data' VPLS, which of course would screw >everything up. It also creates the necessity for some VPLS >coordination so that the bridge sees multiple VPLSs as a single LAN >port. E.g. if the "untagged" VPLS does not come up (not enough labels or >whatever), do the others go down? What of some of the others don't come >up, should the untagged VPLS go down? I get the willies thinking about >the possibilities. Yes, we discussed these issues and some of the potential solutions sometime back. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 17:33:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21120 for ; Thu, 29 May 2003 17:33:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TLWDK05493 for ; Thu, 29 May 2003 17:32:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TLVgN08655 for ; Thu, 29 May 2003 17:31:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030529142226.02057480@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 May 2003 14:29:33 -0700 To: Muneyoshi Suzuki , erosen@cisco.com From: Ali Sajassi Subject: Re: VPLS model for L2VPN Framework document Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp In-Reply-To: <20030529.114748.71129538.suzuki.muneyoshi@lab.ntt.co.jp> References: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-3.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-3.cisco.com [171.68.223.137] X-LYRIS-Message-Id: > >I thought the framework model was that the PE contain a single Bridge. >Certainly, if it contains multiple Bridges, it is impossible to run >an MSTP instance among the Bridges. However, why multiple Bridges are >needed in a single PE? If it is single, I think there is no problem. With respect to IEEE, the proper model is single bridge in a PE; however, if Ethernet access network is not used or IEEE control protocols is not used in the MPLS/IP access network, then one can use multiple bridges model where each bridge is simple 1980-style bridge (e.g., VSI). Although the later model is not recommended because of its restrictions. -Ali >Thanks, > > >Muneyoshi Suzuki >Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 17:36:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21298 for ; Thu, 29 May 2003 17:36:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TLaGK09084 for ; Thu, 29 May 2003 17:36:16 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TLaDN14953 for ; Thu, 29 May 2003 17:36:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20030529143000.0204b638@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 May 2003 14:34:21 -0700 To: "Mark Seery" , From: Ali Sajassi Subject: RE: VPLS model for L2VPN Framework document In-Reply-To: References: <3ED56CAF.3080609@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-4.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-4.cisco.com [171.68.223.138] X-LYRIS-Message-Id: At 06:16 AM 5/29/2003 -0700, Mark Seery wrote: >Some questions: > >1) Is a VPLS subscriber not allowed to send frames that are already >formatted as a "stacked VLAN"? No, it is allowed. >2) In the model where the SP only has one VPLS, and each subscriber is a >VLAN, how many VLANs can be supported? I don't know if anyone is suggesting such model; however, one model is one VPLS instance per subscriber and in a given island Ethernet island a subscriber maps into a VLAN. So the number of subscribers in a given island is limited to 4K but not in the network since the network can consist of many islands join together with a set of PWs. -Ali >3) What are the scaling limitations/determinants of the model where the SP >has one VPLS for all subscribers? > >Thanks, >Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 17:40:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21488 for ; Thu, 29 May 2003 17:40:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TLeDK13010 for ; Thu, 29 May 2003 17:40:14 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TLeAN19257 for ; Thu, 29 May 2003 17:40:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20030529143549.0204aa30@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 May 2003 14:38:16 -0700 To: richard.spencer@bt.com, erosen@cisco.com From: Ali Sajassi Subject: RE: VPLS model for L2VPN Framework document Cc: ppvpn@nortelnetworks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-4.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-4.cisco.com [171.68.223.138] X-LYRIS-Message-Id: At 05:33 PM 5/29/2003 +0100, richard.spencer@bt.com wrote: >Eric > >Is the sole purpose of the untagged VPLS instance to carry service provider >BPDUs? Basically yes. >If so there aren't any security concerns as all other untagged frames >can simply be dropped. However, I think the general term "untagged packets" >is misleading: > >- a further distinct VPLS instance is used to carry the "untagged packets" > of the emulated LAN. > >Perhaps replacing "untagged packets" with "Service provider BPDUs" would >provide clarification on exactly what traffic can be carried using this VPLS >instance? Or we can say "SP untagged packets - e.g., BPDUs". -Ali >Richard > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: 29 May 2003 15:29 > > To: Spencer,R,Richard,XGH5 R > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: VPLS model for L2VPN Framework document > > > > > > > > Richard> Is the intention here to create 1 VPLS control > > instance (i) per > > Richard> customer > > > > No. > > > > Richard> or (ii) per service provider network? > > > > Not necessarily limited to one per service provider network. > > > > However, this would be a deployment consideration, I think. > > > > Richard> what traffic will be carried over the control > > VPLS? Untagged > > Richard> customer frames or untagged service provider > > frames, either way > > Richard> this sounds like it may lead to security concerns. > > > > I think "untagged service provider frames" is the > > answer. What is the > > security concern? > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 17:46:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21789 for ; Thu, 29 May 2003 17:46:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4TLjsK17769 for ; Thu, 29 May 2003 17:45:54 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4TLjoQ25843 for ; Thu, 29 May 2003 17:45:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20030529143912.02059438@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 May 2003 14:43:15 -0700 To: richard.spencer@bt.com, richard.spencer@bt.com, erosen@cisco.com From: Ali Sajassi Subject: RE: VPLS model for L2VPN Framework document Cc: ppvpn@nortelnetworks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-3.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-3.cisco.com [171.68.223.137] X-LYRIS-Message-Id: At 06:21 PM 5/29/2003 +0100, richard.spencer@bt.com wrote: >Eric, > >The security concern I was thinking of is the possibility of a customer >injecting untagged frames into the SP network via a trunk port. In an >Ethernet switch all untagged frames arriving on a trunk port can either be >dropped or forwarded on the native VLAN (where the forward or drop action is >dependant on the implementation and configuration). If untagged customer >frames are not dropped by default, then access lists would have to be used >to ensure untagged customer frames were not forwarded on the untagged VPLS >instance. This is probably an implementation issue rather than something >that would need to be defined in the draft. The control VPLS is only for SP use and there shouldn't be any leak of customers' frames into this VPLS. If there is, then there is an intentional config error. -Ali >Richard > > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: 29 May 2003 17:34 > > To: erosen@cisco.com > > Cc: ppvpn@nortelnetworks.com > > Subject: RE: VPLS model for L2VPN Framework document > > > > > > Eric > > > > Is the sole purpose of the untagged VPLS instance to carry > > service provider > > BPDUs? If so there aren't any security concerns as all other > > untagged frames > > can simply be dropped. However, I think the general term > > "untagged packets" > > is misleading: > > > > - a further distinct VPLS instance is used to carry the > > "untagged packets" > > of the emulated LAN. > > > > Perhaps replacing "untagged packets" with "Service provider > > BPDUs" would > > provide clarification on exactly what traffic can be carried > > using this VPLS > > instance? > > > > Richard > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: 29 May 2003 15:29 > > > To: Spencer,R,Richard,XGH5 R > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: VPLS model for L2VPN Framework document > > > > > > > > > > > > Richard> Is the intention here to create 1 VPLS control > > > instance (i) per > > > Richard> customer > > > > > > No. > > > > > > Richard> or (ii) per service provider network? > > > > > > Not necessarily limited to one per service provider network. > > > > > > However, this would be a deployment consideration, I think. > > > > > > Richard> what traffic will be carried over the control > > > VPLS? Untagged > > > Richard> customer frames or untagged service provider > > > frames, either way > > > Richard> this sounds like it may lead to security concerns. > > > > > > I think "untagged service provider frames" is the > > > answer. What is the > > > security concern? > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 21:04:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01481 for ; Thu, 29 May 2003 21:04:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U13WK12641 for ; Thu, 29 May 2003 21:03:32 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U13Qf29726 for ; Thu, 29 May 2003 21:03:27 -0400 (EDT) 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: multi-link CE-PE connections Date: Thu, 29 May 2003 18:01:11 -0700 Message-ID: Thread-Topic: multi-link CE-PE connections Thread-Index: AcMmRvY5Nuv4PVjAQo2jBd2RUEoQUQ== From: "Shanthi Pendyala" To: X-SMTP-HELO: claven.luminous.com X-SMTP-MAIL-FROM: spendyala@luminous.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.luminous.com [63.150.47.131] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA01481 hi, what is recommended way to support/detect the following VPLS (mis)configuration. For simplicity assume Ethernet attachment circuits. ------------------------- | PE | | | ------------------------ P1/ \ P2 / \ ------------------ | HUB | ----------------- | | ---------------- | CE | -------------- 1: it is a misconfiguration. don't do it 2: vendors are running proprietary link-level protocols to break the local loop (P1<->P2) at the PE. one of the ports (P1 or P2) is blocked at any one time.. 3: what if it is not a misconfiguration but customers want to do this intentionally to provide redundant PE-CE links ? Thank you shanthi kiran Luminous Networks Cupertino CA From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 23:21:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06703 for ; Thu, 29 May 2003 23:21:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U3L3005706 for ; Thu, 29 May 2003 23:21:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U3L0c23022 for ; Thu, 29 May 2003 23:21:00 -0400 (EDT) Message-ID: <3ED6CD65.1040004@acm.org> Date: Thu, 29 May 2003 23:17:57 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en, pdf MIME-Version: 1.0 To: richard.spencer@bt.com CC: erosen@cisco.com, ppvpn@nortelnetworks.com, nfinn@cisco.com Subject: Re: VPLS model for L2VPN Framework document References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rrcs-midsouth-24-199-201-22.biz.rr.com [24.199.201.22] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit richard.spencer@bt.com wrote: > > So this is where I may (or may not) offer a different > > opinion from Norm > > and/or Ali. I continue to be of the opinion that the "emulated LAN" > > (e.g. VPLS) should look like a LAN to the bridge function, > > which implies > > (to me anyway) that > > a) if that VPLS is provisioned as a trunk port to the bridge, then > > there are multiple VLANs per VPLS (not one VPLS/vlan) - this > > is after > > all how a bridge views a non-emulated trunk port > > b) if that VPLS is provisioned as an access port to the > > bridge, then > > there is only one VLAN per VPLS (though as with tag stacking, one > > "carrier" VLAN may not equal one "customer" VLAN). > > To me, this keeps the terminology and model incredibly > > consistent to the > > existing briding models. > > [RS] This seems to me to be a more attractive option. However, if a single > VPLS instance is allowed to carry multiple VLANs then customer frames must > carry a VLAN ID so that the receiving PE can determine which VLAN a frame > belongs to. Thats the whole idea (at least to me). The VPLS is treated by the forwarding entities just like an Etherne segment, and can carry tagged or untagged traffic depending on how the ports are configured. > > I seem to remember a debate about whether customer frames should have their > VLAN information stripped of or not. Can anyone tell me if there was a > conclusion to that debate and what the reason was for removing the VLAN tag > was? Was it simply to save bandwidth? > As I recall it was so neither side had to care if they used the same tags for the same VLANs. The BW difference is minimal. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 23:23:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06740 for ; Thu, 29 May 2003 23:23:03 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U3MW007700 for ; Thu, 29 May 2003 23:22:33 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U3MTc25266 for ; Thu, 29 May 2003 23:22:30 -0400 (EDT) Message-ID: <3ED6CD59.6060808@acm.org> Date: Thu, 29 May 2003 23:17:45 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en, pdf MIME-Version: 1.0 To: erosen@cisco.com CC: ppvpn@nortelnetworks.com, Norman Finn Subject: Re: VPLS model for L2VPN Framework document References: <200305291426.h4TEQkFV015392@rtp-core-1.cisco.com> In-Reply-To: <200305291426.h4TEQkFV015392@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rrcs-midsouth-24-199-201-22.biz.rr.com [24.199.201.22] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric Rosen wrote: > Matt> So this is where I may (or may not) offer a different opinion from > Matt> Norm and/or Ali. > > Well, trying to figure out when the bridge experts are agreeing and when > they are disagreeing is one of the challenges we face ;-) I can't always agree with Norm - he works with you! And if you start making fun of me for disagreeing with people... well I'm just not sure if I'm the kettle or the pot. > > Matt> Using a separate VPLS instance for discovery and setup (as discussed > Matt> below) creates a likely opportunity of the 'discovery' VPLS being in a > Matt> different state than the 'data' VPLS, which of course would screw > Matt> everything up. > > I think the vision here is that a service provider's network might consist > of several Q-in-Q islands, where some VPLS instances are intra-island, some > are inter-island, and some are inter-provider. However, an MSTP instance > would always be intra-island, by definition. I'm not sure how your model > handles this. > And thats fine for me as well. xSTP is a protocol that may run over LANs. If you have a inter-provider VPLS and choose not to run xSTP over it, thats ok. xSTP is enabled/disabled per VPLS port (e.g. PE) just as it would be for a real LAN. > However, I don't think anything in my proposed writeup prevents you from > setting up a single VPLS instance which contains multiple VLANs, though > there is the question of how the encapsulation would distinguish the VLANs. > Well, you said that the control traffic is separate from the data traffic, which is a huge difference than how LANs operate today. I'll admit - I'm a coward. Trying to coordinate multiple VPLS instances to create an "emulated LAN" is a scary proposition in light of the abundance of failure scenarios where not every VPLS is in that emulated LAN is working as well as every other. Seems like a rathole to avoid. - Matt From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu May 29 23:50:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07241 for ; Thu, 29 May 2003 23:50:44 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U3oEn10868 for ; Thu, 29 May 2003 23:50:14 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U3oBB02486 for ; Thu, 29 May 2003 23:50:11 -0400 (EDT) Message-ID: <3ED6D22C.7090407@acm.org> Date: Thu, 29 May 2003 23:38:20 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en, pdf MIME-Version: 1.0 To: Ali Sajassi CC: erosen@cisco.com, ppvpn@nortelnetworks.com, Norman Finn Subject: Re: VPLS model for L2VPN Framework document References: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <4.3.2.7.2.20030529132331.01fae910@airborne.cisco.com> In-Reply-To: <4.3.2.7.2.20030529132331.01fae910@airborne.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rrcs-midsouth-24-199-201-22.biz.rr.com [24.199.201.22] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali Sajassi wrote: > >> >> >> So this is where I may (or may not) offer a different opinion from >> Norm and/or Ali. I continue to be of the opinion that the "emulated >> LAN" (e.g. VPLS) should look like a LAN to the bridge function, which >> implies (to me anyway) that >> a) if that VPLS is provisioned as a trunk port to the bridge, then >> there are multiple VLANs per VPLS (not one VPLS/vlan) - this is after >> all how a bridge views a non-emulated trunk port > > > Considering a VPLS as an "emulated LAN" with respect to the bridge, is > certainly another model. However, the issue of handling inter-island and > inter-provider loop prevention as well as scalability of expanding # of > VLANs across different islands and providers become much more > challenging (e.g., running STP between different islands and different > providers for tens of thousands of customers). > In the model that considers a VPLS as emulated VLANs, the L3 connection > of the PE to the core is considered as a single trunk port and thus > split-horizon mechanism serves as a loop prevention mechanism for the > emulated VLANs. > This "emulated LAN == LAN" is the traditional model used by emulated LANs over frame relay and emulated LANs over ATM. "Emulated LAN = VLAN" is a model supported by "emulated LAN = LAN" because many LAN ports (access ports) have only a single VLAN. But what it doesn't do is introduce separate control and data planes. Maybe its just me, but bridged networks have limits. They always have. They weren't designed or intended to provide limitless worldwide connectivity. They're designed for simplicity, flexibility, and and loop-free connectivity. Global scaling was not one of the criteria. Thats why routers came along. Geez, you work for Cisco, you have to appreciate that. > >> b) if that VPLS is provisioned as an access port to the bridge, then >> there is only one VLAN per VPLS (though as with tag stacking, one >> "carrier" VLAN may not equal one "customer" VLAN). > > > A PW can certainly be considered as a trunk or access port Assuming that PW is used as an P2P emulated LAN, sure. > >> To me, this keeps the terminology and model incredibly consistent to >> the existing briding models. > > > If you consider, the L3 connectivity of a PE to the core as a trunk port > with each VPLS instance as a VLAN over this trunk port, then the > operation of this model would be consistent as well with the existing > bridging model. > Well, no. On a briding port, the control and data plane are tied togehe. A VLAN VPLS can fail without the control VPLS failing, or vice versa. Thats pretty inconsistent with existing models. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 00:31:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07873 for ; Fri, 30 May 2003 00:31:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U4Urn26739 for ; Fri, 30 May 2003 00:30:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U4Uoo02439 for ; Fri, 30 May 2003 00:30:50 -0400 (EDT) Date: Fri, 30 May 2003 13:27:37 +0900 (JST) Message-Id: <20030530.132737.07596716.suzuki.muneyoshi@lab.ntt.co.jp> To: erosen@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: VPLS model for L2VPN Framework document From: Muneyoshi Suzuki In-Reply-To: <200305291412.h4TEC3FV011191@rtp-core-1.cisco.com> References: <20030529.114748.71129538.suzuki.muneyoshi@lab.ntt.co.jp> <200305291412.h4TEC3FV011191@rtp-core-1.cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > The way the framework document is written, it seems to suggest that an > "emulated LAN" is the as a "VPLS instance", which in turn suggests that a > single MSTP instance cannot govern multiple VPLS instances. So I just > wanted to make it clearer that an emulated LAN could consist of a set of > VPLS instances plus an MSTP instance; I think this would remove Mick's and > Norm's objection. It seems to me, something is still confusing. What is different between emulated LAN and VPLS instance? Could you clarify this? Regarding the framework model, if a single PE contains multiple logical Bridges, a single VPLS Forwarder cannot be shared by Bridges. In this case, a PE must contain multiple logical Bridges and VPLS Forwarders. Each Bridge may have a single MSTP instance, and the instances interwork through VPLS Forwarders. I can't see any problem in this model. (Needless to say, if the VPLS Forwarders is supported by full mesh, there is a big issue ;-) Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 00:43:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08013 for ; Fri, 30 May 2003 00:43:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U4h1n01380 for ; Fri, 30 May 2003 00:43:01 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U4gwo07957 for ; Fri, 30 May 2003 00:42:58 -0400 (EDT) Date: Fri, 30 May 2003 13:39:24 +0900 (JST) Message-Id: <20030530.133924.41674429.suzuki.muneyoshi@lab.ntt.co.jp> To: sajassi@cisco.com Cc: erosen@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: VPLS model for L2VPN Framework document From: Muneyoshi Suzuki In-Reply-To: <4.3.2.7.2.20030529142226.02057480@airborne.cisco.com> References: <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <20030529.114748.71129538.suzuki.muneyoshi@lab.ntt.co.jp> <4.3.2.7.2.20030529142226.02057480@airborne.cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, > With respect to IEEE, the proper model is single bridge in a PE; however, > if Ethernet access network is not used or IEEE control protocols is not > used in the MPLS/IP access network, then one can use multiple bridges model > where each bridge is simple 1980-style bridge (e.g., VSI). Although the > later model is not recommended because of its restrictions. I'm not sure relation ship between the above and MSTP issue in the framework model. If a Bridged LAN consists of 1980-style bridges that don't support xSTP, it is logically equivalent a LAN segment from a viewpoint of Bridges that support xSTP, so I think there is no xSTP related issue. I still don't understand the issue in the framework model. I'm still waiting answers to the following questions as I posted over two weeks ago. ---- (1) Could you clarify what the mistake is in the Eric's model, and and how your model resolved it? (2) Could you clarify what the right part from "A" means? I my understanding it must be a MAC entity or a part of a MAC relay entity that distributed PEs. (3) Could you clarify why the above model is consistent with the following Mick's interpretation of the Bridge protocol architecture. --- Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 03:24:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22667 for ; Fri, 30 May 2003 03:24:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U7O9n24974 for ; Fri, 30 May 2003 03:24:10 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U7O6J16865 for ; Fri, 30 May 2003 03:24:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: multi-link CE-PE connections Date: Fri, 30 May 2003 00:22:12 -0700 Message-ID: Thread-Topic: multi-link CE-PE connections Thread-Index: AcMmRvY5Nuv4PVjAQo2jBd2RUEoQUQANOAEw From: "Javier Antich" To: "Shanthi Pendyala" , X-OriginalArrivalTime: 30 May 2003 07:22:12.0455 (UTC) FILETIME=[304B5770:01C3267C] X-SMTP-HELO: RS-SC-EXC6.rs.riverstonenet.com X-SMTP-MAIL-FROM: Javier.Antich@riverstonenet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host13.riverstonenet.com [64.95.122.13] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA22667 I would make the hub to be a switch and run STP, and make the PE(s) tunnel its BPDUs, so that the switch receives on one link its own BPDUs, that would make the switch block one of the ports. Now, what if the customer switch does not configure properly STP, or just forgets to do it, you will have a funny (and dangerous) loop unless the PE is able to handle that situation. regards. Javier. __________________________________________________ Javier Antich Romaguera Systems Engineer Riverstone Networks EMEA e-mail: javier.antich@riverstonenet.com mobile: +34 639 218 428 __________________________________________________ -----Original Message----- From: Shanthi Pendyala [mailto:spendyala@luminous.com] Sent: viernes, 30 de mayo de 2003 3:01 To: ppvpn@nortelnetworks.com Subject: multi-link CE-PE connections hi, what is recommended way to support/detect the following VPLS (mis)configuration. For simplicity assume Ethernet attachment circuits. ------------------------- | PE | | | ------------------------ P1/ \ P2 / \ ------------------ | HUB | ----------------- | | ---------------- | CE | -------------- 1: it is a misconfiguration. don't do it 2: vendors are running proprietary link-level protocols to break the local loop (P1<->P2) at the PE. one of the ports (P1 or P2) is blocked at any one time.. 3: what if it is not a misconfiguration but customers want to do this intentionally to provide redundant PE-CE links ? Thank you shanthi kiran Luminous Networks Cupertino CA From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 03:50:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23845 for ; Fri, 30 May 2003 03:50:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4U7oOn00122 for ; Fri, 30 May 2003 03:50:24 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4U7oLq24973 for ; Fri, 30 May 2003 03:50:21 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: sajassi@cisco.com, erosen@cisco.com Cc: ppvpn@nortelnetworks.com Subject: RE: VPLS model for L2VPN Framework document Date: Fri, 30 May 2003 08:47:43 +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" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Ali > Or we can say "SP untagged packets - e.g., BPDUs". I still don't think that the above gives enough clarification. Packets are only tagged between trunk ports. An operator may have access ports connecting to different management networks that belong to different VLANs, e.g. VLAN 100 for management application X, and VLAN 200 for management application Y. Now, both of these access ports will receive untagged SP packets, but they will be destined for different VLANs. Both sets of SP untagged packets could not be sent over the same 'untagged VPLS instance' as they belong to different VLANs. Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 06:29:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26994 for ; Fri, 30 May 2003 06:29:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UAT3n28655 for ; Fri, 30 May 2003 06:29:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UAT1728944 for ; Fri, 30 May 2003 06:29:01 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: ppvpn@nortelnetworks.com Cc: jh@lohi.eng.song.fi, aboba@internaut.com Subject: draft-heinanen-radius-pe-discovery: Summary Date: Fri, 30 May 2003 11:25:21 +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" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: As a result of issues that have been raised, Juha has agreed to make a number of changes to the RADIUS discovery draft. It has also been agreed that the draft will be refined and additions made as work progresses. The changes to be made as work progresses are minor issues rather than objections to the draft becoming a WG document. Some of which are concerned with CE authentication rather than actual VPN endpoint discovery. As its getting towards the end of the 2 week discussion period, are there any objections to the draft becoming a WG document? Or indeed, following the issues that have been raised and resolved, are there any individuals that would like to express their support that haven't done so yet? A summary of the changes Juha has agreed to make to the draft and changes that will be investigated as work progresses are summarised below: AGREED CHANGES TO THE DRAFT: ============================ 1. "Requirement that RADIUS servers be stateful" - Agreed to add a statement to this effect in the next version of the draft. 2. "Incorrect use of interim accounting" - Agreed to replace interim accounting with re-authentication in the next version of the draft. 3. "Exponential backoff is required to support a large number of VPN sites" - The draft currently states that PEs should use exponential backoff. Future versions of the discovery draft could reference the new AAA draft described by Bernard that will provide details of exponential backoff behaviour in RADIUS. 4. In the following paragraph: "If a PE wants for some reason to get from Radius an up-to-date list of PEs in a particular VPN, it can at any time issue a new Access-Request for any one of its CEs that belongs to the VPN." - Make it clear that the intent is for the CE to re-authenticate as part of the Access-Request. 5. "Use of RADIUS for CE-based VPNs" - Agreed to remove this reference as it is confusing and not within the scope of the draft. REFINEMENTS/ADDITIONS AS WORK PROGRESSES: ========================================= 1. "Include potential mitigating measures in the Security Considerations section" - Security considerations such as those in RFC2868 and draft-aboba-radius-rfc2869bis-22.txt could be incorporated or referenced in the next version of the draft. 2. "Use of re-authentication (instead of interim accounting)" - Investigate the use of re-authorisation (as described in draft-chiba) instead of re-authentication for this purpose. 3. "Re-use of existing attributes in RFC2868" - Agreed to consider using "Tunnel-Client-Endpoint" and "Tunnel-Server Endpoint" attributes for carrying PE IP addresses. - Agreed to consider using "Tunnel-Assignment-ID" and/or "Tunnel-Private-Group-ID" attributes for carrying VPN ID. 4. "Multiple tunnels for the same VPN using RFC2868" - Need to investigate how by using RFC2868 attributes multiple tunnels can be supported, taking into consideration the way the 'Tunnel-Preference' attribute is currently used to select a single tunnel. 5. "CE Identifier" - As this has not been discussed within the PPVPN, the CE Identifier (e.g. port, MAC address, name, IP address, etc) needs to be determined, or to be agreed that it is up to the service provider to choose a suitable CE ID. 6. "Use of 'Call Check' and 'Authorise Only' - Decide whether Call Check/Authorise Only should be used in an Access-Request instead of authentication using CE name and password. This also involves the issue of storing passwords on PEs instead of in a single place. 7. "Re-authentication initiation" - Existing mechanisms such as Session-Time and CoA-Request will be investigated and incorporated to control re-authentication. Thanks, Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 09:57:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07680 for ; Fri, 30 May 2003 09:57:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UDuen00823 for ; Fri, 30 May 2003 09:56:40 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UDubq07994 for ; Fri, 30 May 2003 09:56:37 -0400 (EDT) Message-ID: <3j$5u$49j14070yr@33f3r9.5f> From: "Constance Swanson" To: , Subject: GIA'S pics xey lzcdifn d Date: Fri, 30 May 03 17:48:47 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="9C_ED44299BDE__FC" X-SMTP-HELO: c-66-177-16-77.se.client2.attbi.com X-SMTP-MAIL-FROM: wohu6u4rnl98@aol.com X-SMTP-RCPT-TO: postmaster@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: c-66-177-16-77.se.client2.attbi.com [66.177.16.77] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --9C_ED44299BDE__FC Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I hope this is apostmaster@nortelnetworks.com ... Here are the snapshot from my c@m last ni= ght




This will piss off my dink BF!!
I hope I got your address right
XOXOXOXOXOXOXOX
beam me of= f scotty jsub ubwnj --9C_ED44299BDE__FC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 10:02:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07898 for ; Fri, 30 May 2003 10:02:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UE25n17606 for ; Fri, 30 May 2003 10:02:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UE23927336 for ; Fri, 30 May 2003 10:02:03 -0400 (EDT) Message-Id: <200305301358.JAA07737@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ppvpn@nortelnetworks.com From: The IESG Subject: Document Action: A Framework for Layer 3 Provider Provisioned Virtual Private Networks to Informational (revised) Date: Fri, 30 May 2003 09:58:38 -0400 Sender: mlee@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: mlee@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: The IESG has approved 'A Framework for Layer 3 Provider Provisioned Virtual Private Networks' as an Informational RFC. This document is the product of the Provider Provisioned Virtual Private Networks Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. ======== RFC Editor Note: Section 4.2.1.1, 1st paragraph Replace OLD: VPN configuration information could be entered into the network management application and distributed via SNMP, XML, CLI, or other means to the remote sites. With NEW: VPN configuration information could be entered into a network management application and distributed to the remote sites via the same means used to distribute other network management information. ---------------------------------------------- Section 4.3.6.2, 6th paragraph (5th item) Replace OLD: An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. With NEW: An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. ---------------------------------------------- Section 4.7.1, 4th paragraph Replace OLD: Use of proprietary command-line interfaces is highly undesirable for this task, as they do not lend themselves to standard representations of managed objects. With NEW: Use of proprietary command-line interfaces has the disadvantage that proprietary interfaces do not lend themselves to standard representations of managed objects. ---------------------------------------------- Section 5.2, 3rd paragraph DELETE OLD: With layer 3 VPNs it is normal for PEs to have a physical link per VPN. In this case the PEs which terminate the interworking interface have a tunnel per VPN. ---------------------------------------------- Intellectual Property, 1st paragraph Replace OLD: The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. With NEW: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 10:26:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10216 for ; Fri, 30 May 2003 10:26:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UEQ5n24455 for ; Fri, 30 May 2003 10:26:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UEQ2t04585 for ; Fri, 30 May 2003 10:26:02 -0400 (EDT) Message-Id: <4.3.2.20030529212843.02aff388@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 30 May 2003 10:21:33 -0400 To: The IESG , Internet Architecture Board , ppvpn@nortelnetworks.com From: Ross Callon Subject: Re: Document Action: A Framework for Layer 3 Provider Provisioned Virtual Private Networks to Informational In-Reply-To: <200305291347.JAA03419@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: rcallon@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: At 09:47 AM 5/29/2003 -0400, The IESG wrote: >... >Alex: >Generally, I liked this document _much_ better than the >requirements doc, Ross did a great job, still it needs >more work, I believe. Muneyoshi and the other co-authors deserve a lot of credit also. This was a team effort. Ross From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 10:29:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10307 for ; Fri, 30 May 2003 10:29:21 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UESon28626 for ; Fri, 30 May 2003 10:28:50 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UESlt09008 for ; Fri, 30 May 2003 10:28:47 -0400 (EDT) Message-Id: <200305301425.h4UEPsFV008854@rtp-core-1.cisco.com> To: richard.spencer@bt.com cc: ppvpn@nortelnetworks.com Subject: Re: VPLS model for L2VPN Framework document In-reply-to: Your message of Thu, 29 May 2003 18:21:01 +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: Fri, 30 May 2003 10:25:54 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Richard> The security concern I was thinking of is the possibility of a Richard> customer injecting untagged frames into the SP network via a trunk Richard> port. I'm not sure I see what this has to do with VPLS. I'd have thought that SPs don't let their customers inject untagged frames into the SP network via a trunk port. If they do, there seems to be a security problem whether or not VPLS is in use. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 10:44:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11045 for ; Fri, 30 May 2003 10:44:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UEhwn04128 for ; Fri, 30 May 2003 10:43:58 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UEhqb18297 for ; Fri, 30 May 2003 10:43:52 -0400 (EDT) Message-Id: <200305301441.h4UEf4FV014137@rtp-core-1.cisco.com> To: mattsquire@acm.org cc: ppvpn@nortelnetworks.com, Norman Finn Subject: Re: VPLS model for L2VPN Framework document In-reply-to: Your message of Thu, 29 May 2003 23:17:45 -0400. <3ED6CD59.6060808@acm.org> 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, 30 May 2003 10:41:04 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Matt> if you start making fun of me for disagreeing with people... The problem is not that the L2 guys may disagree, it's that it's so hard (for me) to tell whether they disagree or not ;-) Eric> I think the vision here is that a service provider's network might Eric> consist of several Q-in-Q islands, where some VPLS instances are Eric> intra-island, some are inter-island, and some are inter-provider. Eric> However, an MSTP instance would always be intra-island, by definition. Eric> I'm not sure how your model handles this. Matt> And thats fine for me as well. xSTP is a protocol that may run over Matt> LANs. If you have a inter-provider VPLS and choose not Matt> to run xSTP over it, thats ok. xSTP is enabled/disabled per VPLS port Matt> (e.g. PE) just as it would be for a real LAN. So, if a PE has to support an inter-provider VPLS and an intra-provider VPLS, it would then need to contain two virtual bridges, one for each VPLS? That seems more like my original model, which I thought you didn't agree with either ;-) From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 12:40:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15727 for ; Fri, 30 May 2003 12:40:16 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UGdjn22656 for ; Fri, 30 May 2003 12:39:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UGdg325136 for ; Fri, 30 May 2003 12:39:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030530090757.020733d0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 09:37:27 -0700 To: mattsquire@acm.org, Ali Sajassi From: Ali Sajassi Subject: Re: VPLS model for L2VPN Framework document Cc: erosen@cisco.com, ppvpn@nortelnetworks.com, Norman Finn In-Reply-To: <3ED6D22C.7090407@acm.org> References: <4.3.2.7.2.20030529132331.01fae910@airborne.cisco.com> <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <4.3.2.7.2.20030529132331.01fae910@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 11:38 PM 5/29/2003 -0400, Matt Squire wrote: >Ali Sajassi wrote: >> >>> >>> >>>So this is where I may (or may not) offer a different opinion from Norm >>>and/or Ali. I continue to be of the opinion that the "emulated LAN" >>>(e.g. VPLS) should look like a LAN to the bridge function, which implies >>>(to me anyway) that >>> a) if that VPLS is provisioned as a trunk port to the bridge, then >>> there are multiple VLANs per VPLS (not one VPLS/vlan) - this is after >>> all how a bridge views a non-emulated trunk port >> >>Considering a VPLS as an "emulated LAN" with respect to the bridge, is >>certainly another model. However, the issue of handling inter-island and >>inter-provider loop prevention as well as scalability of expanding # of >>VLANs across different islands and providers become much more challenging >>(e.g., running STP between different islands and different providers for >>tens of thousands of customers). >>In the model that considers a VPLS as emulated VLANs, the L3 connection >>of the PE to the core is considered as a single trunk port and thus >>split-horizon mechanism serves as a loop prevention mechanism for the >>emulated VLANs. > >This "emulated LAN == LAN" is the traditional model used by emulated LANs >over frame relay and emulated LANs over ATM. > >"Emulated LAN = VLAN" is a model supported by "emulated LAN = LAN" because >many LAN ports (access ports) have only a single VLAN. But what it >doesn't do is introduce separate control and data planes. The bridge module of the PE doesn't see separate control and data paths. It sees a single port over which both control and data traffic gets sent. >Maybe its just me, but bridged networks have limits. They always >have. They weren't designed or intended to provide limitless worldwide >connectivity. They're designed for simplicity, flexibility, and and >loop-free connectivity. Global scaling was not one of the criteria. What ! Have you talked to any SP regarding their VPLS requirements !! On the contrary global scaling is one of the major criteria for VPLS. The SPs are not only asking for the support of large number of customers within a metro region but also asking for much larger number across their metro regions. >Thats why routers came along. Geez, you work for Cisco, you have to >appreciate that. Using VPLS as a low cost access into a L3VPN is certainly a viable model and option at SP's disposal. But that's not what SP have in mind when they talk about using VPLS end-to-end. >>If you consider, the L3 connectivity of a PE to the core as a trunk port >>with each VPLS instance as a VLAN over this trunk port, then the >>operation of this model would be consistent as well with the existing >>bridging model. > >Well, no. On a briding port, the control and data plane are tied >togehe. A VLAN VPLS can fail without the control VPLS failing, or vice >versa. Thats pretty inconsistent with existing models. Bridge module sees them tied together even though at PW level they are not tied together. And the better the failure detection/recovery mechanism, the more negligible this difference looks to the bridge module. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 12:53:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16547 for ; Fri, 30 May 2003 12:53:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UGrBn27522 for ; Fri, 30 May 2003 12:53:11 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UGr7807272 for ; Fri, 30 May 2003 12:53:07 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Vasile Radoaca" , "Dinesh Mohan" , "Ppvpn" , "Rick Wilder" Subject: RE: decisions on L2 solutions documents Date: Fri, 30 May 2003 09:49:56 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6C5B@zbl6c002.corpeast.baynetworks.com> X-OriginalArrivalTime: 30 May 2003 16:49:45.0465 (UTC) FILETIME=[79784E90:01C326CB] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,mohand@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vasile, Dinesh, Some comments below. I've tried to identify Rick's, Vasile's and my comments. Outlook may mess the whole thing up, so apologies in advance. -Vach Rick>> Here are the questions/requests-for-clarification that came up. Rick>> a) how do the discovery and signaling parts of the document Rick>> relate to those described in the other solutions documents and which Rick>> of them are suggested to be mandatory to implement VR> > vasile VR> There are couple of assumptions that need to be taken in consideration: VR> 1) VR> The GVPLS model, as a distributed model, needs to have a signaling mechanism that allows PW to be VR> identified by VPN-ID, and the End Points together. The pwe3-control-protocol-02.txt draft, with VR> Rosen's extensions to the PW Signaling mechanism address this problem. Vach>> As a matter of fact, Rosen's signaling separately identifies the PW and the VPN. Think of the Vach>> VPNID as a collection of PWs, and think of the SAII, TAII between a pair of PEs as the PW Vach>> identifier. So, if you want to use the Rosen model, why write your own draft? VR> 2) VR> The GVPLS model is defined as an extension of the VPLS model, as HVPLS is defined as an extension of VR> it in order to optimize some of the parameters (e.g. VC-Label) VR> There are two ways to mitigate these two elements: VR> a) the lasserre-vkompella-vpls draft includes the Rosen's signaling model, but it used only for non VR> distributed model. In this case, GVPLS would be built using Rosen's mechanism VR> b) extends the current vpls signaling mechanism to include the components needed for the distributed VR> model VR> We had intensive discussions between the authors of vpls, gvpls and rosen's proposals to achieve a VR> reasonable compromise. Unfortunately, at this point in time, the authors of the lasserre-vkompella VR> draft didn't consider to include Rosen's signaling mechanism. As such, based on assumption 2) we VR> decided for GVPLS to extend the current vpls signaling mechanism. However, the model is transparent VR> to such extensions, should a decision would be taken in favor of Rosen's signaling, then GVPLS VR> solution can accommodate it. VR> Regarding the signaling protocol: the current draft has a default model, the LDP protocol. However, VR> the BGP signaling is presented as an alternative. Our current resolution is the following: LDP is VR> mandatory for GVPLS. Vach>> There are two issues here. The first is whether we need a separate model for distributed VPLS or Vach>> not. The second is whether we need a VPN ID. Vach>> To the first point, Ali and Eric have described how to use p2p PWs in conjuction with a learning Vach>> bridge in the position of the MTU to make a distributed VPLS node. I don't think we need to have Vach>> another way to create a distributed VPLS node. Vach>> To the second point, the primary difference between the Rosen draft and the HVPLS draft is in Vach>> naming the PWs, not in naming the VPN ID. The issue of using a globally unique name for the VPLS Vach>> has been discussed. In an attempt to keep the signaling compatible with draft-martini, we agreed Vach>> on using a VCID. However, there was an intent all along to somehow make that identifier a Vach>> globally unique. Suggestions were made such as adding a VPN ID in the optional parameters field, Vach>> etc. My last proposal was to have a bona fide VPN ID TLV in the FEC. Vach>> Again, you mention that you would do draft-rosen. Why are you specifying a different protocol Vach>> then? Vach>> If LDP is mandatory, why do you feel it is necessary to describe BGP signaling in your draft? Vach>> What is different about your BGP signaling and draft-kompella? VR> The BGP signaling option would be defined in a separate draft. We would try to see how we can VR> accommodate our BGP signaling with draft-kompella-ppvpn-vpls-01 bgp model. VR> Regarding the discovery process: We recognize that an auto-discovery mechanism is needed for 3 VPLS VR> components: VR> - VPLS core [N-PE devices] VR> - VPLS access [U-PE devices] VR> - VPN Members/VPN End Points VR> However, the M2P PW model has a very nice property: the U-PE and VPN Members auto-discovery VR> processes can be combined with LDP signaling protocol. While the M2P is not mandatory, we considered VR> that it is worth to present such property and allow vendors to implement and interop. Vach>> Then define BGP in a separate draft. There is a claim that the informational model is the same Vach>> for BGP and LDP. However, there are a lot of different fields in the signaling that are Vach>> described in the LDP signaling. I don't know how you are going to add them to the BGP signaling. Vach>> Are the BGP signaling components such as label blocks and VE IDs or site identifiers part of the Vach>> informational model? Are the LDP signaling components Vach>> If draft-rosen is your model for LDP signaling, how are you going to keep gvpls interoperable Vach>> with HVPLS? Rick>> b) what is the status of the MAC-in-MAC encapsulation work in IEEE? VR> > vasile VR> A distributed model needs to have an access protocol that must comply with the Service address VR> scheme presented in GVPLS. VR> There are two models that can be used: PW (splice PW) or Mac-in-Mac. Mac-in-Mac protocol is not VR> mandatory. However, regarding it's status in IETF, the solution was socialized, and Nortel together VR> with other vendors/SPs are looking to present a solution draft in the next IEEE sessions. VR> From GVPLS perspective, Mac-in-Mac is just an option - it's shows that GVPLS is flexible enough to VR> adopt different access protocols, if the assumptions are respected. VR> Probable the best resolution for GVPLS would be to adopt the splice PW as the default model. Mac-in VR> Mac model would be explained in a separate draft [ex. informational rfc] until a specific resolution VR> would take place in IEEE. Rick>> c) for the case where the U-PE network is a completely ethernet Rick>> switched network, and encapsulation like MAC-in-MAC is used, Rick>> what part of the architecture belongs to the IETF? VR> > vasile VR> definitively, the architecture of such access networks should belong to IEEE. However, regardless of VR> Mac-in-Mac or PW models, a control protocol should be employed in such access networks - we are VR> considering to submit a GVPLS companion proposal for such control protocol. In addition, such VR> control protocol can be used also for Q-in-Q and HVPLS models Rick>> c) definition of M2P PWs is outside the scope of this WG and Rick>> probably should go to PWE3 VR> > vasile VR> we are considering to get the M2P PW topic in the PWE3 agenda. The M2P PW can be used in other VR> contexts than VPLS. VR> The M2P PW is an option that can fit nicely with the multipoint nature of the VPLS service - VR> d) how does the definition of semantics of the PW CW given VR> in the document relate to those defined in the PWE3 WG? VR> > vasile VR> the CW, is optional in both pwe3-ethernet-encap-01.txt and in gvpls drafts. In GVPLS we use the VR> format that was presented in the version mentioned above, where the sequence number was replaced VR> with the SRC-ID indication. VR> In the new GVPLS version we would use the new format presented in the version pwe3-ethernet-encap- VR> 02.txt, where there are 16 bits reserved and 16 bits used for the sequence number. The 16 bits VR> reserved "for further extension" would be used in the VPLS context as SRC-ID indication. We VR> understand that such proposal needs to be discussed also in the PWE3 group. VR> However, a PW P2P used in the context of the VPLS can have a mechanism to indicate the SP source VR> address from where it's originating, without breaking the original PW model. In the current VR> solutions there are two ways to indicate the SP Source address: a) using the Control Plane [ex.VC- VR> label ] or using the Data Plane [ex. CW]. In our current experiments by far, the Data Plane model VR> scale and perform better than the Control plane model. VR> IF we use PW P2P with Source indication, in the control plane, then the natural evolution is to VR> combine the LSPs that have the same destination into a M2P PW. VR> Some conclusions: VR> As we understand the questions, I think there are ways to move forward, and to see GVPLS as an VR> extension of the vpls non-distributed model [draft-lasserre-vkomeplla-vpls], and worth to be VR> continued as working document. However, a revised version would be taken in consideration for the VR> next IETF meeting; some components as BGP signaling and MAC-in-MAC would be presented in separate VR> drafts. The interoperability aspects between vpls and gvpls would still be maintained in the draft, VR> if there are not other opinions. Vach>> Some conclusions: Vach>> - GVPLS says LDP is the signaling protocol of choice Vach>> - GVPLS proposes basic interop with draft-lasserre-vkompella-vpls Vach>> - one can construct a distributed VPLS node using ethernet PWs and VPLS Vach>> - MAC-in-MAC is clearly outside the scope of the IETF Vach>> - at the Yokohama IETF we were told MAC-in-MAC was not currently in any IEEE charter Vach>> - the BGP in GVPLS is too similar to draft-kompella-vpls to warrant a separate draft Vach>> - the claim to identical information models between BGP and LDP signaling is not borne out Vach>> - GVPLS uses different encaps from the ones being defined in PWE3 Vach>> Can you stil justify the GVPLS draft? VR> Cheers VR> Vasile -Vach From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 12:57:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16704 for ; Fri, 30 May 2003 12:57:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UGv0n01569 for ; Fri, 30 May 2003 12:57:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UGuu813259 for ; Fri, 30 May 2003 12:56:57 -0400 (EDT) Message-Id: <4.3.2.7.2.20030530093956.02091300@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 09:54:26 -0700 To: Muneyoshi Suzuki , erosen@cisco.com From: Ali Sajassi Subject: Re: VPLS model for L2VPN Framework document Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp In-Reply-To: <20030530.132737.07596716.suzuki.muneyoshi@lab.ntt.co.jp> References: <200305291412.h4TEC3FV011191@rtp-core-1.cisco.com> <20030529.114748.71129538.suzuki.muneyoshi@lab.ntt.co.jp> <200305291412.h4TEC3FV011191@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 01:27 PM 5/30/2003 +0900, Muneyoshi Suzuki wrote: > > The way the framework document is written, it seems to > suggest that an > > "emulated LAN" is the as a "VPLS instance", which in turn suggests > that a > > single MSTP instance cannot govern multiple VPLS instances. So > I just > > wanted to make it clearer that an emulated LAN could consist of > a set of > > VPLS instances plus an MSTP instance; I think this would remove > Mick's and > > Norm's objection. > >It seems to me, something is still confusing. What is different between >emulated LAN and VPLS instance? Could you clarify this? This is the way I look at it: A VPLS instance corresponds to an end-to-end service instance that can spans across different access networks (e.g., one side to be QinQ and the other side to be MPLS). An emulated LAN correspond to a set of PWs and their associated forwarding functions. An emulated LAN looks like an emulated VLAN with respect to the bridge module. >Regarding the framework model, if a single PE contains multiple logical >Bridges, a single VPLS Forwarder cannot be shared by Bridges. In this >case, a PE must contain multiple logical Bridges and VPLS Forwarders. Each >Bridge may have a single MSTP instance, and the instances interwork through >VPLS Forwarders. I can't see any problem in this model. (Needless to say, >if the VPLS Forwarders is supported by full mesh, there is a big issue ;-) Yes, in that model there is a one to one correspondence between logical bridge and forwarder and sometimes the combination of the two is referred to as VSI. -Ali >Thanks, > > >Muneyoshi Suzuki >Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 13:09:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17331 for ; Fri, 30 May 2003 13:09:45 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UH9En22999 for ; Fri, 30 May 2003 13:09:14 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UH9Ad25938 for ; Fri, 30 May 2003 13:09:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20030530095451.02090ea0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 10:06:07 -0700 To: Muneyoshi Suzuki , sajassi@cisco.com From: Ali Sajassi Subject: Re: VPLS model for L2VPN Framework document Cc: erosen@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp In-Reply-To: <20030530.133924.41674429.suzuki.muneyoshi@lab.ntt.co.jp> References: <4.3.2.7.2.20030529142226.02057480@airborne.cisco.com> <200305271732.h4RHWSFV009263@rtp-core-1.cisco.com> <20030529.114748.71129538.suzuki.muneyoshi@lab.ntt.co.jp> <4.3.2.7.2.20030529142226.02057480@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: At 01:39 PM 5/30/2003 +0900, Muneyoshi Suzuki wrote: >Ali, > > > With respect to IEEE, the proper model is single bridge in a PE; however, > > if Ethernet access network is not used or IEEE control protocols is not > > used in the MPLS/IP access network, then one can use multiple bridges > model > > where each bridge is simple 1980-style bridge (e.g., VSI). Although the > > later model is not recommended because of its restrictions. > >I'm not sure relation ship between the above and MSTP issue in the >framework model. MSTP would apply to the first model - a single bridge within the PE. >If a Bridged LAN consists of 1980-style bridges that don't support xSTP, >it is logically equivalent a LAN segment from a viewpoint of Bridges that >support xSTP, so I think there is no xSTP related issue. correct. >I still don't understand the issue in the framework model. I'm still >waiting answers to the following questions as I posted over two weeks ago. > >---- >(1) Could you clarify what the mistake is in the Eric's model, and >and how your model resolved it? Frankly I think it was a nit because Eric's wording is general and abstract enough that applies to both models. However, in the paragraph after the figure, there is a sentence that says:"Within the VPLS-PE, the bridge module attaches, through an "Emulated LAN Interface" to an Emulated LAN". If one considers an emulated LAN as an emulated VLAN, then he can interpret this sentence as there is a bridge module for every emulated VLAN (e.g., for every VPLS instance) which in turn becomes the multi-bridge model within a PE. >(2) Could you clarify what the right part from "A" means? I my understanding >it must be a MAC entity or a part of a MAC relay entity that distributed PEs. I cannot put this question in the proper context. >(3) Could you clarify why the above model is consistent with the following >Mick's interpretation of the Bridge protocol architecture. Hope it is clear now from the above description. -Ali >--- > >Thanks, > > >Muneyoshi Suzuki >Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 13:31:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18104 for ; Fri, 30 May 2003 13:31:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UHV2n28894 for ; Fri, 30 May 2003 13:31:02 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UHUxS07940 for ; Fri, 30 May 2003 13:30:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20030530101553.02094540@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 10:28:54 -0700 To: richard.spencer@bt.com, sajassi@cisco.com, erosen@cisco.com From: Ali Sajassi Subject: RE: VPLS model for L2VPN Framework document Cc: ppvpn@nortelnetworks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: At 08:47 AM 5/30/2003 +0100, richard.spencer@bt.com wrote: >Ali > > > Or we can say "SP untagged packets - e.g., BPDUs". > >I still don't think that the above gives enough clarification. Packets are >only tagged between trunk ports. An operator may have access ports >connecting to different management networks that belong to different VLANs, >e.g. VLAN 100 for management application X, and VLAN 200 for management >application Y. Now, both of these access ports will receive untagged SP >packets, but they will be destined for different VLANs. Both sets of SP >untagged packets could not be sent over the same 'untagged VPLS instance' as >they belong to different VLANs. If the access ports are .1q access ports, then bridge would only see tagged traffic from these two ports. If they are not .1q access ports, then the bridge can not differentiate between them and it gets sent over the control VPLS instance. Anyway, if we want to limit the control VPLS instance to only BPDUs, then we can state it as such; however, if we want to allow other control/management frames over it, then we don't need to be that explicit. -Ali -Ali >Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 13:39:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18352 for ; Fri, 30 May 2003 13:39:48 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UHdHn03438 for ; Fri, 30 May 2003 13:39:17 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UHdBS20167 for ; Fri, 30 May 2003 13:39:12 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: vkompella@timetra.com, "Vasile Radoaca" , "Dinesh Mohan" , Ppvpn , Rick Wilder Subject: RE: decisions on L2 solutions documents Date: Fri, 30 May 2003 13:37:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326D2.24A279A2" X-LYRIS-Message-Id: 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_01C326D2.24A279A2 Content-Type: text/plain; charset="iso-8859-1" Vach, A comment on vpn-id/martini... > Vach>> naming the PWs, not in naming the VPN ID. The issue > of using a globally > unique name for the VPLS > Vach>> has been discussed. In an attempt to keep the > signaling compatible with > draft-martini, we agreed > Vach>> on using a VCID. I think in the pw control draft (draft-ietf-pwe3-control-protocol-02.txt), Eric's signaling extensions have been added that can accommodate as well a global unique id. Why not use the control draft extensions. >However, there was an intent all > along to somehow make > that identifier a > Vach>> globally unique. Suggestions were made such as adding > a VPN ID in the > optional parameters field, > Vach>> etc. My last proposal was to have a bona fide VPN ID > TLV in the FEC. > Yes. But that is not defined in pwe control draft and if added it looks redundant to Eric's additions. I requested before clarifications on the use of VPN-ID TLV (which was left unanswered btw - see the archive) http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&O= A&P=980. I don't see why we still didn't resolve that problem. Why not just adopt the pwe3 control draft's Generalized ID FEC element instead of defining another VPN-ID TLV (which I assume if done needs to be captured in the same draft). Is there any reason why not? Hamid. ------_=_NextPart_001_01C326D2.24A279A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: decisions on L2 solutions documents

Vach,

A comment on vpn-id/martini...

> Vach>> naming the PWs, not in naming the = VPN ID.  The issue
> of using a globally
> unique name for the VPLS
> Vach>> has been discussed.  In an = attempt to keep the
> signaling compatible with
> draft-martini, we agreed
> Vach>> on using a VCID. 

I think in the pw control draft = (draft-ietf-pwe3-control-protocol-02.txt),
Eric's signaling extensions have been added that = can
accommodate as well a global unique id. Why not = use
the control draft extensions.


>However, there was an intent all
> along to somehow make
> that identifier a
> Vach>> globally unique.  Suggestions = were made such as adding
> a VPN ID in the
> optional parameters field,
> Vach>> etc.  My last proposal was to = have a bona fide VPN ID
> TLV in the FEC.
>

Yes. But that is not defined in pwe control draft and = if added
it looks redundant to Eric's additions. I requested = before
clarifications on the use of VPN-ID TLV (which was = left
unanswered btw - see the archive)
 
http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=3D= ind0305&L=3Dppvpn&T=3D0&O=3DA&P=3D980.

I don't see why we still didn't resolve that = problem.

Why not just adopt the pwe3 control draft's = Generalized ID
FEC element instead of defining another VPN-ID = TLV
(which I assume if done needs to be captured in the = same
draft).

Is there any reason why not?

Hamid.

------_=_NextPart_001_01C326D2.24A279A2-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 15:13:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23396 for ; Fri, 30 May 2003 15:13:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UJCvn21967 for ; Fri, 30 May 2003 15:12:58 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UJCsJ12519 for ; Fri, 30 May 2003 15:12:54 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Hamid Ould-Brahim" , "Vasile Radoaca" , "Dinesh Mohan" , "Ppvpn" , "Rick Wilder" Subject: RE: decisions on L2 solutions documents Date: Fri, 30 May 2003 12:10:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01C326A4.7E8F04E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 30 May 2003 19:10:30.0648 (UTC) FILETIME=[2330F780:01C326DF] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,vasile@nortelnetworks.com,mohand@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0162_01C326A4.7E8F04E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: decisions on L2 solutions documentsHamid, Two meta-points. First, Eric has resubmitted his draft to ppvpn as draft-rosen-ppvpn-l2-signaling-03.txt. Second, why have two FECs for PWE3? Surely, if we use the Generalized ID FEC, then we don't need fec type 128. Let's simplify. I have no problem with the "Generalized ID FEC TLV" concept. In fact, we are probably in violent agreement on that. The (minor) issue is what it looks like: AGI: VPN ID TLV: But where I have considerably more difference of opinion is how to name a PW. In a VPWS or a VPLS, I would like to be able to name each constituent PW. So, I want a VPN ID that contains a number of PWs. pwe3-control says use a 32-bit number that is unique between a pair of PEs. It also qualifies that 32-bit number with a VC type. That's probably not necessary, and some of the implementations that I have had the pleasure of working with agree with me. In other words, a PW is named (PE1, VC type, VCID, PE2). I would suggest that the full name of a PW is {VPNID (PE1, VC type, VCID, PE2)}. draft-rosen suggests that a PW is named (PE1, SAII, TAII, PE2). I am not not convinced of the benefits of this naming scheme. Eric and I have exchanged some emails in this regard, and are continuing to do so. Finally, draft-rosen says the SAII and TAII are 0 for VPLS. That means that there is no name for the PW between a pair of VPLS nodes. That may generally be ok since the full name of a PW is {VPNID, (PE1, 0, 0, PE2)} and we generally have only a single PW between a pair of nodes in a VPLS. However, when we have a VPLS node which has a pair of spokes to the same MTU (HVPLS situation), we have to name the PWs differently. This scenario comes up in certain regulatory environments where the MTU owner is only allowed to provide L2 transport service. Consider the following physical topology. CE1------------MTU-------------PE | CE2-------------- In an unregulated case, the MTU could host a FIB, and turn packets around between the two CEs. However, in a regulated environment, the PE may have to host the FIB. We have then two spokes from the PE to the MTU, one for CE1 and one for CE2. CE1------------\ /-----------\ MTU PE CE2=============/ \=============/ I want to be able to name each spoke. On the PE side, I have a FIB. In draft-rosen, the PE would name the SAII 0. The PE would have to know the name of the TAII on the MTU going to CE1. The PE would have to know the name of the TAII on the MTU going to CE2. Otherwise, there would be no names for these two PWs. In summary: - my proposal would remove the limited use Group ID field (actually, Eric pointed out I had no use for it) - my proposal requires a VPN ID that groups PWs across the network that belong to the same VPN - my proposal uses the VCID field to name a PW within the VPN - the delta between existing fec type 128 in pwe3-control and my proposal is minimal - I feel that draft-rosen suggests a much broader change (with additional benefits, but do we need them?) -Vach -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Friday, May 30, 2003 10:37 AM To: vkompella@timetra.com; Vasile Radoaca; Dinesh Mohan; Ppvpn; Rick Wilder Subject: RE: decisions on L2 solutions documents Vach, A comment on vpn-id/martini... > Vach>> naming the PWs, not in naming the VPN ID. The issue > of using a globally > unique name for the VPLS > Vach>> has been discussed. In an attempt to keep the > signaling compatible with > draft-martini, we agreed > Vach>> on using a VCID. I think in the pw control draft (draft-ietf-pwe3-control-protocol-02.txt), Eric's signaling extensions have been added that can accommodate as well a global unique id. Why not use the control draft extensions. >However, there was an intent all > along to somehow make > that identifier a > Vach>> globally unique. Suggestions were made such as adding > a VPN ID in the > optional parameters field, > Vach>> etc. My last proposal was to have a bona fide VPN ID > TLV in the FEC. > Yes. But that is not defined in pwe control draft and if added it looks redundant to Eric's additions. I requested before clarifications on the use of VPN-ID TLV (which was left unanswered btw - see the archive) http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&O= A&P=980. I don't see why we still didn't resolve that problem. Why not just adopt the pwe3 control draft's Generalized ID FEC element instead of defining another VPN-ID TLV (which I assume if done needs to be captured in the same draft). Is there any reason why not? Hamid. ------=_NextPart_000_0162_01C326A4.7E8F04E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: decisions on L2 solutions documents
Hamid,
 
Two=20 meta-points.  First, Eric has resubmitted his draft to ppvpn as=20 draft-rosen-ppvpn-l2-signaling-03.txt.  Second, why have two FECs = for=20 PWE3?  Surely, if we use the Generalized ID FEC, then we don't need = fec=20 type 128.  Let's simplify.
 
I=20 have no problem with the "Generalized ID FEC TLV" concept.  In = fact, we are=20 probably in violent agreement on that.  The (minor) issue is what = it looks=20 like:
 
AGI:=20 <type> <octet-string>
VPN=20 ID TLV: <type> <length> = <octet-string>
 
But=20 where I have considerably more difference of opinion=20 is how to name a PW.  In a VPWS or a VPLS, I = would like to=20 be able to name each constituent PW.  So, I want a VPN ID that = contains a=20 number of PWs.  pwe3-control says use a 32-bit number that is = unique=20 between a pair of PEs.  It also qualifies that 32-bit number with a = VC=20 type.  That's probably not necessary, and some of the = implementations that=20 I have had the pleasure of working with agree with me.  In other = words, a=20 PW is named (PE1, VC type, VCID, PE2).
 
I=20 would suggest that the full name of a PW is {VPNID (PE1, VC type, VCID,=20 PE2)}.
 
draft-rosen suggests that a PW is named (PE1, SAII, TAII, = PE2).  I=20 am not not convinced of the benefits of this naming scheme.  Eric = and I=20 have exchanged some emails in this regard, and are continuing to do=20 so.
 
Finally, draft-rosen says the SAII and TAII are 0 for = VPLS.  That=20 means that there is no name for the PW between a pair of VPLS = nodes.  That=20 may generally be ok since the full name of a PW is {VPNID, (PE1, 0, = 0,=20 PE2)} and we generally have only a single PW between a pair of nodes in = a=20 VPLS.
 
However, when we have a VPLS node which has a pair of spokes to = the same=20 MTU (HVPLS situation), we have to name the PWs differently.  This = scenario=20 comes up in certain regulatory environments where the MTU owner is only = allowed=20 to provide L2 transport service.  Consider the following physical=20 topology.
 
   = CE1------------MTU-------------PE
          &nbs= p;       =20 |
   CE2--------------
 
In=20 an unregulated case, the MTU could host a FIB, and turn packets = around=20 between the two CEs.  However, in a regulated environment, the PE = may have=20 to host the FIB.  We have then two spokes from the PE to the MTU, = one for=20 CE1 and one for CE2.
 
 
  =20 CE1------------\    /-----------\
=
          &nbs= p;        =20 MTU           &nbs= p; PE
   CE2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ =20 \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/
 
I=20 want to be able to name each spoke.  On the PE side, I have a = FIB. =20 In draft-rosen, the PE would name the = SAII 0.  The=20 PE would have to know the name of the TAII on the MTU going to=20 CE1.  The PE would have to know the name of the TAII on = the MTU=20 going to CE2.  Otherwise, there would be no names for these two=20 PWs.
 
In=20 summary:
 - my proposal would remove the limited use Group ID = field=20 (actually, Eric pointed out I had no use for = it)
 - my proposal requires a VPN ID that groups PWs = across the=20 network that belong to the same VPN
 - my proposal uses the VCID field to name a PW = within the=20 VPN
 - the delta between existing fec type 128 in pwe3-control = and my=20 proposal is minimal
 - I feel that draft-rosen suggests a much broader = change (with=20 additional benefits, but do we need them?)
 
-Vach
 
-----Original Message-----
From: Hamid Ould-Brahim=20 [mailto:hbrahim@nortelnetworks.com]
Sent: Friday, May 30, = 2003 10:37=20 AM
To: vkompella@timetra.com; Vasile Radoaca; Dinesh Mohan; = Ppvpn;=20 Rick Wilder
Subject: RE: decisions on L2 solutions=20 documents

Vach,

A comment on vpn-id/martini...

> Vach>> naming the PWs, not in naming the = VPN=20 ID.  The issue
> of using a = globally=20
> unique name for the VPLS
>=20 Vach>> has been discussed.  In an attempt to keep the=20
> signaling compatible with =
> draft-martini, we agreed
> = Vach>>=20 on using a VCID. 

I think in the pw control draft=20 (draft-ietf-pwe3-control-protocol-02.txt),
Eric's=20 signaling extensions have been added that can
accommodate as well a global unique id. Why not use =
the control draft extensions.


>However, there was an intent all =
> along to somehow make
> = that identifier=20 a
> Vach>> globally unique.  = Suggestions=20 were made such as adding
> a VPN ID in = the=20
> optional parameters field,
>=20 Vach>> etc.  My last proposal was to have a bona fide VPN = ID=20
> TLV in the FEC.
>=20

Yes. But that is not defined in pwe control draft = and if=20 added
it looks redundant to Eric's = additions. I=20 requested before
clarifications on the use = of VPN-ID=20 TLV (which was left
unanswered btw - see the = archive)
 
http://standards.nortelnetw= orks.com/cgi-bin/wa.exe?A2=3Dind0305&L=3Dppvpn&T=3D0&O=3DA&am= p;P=3D980.=20

I don't see why we still didn't resolve that = problem.=20

Why not just adopt the pwe3 control draft's = Generalized=20 ID
FEC element instead of defining another = VPN-ID=20 TLV
(which I assume if done needs to be = captured in=20 the same
draft).

Is there any reason why not?

Hamid.

------=_NextPart_000_0162_01C326A4.7E8F04E0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri May 30 15:58:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25362 for ; Fri, 30 May 2003 15:58:21 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UJvnn01837 for ; Fri, 30 May 2003 15:57:50 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4UJvkb07322 for ; Fri, 30 May 2003 15:57:46 -0400 (EDT) Date: Fri, 30 May 2003 12:54:31 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <46580372261.20030530125431@psg.com> To: Ross Callon CC: Yakov Rekhter , Juha Heinanen , PPVPN@nortelnetworks.com Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider In-Reply-To: <4.3.2.20030516140719.028fab60@zircon.juniper.net> References: <4.3.2.20030516140719.028fab60@zircon.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ross, Friday, May 16, 2003, 11:32:23 AM, Ross Callon wrote: [...] > My understanding is that this discussion is still related to what goes into > the proposed charter for the Layer 3 VPN working group. In this context > we don't have to solve the problem right now, we just need to decide > what goes into the charter. Agreed [...] > To me whether to insist on the inter-AS case being solved and fully > documented before progressing the solutions documents comes down > to three things: (i) How important are the multi-AS cases; and (ii) How > confident are we that if we postpone the multi-AS work, that we > won't end up with a situation where we wish that we had changed the > base documents; and (iii) How long will it take to fully document the > inter-AS cases? Very true > A question for Alex and Thomas Narten: Suppose hypothetically that > there is consensus to work on the inter-AS cases, and suppose that > we don't want to slow down the base documents to wait for this to > complete. In this case, the L3 VPN working group might work on > progressing existing documents (the long list from the proposed > charter that Alex sent out) as a high priority item, and work on the > inter-AS cases as a lower priority. In this case, would we want to > explicitly mention the Inter-AS cases in the charter? This would be reasonable, I think. I will follow up on Loa's message too. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat May 31 03:18:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26145 for ; Sat, 31 May 2003 03:18:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4V7I2w20456 for ; Sat, 31 May 2003 03:18:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4V7HxE03237 for ; Sat, 31 May 2003 03:18:00 -0400 (EDT) Message-Id: <200305310716.h4V7GHr10825@zcars0jk.ca.nortel.com> From: "Dr. Ibrahim George Quattara" Reply-To: ibrageorge1@indiatimes.com Date: Sat, 31 May 2003 23:17:13 +0430 Subject: treat as urgent and confidential X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: emztd2417.com X-SMTP-MAIL-FROM: ibrageorge@indiatimes.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: de1794.emirates.net.ae [217.165.88.32] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA26145 FROM THE DESK: DR. IBRAHIM GEORGE QUATTARA DIRECTOR, PROJECT IMPLEMENTATION FEDERAL MINISTRY OF HEALTH AND SOCIAL SERVICES ABDIJAN -COTE D'IVOIRE DIRECT TEL: 008821688854690 STRICTLY CONFIDENTIAL DEAR FRIEND, TRANSFER OF US$11.5MILLION INTO A PERSONAL/COMPANY'S OFFSHORE ACCOUNT Based on the information gathered from the Ministry of Trade and Industries, we intend to solicit for your assistance on this transaction with you on the assumption that you will not disappoint us. We have eleven Million, Five Hundred Thousand United States Dollars (US$11,500,000.00) which we made over time from over inflated contracts in my Ministry (Federal Ministry of Health and Social Services). We are seeking your assistance and permission to remit this amount into your account or any other nominated account you can provide for us. Your commission will be 20% of the total sum, 10% for expenses and the remaining 70% is for my colleagues and me. Could you please notify me of your acceptance to carry out this transaction urgently by e-mail or via my direct telephone line only on the receipt of this message. Kindly, acknowledge the receipt of this letter by sending to me by email a copy of this letter with your private Tel. And Fax number. I shall in turn inform you of the modalities for a formal application to secure the necessary approvals for the immediate release of this fund into your account. Thanks for your co-operation. Yours faithfully, DR. George Ibrahim Quattara