From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Mar 20 12:10: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 MAA25346 for ; Thu, 20 Mar 2003 12:10:58 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KHCbB03303 for ; Thu, 20 Mar 2003 12:12:37 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2KHCrL26724 for ; Thu, 20 Mar 2003 12:12:54 -0500 (EST) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15993.62882.13060.473421@lohi.eng.song.fi> Date: Thu, 20 Mar 2003 19:08:50 +0200 To: ppvpn@nortelnetworks.com Subject: radius based discovery 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 considerable interest was expressed in radius based discovery at the s.f. meeting. i would therefore like to invite a team to complete the specification by target date of end of may. could those who are interested in participating, send me an email note and i'll setup a mailing list for the team. it would also be nice to get some real radius experts onboard. i myself don't insist in being an editor of the document especially if someone else could show up with more cycles available on this than me. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Mar 20 18:30: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 SAA14063 for ; Thu, 20 Mar 2003 18:30:48 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KNWWB25415 for ; Thu, 20 Mar 2003 18:32:32 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2KNWmL08894 for ; Thu, 20 Mar 2003 18:32:49 -0500 (EST) Date: Thu, 20 Mar 2003 15:29:33 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Vach Kompella Cc: Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-Reply-To: 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 Vach, A couple of high level comments and then please see inline: - IMHO the WG should move in the direction of making 'one' LDP signaling solution, a BGP signaling solution, a L2TP signaling solution and if there is enough interest a radius signaling solution WG documents. LDP, BGP and L2TP signaling solutions have their own merits/demerits and fulfill different needs. - draft-lasserre-vkompella-...is a good starting point for a LDP signaling solution. The major caveat is VPLS/L2-VPN identifier. (Please see inline) With a common understanding of the how this issue should be addressed IMHO draft-lasserre-vkompella...should be made a WG doc. On Wed, 19 Mar 2003, Vach Kompella wrote: > Having been asked to request comments on the ppvpn mailing lists minutes ago, > I'm soliciting your comments. Rather than just throwing the questions to the > WG, I've added a couple of my thoughts as a starting point for discussion. > > The points raised in the WG are: > 1. how to differentiate between a signaled vpls and vpws if the vc type is going > to be the same? > 2. how to name a vpls? > > For point 1, there are three approaches: > - go back to using different vc types. The problem is that the vc type relates > closely to the PW whose behavior is identical to the ethernet vc and the service > property is above the encapsulation behavior. > - use a different fec type. draft-martini uses fec type 128, draft-rosen (now > merged into the WG version of draft-martini) uses fec type 129. VPLS could use > fec type 130. > - use a flag in the fec tlv to differentiate between vpls and vpws. In that > case, we could use fec type 129 and a flag for vpls vs. vpws. > So I'd like to get some feedback on one of the three above, for starters, or > some other approach, too. > A local PE clearly has to know if the remote PE is capable of doing MAC address learning over a PW that it has signaled. Else it cannot use that PW for sending VPLS traffic to the remote PE. Hence the differentiation you talk about is needed and that is what I meant to convey in my comment in the WG meeting. Its preferable to convey this in the FEC and it probably relates to issue #2, though I don't have a strong opinion. > For point 2, I propose the following: > A VPN ID TLV formatted something like: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VPNID TLV | Length | VPNID Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VPN ID (variable length) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The VPN ID Type could then identify the value as any one of flat 32-bit ID, > route target, OUI-based VPN ID (rfc2685), other types (including AGI, SAII, TAII > as used in VPWS for draft-rosen). > I'd like some feedback on this too. > This seems to be in the right direction and leaves room for extensibility etc. I would also like to suggest that we come up with a VPLS/L2-VPN end identifier draft. It will briefly describe the VPN ID TLV format and suggested semantics for a VPLS, L2VPN and colored pool application. draft-lasserre-vkompella...and the L2TPv3 signaling draft can then simply treat the end ID as an opaque object and refer to this draft. This has the following advantages: - Consistancy between LDP and L2TPv3 signaling as far as the end identifier goes. Coming from a vendor that is implementing both these approaches, this is very helpful. - From what I can gather there is contention with respect to the end identifier format and that is one of the reasons why draft-lasserre-vkomplella is facing some resistance as far as the LDP solution goes. Decoupling this from draft-lasserre will help move things forward. Comments ? > Having said that, there are probably other issues that may have been irritating > you that you'd like to bring to the table - let's talk about them. My only > comment on this process is that there is more consensus than is apparent, and > we'd like to get a pretty good solution out there, even if it is not perfect. Agreed ! Thanks, rahul > > -Vach > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Mar 21 12: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 MAA20526 for ; Fri, 21 Mar 2003 12:58:21 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2LHxxM03187 for ; Fri, 21 Mar 2003 12:59:59 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2LI0Dn17995 for ; Fri, 21 Mar 2003 13:00:14 -0500 (EST) Message-ID: <00c401c2efd3$3a6c28e0$31726051@c2f4r3> Reply-To: "Brian Powell" From: "Brian Powell" To: "MVNO world" Subject: 2.5G Rules - OK? Date: Fri, 21 Mar 2003 17:56:31 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01C2EFD3.3A6C28E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: mta06-svc.ntlworld.com X-SMTP-MAIL-FROM: bpowell@arran.prestel.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mta06-svc.ntlworld.com [62.253.162.46] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01C2EFD3.3A6C28E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 2.5G Rules - OK? The longevity of 2.5G was predicted in both of our incisive (and now = highly-acclaimed) reports, first published in September 2001:=20 Report 1 - "The Emerging MVNO Market, Challenges and Opportunities" = (Section 6); and Report 2 - "MVNO Roadmap" (Section 7). Now, there is real tangible evidence that MVNOinfo.com's prediction has = become reality. The Japanese mobile operator NTT DoCoMo recently announced that it is = earning less per user for its 3G FOMA service than it is for its 2.5G i-mode service. = This was reported recently in The German Financial Times newspaper (FT Deutschland) and makes very = uncomfortable reading for any mobile operator planning to commercially launch 3G services = later this year. FT Deutschland quoted prominent NTT DoCoMo board member Takanori Utano = as saying: "Data revenues per customer for FOMA (3G) are below those that we have = with the systems of the second generation." It appears that the main problem is the lack of = applications for 3G phones, which, in turn, is put down to the low number of subscribers to NTT = DoCoMo=92s 3G service (FOMA).=20 It appears that a non-virtuous loop is beginning to emerge in the global = mobile market. With few 3G customers to aim at, application developers are pitching their = products at the much more developed i-mode market. The knock-on effect is that with fewer = attractive services to offer, 3G operators will find it hard to build the critical mass of customers = they need for next generation mobile phone systems to be viable.=20 ARPU at DoCoMo=92s FOMA service started out relatively high in the = period from October to December 2001, when it stood at Yen10,400 (US$77.80). This was then = almost 25% more than DoCoMo's ARPU for its i-mode customers (Yen8,500). However, the = trend reversed during 2002 when the company=92s ARPU from 3G customers fell to Yen 8,300 while = the revenue per i-mode user remained static. =A9 MVNOinfo.com March 2003, All rights reserved. The MVNO market is one of the few areas offering great potential = opportunity in today's communications industry. To make sure YOU don't miss out on the chance to get plugged in to this brand new market opportunity - visit: www.mvnoinfo.com, where you can access our highly-acclaimed reports and can also find FREE WHITE PAPERS and a Community Section. Alternatively, contact Brian at: brianp@mvnoinfo.com or Katalin at: = mvnoworld@thailand.com <><><>< MVNOinfo.com - the definitive global voice of the MVNO community = ><><><> -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------ Messages are e-mailed to keep you up-to-date with new MVNOinfo topics, = products and services. If you prefer not to receive these messages, = please reply with 'unsubscribe' in the subject area. ------=_NextPart_000_00C1_01C2EFD3.3A6C28E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
2.5G Rules -=20 OK?
 
 
The = longevity of 2.5G=20 was predicted in both of our incisive (and now highly-acclaimed)=20 reports,
first = published in=20 September 2001:
Report 1 - "The Emerging = MVNO=20 Market, Challenges and Opportunities" (Section 6); and
 
Report 2 - "MVNO = Roadmap"=20 (Section 7).
Now, there is real tangible evidence=20 that MVNOinfo.com's prediction has become = reality.
 
The Japanese mobile operator NTT DoCoMo = recently=20 announced that it is earning less per
user for its 3G FOMA service than it is for = its 2.5G=20 i-mode service. This was reported recently in
The German Financial Times newspaper (FT = Deutschland)=20 and makes very uncomfortable reading
for any mobile operator planning to = commercially launch 3G services later this=20 year.
FT Deutschland quoted prominent NTT DoCoMo = board member=20 Takanori Utano as saying:
"Data revenues per customer for FOMA (3G) are = below=20 those that we have with the systems of the
second generation." It appears that the main = problem is=20 the lack of applications for 3G phones,
which, in turn, is put down to the low number = of=20 subscribers to NTT DoCoMo=92s 3G service (FOMA).

It appears that a = non-virtuous=20 loop is beginning to emerge in the global mobile market. = With=20 few
3G customers to aim at, application = developers are=20 pitching their products at the much more
developed i-mode market. The knock-on effect = is that=20 with fewer attractive services to offer,
3G operators will find it hard to build the = critical=20 mass of customers they need for=20 next
generation mobile phone systems to be viable. =
ARPU at DoCoMo=92s FOMA service started out = relatively=20 high in the period from October to
December 2001, when it stood at Yen10,400 = (US$77.80).=20 This was then almost 25% more
than DoCoMo's ARPU for its i-mode customers = (Yen8,500).=20 However, the trend reversed during
2002 when the company=92s ARPU from 3G = customers fell to=20 Yen 8,300 while the revenue
per i-mode user remained static.
 
=A9 = MVNOinfo.com March=20 2003, All rights = reserved.
 
 

The MVNO market is one of the few areas offering great = potential=20 opportunity

in today's communications=20 industry.

To make sure YOU don't miss out on the chance to get = plugged in=20 to this

brand new market opportunity = - visit: www.mvnoinfo.com,=20 where you

can access our highly-acclaimed = reports and can also find

FREE=20 WHITE PAPERS and a Community=20 Section. Alternatively,

contact Brian at: brianp@mvnoinfo.com or Katalin = at: mvnoworld@thailand.com

 
 
 
<><><><=20 MVNOinfo.com - the definitive global voice of the MVNO = community=20 ><><><>
----------------------------------------------------------= -------------------------------------------------------------------------= ---------------------
Messages=20 are e-mailed to keep you up-to-date with new = MVNOinfo=20 topics, products and services. If you prefer not to receive these = messages,=20 please reply with 'unsubscribe' in the subject area.
 
 
 
------=_NextPart_000_00C1_01C2EFD3.3A6C28E0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Mar 22 06:11: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 GAA24086 for ; Sat, 22 Mar 2003 06:11:44 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2MBDTE20802 for ; Sat, 22 Mar 2003 06:13:30 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2MBDkP06061 for ; Sat, 22 Mar 2003 06:13:46 -0500 (EST) Message-Id: <200303221111.h2MBB7i11122@zrtps06t.us.nortel.com> From: "Steve Luksa" Date: Sat, 22 Mar 2003 12:11:04 To: ppvpn@nortelnetworks.com Subject: Urgent MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SMTP-HELO: ertpsms1.nortelnetworks.com X-SMTP-MAIL-FROM: slmt1234@netscape.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: node-c-073c.a2000.nl [62.194.7.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Dear Sir/Madam, URGENT As widely and correctely too reported in most celebrated International mass media notably the Cable News Network (CNN), British Broadcasting Service (BBC) and other local stations, events in Cote D'Ivoire a hitherto serene country in Africa is turning for the worst. Recently, mutinous forces loyal to the opposition party attacked government soldiers that resulted to the wanton destruction of lives and properties. All efforts by the United Nations Secetary General, Mr Kofi Anan, western powers led by United States and Britian and African Leaders to bring sanity to this country has failed. During this melee however, the wife of the President, Her Excellency, Mrs Gbagbo was able to airfreight to Europe the sum of Fifty Million United States Dollars ($50m) because of her fears of not knowing the outcome of this conflict. She was assisted by one of the friendly countries who came to evacuate her citizens from this troubled spot. It was airfreighted in luggages labelled as "diplomatic valuables". It is currently with a courier security firm in Europe. Those who airfreighted it and the security firm now in position of it are not aware of the contents. Sequel to this development, I, STEVE LUKAS an attorney by proffession have been mandated by the first lady to look for an honest and a reliable foreign partner who will cliam the fund deposited with the security company, lodge it in his name in his designated bank and if the need arises, he can also help invest the fund in real estate or any other business/s that yields high returns. All the necessary legal documents: Certificate of Deposit, will be prapared for you and a letter of authority will be sent to the security company that will enable you claim this money without any risk will be sent to you. You will also be introduced to the security firm officially. If this proposal appeals to you, please let me have your telephone and fax numbers and contact address so that I can call you to discuss this issue further. For all your efforts, you will be compensated with 30% of the total fund. My e-mail address is very private. Waiting for your urgent response. Regards, Steve Lukas From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 00: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 AAA22946 for ; Mon, 24 Mar 2003 00:50:03 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2O5pgm15740 for ; Mon, 24 Mar 2003 00:51:43 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2O5q1P24279 for ; Mon, 24 Mar 2003 00:52:02 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501272732@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: subip-area@subip.ietf.org Cc: "Ccamp-wg (E-mail)" , "Ppvpn (E-mail)" , "Mpls (E-mail)" , "Tewg (E-mail)" , "Gsmp (E-mail)" , "Ipo (E-mail)" Subject: Change of primary AD for SUB-IP WGs Date: Mon, 24 Mar 2003 06:48:27 +0100 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: bwijnen@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: auemail1.lucent.com [192.11.223.161] X-LYRIS-Message-Id: All, Scott has left the IESG and Alex has volunteered to be co-AD for SUB-IP with Bert. IESG has approved this. See announcement by Harald a week or so ago. We have divided the WGs between the two of us as follows (i.e. we act as primary AD as follows): For CCAMP, no change, so Bert Wijnen For GSMP: change Scott Bradner into Bert Wijnen For IPO: change Scott Bradner into Alex Zinin For MPLS: change Scott Bradner into Alex Zinin For PPVPN: change Scott Bradner into Alex Zinin For TEWG: no change, so Bert Wijnen Thanks, Bert and Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 00:53: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 AAA23055 for ; Mon, 24 Mar 2003 00:53:51 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2O5tbm18979 for ; Mon, 24 Mar 2003 00:55:37 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2O5tsP28105 for ; Mon, 24 Mar 2003 00:55:54 -0500 (EST) Message-ID: <20030324055239.72165.qmail@web20508.mail.yahoo.com> Date: Mon, 24 Mar 2003 05:52:39 +0000 (GMT) From: =?iso-8859-1?q?John=20Smith?= Subject: eth0 and VRFs To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web20508.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web20508.mail.yahoo.com [216.136.226.143] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Hello, We can put each of our serial links in unique VRFs. Can we do the same for our ethernet links? Let me clarify. I can give a following configuration on my router if i have two p2p links from which i want to connect my two BGP VPN routers. ! interface serial0 ip vrf forwarding XXXXX ip address xx.xx.xx.x m.m.m.m ! interface serial1 ip vrf forwarding ZZZZZ ip address zz.zz.z.z m.m.m.m ! NOw how can i achieve the same using ethernet links. Suppose my router has just one ethernet card and i want to connect to two BGP VPN routers. How can i do that? My setup is as following: ______ | A | ------ |eth0 | __________ |(eth0) | eth1 ----- ----- | B | | C | ------ ------ I would be very grateful if somebody can help me out or give some pointers. Thanks and Waiting, Warm Regards, Smith __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 01:54: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 BAA24117 for ; Mon, 24 Mar 2003 01:54:01 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2O6tmm01743 for ; Mon, 24 Mar 2003 01:55:48 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2O6u6P22813 for ; Mon, 24 Mar 2003 01:56:07 -0500 (EST) Message-ID: <20030324065248.18117.qmail@web20502.mail.yahoo.com> Date: Mon, 24 Mar 2003 06:52:48 +0000 (GMT) From: =?iso-8859-1?q?John=20Smith?= Subject: Re: eth0 and VRFs To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web20502.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web20502.mail.yahoo.com [216.136.226.137] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit I am sorry for some ambiguity .. what i had wanted to ask was that can i put two routers connected to my router (on an ethernet) in different VPNs or can i assign them different VRF IDs. AFAIK i need to have two different ethernets to do that wherein each ethernet is assigned a unique VRF. Is my understanding correct? Thanks, Smith ----- Original Message ----- From: "John Smith" To: Sent: Monday, March 24, 2003 11:22 AM Subject: eth0 and VRFs > Hello, > We can put each of our serial links in unique VRFs. Can we do the same for our ethernet > links? > > Let me clarify. > > I can give a following configuration on my router if i have two p2p links from which i > want to connect my two BGP VPN routers. > > ! > interface serial0 > ip vrf forwarding XXXXX > ip address xx.xx.xx.x m.m.m.m > ! > interface serial1 > ip vrf forwarding ZZZZZ > ip address zz.zz.z.z m.m.m.m > ! > > NOw how can i achieve the same using ethernet links. Suppose my router has just one > ethernet card and i want to connect to two BGP VPN routers. How can i do that? > > My setup is as following: > > ______ > | A | > ------ > |eth0 > | > __________ > |(eth0) | eth1 > ----- ----- > | B | | C | > ------ ------ > > I would be very grateful if somebody can help me out or give some pointers. > > Thanks and Waiting, > Warm Regards, > Smith > __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 02:52: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 CAA06993 for ; Mon, 24 Mar 2003 02:52:21 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2O7s7m11415 for ; Mon, 24 Mar 2003 02:54:07 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2O7sPP21409 for ; Mon, 24 Mar 2003 02:54:26 -0500 (EST) Message-ID: From: Ives Dekoninck To: "'John Smith'" , ppvpn@nortelnetworks.com Subject: RE: eth0 and VRFs Date: Mon, 24 Mar 2003 08:50:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F1DA.02E4D170" X-SMTP-HELO: stella.comtech.be X-SMTP-MAIL-FROM: Ives.Dekoninck@eu.didata.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: stella.comtech.be [212.35.105.114] 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_01C2F1DA.02E4D170 Content-Type: text/plain; charset="iso-8859-1" Hi, John You can do that though you need two different Ethernet interfaces. Of course this can be done on physical interface or logical interfaces (dot1q). The thing is that one interface can only be assigned to one VRF. Cheers, -Ives- -----Original Message----- From: John Smith [mailto:jsmith4112003@yahoo.co.uk] Sent: lundi 24 mars 2003 7:53 To: ppvpn@nortelnetworks.com Subject: Re: eth0 and VRFs I am sorry for some ambiguity .. what i had wanted to ask was that can i put two routers connected to my router (on an ethernet) in different VPNs or can i assign them different VRF IDs. AFAIK i need to have two different ethernets to do that wherein each ethernet is assigned a unique VRF. Is my understanding correct? Thanks, Smith ----- Original Message ----- From: "John Smith" To: Sent: Monday, March 24, 2003 11:22 AM Subject: eth0 and VRFs > Hello, > We can put each of our serial links in unique VRFs. Can we do the same for our ethernet > links? > > Let me clarify. > > I can give a following configuration on my router if i have two p2p links from which i > want to connect my two BGP VPN routers. > > ! > interface serial0 > ip vrf forwarding XXXXX > ip address xx.xx.xx.x m.m.m.m > ! > interface serial1 > ip vrf forwarding ZZZZZ > ip address zz.zz.z.z m.m.m.m > ! > > NOw how can i achieve the same using ethernet links. Suppose my router has just one > ethernet card and i want to connect to two BGP VPN routers. How can i do that? > > My setup is as following: > > ______ > | A | > ------ > |eth0 > | > __________ > |(eth0) | eth1 > ----- ----- > | B | | C | > ------ ------ > > I would be very grateful if somebody can help me out or give some pointers. > > Thanks and Waiting, > Warm Regards, > Smith > __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------_=_NextPart_001_01C2F1DA.02E4D170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: eth0 and VRFs

Hi, John

You can do that though you need two different = Ethernet interfaces. Of course this can be done on physical interface = or logical interfaces (dot1q).

The thing is that one interface can only be assigned = to one VRF.

Cheers,

-Ives-

-----Original Message-----
From: John Smith [mailto:jsmith4112003@yahoo.co.= uk]
Sent: lundi 24 mars 2003 7:53
To: ppvpn@nortelnetworks.com
Subject: Re: eth0 and VRFs


I am sorry for some ambiguity .. what i had wanted to = ask was that can i put two routers
connected to my router (on an ethernet) in different = VPNs or can i assign them different
VRF IDs.

AFAIK i need to have two different ethernets to do = that wherein each ethernet is assigned
a unique VRF.

Is my understanding correct?

Thanks,
Smith

----- Original Message -----
From: "John Smith" = <jsmith4112003@yahoo.co.uk>
To: <ppvpn@nortelnetworks.com>
Sent: Monday, March 24, 2003 11:22 AM
Subject: eth0 and VRFs


> Hello,
> We can put each of our serial links in unique = VRFs. Can we do the same for our ethernet
> links?
>
> Let me clarify.
>
> I can give a following configuration on my = router if i have two p2p links from which i
> want to connect my two BGP VPN routers.
>
> !
> interface serial0
> ip vrf forwarding XXXXX
> ip address xx.xx.xx.x m.m.m.m
> !
> interface serial1
> ip vrf forwarding ZZZZZ
> ip address zz.zz.z.z m.m.m.m
> !
>
> NOw  how can i achieve the same using = ethernet links. Suppose my router has just one
> ethernet card and i want to connect to two BGP = VPN routers. How can i do that?
>
> My setup is as following:
>
>          = ; ______
>          = ; | A  |
>          = ; ------
>          = ;    |eth0
>          = ;    |
>          = __________
>        &= nbsp; |(eth0)  | eth1
>        = -----    -----
>        | = B  |   | C  |
>        = ------   ------
>
> I would be very grateful if somebody can help = me out or give some pointers.
>
> Thanks and Waiting,
> Warm Regards,
> Smith
>         =


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

------_=_NextPart_001_01C2F1DA.02E4D170-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 04:37: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 EAA08585 for ; Mon, 24 Mar 2003 04:37:39 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2O9dQm24056 for ; Mon, 24 Mar 2003 04:39:26 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2O9dhP11728 for ; Mon, 24 Mar 2003 04:39:44 -0500 (EST) Message-Id: <4.3.2.7.2.20030323221501.01dabf08@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Mar 2003 01:36:24 -0800 To: Cheng-Yin.Lee@alcatel.com, ppvpn@nortelnetworks.com From: Ali Sajassi Subject: Re: Ali Sajassi's comments on Hybrid VPLS In-Reply-To: <3E796142.18906D3E@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: syd-msg-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: syd-msg-core-1.cisco.com [64.104.193.198] X-LYRIS-Message-Id: Let me give all my comments on the deficiencies of this draft: 1) Need to get the terminologies straight out: the draft talks about an Attachment Circuit as demarcation point between provider's CLE and PE as well as demarcation point between customer's CE and provider's PE. AC as defined in L2VPN framework, refers to demarcation between customer's CE and provider's PE and if you go by this, then the service that is provided by the PEs is basically just VPWS and nothing more !! and there is no reason to mix this up with VPLS service - please refer to L2VPN framework draft. Now if you add in the CLEs in the mix, then AC becomes the demarcation between CEs and CLEs (not between CLEs and PEs) and in that case there are other deficiencies as described below ... 2) With CLEs in the mix, then there are two cases: a) a CLE cannot use VLANs as virtual interfaces and b) a CLE has a magical ability to use VLANs as virtual interfacs. Case (a) is clearly not scalable since one would need as many interfaces on a CE/CLE as number of customer sites - so if a customer has 100 sites, then you need 100 interfaces on the CLEs for that customer alone !!! Case (b) uses VLAN tags not only as service delimiter but also as virtual ports in a CLE and the main premise of this draft is based on this. This concept is nothing new and was first introduced by Kompella in his VPLS draft. But as soon as you introduce such concept, you cannot use typical bridges and you need to develop modified bridges for such functionality which would defeat the purpose of low-cost CLE. If someone wants to develop a modified bridge for using VLAN tags as virtual circuits/ports, then he can as easily develop modified bridge using PWs (either MPLS or L2TPv3) as VCs and this becomes the good old draft-lasserre. 3) Interworking between disparate Attachment Circuits has already been covered by two drafts. draft-shah-ppvpn-arp-mediation talks about interworking for IP end points and draft-sajassi-l2vpn-interworking talks about more general case of interworking and covers interworking for VPLS as well. I didn't see anything new that has not been already covered by these two drafts. 4) Furthermore, ARP-mediation is a PtP mechanism and for multi-point service, IPLS which is based somewhat on ARP-mdediation was introduced. So lets not re-invent the wheel and lets not re-describe IPLS mechanism in here again. 5) Discovery deals with the discovery of members of a VPN and there are already few proposal on the table (e.g., BGP-based, directory-based such as Radius, and MPLS-based). Mapping VLAN-tags to PWs is not related to auto-discovery and such mapping in more general sense (ACs to PWs) has already been described in details in L2VPN framework. 6) STP : if provider's access network is Ethernet (e.g., .1q or QinQ) and these access networks (metro regions) are connected via an MPLS or IP core, then my point was that STP is not suitable for putting everything on one giant flat network and it would create administrative issues. Regards, Ali At 01:35 AM 3/20/2003 -0500, Cheng-Yin Lee wrote: >Ali, >I am trying to understand your comments at PPVPN WG meeting this >afternoon about Spanning Tree and Hybrid VPLS. Could you elaborate pls? > >Thanks, >Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 08:36: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 IAA17001 for ; Mon, 24 Mar 2003 08:36:16 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ODc2m26479 for ; Mon, 24 Mar 2003 08:38:02 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2ODcJP02296 for ; Mon, 24 Mar 2003 08:38:19 -0500 (EST) Message-ID: <3E7F093B.DE029DB5@alcatel.be> Date: Mon, 24 Mar 2003 14:33:47 +0100 From: jeremy.de_clercq@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rahul Aggarwal Cc: Vach Kompella , Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt References: X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/24/2003 14:34:58, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/24/2003 14:35:00, Serialize complete at 03/24/2003 14:35:00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: relay2.alcatel.be X-SMTP-MAIL-FROM: Jeremy.De_Clercq@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc239.alcatel.be [195.207.101.239] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rahul, Vach, why is there a need to differentiate explicitly between point-to-point and VPLS Ethernet PW signalling ? Isn't this done implicitly as the signalled VPN ID (or VC ID) is assigned at both sides either for VPLS or for p2p PW ? thanks, Jeremy. > - draft-lasserre-vkompella-...is a good starting point for a LDP > signaling solution. The major caveat is VPLS/L2-VPN identifier. (Please > see inline) With a common understanding of the how this issue should be > addressed IMHO draft-lasserre-vkompella...should be made a WG doc. [...] > > The points raised in the WG are: > > 1. how to differentiate between a signaled vpls and vpws if the vc type is going > > to be the same? > > 2. how to name a vpls? > > > > For point 1, there are three approaches: > > - go back to using different vc types. The problem is that the vc type relates > > closely to the PW whose behavior is identical to the ethernet vc and the service > > property is above the encapsulation behavior. > > - use a different fec type. draft-martini uses fec type 128, draft-rosen (now > > merged into the WG version of draft-martini) uses fec type 129. VPLS could use > > fec type 130. > > - use a flag in the fec tlv to differentiate between vpls and vpws. In that > > case, we could use fec type 129 and a flag for vpls vs. vpws. > > So I'd like to get some feedback on one of the three above, for starters, or > > some other approach, too. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 11:10: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 LAA24311 for ; Mon, 24 Mar 2003 11:10:49 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OGCam17084 for ; Mon, 24 Mar 2003 11:12:36 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OGCtP15441 for ; Mon, 24 Mar 2003 11:12:55 -0500 (EST) Date: Mon, 24 Mar 2003 09:05:49 -0700 (MST) From: Chris Sieber To: =?iso-8859-1?q?John=20Smith?= Cc: Subject: Re: eth0 and VRFs In-Reply-To: <20030324065248.18117.qmail@web20502.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: qmail.qwest.net X-SMTP-MAIL-FROM: sieber@qmail.qwest.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: qmail.qwest.net [216.111.66.180] X-LYRIS-Message-Id: Not sure if I am understanding, but if you want a single ethernet to multiple vpns, have you tried binding 802.1q to a VRF? Not sure if Cisco does this, but other vendors do. On Mon, 24 Mar 2003, [iso-8859-1] John Smith wrote: > I am sorry for some ambiguity .. what i had wanted to ask was that can i put two routers > connected to my router (on an ethernet) in different VPNs or can i assign them different > VRF IDs. > > AFAIK i need to have two different ethernets to do that wherein each ethernet is assigned > a unique VRF. > > Is my understanding correct? > > Thanks, > Smith > > ----- Original Message ----- > From: "John Smith" > To: > Sent: Monday, March 24, 2003 11:22 AM > Subject: eth0 and VRFs > > > > Hello, > > We can put each of our serial links in unique VRFs. Can we do the same for our ethernet > > links? > > > > Let me clarify. > > > > I can give a following configuration on my router if i have two p2p links from which i > > want to connect my two BGP VPN routers. > > > > ! > > interface serial0 > > ip vrf forwarding XXXXX > > ip address xx.xx.xx.x m.m.m.m > > ! > > interface serial1 > > ip vrf forwarding ZZZZZ > > ip address zz.zz.z.z m.m.m.m > > ! > > > > NOw how can i achieve the same using ethernet links. Suppose my router has just one > > ethernet card and i want to connect to two BGP VPN routers. How can i do that? > > > > My setup is as following: > > > > ______ > > | A | > > ------ > > |eth0 > > | > > __________ > > |(eth0) | eth1 > > ----- ----- > > | B | | C | > > ------ ------ > > > > I would be very grateful if somebody can help me out or give some pointers. > > > > Thanks and Waiting, > > Warm Regards, > > Smith > > > > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 14: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 OAA00049 for ; Mon, 24 Mar 2003 14:33:59 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OJZjm06185 for ; Mon, 24 Mar 2003 14:35:45 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OJa1P07563 for ; Mon, 24 Mar 2003 14:36:02 -0500 (EST) Message-ID: <3E7F5CAA.1C828882@cisco.com> Date: Mon, 24 Mar 2003 11:29:46 -0800 From: Wei Luo X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: Rahul Aggarwal CC: Vach Kompella , Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.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: luo@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 Rahul, > A local PE clearly has to know if the remote PE is capable of doing MAC > address learning over a PW that it has signaled. Else it cannot use that > PW for sending VPLS traffic to the remote PE. Hence the differentiation > you talk about is needed and that is what I meant to convey in my comment > in the WG meeting. Its preferable to convey this in the FEC and it > probably relates to issue #2, though I don't have a strong opinion. What's the reason the local PE has to know whether the remote PE is capable of learning MAC address or not? Isn't that some matter of the remote PE? In the actual ethernet environment, an ethernet switch does not have to know whether it connects to another ethernet switch (capable of learning MAC address) or a dumb repeater (incapable of learning MAC address) on the other side of the wire before it sends/receives traffic to/from it. Do we need to make VPLS different from it? ---Wei From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 14: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 OAA00340 for ; Mon, 24 Mar 2003 14:44:59 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OJkjm10920 for ; Mon, 24 Mar 2003 14:46:46 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OJl1P17142 for ; Mon, 24 Mar 2003 14:47:01 -0500 (EST) Message-Id: <200303241933.h2OJXsiH013236@rtp-core-1.cisco.com> To: vkompella@timetra.com cc: "Ppvpn" Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-reply-to: Your message of Wed, 19 Mar 2003 14:46:53 -0800. 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.2 (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, 24 Mar 2003 14:33:53 -0500 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: With the criterion being that the document is a suitable basis upon which to continue the work, I think this should be a working group document; it certainly meets this criterion. On some specific issues: Vach> 1. how to differentiate between a signaled vpls and vpws if the vc Vach> type is going to be the same? The short answer is that if you want to connect a PW to a VPLS VSI, you use the signaling to identify that VSI. If you want to connect the PW to an Attachment Circuit (VPWS), you use the signaling to identify that Attachment Circuit. If the difference has to do with what you are connecting to, rather than what encapsulation you are using, then the difference should be reflected in how you identify the forwarder, not in the type of PW. But I think that in Hierarchical VPLS, there is a further issue. In Hierarchical VPLS, a PW can fall into one of the following classes: a. it's a Hub-Hub PW, i.e., it connects two Hub VSIs b. it's a Hub-Spoke PW, i.e., it connects a Hub VSI to a Spoke VSI c. it's an "Attachment PW", i.e, it connects an Attachment Circuit to a VSI, where the AC and the VSI are on different PEs A Hub VSI must be able to distinguish the set of Hub-Hub PWs from the other PWs, so that it can correctly apply split horizon to the Hub-Hub PWs only. So in Hierarchical VPLS, you need to know something about the forwarder that the remote endpoint is connected to. I think the most natural way to handle this in LDP would be with an optional TLV whose semantics are "I am a hub VSI". Vach says we need to distinguish between VPLS and VPWS, which is different than distinguishing between Hub-Hub PWs and other PWs. So perhaps I'm misunderstanding the problem, or looking at a different problem. Vach> For point 1, there are three approaches: Vach> - go back to using different vc types. The problem is that the vc Vach> type relates closely to the PW whose behavior is identical to the Vach> ethernet vc and the service property is above the encapsulation Vach> behavior. I don't like this approach; a single PW type should be able to connect to different sorts of applications (i.e., to different sorts of forwarders). We don't want to have to invent a new PW type every time we devise a new PW application. Vach> - use a different fec type. draft-martini uses fec type 128, Vach> draft-rosen (now merged into the WG version of draft-martini) uses Vach> fec type 129. VPLS could use fec type 130. A FEC type is really a specification for identifying a PW (i.e., for identifying the forwarders to which the PW attaches). So I don't think we want to add another FEC type unless we add a fundamentally different way of identifying forwarders. FEC 129 was added because FEC 128 uses a single, fixed length, 32-bit identifier to identify the forwarders, and we wanted to be able to use variable length identifiers instead. Vach> - use a flag in the fec tlv to differentiate between vpls and vpws. Vach> In that case, we could use fec type 129 and a flag for vpls Vach> vs. vpws. A flag in the FEC TLV (or something in the "interface parameters") would be appropriate if we want to make sure that the PW does not get set up if both sides don't agree in advance on what kind of forwarder is at the other end. On the other hand, if we want to be able to discover dynamically (through the signaling) what type of forwarder is at the other end, we would need the optional TLV (not part of the FEC TLV) that I mentioned above. Vach> 2. how to name a vpls? Vach> A VPN ID TLV formatted something like: Vach> 0 1 2 3 Vach> 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 Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vach> | VPNID TLV | Length | VPNID Type | Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vach> | | Vach> ~ VPN ID (variable length) ~ Vach> | | Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vach> The VPN ID Type could then identify the value as any one of flat Vach> 32-bit ID, route target, OUI-based VPN ID (rfc2685), other types Vach> (including AGI, SAII, TAII as used in VPWS for draft-rosen). My take on this is the following. A protocol which creates a connection between two things needs some way to identify those two things. When the connection is a PW, the two things are forwarders. In VPLS and Hierarchical VPLS, when the PW connects two VSIs, we can use a single VPN-id to identify both VSIs. (This works because a single PE can have only one VSI for a given VPLS.) However, if the PW connects an attachment circuit to a remote VSI, one forwarder will have a "VPWS name" of some sort, while the other will have a VPLS name. In VPWS, the names are likely to be different at the two endpoints; in distributed VPLS or GVPLS the names are likely to be different, but related. To try to accommodate all this in a general way, I proposed that the identifier field should be specified as a triple: , where one of the Forwarders has the name and the other has the name . (Others have objected that the identifier should simply consist of a local name and a remote name, without a separate common part. That would work too, though in some cases you might just end up encoding a common part into both names.) In the case of VPLS or Hierarchical VPLS VSI-to-VSI signaling, the local part and remote part could be omitted, and the common part would be the VPLS identifier. In the case of Attachment Circuit to VSI signaling, the common part would still be the VPLS identifier, but the local part (for signaling in the "towards the VSI direction") would be a "VPWS name" identifying the attachment circuit. I'm not sure how Vach proposes to handle this case; perhaps he is thinking that the signaling should be pure VPWS signaling, with the PW connecting a real attachment circuit to a "virtual attachment circuit", where the virtual attachment circuit attaches by configuration to the VSI. This would certainly work, but seems to require more configuration. Vach's proposal and mine differ in the way the identifiers are encoded. I proposed a three-part encoding, with null values for any parts that aren't used. Vach proposes a VPNid Type field, which says (among other things) whether the identifier has one part, two parts, three parts, etc. I don't really care very much about that particular coding detail, but I do think we need a common understanding of how we signal a PW which connects an attachment circuit to a remote VSI. I continue to believe that section 7 of draft-laserre-vkompella should largely be replaced with references to the PWE3 and L2TP documents that specify the signaling. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 16: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 QAA04124 for ; Mon, 24 Mar 2003 16:25:25 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OLRAm15142 for ; Mon, 24 Mar 2003 16:27:10 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OLRSP21656 for ; Mon, 24 Mar 2003 16:27:29 -0500 (EST) Date: Mon, 24 Mar 2003 13:24:39 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Eric Rosen Cc: vkompella@timetra.com, Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-Reply-To: <200303241933.h2OJXsiH013236@rtp-core-1.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: Hi Eric, [clipped] > A flag in the FEC TLV (or something in the "interface parameters") would be > appropriate if we want to make sure that the PW does not get set up if both > sides don't agree in advance on what kind of forwarder is at the other end. > On the other hand, if we want to be able to discover dynamically (through > the signaling) what type of forwarder is at the other end, we would need the > optional TLV (not part of the FEC TLV) that I mentioned above. > Its good to retain the option of not setting up a PW if the two sides do not agree on the forwarder on either end. The forwarder could be an attachment circuit, VSI, spoke/hub attachment etc. Encoding this in the interface parameters seems like a good idea. > Vach> 2. how to name a vpls? > > Vach> A VPN ID TLV formatted something like: > > Vach> 0 1 2 3 > Vach> 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 > Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Vach> | VPNID TLV | Length | VPNID Type | > Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Vach> | | > Vach> ~ VPN ID (variable length) ~ > Vach> | | > Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Vach> The VPN ID Type could then identify the value as any one of flat > Vach> 32-bit ID, route target, OUI-based VPN ID (rfc2685), other types > Vach> (including AGI, SAII, TAII as used in VPWS for draft-rosen). > > > Vach's proposal and mine differ in the way the identifiers are encoded. I > proposed a three-part encoding, with null values for any parts that aren't > used. Vach proposes a VPNid Type field, which says (among other things) > whether the identifier has one part, two parts, three parts, etc. I don't > really care very much about that particular coding detail, but I do think we > need a common understanding of how we signal a PW which connects an > attachment circuit to a remote VSI. I agree with this. The key is to have a common understanding. Having the vpn-type field adds flexibility to the encoding. > > I continue to believe that section 7 of draft-laserre-vkompella should > largely be replaced with references to the PWE3 and L2TP documents that > specify the signaling. > > Wouldn't it be even better to have a common document (for LDP, L2TPv3) that specifies the identifier encoding and possibly signaling ? rahul > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 16:29: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 QAA04233 for ; Mon, 24 Mar 2003 16:29:53 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OLVdm18753 for ; Mon, 24 Mar 2003 16:31:39 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OLVwP26059 for ; Mon, 24 Mar 2003 16:31:59 -0500 (EST) Message-Id: <200303242128.h2OLSmiH007622@rtp-core-1.cisco.com> To: Cheng-Yin.Lee@alcatel.com cc: ppvpn@nortelnetworks.com Subject: Re: Eric Rosen's comments on Hybrid VPLS In-reply-to: Your message of Thu, 20 Mar 2003 01:36:23 -0500. <3E796167.B61637@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.2 (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, 24 Mar 2003 16:28:47 -0500 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: It seems to me that what you call CLEs are really CEs, as the term is generally used in PPVPN. So the solution you are proposing is: a. Interconnect the CEs of a particular customer with a topology of p2p links provided by a VPWS service b. The CEs function as bridges, extending the customer's spanning tree over that p2p topology. My comment is that this solution does not appear to require any new work from the PPVPN WG. From the PPVPN perspective, it is simply VPWS. The fact that the CEs are bridges rather than hosts or routers doesn't matter. I believe this same comment has been made a number of times, by a number of different people. It may well be the case that bridging over VPWS is a good solution. But there's nothing for the PPVPN WG to specify. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 16:32: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 QAA04303 for ; Mon, 24 Mar 2003 16:32:51 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OLYcm22238 for ; Mon, 24 Mar 2003 16:34:38 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OLYvP00252 for ; Mon, 24 Mar 2003 16:34:58 -0500 (EST) Date: Mon, 24 Mar 2003 13:30:56 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Wei Luo Cc: Vach Kompella , Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-Reply-To: <3E7F5CAA.1C828882@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: On Mon, 24 Mar 2003, Wei Luo wrote: > Rahul, > > > A local PE clearly has to know if the remote PE is capable of doing MAC > > address learning over a PW that it has signaled. Else it cannot use that > > PW for sending VPLS traffic to the remote PE. Hence the differentiation > > you talk about is needed and that is what I meant to convey in my comment > > in the WG meeting. Its preferable to convey this in the FEC and it > > probably relates to issue #2, though I don't have a strong opinion. > > What's the reason the local PE has to know whether the remote PE is capable of > learning MAC address or not? Isn't that some matter of the remote PE? There is no reason for the local PE to flood packets over the PW if the other end can't really participate in the VPLS over that PW. > > In the actual ethernet environment, an ethernet switch does not have to know > whether it connects to another ethernet switch (capable of learning MAC address) > or a dumb repeater (incapable of learning MAC address) on the other side of the > wire before it sends/receives traffic to/from it. Do we need to make VPLS > different from it? > The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the forwarder capabilities on that PW can help in flooding optimization, split horizon checks and adds robustness. IMHO there is no point in bringing up the PW if the forwarder capabilities at either end don't match.. rahul > ---Wei > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 16: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 QAA04471 for ; Mon, 24 Mar 2003 16:36:04 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OLbpm25744 for ; Mon, 24 Mar 2003 16:37:52 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OLc9P04857 for ; Mon, 24 Mar 2003 16:38:10 -0500 (EST) Date: Mon, 24 Mar 2003 13:34:08 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: jeremy.de_clercq@alcatel.be Cc: Vach Kompella , Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-Reply-To: <3E7F093B.DE029DB5@alcatel.be> 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: On Mon, 24 Mar 2003 jeremy.de_clercq@alcatel.be wrote: > Rahul, Vach, > > why is there a need to differentiate explicitly between point-to-point > and VPLS Ethernet PW signalling ? Isn't this done implicitly as the > signalled VPN ID (or VC ID) is assigned at both sides either for VPLS or > for p2p PW ? > We shouldn't rely on the identifier semantics to convey the type of the forwarder. One end may be an attachment circuit and the other a VSI with the PW signalled using the same identifier. regards, rahul > thanks, > Jeremy. > > > - draft-lasserre-vkompella-...is a good starting point for a LDP > > signaling solution. The major caveat is VPLS/L2-VPN identifier. (Please > > see inline) With a common understanding of the how this issue should be > > addressed IMHO draft-lasserre-vkompella...should be made a WG doc. > > [...] > > > > The points raised in the WG are: > > > 1. how to differentiate between a signaled vpls and vpws if the vc type is going > > > to be the same? > > > 2. how to name a vpls? > > > > > > For point 1, there are three approaches: > > > - go back to using different vc types. The problem is that the vc type relates > > > closely to the PW whose behavior is identical to the ethernet vc and the service > > > property is above the encapsulation behavior. > > > - use a different fec type. draft-martini uses fec type 128, draft-rosen (now > > > merged into the WG version of draft-martini) uses fec type 129. VPLS could use > > > fec type 130. > > > - use a flag in the fec tlv to differentiate between vpls and vpws. In that > > > case, we could use fec type 129 and a flag for vpls vs. vpws. > > > So I'd like to get some feedback on one of the three above, for starters, or > > > some other approach, too. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 17:55: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 RAA07066 for ; Mon, 24 Mar 2003 17:55:17 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2OMv5m22756 for ; Mon, 24 Mar 2003 17:57:05 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2OMvNP14974 for ; Mon, 24 Mar 2003 17:57:24 -0500 (EST) Message-ID: <3E7F8C4F.5FAB67F9@cisco.com> Date: Mon, 24 Mar 2003 14:53:03 -0800 From: Wei Luo X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: Rahul Aggarwal CC: Vach Kompella , Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.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: luo@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 Rahul Aggarwal wrote: > > On Mon, 24 Mar 2003, Wei Luo wrote: > > > Rahul, > > > > > A local PE clearly has to know if the remote PE is capable of doing MAC > > > address learning over a PW that it has signaled. Else it cannot use that > > > PW for sending VPLS traffic to the remote PE. Hence the differentiation > > > you talk about is needed and that is what I meant to convey in my comment > > > in the WG meeting. Its preferable to convey this in the FEC and it > > > probably relates to issue #2, though I don't have a strong opinion. > > > > What's the reason the local PE has to know whether the remote PE is capable of > > learning MAC address or not? Isn't that some matter of the remote PE? > > There is no reason for the local PE to flood packets over the PW if the > other end can't really participate in the VPLS over that PW. For unknown unicast and broadcast packet, you will have to flood it regardless of the capability of the remote end, won't you? Otherwise, you lose packets and have a connectivity problem. > > In the actual ethernet environment, an ethernet switch does not have to know > > whether it connects to another ethernet switch (capable of learning MAC address) > > or a dumb repeater (incapable of learning MAC address) on the other side of the > > wire before it sends/receives traffic to/from it. > > Do we need to make VPLS > > different from it? > > > > The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the > forwarder capabilities on that PW can help in flooding optimization, split > horizon checks and adds robustness. IMHO there is no point in bringing up > the PW if the forwarder capabilities at either end don't match.. Shouldn't we use some kind of capability TLV in this case, which has more extensibility and better semantics than PW type? ---Wei From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 19:56: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 TAA11829 for ; Mon, 24 Mar 2003 19:56:23 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2P0uxm09562 for ; Mon, 24 Mar 2003 19:57:00 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2P0vIP13070 for ; Mon, 24 Mar 2003 19:57:19 -0500 (EST) Date: Mon, 24 Mar 2003 16:54:26 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Wei Luo Cc: Vach Kompella , Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-Reply-To: <3E7F8C4F.5FAB67F9@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: On Mon, 24 Mar 2003, Wei Luo wrote: > > > Rahul Aggarwal wrote: > > > > On Mon, 24 Mar 2003, Wei Luo wrote: > > > > > Rahul, > > > > > > > A local PE clearly has to know if the remote PE is capable of doing MAC > > > > address learning over a PW that it has signaled. Else it cannot use that > > > > PW for sending VPLS traffic to the remote PE. Hence the differentiation > > > > you talk about is needed and that is what I meant to convey in my comment > > > > in the WG meeting. Its preferable to convey this in the FEC and it > > > > probably relates to issue #2, though I don't have a strong opinion. > > > > > > What's the reason the local PE has to know whether the remote PE is capable of > > > learning MAC address or not? Isn't that some matter of the remote PE? > > > > There is no reason for the local PE to flood packets over the PW if the > > other end can't really participate in the VPLS over that PW. > > For unknown unicast and broadcast packet, you will have to flood it regardless > of the capability of the remote end, won't you? Otherwise, you lose packets and > have a connectivity problem. Agreed. But if the other end can't learn over that PW, its not really participating in the VPLS.. > > > > In the actual ethernet environment, an ethernet switch does not have to know > > > whether it connects to another ethernet switch (capable of learning MAC address) > > > or a dumb repeater (incapable of learning MAC address) on the other side of the > > > wire before it sends/receives traffic to/from it. > > > > Do we need to make VPLS > > > different from it? > > > > > > > The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the > > forwarder capabilities on that PW can help in flooding optimization, split > > horizon checks and adds robustness. IMHO there is no point in bringing up > > the PW if the forwarder capabilities at either end don't match.. > > Shouldn't we use some kind of capability TLV in this case, which has more > extensibility and better semantics than PW type? Very true. This was well summarised by Eric in his response on this issue.. rahul > > ---Wei > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 22:10: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 WAA15518 for ; Mon, 24 Mar 2003 22:10:19 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2P3C5m23933 for ; Mon, 24 Mar 2003 22:12:06 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2P3COP10307 for ; Mon, 24 Mar 2003 22:12:24 -0500 (EST) 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: draft-lasserre-vkompella-ppvpn-vpls-04.txt Date: Mon, 24 Mar 2003 22:09:11 -0500 Message-ID: <4E43B7A82443DE478E08E0D08C0CF18E225067@m-va-bsod03.add0.masergy.com> Thread-Topic: draft-lasserre-vkompella-ppvpn-vpls-04.txt Thread-Index: AcLyaU8A2x+qzcogTEuT+iaXwfhLRAAEe9cp From: "Ron Haberman" To: "Rahul Aggarwal" , "Wei Luo" Cc: "Vach Kompella" , "Ppvpn" 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 base64 to 8bit by ietf.org id WAA15518 -----Original Message----- From: Rahul Aggarwal [mailto:rahul@redback.com] Sent: Mon 3/24/2003 7:54 PM To: Wei Luo Cc: Vach Kompella; Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt On Mon, 24 Mar 2003, Wei Luo wrote: > > > Rahul Aggarwal wrote: > > > > On Mon, 24 Mar 2003, Wei Luo wrote: > > > > > Rahul, > > > > > > > A local PE clearly has to know if the remote PE is capable of doing MAC > > > > address learning over a PW that it has signaled. Else it cannot use that > > > > PW for sending VPLS traffic to the remote PE. Hence the differentiation > > > > you talk about is needed and that is what I meant to convey in my comment > > > > in the WG meeting. Its preferable to convey this in the FEC and it > > > > probably relates to issue #2, though I don't have a strong opinion. > > > > > > What's the reason the local PE has to know whether the remote PE is capable of > > > learning MAC address or not? Isn't that some matter of the remote PE? > > > > There is no reason for the local PE to flood packets over the PW if the > > other end can't really participate in the VPLS over that PW. > > For unknown unicast and broadcast packet, you will have to flood it regardless > of the capability of the remote end, won't you? Otherwise, you lose packets and > have a connectivity problem. >Agreed. But if the other end can't learn over that PW, its not really >participating in the VPLS.. Ron> unless another bridge is connected to the PW (either internally or though another device). That bridge might be learning. A good example is a bridge connected to a VPLS cloud though a PW. > > > > In the actual ethernet environment, an ethernet switch does not have to know > > > whether it connects to another ethernet switch (capable of learning MAC address) > > > or a dumb repeater (incapable of learning MAC address) on the other side of the > > > wire before it sends/receives traffic to/from it. > > > > Do we need to make VPLS > > > different from it? > > > > > > > The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the > > forwarder capabilities on that PW can help in flooding optimization, split > > horizon checks and adds robustness. IMHO there is no point in bringing up > > the PW if the forwarder capabilities at either end don't match.. > > Shouldn't we use some kind of capability TLV in this case, which has more > extensibility and better semantics than PW type? Very true. This was well summarised by Eric in his response on this issue.. rahul > > ---Wei > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 24 22:20: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 WAA15995 for ; Mon, 24 Mar 2003 22:20:17 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2P3M0m27388 for ; Mon, 24 Mar 2003 22:22:00 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2P3MHP15072 for ; Mon, 24 Mar 2003 22:22:18 -0500 (EST) Date: Mon, 24 Mar 2003 19:19:20 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Ron Haberman Cc: Wei Luo , Vach Kompella , Ppvpn Subject: RE: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-Reply-To: <4E43B7A82443DE478E08E0D08C0CF18E225067@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: On Mon, 24 Mar 2003, Ron Haberman wrote: > > > -----Original Message----- > From: Rahul Aggarwal [mailto:rahul@redback.com] > Sent: Mon 3/24/2003 7:54 PM > To: Wei Luo > Cc: Vach Kompella; Ppvpn > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt > > > > > > > On Mon, 24 Mar 2003, Wei Luo wrote: > > > > > > > Rahul Aggarwal wrote: > > > > > > On Mon, 24 Mar 2003, Wei Luo wrote: > > > > > > > Rahul, > > > > > > > > > A local PE clearly has to know if the remote PE is capable of doing MAC > > > > > address learning over a PW that it has signaled. Else it cannot use that > > > > > PW for sending VPLS traffic to the remote PE. Hence the differentiation > > > > > you talk about is needed and that is what I meant to convey in my comment > > > > > in the WG meeting. Its preferable to convey this in the FEC and it > > > > > probably relates to issue #2, though I don't have a strong opinion. > > > > > > > > What's the reason the local PE has to know whether the remote PE is capable of > > > > learning MAC address or not? Isn't that some matter of the remote PE? > > > > > > There is no reason for the local PE to flood packets over the PW if the > > > other end can't really participate in the VPLS over that PW. > > > > For unknown unicast and broadcast packet, you will have to flood it regardless > > of the capability of the remote end, won't you? Otherwise, you lose packets and > > have a connectivity problem. > > >Agreed. But if the other end can't learn over that PW, its not really > >participating in the VPLS.. > > > Ron> unless another bridge is connected to the PW (either internally or though another device). That bridge might be learning. A good example is a bridge connected to a VPLS cloud though a PW. > True. I would consider the PW to be participating in the VPLS in that case and it should be signaled appropriately. Similar situation also arises in hierarchical VPLS. > > > > > > In the actual ethernet environment, an ethernet switch does not have to know > > > > whether it connects to another ethernet switch (capable of learning MAC address) > > > > or a dumb repeater (incapable of learning MAC address) on the other side of the > > > > wire before it sends/receives traffic to/from it. > > > > > > Do we need to make VPLS > > > > different from it? > > > > > > > > > > The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the > > > forwarder capabilities on that PW can help in flooding optimization, split > > > horizon checks and adds robustness. IMHO there is no point in bringing up > > > the PW if the forwarder capabilities at either end don't match.. > > > > Shouldn't we use some kind of capability TLV in this case, which has more > > extensibility and better semantics than PW type? > > Very true. This was well summarised by Eric in his response on this > issue.. > > rahul > > > > > ---Wei > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Mar 25 02:25: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 CAA02312 for ; Tue, 25 Mar 2003 02:25:44 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2P7RQV26512 for ; Tue, 25 Mar 2003 02:27:26 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2P7RiY19734 for ; Tue, 25 Mar 2003 02:27:45 -0500 (EST) Message-Id: <4.3.2.7.2.20030324224134.01e9ad00@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Mar 2003 23:23:33 -0800 To: erosen@cisco.com, vkompella@timetra.com From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt Cc: "Ppvpn" In-Reply-To: <200303241933.h2OJXsiH013236@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: syd-msg-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: syd-msg-core-1.cisco.com [64.104.193.198] X-LYRIS-Message-Id: At 02:33 PM 3/24/2003 -0500, Eric Rosen wrote: >With the criterion being that the document is a suitable basis upon which to >continue the work, I think this should be a working group document; it >certainly meets this criterion. > >On some specific issues: > >Vach> 1. how to differentiate between a signaled vpls and vpws if the vc >Vach> type is going to be the same? > >The short answer is that if you want to connect a PW to a VPLS VSI, you use >the signaling to identify that VSI. If you want to connect the PW to an >Attachment Circuit (VPWS), you use the signaling to identify that >Attachment Circuit. If the difference has to do with what you are >connecting to, rather than what encapsulation you are using, then the >difference should be reflected in how you identify the forwarder, not in the >type of PW. > >But I think that in Hierarchical VPLS, there is a further issue. In >Hierarchical VPLS, a PW can fall into one of the following classes: > >a. it's a Hub-Hub PW, i.e., it connects two Hub VSIs > >b. it's a Hub-Spoke PW, i.e., it connects a Hub VSI to a Spoke VSI > >c. it's an "Attachment PW", i.e, it connects an Attachment Circuit to a VSI, > where the AC and the VSI are on different PEs > >A Hub VSI must be able to distinguish the set of Hub-Hub PWs from the other >PWs, so that it can correctly apply split horizon to the Hub-Hub PWs >only. So in Hierarchical VPLS, you need to know something about the >forwarder that the remote endpoint is connected to. > >I think the most natural way to handle this in LDP would be with an optional >TLV whose semantics are "I am a hub VSI". > >Vach says we need to distinguish between VPLS and VPWS, which is different >than distinguishing between Hub-Hub PWs and other PWs. So perhaps I'm >misunderstanding the problem, or looking at a different problem. Eric, you're right on the money. One additional comment that I'd like to add is that the split-horizon for hub-to-hub PW is really a local function and it should be configured locally. However, the remote-end indication would provide additional check for the other half of the PW. If the two halves have the same setting/indications and it is consistent w/ local config, then the PW should be established; otherwise, it should not. Also this type of check would be viable for symmetric connection (e.g., PtP PW) and not for asymmetric connections such as PtMP or MPtP PWs. Even for symmetric connection, if the operator makes double errors, then it cannot be detected. So signaling "I am a hub VSI" during PW setup can be helpful for HVPLS but it has its limitations. >Vach> For point 1, there are three approaches: > >Vach> - go back to using different vc types. The problem is that the vc >Vach> type relates closely to the PW whose behavior is identical to the >Vach> ethernet vc and the service property is above the encapsulation >Vach> behavior. > >I don't like this approach; a single PW type should be able to connect to >different sorts of applications (i.e., to different sorts of forwarders). >We don't want to have to invent a new PW type every time we devise a new >PW application. > >Vach> - use a different fec type. draft-martini uses fec type 128, >Vach> draft-rosen (now merged into the WG version of draft-martini) uses >Vach> fec type 129. VPLS could use fec type 130. > >A FEC type is really a specification for identifying a PW (i.e., for >identifying the forwarders to which the PW attaches). So I don't think we >want to add another FEC type unless we add a fundamentally different way of >identifying forwarders. FEC 129 was added because FEC 128 uses a single, >fixed length, 32-bit identifier to identify the forwarders, and we wanted to >be able to use variable length identifiers instead. > >Vach> - use a flag in the fec tlv to differentiate between vpls and vpws. >Vach> In that case, we could use fec type 129 and a flag for vpls >Vach> vs. vpws. > >A flag in the FEC TLV (or something in the "interface parameters") would be >appropriate if we want to make sure that the PW does not get set up if both >sides don't agree in advance on what kind of forwarder is at the other end. >On the other hand, if we want to be able to discover dynamically (through >the signaling) what type of forwarder is at the other end, we would need the >optional TLV (not part of the FEC TLV) that I mentioned above. > >Vach> 2. how to name a vpls? > >Vach> A VPN ID TLV formatted something like: > >Vach> 0 1 2 3 >Vach> 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 >Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >Vach> | VPNID TLV | Length | VPNID Type | >Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >Vach> | | >Vach> ~ VPN ID (variable length) ~ >Vach> | | >Vach> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Vach> The VPN ID Type could then identify the value as any one of flat >Vach> 32-bit ID, route target, OUI-based VPN ID (rfc2685), other types >Vach> (including AGI, SAII, TAII as used in VPWS for draft-rosen). > >My take on this is the following. A protocol which creates a connection >between two things needs some way to identify those two things. When the >connection is a PW, the two things are forwarders. > >In VPLS and Hierarchical VPLS, when the PW connects two VSIs, we can use a >single VPN-id to identify both VSIs. (This works because a single PE can >have only one VSI for a given VPLS.) However, if the PW connects an >attachment circuit to a remote VSI, one forwarder will have a "VPWS name" of >some sort, while the other will have a VPLS name. In VPWS, the names are >likely to be different at the two endpoints; in distributed VPLS or GVPLS >the names are likely to be different, but related. > >To try to accommodate all this in a general way, I proposed that the >identifier field should be specified as a triple: remote part>, where one of the Forwarders has the name part> and the other has the name . (Others have >objected that the identifier should simply consist of a local name and a >remote name, without a separate common part. That would work too, though in >some cases you might just end up encoding a common part into both names.) > >In the case of VPLS or Hierarchical VPLS VSI-to-VSI signaling, the local >part and remote part could be omitted, and the common part would be the VPLS >identifier. In the case of Attachment Circuit to VSI signaling, the common >part would still be the VPLS identifier, but the local part (for signaling >in the "towards the VSI direction") would be a "VPWS name" identifying the >attachment circuit. I'm not sure how Vach proposes to handle this case; >perhaps he is thinking that the signaling should be pure VPWS signaling, >with the PW connecting a real attachment circuit to a "virtual attachment >circuit", where the virtual attachment circuit attaches by configuration to >the VSI. This would certainly work, but seems to require more >configuration. > >Vach's proposal and mine differ in the way the identifiers are encoded. I >proposed a three-part encoding, with null values for any parts that aren't >used. Vach proposes a VPNid Type field, which says (among other things) >whether the identifier has one part, two parts, three parts, etc. I don't >really care very much about that particular coding detail, but I do think we >need a common understanding of how we signal a PW which connects an >attachment circuit to a remote VSI. Using a VPN-id with three parts identifier (e.g., SAII, AGI, and TAII) doesn't fit well since VPN-id is intuitively associated with a common identifier (AGI). So I would favor the first approach of having three-part encoding with null values for any unused parts. >I continue to believe that section 7 of draft-laserre-vkompella should >largely be replaced with references to the PWE3 and L2TP documents that >specify the signaling. Yes, given that PW signaling is covering it, we should leverage it for HVPLS. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Mar 25 02:39: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 CAA02737 for ; Tue, 25 Mar 2003 02:39:58 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2P7fjV00446 for ; Tue, 25 Mar 2003 02:41:45 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2P7g4Y26106 for ; Tue, 25 Mar 2003 02:42:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030324232538.01ef42c8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Mar 2003 23:38:03 -0800 To: Rahul Aggarwal , Wei Luo From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt Cc: Vach Kompella , Ppvpn In-Reply-To: References: <3E7F5CAA.1C828882@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: syd-msg-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: syd-msg-core-1.cisco.com [64.104.193.198] X-LYRIS-Message-Id: At 01:30 PM 3/24/2003 -0800, Rahul Aggarwal wrote: >The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the >forwarder capabilities on that PW can help in flooding optimization, split >horizon checks and adds robustness. IMHO there is no point in bringing up >the PW if the forwarder capabilities at either end don't match.. There are valid HVPLS scenarios where the forwarder capabilities at the two ends don't match - e.g., PW connection between PE-r and PE-rs. The setting of split-horizon capability is a local matter; however, providing forwarder capability indication provides additional check. In other words, for a PW to become active, then: a) if it is configured locally w/ split horzion, then both halves of PWs need to indicate VSI capability b) if it is not configured locally w/ slit horizon, then one half of PW need to indicate non-VSI capability As I mentioned earlier this checking is valid for symmetric PtP PW and for detecting a single operator error (not for double error). -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Mar 25 13:49: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 NAA25095 for ; Tue, 25 Mar 2003 13:49:05 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PIorV06881 for ; Tue, 25 Mar 2003 13:50:53 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2PIpCY12883 for ; Tue, 25 Mar 2003 13:51:12 -0500 (EST) Date: Tue, 25 Mar 2003 10:46:30 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Ali Sajassi Cc: Wei Luo , Vach Kompella , Ppvpn Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt In-Reply-To: <4.3.2.7.2.20030324232538.01ef42c8@airborne.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: On Mon, 24 Mar 2003, Ali Sajassi wrote: > At 01:30 PM 3/24/2003 -0800, Rahul Aggarwal wrote: > >The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the > >forwarder capabilities on that PW can help in flooding optimization, split > >horizon checks and adds robustness. IMHO there is no point in bringing up > >the PW if the forwarder capabilities at either end don't match.. > > There are valid HVPLS scenarios where the forwarder capabilities at the two > ends don't match - e.g., PW connection between PE-r and PE-rs. The setting > of split-horizon capability is a local matter; however, providing forwarder > capability indication provides additional check. In other words, for a PW > to become active, then: True. There are caveats to my statement. Probably a better way to put it is to say that the PW should be brought up only if the forwarder capabilities match the expected criterion, which is dictated by the application. > > a) if it is configured locally w/ split horzion, then both halves of PWs > need to indicate VSI capability > b) if it is not configured locally w/ slit horizon, then one half of PW > need to indicate non-VSI capability > > As I mentioned earlier this checking is valid for symmetric PtP PW and for > detecting a single operator error (not for double error). > > -Ali > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Mar 27 07:50: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 HAA25869 for ; Thu, 27 Mar 2003 07:50:34 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RCpvY09110 for ; Thu, 27 Mar 2003 07:52:01 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2RCqHr14154 for ; Thu, 27 Mar 2003 07:52:17 -0500 (EST) Message-Id: <200303271246.HAA25527@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-framework-08.txt Date: Thu, 27 Mar 2003 07:46:33 -0500 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 : A Framework for Layer 3 Provider Provisioned Virtual Private Networks Author(s) : R. Callon, M. Suzuki Filename : draft-ietf-ppvpn-framework-08.txt Pages : 80 Date : 2003-3-26 This document provides a framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues which are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-framework-08.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-framework-08.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-framework-08.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-3-26123046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-framework-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-framework-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26123046.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Mar 27 08:27: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 IAA28386 for ; Thu, 27 Mar 2003 08:27:31 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RDTLY21370 for ; Thu, 27 Mar 2003 08:29:21 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2RDTgr27015 for ; Thu, 27 Mar 2003 08:29:43 -0500 (EST) Message-ID: <3549C09B853DD5119B540002A52CDD3406BE1067@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: ppvpn@nortelnetworks.com Subject: Suggestion for VR MIB Date: Thu, 27 Mar 2003 08:26:33 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-LYRIS-Message-Id: hi I think the discussion of the "admin" context and the fact that there are single instances of the Interfaces, Entity and ATM MIBs that live in this context needs to be highlighted more in section 7.1. It is in the picture in that section and implied by the fact there is a MIB table that maps from interfaces to virtual router IDs, but this is really easy to miss on a first/second pass. Another point that you may want to highlight is that for tables instantiated in the virtual router, indexing can only be assumed unique for that particular VR, but those in the "admin" context are unique across the entire system, including all VRs. Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Mar 27 19:47: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 TAA28941 for ; Thu, 27 Mar 2003 19:47:03 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2S0mrY20724 for ; Thu, 27 Mar 2003 19:48:53 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2S0nEr02386 for ; Thu, 27 Mar 2003 19:49:15 -0500 (EST) Date: Fri, 28 Mar 2003 09:45:52 +0900 (JST) Message-Id: <20030328.094552.41174075.suzuki.muneyoshi@lab.ntt.co.jp> To: ppvpn@nortelnetworks.com Subject: Re: I-D ACTION:draft-ietf-ppvpn-framework-08.txt From: Muneyoshi Suzuki 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 Dear, Based on the IESG comments, the L3 FW doc is updated. There are no technical changes but nits are fixed. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. ----- --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 : A Framework for Layer 3 Provider Provisioned Virtual Private Networks Author(s) : R. Callon, M. Suzuki Filename : draft-ietf-ppvpn-framework-08.txt Pages : 80 Date : 2003-3-26 This document provides a framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues which are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-framework-08.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-framework-08.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-framework-08.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-3-26123046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-framework-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-framework-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26123046.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Mar 28 10:10: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 KAA02271 for ; Fri, 28 Mar 2003 10:10:04 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2SF9bR17905 for ; Fri, 28 Mar 2003 10:09:38 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2SF9qX29654 for ; Fri, 28 Mar 2003 10:09:52 -0500 (EST) Date: Fri, 28 Mar 2003 10:05:36 -0500 From: oscarjohnson100@netscape.net To: ppvpn@lyris.nortelnetworks.com Subject: HELLO MIME-Version: 1.0 Message-ID: <0ECF644E.2C1B3320.79C1D4DC@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: oscarjohnson100@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 Mr Defeng, thank you for your reply.i quite appreciate your frank and honest concern.i hope you were not too embarassed by my letter because you do not know me.but you must realise that my family and i have found ourselves in a situation we never expected.now i just have to try to contact anybody out there that can be of help to us since we do not have any relatives or friends outside Sierra leone.i actually got your email address from the chamber of commerce directory as i said before,and i thought i should introduce myself and the terrible situation   me and my family have found ourselves.this is a very physical transaction that will see you coming to The Netherlands to meet with me, inspect the money and effect the transfer to your account. the transaction is completely legal and the documents are not a problem.but you must realise that there should be some form of familiarity and confidence on both our part before this transaction can continue.these documents are very confidential as they prove the existence of this fund.there are various government interests back in my home country who would be more than willing to confisticate this fund and share it among themselves,so i have to be careful.we must first have to determine; 1.the suitability of your country for this kind of transfer 2.your expressed willingness to conclude this transaction 3.the capability of your account to absorb this amount of money either in one single transfer or multiple transfers 4.the safety of such a huge amount and the ease of us repossessing our part after the transfer(so there is no repeat of our present predicament). 5.how convenient it is for you to meet me in The Netherlands as soon as possible so we can together go to the finance and security company to inspect the consignment and effect the transfer to your account. 6.that you will do everything within your power to help me and my family relocate to your country after the money is transferred to your account. once you get back to me on these issues,then i can send you a copy of the certificate of deposit,photos of the consignment,the contact address,phone numbers and website of the private security company holding the fund. this is also in a bid to acquaint you with the summary of the transaction.i will explain it in simple terms,but if you have any questions,you can always ask so i explain better. the issue here is that i cannot assess the money my father deposited before his death(due to circumstances i already explained in my first mail to you).the circumstances and the laws covering my stay  here(as a political refugee) would not allow me keep and invest that kind of large amount of money.besides,some european countries have a history of returning such large amounts back to the depositors' country,labelling it as "stolen" money. there are documents to show that my father deposited this money,that i will send to you to allay your fears.i will also forward to you,the contact address and phone numbers of the private  finance and security company;and they can assure you that the money is not in anyway related to drugs,prostitution or gambling. what we want is a trustworthy and reliable person who would become the beneficiary(after we might have prepared and signed the necessary change of beneficiary documents) and the money is then transferred into your accout.me and my other family members will then emigrate to your country,after which the money is transferred to our care and you get 20% of the sum for your   kindness and co-operation.you understand that this is the delicate aspect of this transaction.otherwise there are millions of people out there who would be more than willing to do this.but are they trustworthy? this transaction is completely legal and straigthforward.as soon as i get your telephone number,we would begin farmiliarisation which is very important in establishing trust and confidence.you must forgive my caution here.but you will also understand that the amount is a lump sum and the circumstances are quite perculiar,especially since we have lost everything we own. thanks for sending your telephone and fax numbers.i will call you as soon as possible so we can communicate more effectively and discuss the fine points of this transaction.but for now,the summary of the transaction will be as follows, 1. i will contact my family members,meet with the security company and my lawyer here, 2.send you a copy of the certificate of deposit,and have the lawyers prepare the power of attorney authorising you as the beneficiary of the fund. 3.then you will have to come to The Netherlands as soon as possible so i can meet you in person and conclude how the money will be held in safe trust. 4. we will together go to the security company,inspect the money and effect the transfer to the account you will provide. if you have further questions as regards this transaction,please ask,and i will make things clearer to you. Regards, OSCAR JOHNSON __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promos=380455 From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Mar 28 10:41: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 KAA04216 for ; Fri, 28 Mar 2003 10:41:43 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2SFhYR26069 for ; Fri, 28 Mar 2003 10:43:34 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2SFhtX23093 for ; Fri, 28 Mar 2003 10:43:56 -0500 (EST) Date: Fri, 28 Mar 2003 16:33:24 +0100 Message-Id: Subject: =?iso-8859-1?Q?BUSINESS_INTENT.?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?seafordezego?=" To: "=?iso-8859-1?Q?seafordezego?=" X-XaM3-API-Version: 3.2 R27 (B52-pl1) X-type: 0 X-SenderIP: 81.23.204.151 X-SMTP-HELO: mailsmtp5.ftmms X-SMTP-MAIL-FROM: seafordezego@voila.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp-out.voila.wanadooportails.com [193.252.117.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04216 From the Desk of: DR.SEAFORD EZEGO HEAD, ACCOUNT DEPARTMENT CONTINENTAL TRUST BANK OF NIGERIA PLC. LAGOS. seafordezego@sify.com Fax:234-1-7597002 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 IAM ASSURING YO 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 DR SEAFORD EZEGO,AN ACCOUNTANT WITH THE CONTINENTAL TRUST BANK OF NIGERIA 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 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 CONTINENTAL TRUST BANK OF NIGERIA,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, EFFORTS WERE MADE BY UNION BANK OF NIGERIA 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. GUEL'S NEXT-OF-KIN(HE WIFE AND CHILDREN) THAT THE MANAGEMENT THE BOARD OF DIRECTORS, UNDER THE CHAIMANSHIP OF MAJOR- GENERAL KALU UKE KALU(Rtd), REACHED AN AGREEMENT THAT THE FUND SHOULD BE DECLARED"UN-CLAIMABLE" AND 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 ANDINVESTMENT COMPANY AT NUMBER 121, WEST 55TH STREET,21st FLOOR, NEW YORK,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 DECIDE USE 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 ANDDILIGENCE. (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 ALREDY BEHIND SCHEDULE FOR THIS FINANCIAL QUATER. IF THIS PROPOSAL IS ALRIGHT BY YOU,THEN KINDLY GET TO ME IMMEDIATELY ON EMAIL ADRESS FOR CONFIDENTIALITY. THANK YOU IN ANTICIPATON OF YOUR COOPERATION. YOURS FAITHFULLY, DR.SEAFORD EZEGO( Chief Accountant) CONTINENTAL TRUST BANK OF NIG. PLC. LAGOS. ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 31 11:17: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 LAA12740 for ; Mon, 31 Mar 2003 11:17:40 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2VGJSi16592 for ; Mon, 31 Mar 2003 11:19:29 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2VGJoM29685 for ; Mon, 31 Mar 2003 11:19:51 -0500 (EST) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Cc: "Marco Carugi" , "'Rick Wilder'" Subject: San Francisco PPVPN WG minutes Date: Mon, 31 Mar 2003 18:16:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F7A0.E00A4474" 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_01C2F7A0.E00A4474 Content-Type: text/plain; charset="iso-8859-1" All, below the minutes of our SF meeting - recorded by Ananth (thanks !!) with some changes/additions by myself. Please comment before the end of this week. Meeting presentations (some are still missing) will be available in one/two days on the informal PPVPN server at http://standards.nortelnetworks.com/ppvpn/calendar.htm (SF area) Thanks, Marco ---------------------------------------------------------------------------- --------------------- PPVPN meeting - 56th IETF - March 19, 2003 - San Francisco, CA ---------------------------------------------------------------------------- --------------------- Minutes recorded by Ananth Nagarajan, some changes/additions by Marco Carugi 1. Marco - Agenda bashing and WG status -------------------------------------------------------------- Marco started with agenda bashing, then gave a status report of the WG. The layer 3 requirements and framework drafts have been submitted to the IESG for consideration as Informational RFCs. The next step is to have WG last calls for the candidate L3 approaches before submission to IESG (2547bis and VR) for proposed standard in a few weeks. Complementary documents will follow this. Corresponding L2 documents would be progressed in the next months before the July meeting. The L3 framework and requirements documents received comments from IESG. The generic requirements draft also needs resolution of comments of IESG. All these drafts would be sent back to IESG in few days. Draft-ietf-ppvpn-ce-based draft will be discontinued as part of it has been integrated in L3 framework, other part in draft-declercq-ppvpn-ce-based-sol-00. WG last call of CE-based IPSec VPN solution ID is targeted before next IETF. Effective progress of the applicability statement guidelines draft is not clear, discussion is needed. The terminology draft and first l2 solution documents will be moved to WG soon after the meeting. The metrics draft will be discontinued (proposal of the L2 team, agreed by AD too), the L2 reqts draft becoming the single basic reference for solutions. The L2 requirements document (L2 team product) needs wider review by the whole WG. The l2 Framework document is in good shape. Both these documents are being targeted for IESG submission in the April-May 2003 timeframe. There are currently no WG documents in the L2 solution space. All design teams, except the L2 design team, have basically concluded their tasks. The L2 team will be closed now, although the team list will continue to live until completion of L2 reqts and L2 framework documents. Marco gave an update on L2 design team discussions. The functional decomposition recommended in Atlanta aimed to complete a set of functional documents, whose initial content was produced by 4 team members for the interim meeting in Billerica - January 2003. The result of discussions in Billerica (Scott attended too) was to discontinue the work on functional decomposition. Other meeting outcome : solutions documents will have to include a requirements compliance section; design team will not recommend any specific solution ID to the WG, discussions and decisions will be made based on mailing list input. Most of (not all) team members favoured the progress of the L2 solution documents as experimental, and not standard track, for now, but this needs to be discussed further by the whole WG. The status as of now for L2 documents is that the optional template has not been widely adopted, few solution IDs contain the reqts compliance section, WG list discussion on various solutions has not happened yet. Wide participation of WG is requested to progress this work soon, by selecting a number of solutions documents in L2 space (need that authors update their solution IDs with reqts compliance section, and start discussion on their document on the list). Current milestones indicate L2 solutions submission to IESG in June, but it will require confirmation (Applicability Statements and MIBs work has not started yet). There is a clear need to have strict relationships with protocol specific WGs for protocol extensions in PPVPN. To evaluate the interest of requesting rechartering of the PPVPN WG at a certain point in time to remove the restriction on protocol development. Alex: Clarified that there is no current intention to take the work of other WGs on protocol deployment and do it in PPVPN. Francois: Didn't mention IPv6 VPN document that is a WG document. Checking if the status has changed. Marco - No. Draft not mentioned explicitly for brevity, but it is in. Further work to be done in PPVPN in terms of QoS, security and management frameworks : WG input is needed to focus areas of development. L2 interworking and service OAM were brought up for discussion in the L2 team: Marco's proposals in this meeting on such items need to be discussed on the list. Other topics for future discussion include multicast, l1/optical VPN and wireless VPN. Alex: There is a lot of work that PPVPN needs to do, that it has not finished. So let us not extend the charter. Marco: It's agreed that multicast, l1/optical VPN and wireless VPN are not WG items for now. ----- 2. Jeremy DeClercq - CE-based L3 PPVPN progress ---------------------------------------------------------------------------- Jeremy gave an update on the CE-based L3 space. draft-declercq-ppvpn-ce-based-sol-00 is proposed as PPVPN CE-based IPSec solution document. Draft-ietf-ppvpn-ce-based will be discontinued and kept for reference only. Clarifications on management responsibility, routing realms and Internet access, auto-discovery were made. Future steps include making this a WG document and progressing the corresponding AS document. Joe Touch: We have running code that is similar to this draft, except it is push-based, and not pull-based. Also it has not been cited as reference. 90% is similar to this document, 10 % is different. We have running code. Jeremy : It will be discussed. Alex Zinin : Is there consensus on the 10% difference? Running code is not enough, need to come to the WG and ask for consensus. Joe Touch: Also need to read prior work and cite reference. Dimitri: What is meant by "what to do with draft-ietf-ppvpn-ce-based?" Jeremy: Parts of this document were moved to L3 framework document. The solution specific part has been taken into draft-declercq-ppvpn-ce-based-sol-00. ----- 3. Robert Jaksa - Hierarchy of Provider Edge Devices in BGP/MPLS VPN ---------------------------------------------------------------------------- ------------------------------ Robert Jaksa described the need for Hierarchy of Provider Edge (HoPE) for better scalability of PEs in RFC2547bis, and discussions that came up in the mailing list on this draft. Eric: Not exhibited any case of lack of interoperability at protocol level with 2547bis. You have only exhibited a deployment model. So it needs no consensus and should not be discussed here. Marco: I agree with Eric, draft doesn't seem to have protocol impact. Need to see now which is support from SPs and debate on the list on possible protocol impacts. Further, we could evaluate interest in progress as informational. Rahul: If people want to do this on 2547bis, pass a default route between CE and PE. This is deployment issue, and shouldn't be taken up by WG. ---- 4. Michael Behringer - MPLS VPN Import/Export Verification ---------------------------------------------------------------------------- ------------ This draft addresses Route Target misconfiguration prevention for 2547bis. Ron Bonica's draft was compared. Michael's draft does not require CE to participate, and does not allow verification by site, and requires routing from CE-PE. Not sure how sensible this is. ??: this is to prevent misconfiguration by SP. Is this enough justification to do this work? Michael - agree Alex: asked technical questions on the draft. Admitted he needs to read the draft to clarify. Marco: We should work with Bonica draft and security framework team. Also look for solutions that are not specific to 2547bis. ??: The potential attraction is to not require change on CEs. It may not be the best solution, but it is a viable solution. ----- 5. Vach Kompella - VPLS draft (draft-lasserre-vkompella) ---------------------------------------------------------------------------- ------ Vach discussed the history and recent updates on this draft. He also mentioned that there are live deployments and several trials, interoperability between 6 vendors. Request this to be a WG draft (been around long enough) Marco: extensive debate should be on mailing list. Support can be registered here, but to be considered that not all of the solutions drafts have a slot in agenda today. Vach: Didn't ask the other guys not to present at the meeting. Rahul: Why did VC type change? Vach: To show that behavior of pseudo wire is the same as the ethernet pseudo wire. Continue to discuss on mailing list. May be FEC type. Juha: Use application ID in L2TP. Vach: It's the same as that, but doesn't do L2TP. Eric: this is an MPLS specific solution. Could generalize several things. the fact that it has been around 2 years, and not been done yet. Vach: Should we not have a separate l2tp specific document? Eric: Doesn't make sense to have 2 documents that are 90% the same. Vach: propose to use a generic VPN ID TLV, instead of using VC ID. It is not fair to say we haven't considered this. We need a wider audience to participate. Marco: This further shows the need to discuss this on the list. But don't prolong the discussion too much. Alex: For a document to become a WG draft, it doesn't have to be 100% correct. It can become a WG document if it is a good start. Matt: I wanted to make the same comment. Rahul: to carry on what Eric said, the arguments should be applied to the entire L2 space (autodiscovery etc.). Marco: that's actually why functional documents were recommended in Atlanta. Rahul: I don't want functional documents, want it as a piece of solutions documents. Marco: If people commit this work within a targeted time, let's have it. Alex: When a document becomes a WG draft, it should be easier to have authors introduce changes to it. Because once it becomes a WG draft, the author becomes an editor. Marco: asked for show of hands to make this a wG draft. Strong interest was shown in room. Further discussion on the list. Vach informed having some overview slides on last ISOCORE Interoperability tests (Rajiv Papneja) : Will be submitted later for discussion on the list. ---- 6. Vasile Radoaca - GVPLS/LPE ----------------------------------------------- Vasile described the history of this document, and explained the characteristics of the GVPLS model. Future steps include convergence with rosen signaling document, integrate qos and resiliency, enhance oam capabilities, convergence with vpls. Rahul: want to clarify if this is not in opposition to the hierarchical VPLS text in Eric's document. Vasile: Convergence can be done pretty easily. Ali: Given that you use two sets of pseudowire, there is a chance of packet reordering. Would like to see some discussion on that. ----- 7. Cheng-Yin Lee - Hybrid Virtual Private LAN ----------------------------------------------------------------- Cheng-Yin described the draft. Ali: pseudowire doesn't have bridging. Cheng Yin: CLE can consider one VPL. Use spanning tree across core. Ali: Scalability of spanning tree over SP core is an issue. Eric: This should not be taken up. Cheng Yin: more scalable appproach. Marco: take it to the list. ----- 8. Juha Heinanen - Radius-based Discovery ---------------------------------------------------------------- Motivation - BGP-free VPN discovery and Wide support for RADIUS in current equipment. This also works in multi-provider cases. Juha explained the working of Radius-based discovery. Juha: IS there interest in working on this. would need co-authors. Room showed great interest. ---- 9. Experimental vs standard track discussion ----------------------------------------------------------------- Marco: For l2 solutions, how many people support them being proposed as experimental solutions (to allow deployment and feedback from the field). Just recall that most of team members (team includes the authors of main solution drafts) favoured the experimental option, but the whole WG has to express his view. To also note that one essential difference between experimental and standard track is that experimental docs cannot be normative references. Vach: As I remember, if there is no consensus around a particular solution, then take the solutions that are gaining momentum and make them experimental. If there is only one solution, no point in making that experimental. Alex: No such thing as a "design team decision". This should be taken up with the WG. Marco : Agreed. WG discussion is requested for this reason. Kireeti: I'd like to disagree with my brother :-). (Ananth's note : but went on to say the same thing as Vach said). Eric : That's been the problem with the design team. We come to some consensus within the DT, and then people individually remember differently. Alex : Requirements for experimental RFCs are clear in RFC 2026. I'd like to move forward with this and want to resolve it before next meeting. If this means an interim meeting of wG, let's do it. Kireeti: Agree with Eric on disagreement of Design Team. So let's pretend the Design team never happened. So let's run the idea of experimental by the WG, and progress all as experimental. Wait for some time to see which become adopted (2 or 3). Vach: The point of "not remembering that the design team decided this" was to exactly bring home the issue that there is disagreement within design team. So to reiterate, let's see if there is consensus on one approach, else we can have experimental. Alex: One missing point is that the WG should decide this. Marco: discussion on the list. ----- Time ran over and other presentations were continued beyond 1500 hrs (good attendance) 10. Fabio Chiussi - PPVPN QoS Framework (draft-chiussi and draft-declercq) ---------------------------------------------------------------------------- ----------------------------------- Fabio described changes and updates on draft-chiussi. Content still needs to be refocused, reorganized and expanded. The next steps are to make the draft more readable (short), merge with draft-declercq-ppvpn-l3vpn-qos, address ppvpn-specific restoration, inter-AS QoS etc. Fabio went ahead and presented Jeremy's draft. The goal of both drafts after merging is to have a PPVPN QoS framework reference document for other QoS drafts defining solutions/QoS signaling extensions, QoS MIBs, etc. Mustafa Aissaoui: question about combining of 2 drafts, because the first draft talked about issues and guidelines for QoS, while Jeremy's draft separates guidelines from issues. Fabio: The merge plan is to keep the guidelines section, and the framework to be merged with Jeremy's draft (keep best of both). Dave McDysan: where does QoS framework document fit in charter? Propose merging necessary material in solutions documents. Marco : One of the issues with merging into existing basic solution documents (L3 solutions drafts) is the issue of extending the documents and therefore affect timeline. But we need to have WG's view on the list. ---- 11. Luyuan Fang - Security Framework for PPVPN ------------------------------------------------------------------------- Luyuan presented the draft and said Jeremy would be added to the authors' team in the next version. Luyuan described that there were different security levels expected in different PPVPN services. Therefore this framework gives guidelines for different implementation technologies. Ananth - suggest adding requirements to generic requirement draft and have the security features of each approach be described in applicability statements. --- Marco: we need to close here. Basic objective of presentations on frameworks was to stimulate input from the WG, to be continued on the list. All presentations will be available on the PPVPN informal server. ------_=_NextPart_001_01C2F7A0.E00A4474 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable San Francisco PPVPN WG minutes

All,
below the minutes of our SF meeting - = recorded by Ananth (thanks !!) with some changes/additions by = myself.
Please comment before the end of this = week.

Meeting presentations (some are still = missing)  will be available in one/two days on the informal PPVPN = server at
http://standards.nortelnetworks.com/ppvpn/calendar.htm= (SF area)

Thanks, Marco


---------------------------------------------------------= ----------------------------------------
PPVPN meeting - 56th IETF - March 19, = 2003 - San Francisco, CA
---------------------------------------------------------= ----------------------------------------

Minutes recorded by Ananth Nagarajan, = some changes/additions by Marco Carugi


1. Marco - Agenda bashing and WG = status
---------------------------------------------------------= -----
Marco started with agenda bashing, = then gave a status report of the WG. 
The layer 3 requirements and = framework drafts have been submitted to the IESG for consideration as = Informational RFCs. 

The next step is to have WG last calls = for the candidate L3 approaches before submission to IESG (2547bis and = VR) for proposed standard in a few weeks.  Complementary documents = will follow this.

Corresponding L2 documents would be = progressed in the next months before the July meeting.

The L3 framework and requirements = documents received comments from IESG.  The generic requirements = draft also needs resolution of comments of IESG. All these drafts would = be sent back to IESG in few days.

Draft-ietf-ppvpn-ce-based draft will = be discontinued as part of it has been integrated in L3 framework, = other part in draft-declercq-ppvpn-ce-based-sol-00.

WG last call of CE-based IPSec VPN = solution ID is targeted before next IETF.

Effective progress of the = applicability statement guidelines draft is not clear, discussion is = needed.
The terminology draft and first l2 = solution documents will be moved to WG soon after the meeting.
The metrics draft will be = discontinued (proposal of the L2 team, agreed by AD too), the L2 reqts = draft becoming the single basic reference for solutions.

The L2 requirements document (L2 team = product) needs wider review by the whole WG.  The l2 Framework = document is in good shape. Both these documents are  being = targeted for IESG submission in the April-May  2003 = timeframe. 

There are currently no WG documents in = the L2 solution space.

All design teams, except the L2 design = team, have basically concluded their tasks. The L2 team will be closed = now, although the team list will continue to live until completion of = L2 reqts and L2 framework documents.

Marco gave an update on L2 design team = discussions.  The functional decomposition recommended in Atlanta = aimed to complete a set of functional documents,  whose initial = content was produced by 4 team members for the interim meeting in = Billerica - January 2003.  The result of discussions in Billerica = (Scott attended too) was to discontinue the work on functional = decomposition. Other meeting outcome : solutions documents will have to = include a requirements compliance section; design team will not = recommend any specific solution ID to the WG, discussions and decisions = will be made based on mailing list input. Most of (not all) team = members favoured the progress of the L2 solution documents as = experimental, and not standard track, for now, but this needs to be = discussed further by the whole WG. 

The status as of now for L2 documents = is that the optional template has not been widely adopted, few solution = IDs contain the reqts compliance section,  WG list discussion on = various solutions has not happened yet. Wide participation of WG is = requested to progress this work soon, by selecting a number of = solutions  documents in L2 space (need that authors update their = solution IDs with reqts compliance section, and start discussion on = their document on the list).  Current milestones indicate L2 = solutions submission to IESG in June, but it will require confirmation = (Applicability Statements and MIBs work has not started = yet).

There is a clear need to have strict = relationships with protocol specific WGs for protocol extensions in = PPVPN.  To evaluate the interest of requesting  rechartering = of the PPVPN WG at a certain point in time to remove the restriction on = protocol development.

Alex: Clarified that there is no = current intention to take the work of other WGs on protocol deployment = and do it in PPVPN.

Francois: Didn't mention IPv6 VPN = document that is a WG document. Checking if the status has = changed.
Marco - No. Draft not mentioned = explicitly for brevity, but it is in.

Further work to be done in PPVPN in = terms of QoS, security and management frameworks : WG input is needed = to focus areas of development.

L2 interworking and service OAM were = brought up for discussion in the L2 team: Marco's proposals in this = meeting on such items need to be discussed on the list.

Other topics for future discussion = include multicast, l1/optical VPN and wireless VPN.

Alex: There is a lot of work that = PPVPN needs to do, that it has not finished. So let us not extend the = charter.
Marco: It's agreed that multicast, = l1/optical VPN and wireless VPN are not WG items for now.
-----

2. Jeremy DeClercq - CE-based L3 PPVPN = progress
---------------------------------------------------------= -------------------

Jeremy gave an update on the CE-based = L3 space.  draft-declercq-ppvpn-ce-based-sol-00 is proposed as = PPVPN CE-based IPSec solution document.  Draft-ietf-ppvpn-ce-based = will be discontinued and kept for reference only.

Clarifications on management = responsibility, routing realms and Internet access, auto-discovery were = made. Future steps include making this a WG document and  = progressing the corresponding AS document.

Joe Touch: We have running code that = is similar to this draft, except it is push-based, and not pull-based. = Also it has not been cited as reference. 90% is  similar to this = document, 10 % is different. We have running code.

Jeremy : It will be discussed.
Alex Zinin : Is there consensus on = the 10% difference? Running code is not enough, need to come to the WG = and ask for consensus.

Joe Touch: Also need to read prior = work and cite reference.

Dimitri: What is meant by "what = to do with draft-ietf-ppvpn-ce-based?"
Jeremy: Parts of this document were = moved to L3 framework document. The solution specific part has been = taken into draft-declercq-ppvpn-ce-based-sol-00.

-----

3. Robert Jaksa - Hierarchy of = Provider Edge Devices in BGP/MPLS VPN
---------------------------------------------------------= -------------------------------------------------

Robert Jaksa described the need for = Hierarchy of Provider Edge (HoPE) for better scalability of PEs in = RFC2547bis, and discussions that came up in the  mailing list on = this draft.

Eric: Not exhibited any case of lack = of interoperability at protocol level with 2547bis. You have only = exhibited a deployment model. So it needs no consensus  and should = not be discussed here.

Marco: I agree with Eric, draft = doesn't seem to have protocol impact. Need to see now which is support = from SPs and debate on the list on possible protocol  impacts. = Further, we could evaluate interest in progress as = informational.

Rahul: If people want to do this on = 2547bis, pass a default route between CE and PE. This is deployment = issue, and shouldn't be taken up by WG.

----
4. Michael Behringer - MPLS VPN = Import/Export Verification
---------------------------------------------------------= -------------------------------

This draft addresses Route Target = misconfiguration prevention for 2547bis.
Ron Bonica's draft was compared. = Michael's draft does not require CE to participate, and does not allow = verification by site, and requires routing from  CE-PE. Not sure = how sensible this is.

??: this is to prevent = misconfiguration by SP. Is this enough justification to do this = work?
Michael - agree

Alex: asked technical questions on the = draft. Admitted he needs to read the draft to clarify.

Marco: We should work with Bonica = draft and security framework team. Also look for solutions that are not = specific to 2547bis.

??: The potential attraction is to not = require change on CEs. It may not be the best solution, but it is a = viable solution.

-----
5. Vach Kompella - VPLS draft = (draft-lasserre-vkompella)
---------------------------------------------------------= -------------------------

Vach discussed the history and recent = updates on this draft.  He also mentioned that there are live = deployments and several trials, interoperability between  6 = vendors.  Request this to be a WG draft (been around long = enough)

Marco: extensive debate should be on = mailing list. Support can be registered here, but to be considered that = not all of the solutions drafts have a slot in agenda today.

Vach: Didn't ask the other guys not to = present at the meeting.

Rahul: Why did VC type change?
Vach: To show that behavior of pseudo = wire is the same as the ethernet pseudo wire. Continue to discuss on = mailing list. May be FEC type.

Juha: Use application ID in = L2TP.
Vach: It's the same as that, but = doesn't do L2TP.

Eric: this is an MPLS specific = solution.  Could generalize several things. the fact that it  = has been around 2 years, and not been done yet.

Vach: Should we not have a separate = l2tp specific document?
Eric: Doesn't make sense to have 2 = documents that are 90% the same.
Vach: propose to use a generic VPN ID = TLV, instead of using VC ID. It is not fair to say we haven't = considered this. We need a wider audience to participate.

Marco: This further shows the need to = discuss this on the list.  But don't prolong the discussion too = much.

Alex: For a document to become a WG = draft, it doesn't have to be 100% correct.  It can become a WG = document if it is a good start.

Matt: I wanted to make the same = comment.
Rahul: to carry on what Eric said, = the arguments should be applied to the entire L2 space  = (autodiscovery etc.).
Marco: that's actually why functional = documents were recommended in Atlanta.
Rahul: I don't want functional = documents, want it as a piece of solutions documents.
Marco: If people commit this work = within a targeted time, let's have it.
Alex: When a document becomes a WG = draft, it should be easier to have authors introduce changes to = it.  Because once it becomes a WG draft, the author  becomes = an editor.

Marco: asked for show of hands to make = this a wG draft.
Strong interest was shown in room. = Further discussion on the list.

Vach informed having some overview = slides on last ISOCORE Interoperability tests (Rajiv Papneja) : Will be = submitted later for discussion on the list.

----
6. Vasile Radoaca - GVPLS/LPE
-----------------------------------------------

Vasile described the history of this = document, and explained the characteristics of the GVPLS model. Future = steps include convergence with rosen signaling  document, = integrate qos and resiliency, enhance oam capabilities, convergence = with vpls.

Rahul: want to clarify if this is not = in opposition to the hierarchical VPLS text in Eric's document.
Vasile: Convergence can be done = pretty easily.

Ali: Given that you use two sets of = pseudowire, there is a chance of packet reordering. Would like to see = some discussion on that.

-----
7. Cheng-Yin Lee - Hybrid Virtual = Private LAN
---------------------------------------------------------= --------

Cheng-Yin described the draft.

Ali: pseudowire doesn't have = bridging.
Cheng Yin: CLE can consider one VPL. = Use spanning tree across core.
Ali: Scalability of spanning tree = over SP core is an issue.

Eric: This should not be taken = up.
Cheng Yin: more scalable = appproach.
Marco: take it to the list.

-----
8. Juha Heinanen - Radius-based  = Discovery
---------------------------------------------------------= -------

Motivation - BGP-free VPN discovery = and Wide support for RADIUS in current equipment.
This also works in multi-provider = cases.  Juha explained the working of Radius-based = discovery.

Juha: IS there interest in working on = this. would need co-authors.
Room showed great interest.

----

9. Experimental vs standard track = discussion
---------------------------------------------------------= --------

Marco: For l2 solutions, how many = people support them being proposed as experimental solutions (to allow = deployment and feedback from the field). Just recall  that most of = team members (team includes the authors of main solution drafts) = favoured the experimental option, but the whole WG has to express his = view. To also note that one essential difference between experimental = and standard track is that experimental docs cannot be normative = references.

Vach: As I remember, if there is no = consensus around a particular solution, then take the solutions that = are gaining momentum and make them experimental.  If  there = is only one solution, no point in making that experimental.

Alex: No such thing as a "design = team decision".  This should be taken up with the WG.
Marco : Agreed. WG discussion is = requested for this reason.
Kireeti: I'd like to disagree with my = brother :-). (Ananth's note : but went on to  say the same thing = as Vach said).
Eric : That's been the problem with = the design team. We come to some consensus within the DT, and then = people individually remember differently.

Alex : Requirements for experimental = RFCs are clear in RFC 2026. I'd like to move forward with this and want = to resolve it before next meeting. If this means  an interim = meeting of wG, let's do it.

Kireeti: Agree with Eric on = disagreement of Design Team. So let's pretend the Design team never = happened.  So let's run the idea of experimental by the WG,  = and progress all as experimental. Wait for some time to see which = become adopted (2 or 3).

Vach: The point of "not = remembering that the design team decided this" was to exactly = bring home the issue that there is disagreement within design = team.  So  to reiterate, let's see if there is consensus on = one approach, else we can have experimental.

Alex: One missing point is that the WG = should decide this.
Marco: discussion on the list.

-----
Time ran over and other presentations = were continued beyond 1500 hrs (good attendance)

10. Fabio Chiussi - PPVPN QoS = Framework (draft-chiussi and draft-declercq)
--------------------------------------= ------------------------------------------------------------------------= -

Fabio described changes and updates on = draft-chiussi. Content still needs to be refocused, reorganized and = expanded.
The next steps are to make the draft = more readable (short), merge with draft-declercq-ppvpn-l3vpn-qos, = address ppvpn-specific restoration, inter-AS QoS etc.

Fabio went ahead and presented = Jeremy's draft. The goal of both drafts after merging is to have a = PPVPN QoS framework reference document for other QoS drafts  = defining solutions/QoS signaling extensions, QoS MIBs, etc.

Mustafa Aissaoui: question about = combining of 2 drafts, because the first draft talked about issues and = guidelines for QoS, while Jeremy's draft separates  guidelines = from issues.

Fabio: The merge plan is to keep the = guidelines section, and the framework to be merged with Jeremy's draft = (keep best of both).

Dave McDysan: where does QoS framework = document fit in charter? Propose merging necessary material in = solutions documents.

Marco : One of the issues with merging = into existing basic solution documents (L3 solutions drafts) is the = issue of extending the documents and therefore  affect timeline. = But we need to have WG's view on the list.  

----

11. Luyuan Fang - Security Framework = for PPVPN
---------------------------------------------------------= ----------------

Luyuan presented the draft and said = Jeremy would be added to the authors' team in the next version. Luyuan = described that there were different security  levels expected in = different PPVPN services. Therefore this framework gives guidelines for = different implementation technologies.

Ananth - suggest adding requirements = to generic requirement draft and have the security features of each = approach be described in applicability statements.

---
Marco: we need to close here. Basic = objective of presentations on frameworks was to stimulate input from = the WG, to be continued on the list. All  presentations will be = available on the PPVPN informal server.













 

------_=_NextPart_001_01C2F7A0.E00A4474-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Mar 31 14:40: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 OAA20322 for ; Mon, 31 Mar 2003 14:40:26 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2VJgJI08356 for ; Mon, 31 Mar 2003 14:42:20 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.5/Switch-2.2.0) with SMTP id h2VJggc16728 for ; Mon, 31 Mar 2003 14:42:43 -0500 (EST) Message-Id: <200303311939.h2VJdZH26952@zrtps0kk.us.nortel.com> From: "salam" Reply-To: zava@joinme.com To: ppvpn@lyris.nortelnetworks.com Date: Mon, 31 Mar 2003 21:39:11 +0200 Subject: reply ASAP X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: ok6750.com X-SMTP-MAIL-FROM: zava@joinme.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: c7-rba-155.absamail.co.za [196.39.53.155] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA20322 Telephone: +27-83-737-6448 Good day I am Ravindra Salma, the Manager Private Banking Operations of National mercantile, jonnhnesburg South Africa. I opened a time coded fixed deposit account for one of my client for the past 5years for an America oil & diamond consultant/contract, valued at US$23,999,500.00 in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After a month, we sent a reminder and finally we discovered from the South Africa mining Corporation that Mr. Patel Cohen died from an automobile ghastly accident. On further investigation, I found out that he died without making a WILL, and all attempts to trace his next of kin were fruitless. This sum of US$23,999,500.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one will ever come forward to claim it and according to South Africa Law, at the expiration of 5 (five) years, the money will revert to the ownership of the South Africa Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you as an individual to stand in as the next of kin to Mr. Patel Cohen so that the fruits of this man labor will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorneys will prepare the necessary documents and affidavits, which will put you in place as the next of kin. We shall employ the service of two Attorneys to process and notarization all the necessary documents and letter of probate/administration in your favor in order for the transfer to take place. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 60% for me and 30% for you the remaining 10% for charity. There is no risk at all as all the paperwork for this transaction will be done by the Attorneys and my position as the Branch Manager Private banking guarantees the successful execution of this transaction. If you are interested, please reply immediately via the private email address below. You can also reply via my EMAIL ADDRESS/PHONE/Fax upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. Please because of my sensitive position, you most observe utmost confidentiality, and rest assured that this transaction would be most profitably to both of us. Thanks and regards. Mr Ravindra Salma Please reply at zava @joinme .com