From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 1 06:53:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05165 for ; Tue, 1 Apr 2003 06:53:56 -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 h31BtoV14396 for ; Tue, 1 Apr 2003 06:55:50 -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 h31BuEv11753 for ; Tue, 1 Apr 2003 06:56:14 -0500 (EST) Message-Id: <200304011149.GAA04898@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-gre-ip-2547-02.txt Date: Tue, 01 Apr 2003 06:49:24 -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 : Use of PE-PE GRE or IP in RFC2547 VPNs Author(s) : Y. Rekhter, E. Rosen Filename : draft-ietf-ppvpn-gre-ip-2547-02.txt Pages : 6 Date : 2003-3-31 This draft describes a variation of RFC2547 [RFC2547] in which the outermost MPLS label of a VPN packet is replaced with either IP or a GRE encapsulation. This enables the VPN packets to be carried over non-MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-02.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-gre-ip-2547-02.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-gre-ip-2547-02.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-31124553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-gre-ip-2547-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-gre-ip-2547-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-31124553.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 1 11:07:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24030 for ; Tue, 1 Apr 2003 11:07:08 -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 h31G93V08327 for ; Tue, 1 Apr 2003 11:09:03 -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 h31G9Nv05551 for ; Tue, 1 Apr 2003 11:09:24 -0500 (EST) Message-ID: <87609AFB433BD5118D5E0002A52CD754054FA88D@zcard0k6.ca.nortel.com> From: "Holger Lambeth" To: ppvpn@nortelnetworks.com Subject: test: who owns this email address? Date: Tue, 1 Apr 2003 11:06:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F868.97109EB2" 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_01C2F868.97109EB2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Could you reply to this email if you read the ppvpn email account. I would like to make a unix psuedo entry for ppvpn. Holger Lambeth (former) Passport Core Networking, Layer II Functional Project rfc2547 - Carrier IP Services Organization, N=D8RTEL NETWORKS(tm) Phone: +1 (613) 765-3168 or ESN 395-3168 Email: holger@nortelnetworks.com ------_=_NextPart_001_01C2F868.97109EB2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable test: who owns this email address?

Hello,
Could you reply to this email if you = read the ppvpn email account.
I would like to make a unix psuedo = entry for ppvpn.

Holger = Lambeth
(former) Passport = Core Networking, Layer II Functional Project
rfc2547 - Carrier = IP Services Organization, N=D8RTEL NETWORKS(tm)
Phone: +1 (613) = 765-3168 or ESN 395-3168
Email: = holger@nortelnetworks.com

------_=_NextPart_001_01C2F868.97109EB2-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 00:01:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28887 for ; Wed, 2 Apr 2003 00:01:54 -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 h3253hQ15714 for ; Wed, 2 Apr 2003 00:03:44 -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 h32547114911 for ; Wed, 2 Apr 2003 00:04:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F8DD.281C5F22" Subject: RE: test: who owns this email address? Date: Wed, 2 Apr 2003 08:00:26 +0200 Message-ID: <1612A4FBCAA7434FB246A491ECF20EC322D7CD@star.radlan.net> Thread-Topic: test: who owns this email address? Thread-Index: AcL4cgog1uXBpXC0QOK74hXLHQ1+LwAaxARQ From: "Michael Indenbaum" To: "Holger Lambeth" , X-OriginalArrivalTime: 02 Apr 2003 06:00:26.0873 (UTC) FILETIME=[28616E90:01C2F8DD] X-SMTP-HELO: mlry.radlan.net X-SMTP-MAIL-FROM: Michael@radlan.com X-SMTP-RCPT-TO: holger@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [212.117.141.36] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F8DD.281C5F22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Holger Lambeth [mailto:holger@nortelnetworks.com] Sent: Tuesday, April 01, 2003 6:06 PM To: ppvpn@nortelnetworks.com Subject: test: who owns this email address? Hello,=20 Could you reply to this email if you read the ppvpn email account.=20 I would like to make a unix psuedo entry for ppvpn.=20 Holger Lambeth=20 (former) Passport Core Networking, Layer II Functional Project=20 rfc2547 - Carrier IP Services Organization, N=D8RTEL NETWORKS(tm)=20 Phone: +1 (613) 765-3168 or ESN 395-3168=20 Email: holger@nortelnetworks.com=20 ------_=_NextPart_001_01C2F8DD.281C5F22 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable test: who owns this email address?
 
-----Original Message-----
From: Holger Lambeth=20 [mailto:holger@nortelnetworks.com]
Sent: Tuesday, April 01, = 2003=20 6:06 PM
To: ppvpn@nortelnetworks.com
Subject: = test: who=20 owns this email address?

Hello,
Could you=20 reply to this email if you read the ppvpn email account. =
I would like to make a unix psuedo entry for = ppvpn.=20

Holger=20 Lambeth
(former) Passport Core Networking, Layer II Functional = Project=20
rfc2547 - Carrier IP = Services=20 Organization, N=D8RTEL NETWORKS(tm)
Phone: +1 (613) 765-3168 or ESN 395-3168
Email: holger@nortelnetworks.com=20

------_=_NextPart_001_01C2F8DD.281C5F22-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 05:10: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 FAA02650 for ; Wed, 2 Apr 2003 05:10: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 h32ACKQ16966 for ; Wed, 2 Apr 2003 05:12:20 -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 h32ACi115668 for ; Wed, 2 Apr 2003 05:12:45 -0500 (EST) Date: Wed, 02 Apr 2003 05:09:21 -0500 From: oscarjohnson100@netscape.net To: ppvpn@lyris.nortelnetworks.com Subject: HELLO MIME-Version: 1.0 Message-ID: <19DB7FEC.2A315C9D.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-m01.mx.aol.com X-SMTP-MAIL-FROM: oscarjohnson100@netscape.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: imo-m01.mx.aol.com [64.12.136.4] 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?promo=380455 From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 09:29:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10311 for ; Wed, 2 Apr 2003 09:29:42 -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 h32EVbQ28547 for ; Wed, 2 Apr 2003 09:31:38 -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 h32EW1110199 for ; Wed, 2 Apr 2003 09:32:01 -0500 (EST) Message-ID: <6204FDDE129D364D8040A98BCCB290EF725D63@zbl6c004.corpeast.baynetworks.com> From: "Ramasamy Jesuraj" To: "'Michael Indenbaum'" , "Holger Lambeth" , ppvpn@nortelnetworks.com Subject: RE: test: who owns this email address? Date: Wed, 2 Apr 2003 09:28:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F924.1E3C34DA" 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_01C2F924.1E3C34DA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable yes -----Original Message----- From: Michael Indenbaum [mailto:Michael@radlan.com]=20 Sent: Wednesday, April 02, 2003 1:00 AM To: Lambeth, Holger [CAR:CS16:EXCH]; ppvpn@nortelnetworks.com Subject: RE: test: who owns this email address? =20 -----Original Message----- From: Holger Lambeth [mailto:holger@nortelnetworks.com] Sent: Tuesday, April 01, 2003 6:06 PM To: ppvpn@nortelnetworks.com Subject: test: who owns this email address? Hello,=20 Could you reply to this email if you read the ppvpn email account.=20 I would like to make a unix psuedo entry for ppvpn.=20 Holger Lambeth=20 (former) Passport Core Networking, Layer II Functional Project=20 rfc2547 - Carrier IP Services Organization, N=D8RTEL NETWORKS(tm)=20 Phone: +1 (613) 765-3168 or ESN 395-3168=20 Email: holger@nortelnetworks.com=20 ------_=_NextPart_001_01C2F924.1E3C34DA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
yes
-----Original Message-----
From: = Michael=20 Indenbaum [mailto:Michael@radlan.com]
Sent: Wednesday, = April 02,=20 2003 1:00 AM
To: Lambeth, Holger [CAR:CS16:EXCH];=20 ppvpn@nortelnetworks.com
Subject: RE: test: who owns this = email=20 address?

 
-----Original Message-----
From: Holger Lambeth=20 [mailto:holger@nortelnetworks.com]
Sent: Tuesday, April = 01, 2003=20 6:06 PM
To: ppvpn@nortelnetworks.com
Subject: = test: who=20 owns this email address?

Hello,
Could=20 you reply to this email if you read the ppvpn email account. =
I would like to make a unix psuedo = entry for=20 ppvpn.

Holger=20 Lambeth
(former) Passport Core Networking, Layer II Functional = Project=20
rfc2547 - Carrier = IP Services=20 Organization, N=D8RTEL NETWORKS(tm)
Phone: +1 (613) 765-3168 or ESN 395-3168
Email: holger@nortelnetworks.com=20

------_=_NextPart_001_01C2F924.1E3C34DA-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 09:33:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10480 for ; Wed, 2 Apr 2003 09:33: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 h32EZkQ02341 for ; Wed, 2 Apr 2003 09:35:46 -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 h32EaA115326 for ; Wed, 2 Apr 2003 09:36:10 -0500 (EST) Message-ID: <39469E08BD83D411A3D900204840EC55D8BA1D@vie-msgusr-01.dc.fore.com> From: "Bapat, Ananda" To: "Ramasamy Jesuraj" , "'Michael Indenbaum'" , "Holger Lambeth" , ppvpn@nortelnetworks.com Subject: RE: test: who owns this email address? Date: Wed, 2 Apr 2003 09:32:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F924.AB6C768A" X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: Ananda.Bapat@Marconi.com X-SMTP-RCPT-TO: rjesuraj@nortelnetworks.com,holger@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] 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_01C2F924.AB6C768A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, -----Original Message----- From: Ramasamy Jesuraj [mailto:rjesuraj@nortelnetworks.com] Sent: Wednesday, April 02, 2003 9:29 AM To: 'Michael Indenbaum'; Holger Lambeth; ppvpn@nortelnetworks.com Subject: RE: test: who owns this email address? yes -----Original Message----- From: Michael Indenbaum [mailto:Michael@radlan.com]=20 Sent: Wednesday, April 02, 2003 1:00 AM To: Lambeth, Holger [CAR:CS16:EXCH]; ppvpn@nortelnetworks.com Subject: RE: test: who owns this email address? =20 -----Original Message----- From: Holger Lambeth [mailto:holger@nortelnetworks.com] Sent: Tuesday, April 01, 2003 6:06 PM To: ppvpn@nortelnetworks.com Subject: test: who owns this email address? Hello,=20 Could you reply to this email if you read the ppvpn email account.=20 I would like to make a unix psuedo entry for ppvpn.=20 Holger Lambeth=20 (former) Passport Core Networking, Layer II Functional Project=20 rfc2547 - Carrier IP Services Organization, N=D8RTEL NETWORKS(tm)=20 Phone: +1 (613) 765-3168 or ESN 395-3168=20 Email: holger@nortelnetworks.com=20 ------_=_NextPart_001_01C2F924.AB6C768A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
OK,
-----Original Message-----
From: Ramasamy Jesuraj=20 [mailto:rjesuraj@nortelnetworks.com]
Sent: Wednesday, April = 02, 2003=20 9:29 AM
To: 'Michael Indenbaum'; Holger Lambeth;=20 ppvpn@nortelnetworks.com
Subject: RE: test: who owns this = email=20 address?

yes
-----Original Message-----
From: = Michael=20 Indenbaum [mailto:Michael@radlan.com]
Sent: Wednesday, = April 02,=20 2003 1:00 AM
To: Lambeth, Holger [CAR:CS16:EXCH];=20 ppvpn@nortelnetworks.com
Subject: RE: test: who owns this = email=20 address?

 
-----Original Message-----
From: Holger = Lambeth=20 [mailto:holger@nortelnetworks.com]
Sent: Tuesday, April = 01, 2003=20 6:06 PM
To: ppvpn@nortelnetworks.com
Subject: = test:=20 who owns this email address?

Hello,
Could=20 you reply to this email if you read the ppvpn email = account.=20
I would like to make a unix = psuedo entry for=20 ppvpn.

Holger=20 Lambeth
(former) Passport Core Networking, Layer II Functional=20 Project
rfc2547 -=20 Carrier IP Services Organization, N=D8RTEL NETWORKS(tm) =
Phone: +1 (613) 765-3168 = or ESN=20 395-3168
Email:=20 holger@nortelnetworks.com=20

------_=_NextPart_001_01C2F924.AB6C768A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 11:31: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 LAA16343 for ; Wed, 2 Apr 2003 11:31:17 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32GX4B16648 for ; Wed, 2 Apr 2003 11:33:05 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32GXTk11772 for ; Wed, 2 Apr 2003 11:33:29 -0500 (EST) Message-ID: <3E8B102A.117FD359@alcatel.com> Date: Wed, 02 Apr 2003 11:30:34 -0500 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ali Sajassi CC: ppvpn@nortelnetworks.com Subject: Re: Ali Sajassi's comments on Hybrid VPLS References: <4.3.2.7.2.20030323221501.01dabf08@airborne.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, (6) is the issue you raised in the PPVPN meeting. > 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. I think you have misunderstood Hybrid VPLS on this aspect. Customers' STP is processed by CLEs - PEs, Ps, L2PEs do not process, participate or even snoop Customers' BPDUs, there are transparent to PEs, L2PEs, Ps. MAC address learning and STP are restricted to a customer VPLS only. I don't understand your point about one giant flat network. A customer (CEs) may run STP even when using PE-based VPLS, are you saying the customer should not run STP then? I would agree that building one giant flat network as in VPLS/VLAN instance switching (and bridging) in the network (i.e. PE/P based VPLS) is not scalable. I do not know how one can aggregate [VPLS instance, MAC address] in that case. Even if the MAC addressing is changed to be aggregatable (reinventing what's already existing), how can one aggregate [VPLS instance, MAC address]. > 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 my response to Eric Rosen's comments on VPWS and VPLS service in Hybrid VPLS. I clarified these services in the discussion at IETF-56 PPVPN WG as well. > - please refer to L2VPN framework draft. If you acknowledge CLEs exist, perhaps a better suggestion is to update the L2VPN framework draft. > 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 !!! As the draft says, Section 2.2 is a migration step (but this can be used for many end-customers today in the interim) and the draft describes bridging over virtual ports for the longer term. > 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. A bridging expert commented that it would be trivial to specify bridging over different VLAN Ids. I see that as a positive comment. You may want to reevaluate your assertion that it is as easy to develop modified bridge using PWs on CLEs. It would be beneficial to review the issues and requirements with full-meshed VCs and reverse split horizon forwarding for VPLS in general. The issues with this are similar to using OSPF NBMA mode, which a well-respected routing person said should be avoided like the plaque. > 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. I don't think they are the same. Hybrid VPLS describes a specific service which allows a CE router with a FR interface to peer on the same broadcast network as CE routers with Ethernet access. IPLS (version 01), Section 10 says: "In addition to (i) an Ethernet port and (ii) combination of Ethernet port and a VLAN ID, an Attachment Circuit to IPLS may also be (iii) an ATM or FR VC carrying encapsulated ***bridged Ethernet*** frames or (iv) the combination of an ATM or FR VC and a VLAN ID. The ATM/FR VC is just used as a way to transport Ethernet frames between a customer site and the PE. " In Router Peering in Hybrid VPLS, the ATM/FR VC transports IP packets between a customer site and the PE. This is not the same as Router Peering in Hybrid VPLS. For the case where the FR CEs are bridges, Hybrid VPLS leverages bridging on CEs & CLEs, so PEs need not do bridging (not by distributing MAC info in the control plane). In contrast, IPLS says (Section 11): However, unlike VPLS, IPLS is restricted to IP traffic only. By restricting the scope of the service to the predominant type of traffic in today's environment, IPLS eliminates the need for service provider edge routers to implement some bridging functions such as MAC address learning in the data path (by, instead, ***distributing MAC information in the control plane***)." > 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. I think the intention of Marco Carugi's solution template (which is used in the Hybrid VPLS draft)is to allow L2VPN "vertical" solutions to refer to other documents which can be used for different L2VPN solutions. Discovery of tunnel endpoints in this proposal is meant to reduce provisioning steps at PEs but is not mandatory (a provider may choose to use a NMS). regards Cheng-Yin > > > 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 Wed Apr 2 11:48:44 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17585 for ; Wed, 2 Apr 2003 11:48:42 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32GoXB23084 for ; Wed, 2 Apr 2003 11:50:34 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32Govk29705 for ; Wed, 2 Apr 2003 11:50:58 -0500 (EST) Message-ID: <3E8B13D8.E0F51E4F@alcatel.com> Date: Wed, 02 Apr 2003 11:46:16 -0500 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: ppvpn@nortelnetworks.com Subject: Re: Eric Rosen's comments on Hybrid VPLS References: <200303242128.h2OLSmiH007622@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, > It seems to me that what you call CLEs are really CEs, as the term is > generally used in PPVPN. CLEs exist and are deployed in operational networks and when used are not the same box as Customer Equipment (CE), as defined in the PPVPN framework document. > 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. It is not simply VPWS. A provider may offer a VPLS service when the provider manages the CLEs. A provider may use p2p PW to build a VPLS service for customers, as discussed in IETF-56 PPVPN WG meeting. In this case, the CE sees a VPLS service. A customer may also choose to subscribe to a VPWS instead, in this case the CE sees a VPWS and the CE is responsible to do any bridging or routing it is configured and designed for, and it is not necessary for the provider to manage or provide any CLEs. > The fact > that the CEs are bridges rather than hosts or routers doesn't matter. Yes. > I believe this same comment has been made a number of times, by a number of > different people. Norm Finn commented it is a VPWS and I clarified this along the same lines and during the discussion in IETF-56 PPVPN. May I know which part of the above clarification is still not clear? > It may well be the case that bridging over VPWS is a good solution. But > there's nothing for the PPVPN WG to specify. As I understand the PPVPN WG charter is about making use of existing technologies (other WG shall specify any necessary mechanisms/extensions to a protocol), it's goal does not appear to be about specifying any new mechanisms or protocols specifically. Quoting the PPVPN WG charter: "The effort will produce a small number of approaches that are based on collections of individual technologies that already exist (see below for specifics). The goal is to foster interoperability among implementations of a specific approach. Standardization of specific approaches will be gauged on (I)SP support. Note that it is not a goal of this WG to develop new protocols or extend existing ones. Rather, the purpose is to document and identify gaps and shortcomings in individual approaches with regards to the requirements. In the case that specific work items are identified, such work will be done in an appropriate WG. Taking on specific protocol work items in this WG will require rechartering" Hybrid VPLS is an example of a "vertical" solution, specifying how existing protocols and any extensions required may be used to offer Hybrid VPLS, so different vendors equipment may interoperate to provide the service. regards Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 11:59:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18168 for ; Wed, 2 Apr 2003 11:59:40 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32H1YB10596 for ; Wed, 2 Apr 2003 12:01:34 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32H1wk08873 for ; Wed, 2 Apr 2003 12:01:58 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F938.EE7F70DF" Subject: security issues with mpls based IP-VPN X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 2 Apr 2003 18:57:23 +0200 Message-ID: <5572DB6D8DD3414F8885CAE287BF94CE3E2BBE@ARIAMAIL1.ariane.tractebel.be> Thread-Topic: security issues with mpls based IP-VPN Thread-Index: AcL5OLNSyrCSmd1ARJyN4HIWGztSCw== From: "Duric Willy" To: X-SMTP-HELO: relay.tractebel.be X-SMTP-MAIL-FROM: Willy.Duric@codenet.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: relay.tractebel.be [195.16.9.20] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F938.EE7F70DF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gents, Does anybody have information related to security on mpls based IP-VPN. = For exemple, is it possible to perform label spoofing (by analogy of IP = spoofing). What are the other security issues ? Thanks in advance. Willy ------_=_NextPart_001_01C2F938.EE7F70DF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable security issues with mpls based IP-VPN

Gents,

Does anybody have information related = to security on mpls based IP-VPN. For exemple, is it possible to perform = label spoofing (by analogy of IP spoofing). What are the other security = issues  ?

Thanks in advance.
Willy



------_=_NextPart_001_01C2F938.EE7F70DF-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 12:18: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 MAA19582 for ; Wed, 2 Apr 2003 12:18:02 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32HJuB21858 for ; Wed, 2 Apr 2003 12:19:56 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32HKKk27737 for ; Wed, 2 Apr 2003 12:20:21 -0500 (EST) Date: Wed, 2 Apr 2003 12:14:58 -0500 From: Ajay Simha To: Duric Willy Cc: ppvpn@nortelnetworks.com Subject: Re: security issues with mpls based IP-VPN Message-ID: <20030402171458.GY2420@cisco.com> References: <5572DB6D8DD3414F8885CAE287BF94CE3E2BBE@ARIAMAIL1.ariane.tractebel.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5572DB6D8DD3414F8885CAE287BF94CE3E2BBE@ARIAMAIL1.ariane.tractebel.be> User-Agent: Mutt/1.4i X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: asimha@uzura.cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: On Wed Apr 02 18:57:23 2003, Duric Willy wrote: > > Gents, > > Does anybody have information related to security on mpls based > IP-VPN. For exemple, is it possible to perform label spoofing (by > analogy of IP spoofing). What are the other security issues ? Miercom did security analysis for Cisco for MPLS-VPNs and here is where you can find the report: http://www.mier.com/reports/cisco/MPLS-VPNs.pdf -ajay > > Thanks in advance. > Willy From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 12:39: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 MAA20264 for ; Wed, 2 Apr 2003 12:39:51 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32HfjB01156 for ; Wed, 2 Apr 2003 12:41:46 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32Hg8k15521 for ; Wed, 2 Apr 2003 12:42:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: security issues with mpls based IP-VPN Date: Wed, 2 Apr 2003 11:36:32 -0600 Message-ID: Thread-Topic: security issues with mpls based IP-VPN Thread-Index: AcL5OLNSyrCSmd1ARJyN4HIWGztSCwAA0KHQ From: "Fang, Luyuan, ALABS" To: "Duric Willy" , X-SMTP-HELO: kcmso2.proxy.att.com X-SMTP-MAIL-FROM: luyuanfang@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kcmso2.att.com [192.128.134.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20264 Willy, There are a few related Drafts on PPVPN or MPLS VPN security: 'Security Framework for Provider Provisioned Virtual Private Networks' http://www.ietf.org/internet-drafts/draft-fang-ppvpn-security-framework-00.txt 'Analysis of the Security of the MPLS Architecture' http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-03.txt 'MPLS VPN Import/Export Verification' http://www.ietf.org/internet-drafts/draft-behringer-mpls-vpn-auth-01.txt 'CE-to-CE Member Verification for Layer 3 VPNs' http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-l3vpn-auth-03.txt We are asking for input on the draft of PPVPN Security Framework. Comments from anyone would be appreciated. Thanks, Luyuan Fang AT&T -----Original Message----- From: Duric Willy [mailto:Willy.Duric@codenet.be] Sent: Wednesday, April 02, 2003 11:57 AM To: ppvpn@nortelnetworks.com Subject: security issues with mpls based IP-VPN Gents, Does anybody have information related to security on mpls based IP-VPN. For exemple, is it possible to perform label spoofing (by analogy of IP spoofing). What are the other security issues ? Thanks in advance. Willy From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 12: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 MAA20436 for ; Wed, 2 Apr 2003 12:50:33 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32HqQB07042 for ; Wed, 2 Apr 2003 12:52:26 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32Hqmk24674 for ; Wed, 2 Apr 2003 12:52:48 -0500 (EST) Message-Id: <200304021746.h32HksiH000960@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 Wed, 02 Apr 2003 11:46:16 -0500. <3E8B13D8.E0F51E4F@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: Wed, 02 Apr 2003 12:46:54 -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: Eric> It seems to me that what you call CLEs are really CEs, as the term is Eric> generally used in PPVPN. Well, your answer to this is "no they aren't". That's not a particularly helpful response. Cheng-Yin> Norm Finn commented it is a VPWS and I clarified this along the Cheng-Yin> same lines and during the discussion in IETF-56 PPVPN. May I know Cheng-Yin> which part of the above clarification is still not clear? I don't believe any clarification was ever made; the same claims were merely repeated. Eric> It may well be the case that bridging over VPWS is a good solution. Eric> But there's nothing for the PPVPN WG to specify. Cheng-Yin> As I understand the PPVPN WG charter is about making use of Cheng-Yin> existing technologies (other WG shall specify any necessary Cheng-Yin> mechanisms/extensions to a protocol), it's goal does not appear Cheng-Yin> to be about specifying any new mechanisms or protocols Cheng-Yin> specifically. If a particular solution does not require the PPVPN WG to issue any specifications, then there is no need to take up the time of the PPVPN WG discussing it. I don't think this is a particularly subtle point. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 13:21: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 NAA21732 for ; Wed, 2 Apr 2003 13:21:01 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32IMuB10822 for ; Wed, 2 Apr 2003 13:22:56 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32INIk03929 for ; Wed, 2 Apr 2003 13:23:19 -0500 (EST) MIME-Version: 1.0 To: ppvpn@nortelnetworks.com Subject: Re: test: who owns this email address? Reply-To: rmadhu@cisco.com References: <39469E08BD83D411A3D900204840EC55D8BA1D@vie-msgusr-01.dc.fore.com> Message-ID: Content-Type: text/plain; charset=iso-8859-15; format=flowed From: Madhu Raghupatruni Organization: Cisco Systems Inc., San Jose, USA Date: Wed, 02 Apr 2003 10:18:35 -0800 In-Reply-To: <39469E08BD83D411A3D900204840EC55D8BA1D@vie-msgusr-01.dc.fore.com> User-Agent: Opera7.03/Win32 M2 build 2670 X-MIME-Autoconverted: from 8bit to quoted-printable by rtp-core-1.cisco.com id h32IIbiH008569 X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: rmadhu@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA21732 > -----Original Message----- > From: Holger Lambeth [mailto:holger@nortelnetworks.com] > Sent: Tuesday, April 01, 2003 6:06 PM > To: ppvpn@nortelnetworks.com > Subject: test: who owns this email address? > > > > Hello, Could you reply to this email if you read the ppvpn email account. > I would like to make a unix psuedo entry for ppvpn. > > Holger Lambeth (former) Passport Core Networking, Layer II Functional > Project rfc2547 - Carrier IP Services Organization, NØRTEL NETWORKS(tm) > Phone: +1 (613) 765-3168 or ESN 395-3168 Email: holger@nortelnetworks.com > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 14:08:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23529 for ; Wed, 2 Apr 2003 14:08:54 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32JAnB13006 for ; Wed, 2 Apr 2003 14:10:49 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32JB9k09381 for ; Wed, 2 Apr 2003 14:11:09 -0500 (EST) Message-ID: <3E8B3499.19DC6269@alcatel.com> Date: Wed, 02 Apr 2003 14:06:01 -0500 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: ppvpn@nortelnetworks.com Subject: Re: Eric Rosen's comments on Hybrid VPLS References: <200304021746.h32HksiH000960@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, Eric Rosen wrote: > Cheng-Yin> Norm Finn commented it is a VPWS and I clarified this along the > Cheng-Yin> same lines and during the discussion in IETF-56 PPVPN. May I know > Cheng-Yin> which part of the above clarification is still not clear? > > I don't believe any clarification was ever made; the same claims were merely > repeated. Ok, I see the problem now, you've deleted/or ignored the clarification ;-). I have repasted it below. "It is not simply VPWS. A provider may offer a VPLS service when the provider manages the CLEs. A provider may use p2p PW to build a VPLS service for customers, as discussed in IETF-56 PPVPN WG meeting. In this case, the CE sees a VPLS service. " Perhaps you can say what is not clear in the above. If the CE sees a VPLS service, why is this not a VPLS service? thanks Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 14:23:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24055 for ; Wed, 2 Apr 2003 14:23:26 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32JPLB20463 for ; Wed, 2 Apr 2003 14:25:21 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32JPfk23370 for ; Wed, 2 Apr 2003 14:25:41 -0500 (EST) Reply-To: From: "Vach Kompella" To: , Cc: Subject: RE: Eric Rosen's comments on Hybrid VPLS Date: Wed, 2 Apr 2003 11:21:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: <3E8B3499.19DC6269@alcatel.com> X-OriginalArrivalTime: 02 Apr 2003 19:21:41.0907 (UTC) FILETIME=[17557630:01C2F94D] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Cheng-Yin, Just because the CE sees it as a VPLS, it doesn't become a VPLS (from the provider's point of view). It still looks like a VPWS which the customer turns into a VPLS by putting bridges with split horizon, etc. The basic point is that the customer needs a VPWS service from the provider, so from a ppvpn perspective, what you presented is that a customer can turn a ppvpn VPWS into a customer-based VPLS. That's a customer deployment/use scenario. -Vach > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: Wednesday, April 02, 2003 11:06 AM > To: erosen@cisco.com > Cc: ppvpn@nortelnetworks.com > Subject: Re: Eric Rosen's comments on Hybrid VPLS > > > Eric, > > Eric Rosen wrote: > > Cheng-Yin> Norm Finn commented it is a VPWS and I clarified this along the > > Cheng-Yin> same lines and during the discussion in IETF-56 PPVPN. May I know > > Cheng-Yin> which part of the above clarification is still not clear? > > > > I don't believe any clarification was ever made; the same claims were merely > > repeated. > Ok, I see the problem now, you've deleted/or ignored the clarification > ;-). I have repasted it below. > > "It is not simply VPWS. A provider may offer a VPLS service when the > provider manages the CLEs. > A provider may use p2p PW to build a VPLS service for customers, as > discussed in IETF-56 PPVPN WG meeting. In this case, the CE sees a VPLS > service. " > > Perhaps you can say what is not clear in the above. > If the CE sees a VPLS service, why is this not a VPLS service? > > thanks > Cheng-Yin > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 14:36:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24603 for ; Wed, 2 Apr 2003 14:36:32 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32JcNB27827 for ; Wed, 2 Apr 2003 14:38:23 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32Jcjk08865 for ; Wed, 2 Apr 2003 14:38:45 -0500 (EST) Message-ID: <3E8B39B2.ACD9A39E@alcatel.com> Date: Wed, 02 Apr 2003 14:27:46 -0500 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vkompella@timetra.com CC: erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Eric Rosen's comments on Hybrid VPLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, Vach Kompella wrote: > > Cheng-Yin, > > Just because the CE sees it as a VPLS, it doesn't become a VPLS (from the > provider's point of view). It still looks like a VPWS which the customer turns > into a VPLS by putting bridges with split horizon, etc. The point is the provider manages the CLEs and provide a VPLS. The "UNI" is at CE to provider device/CLE and the CE sees a VPLS service from the provider. > The basic point is that the customer needs a VPWS service from the provider, so > from a ppvpn perspective, what you presented is that a customer can turn a ppvpn > VPWS into a customer-based VPLS. This is the VPWS case, not the VPLS service described above. regards, cheng-yin > > That's a customer deployment/use scenario. > > -Vach > > > -----Original Message----- > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > Sent: Wednesday, April 02, 2003 11:06 AM > > To: erosen@cisco.com > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: Eric Rosen's comments on Hybrid VPLS > > > > > > Eric, > > > > Eric Rosen wrote: > > > Cheng-Yin> Norm Finn commented it is a VPWS and I clarified this along the > > > Cheng-Yin> same lines and during the discussion in IETF-56 PPVPN. May I know > > > Cheng-Yin> which part of the above clarification is still not clear? > > > > > > I don't believe any clarification was ever made; the same claims were merely > > > repeated. > > Ok, I see the problem now, you've deleted/or ignored the clarification > > ;-). I have repasted it below. > > > > "It is not simply VPWS. A provider may offer a VPLS service when the > > provider manages the CLEs. > > A provider may use p2p PW to build a VPLS service for customers, as > > discussed in IETF-56 PPVPN WG meeting. In this case, the CE sees a VPLS > > service. " > > > > Perhaps you can say what is not clear in the above. > > If the CE sees a VPLS service, why is this not a VPLS service? > > > > thanks > > Cheng-Yin > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 14:45:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25078 for ; Wed, 2 Apr 2003 14:45:57 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32JlrB06568 for ; Wed, 2 Apr 2003 14:47:54 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32JmIR20977 for ; Wed, 2 Apr 2003 14:48:18 -0500 (EST) Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C890@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'vkompella@timetra.com'" , Cheng-Yin.Lee@alcatel.com, erosen@cisco.com Cc: ppvpn@nortelnetworks.com Subject: RE: Eric Rosen's comments on Hybrid VPLS Date: Wed, 2 Apr 2003 11:37:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-SMTP-HELO: father.pmc-sierra.bc.ca X-SMTP-MAIL-FROM: Shahram_Davari@pmc-sierra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: father.pmc-sierra.com [216.241.224.13] X-LYRIS-Message-Id: Vach, How come CE-based L3VPN is in PPVPN scope but this draft is not? -Shahram >-----Original Message----- >From: Vach Kompella [mailto:vkompella@timetra.com] >Sent: Wednesday, April 02, 2003 2:21 PM >To: Cheng-Yin.Lee@alcatel.com; erosen@cisco.com >Cc: ppvpn@nortelnetworks.com >Subject: RE: Eric Rosen's comments on Hybrid VPLS > > >Cheng-Yin, > >Just because the CE sees it as a VPLS, it doesn't become a >VPLS (from the >provider's point of view). It still looks like a VPWS which >the customer turns >into a VPLS by putting bridges with split horizon, etc. > >The basic point is that the customer needs a VPWS service from >the provider, so >from a ppvpn perspective, what you presented is that a >customer can turn a ppvpn >VPWS into a customer-based VPLS. > >That's a customer deployment/use scenario. > >-Vach > >> -----Original Message----- >> From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] >> Sent: Wednesday, April 02, 2003 11:06 AM >> To: erosen@cisco.com >> Cc: ppvpn@nortelnetworks.com >> Subject: Re: Eric Rosen's comments on Hybrid VPLS >> >> >> Eric, >> >> Eric Rosen wrote: >> > Cheng-Yin> Norm Finn commented it is a VPWS and I >clarified this along the >> > Cheng-Yin> same lines and during the discussion in IETF-56 >PPVPN. May I know >> > Cheng-Yin> which part of the above clarification is still >not clear? >> > >> > I don't believe any clarification was ever made; the same >claims were merely >> > repeated. >> Ok, I see the problem now, you've deleted/or ignored the >clarification >> ;-). I have repasted it below. >> >> "It is not simply VPWS. A provider may offer a VPLS service when the >> provider manages the CLEs. >> A provider may use p2p PW to build a VPLS service for customers, as >> discussed in IETF-56 PPVPN WG meeting. In this case, the CE >sees a VPLS >> service. " >> >> Perhaps you can say what is not clear in the above. >> If the CE sees a VPLS service, why is this not a VPLS service? >> >> thanks >> Cheng-Yin >> >> >> > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 14:50:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25462 for ; Wed, 2 Apr 2003 14:50:36 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32JqNB09571 for ; Wed, 2 Apr 2003 14:52:24 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32JqlR26114 for ; Wed, 2 Apr 2003 14:52:47 -0500 (EST) Message-ID: <3E8B3B04.693D1C37@alcatel.com> Date: Wed, 02 Apr 2003 14:33:24 -0500 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: ppvpn@nortelnetworks.com Subject: Re: Eric Rosen's comments on Hybrid VPLS References: <200304021925.h32JPhiH026798@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric Rosen wrote: > > Cheng-Yin> Perhaps you can say what is not clear in the above. If the CE > Cheng-Yin> sees a VPLS service, why is this not a VPLS service? > > And round and round we go ... > > The CE doesn't see a VPLS service, it sees a VPWS service. No, I'm afraid you've misunderstood this point, Eric. I just sent a clarification to Vach about this. > The CE provides > an emulated lan service to other nodes at its site. You keep obscuring this > by calling the CE "CLEs" and calling other routers at the sites "CEs". Perhaps people may want to read the draft first, just a suggestion ... Also, CEs are not CLEs and CEs are not necessarily routers. thanks, Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 15:00: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 PAA25842 for ; Wed, 2 Apr 2003 15:00:26 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32K2M702567 for ; Wed, 2 Apr 2003 15:02:22 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32K2iR19637 for ; Wed, 2 Apr 2003 15:02:45 -0500 (EST) Message-Id: <200304021925.h32JPhiH026798@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 Wed, 02 Apr 2003 14:06:01 -0500. <3E8B3499.19DC6269@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: Wed, 02 Apr 2003 14:25:43 -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: Cheng-Yin> Perhaps you can say what is not clear in the above. If the CE Cheng-Yin> sees a VPLS service, why is this not a VPLS service? And round and round we go ... The CE doesn't see a VPLS service, it sees a VPWS service. The CE provides an emulated lan service to other nodes at its site. You keep obscuring this by calling the CE "CLEs" and calling other routers at the sites "CEs". From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 15:42: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 PAA08312 for ; Wed, 2 Apr 2003 15:42:16 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32KiB727428 for ; Wed, 2 Apr 2003 15:44:12 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32KiYR27808 for ; Wed, 2 Apr 2003 15:44:34 -0500 (EST) Reply-To: From: "Vach Kompella" To: "Shahram Davari" , , Cc: Subject: RE: Eric Rosen's comments on Hybrid VPLS Date: Wed, 2 Apr 2003 12:40:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C890@nt-exch-yow.pmc-sierra.bc.ca> X-OriginalArrivalTime: 02 Apr 2003 20:41:09.0895 (UTC) FILETIME=[3146B170:01C2F958] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Did I say it is not in scope? All I said is that the CEs are using a ppvpn based VPWS in a particular way. But, on a different note: Perhaps you don't remember the position of my hand when the call for whether a ce-based l3vpn was in the ppvpn scope was made. I haven't changed my position, regardless of whether the consensus is that it is in scope. Which is not to say that CE-based VPNs are not important, particularly if they make demands of a provider provisioned VPN that are specific to the CE-based model. As far as I can see, the fact that the CEs are using a VPWS (from the provider's perspective) to create a CE-based VPLS. In response to Cheng-Yin's clarification, what you have done is identify how, given a VPLS capable node (CLE), and a set of VPLS-challenged routers (PEs), you can build a distributed VPLS, where the PEs only do VPWS, and the CLEs do the VPLS bit of learning, split horizon, etc. As a result you don't need to do DTLS or GVPLS style decoupling. I still maintain that this is an application of VPLS and VPWS, not something new. -Vach > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, April 02, 2003 11:38 AM > To: 'vkompella@timetra.com'; Cheng-Yin.Lee@alcatel.com; erosen@cisco.com > Cc: ppvpn@nortelnetworks.com > Subject: RE: Eric Rosen's comments on Hybrid VPLS > > > Vach, > > How come CE-based L3VPN is in PPVPN scope but this draft is not? > > -Shahram > > >-----Original Message----- > >From: Vach Kompella [mailto:vkompella@timetra.com] > >Sent: Wednesday, April 02, 2003 2:21 PM > >To: Cheng-Yin.Lee@alcatel.com; erosen@cisco.com > >Cc: ppvpn@nortelnetworks.com > >Subject: RE: Eric Rosen's comments on Hybrid VPLS > > > > > >Cheng-Yin, > > > >Just because the CE sees it as a VPLS, it doesn't become a > >VPLS (from the > >provider's point of view). It still looks like a VPWS which > >the customer turns > >into a VPLS by putting bridges with split horizon, etc. > > > >The basic point is that the customer needs a VPWS service from > >the provider, so > >from a ppvpn perspective, what you presented is that a > >customer can turn a ppvpn > >VPWS into a customer-based VPLS. > > > >That's a customer deployment/use scenario. > > > >-Vach > > > >> -----Original Message----- > >> From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > >> Sent: Wednesday, April 02, 2003 11:06 AM > >> To: erosen@cisco.com > >> Cc: ppvpn@nortelnetworks.com > >> Subject: Re: Eric Rosen's comments on Hybrid VPLS > >> > >> > >> Eric, > >> > >> Eric Rosen wrote: > >> > Cheng-Yin> Norm Finn commented it is a VPWS and I > >clarified this along the > >> > Cheng-Yin> same lines and during the discussion in IETF-56 > >PPVPN. May I know > >> > Cheng-Yin> which part of the above clarification is still > >not clear? > >> > > >> > I don't believe any clarification was ever made; the same > >claims were merely > >> > repeated. > >> Ok, I see the problem now, you've deleted/or ignored the > >clarification > >> ;-). I have repasted it below. > >> > >> "It is not simply VPWS. A provider may offer a VPLS service when the > >> provider manages the CLEs. > >> A provider may use p2p PW to build a VPLS service for customers, as > >> discussed in IETF-56 PPVPN WG meeting. In this case, the CE > >sees a VPLS > >> service. " > >> > >> Perhaps you can say what is not clear in the above. > >> If the CE sees a VPLS service, why is this not a VPLS service? > >> > >> thanks > >> Cheng-Yin > >> > >> > >> > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 17:22:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12204 for ; Wed, 2 Apr 2003 17:22:02 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32MNv700381 for ; Wed, 2 Apr 2003 17:23:57 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32MOKR23810 for ; Wed, 2 Apr 2003 17:24:21 -0500 (EST) Message-ID: <3E8B6217.2D2F7415@alcatel.com> Date: Wed, 02 Apr 2003 17:20:07 -0500 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vkompella@timetra.com CC: Shahram Davari , erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Eric Rosen's comments on Hybrid VPLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, Vach Kompella wrote: > As far as I can see, the fact that the CEs are using a VPWS (from the provider's > perspective) to create a CE-based VPLS. As described now, a CE sees a VPLS service not a VPWS in the case where the service subscribed is VPLS. As I mentioned before, a provider may provide or a customer may subscribe to a VPWS instead (in that case a CE sees a VPWS. The migration approach may be a VPWS as outlined in Section 2.2) > In response to Cheng-Yin's clarification, what you have done is identify how, > given a VPLS capable node (CLE), CLEs as defined in the draft are not lasseurre-vkompella VPLS capable node. > and a set of VPLS-challenged routers (PEs), you > can build a distributed VPLS, where the PEs only do VPWS, and the CLEs do the > VPLS bit of learning, split horizon, etc. The draft as described now - CLEs process customer's STP, the draft is currently not in favour of split horizon, some reasons are given in the draft, issues with inconsistent view of routing when a VC/PW is down. Other reasons include some providers concerns with the full-meshed requirements. Even if only a few hubs are used, every site must be full-meshed. Some people are questioning why a full-meshed (plus protections VCs) must be setup when some sites only need connectivity to a one or two hub sites. Regards, Cheng-Yin > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, April 02, 2003 11:38 AM > > To: 'vkompella@timetra.com'; Cheng-Yin.Lee@alcatel.com; erosen@cisco.com > > Cc: ppvpn@nortelnetworks.com > > Subject: RE: Eric Rosen's comments on Hybrid VPLS > > > > > > Vach, > > > > How come CE-based L3VPN is in PPVPN scope but this draft is not? > > > > -Shahram > > > > >-----Original Message----- > > >From: Vach Kompella [mailto:vkompella@timetra.com] > > >Sent: Wednesday, April 02, 2003 2:21 PM > > >To: Cheng-Yin.Lee@alcatel.com; erosen@cisco.com > > >Cc: ppvpn@nortelnetworks.com > > >Subject: RE: Eric Rosen's comments on Hybrid VPLS > > > > > > > > >Cheng-Yin, > > > > > >Just because the CE sees it as a VPLS, it doesn't become a > > >VPLS (from the > > >provider's point of view). It still looks like a VPWS which > > >the customer turns > > >into a VPLS by putting bridges with split horizon, etc. > > > > > >The basic point is that the customer needs a VPWS service from > > >the provider, so > > >from a ppvpn perspective, what you presented is that a > > >customer can turn a ppvpn > > >VPWS into a customer-based VPLS. > > > > > >That's a customer deployment/use scenario. > > > > > >-Vach > > > > > >> -----Original Message----- > > >> From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > >> Sent: Wednesday, April 02, 2003 11:06 AM > > >> To: erosen@cisco.com > > >> Cc: ppvpn@nortelnetworks.com > > >> Subject: Re: Eric Rosen's comments on Hybrid VPLS > > >> > > >> > > >> Eric, > > >> > > >> Eric Rosen wrote: > > >> > Cheng-Yin> Norm Finn commented it is a VPWS and I > > >clarified this along the > > >> > Cheng-Yin> same lines and during the discussion in IETF-56 > > >PPVPN. May I know > > >> > Cheng-Yin> which part of the above clarification is still > > >not clear? > > >> > > > >> > I don't believe any clarification was ever made; the same > > >claims were merely > > >> > repeated. > > >> Ok, I see the problem now, you've deleted/or ignored the > > >clarification > > >> ;-). I have repasted it below. > > >> > > >> "It is not simply VPWS. A provider may offer a VPLS service when the > > >> provider manages the CLEs. > > >> A provider may use p2p PW to build a VPLS service for customers, as > > >> discussed in IETF-56 PPVPN WG meeting. In this case, the CE > > >sees a VPLS > > >> service. " > > >> > > >> Perhaps you can say what is not clear in the above. > > >> If the CE sees a VPLS service, why is this not a VPLS service? > > >> > > >> thanks > > >> Cheng-Yin > > >> > > >> > > >> > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 2 18:54: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 SAA17293 for ; Wed, 2 Apr 2003 18:54:57 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32Nuc703239 for ; Wed, 2 Apr 2003 18:56:39 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h32Nv2R00667 for ; Wed, 2 Apr 2003 18:57:03 -0500 (EST) Message-Id: <200304022353.h32NrOiH012921@rtp-core-1.cisco.com> To: Shahram Davari cc: "'vkompella@timetra.com'" , Cheng-Yin.Lee@alcatel.com, ppvpn@nortelnetworks.com Subject: Re: Eric Rosen's comments on Hybrid VPLS In-reply-to: Your message of Wed, 02 Apr 2003 11:37:46 -0800. <4B6D09F3B826D411A67300D0B706EFDE0115C890@nt-exch-yow.pmc-sierra.bc.ca> 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: Wed, 02 Apr 2003 18:53:23 -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: Shahram> How come CE-based L3VPN is in PPVPN scope but this draft is not? The basic issues in CE-based PPVPN (whether L2 or L3) are (a) the methods by which the CEs in a common VPN may discover each other, and (b) the methods by which the SP provisions and monitors the CEs. These issues are in scope. These issues are already being addressed. I don't think these issues are any different if the CEs are bridges than if they are routers. Certainly the draft in question does not exhibit any L2VPN-specific issues in this area. In CE-based L3VPN, the CEs appear as routers to the other devices at the site, and to CEs at other sites. How the CEs perform routing, with each other, and with other devices at the customer sites, is not within the WG's scope. In CE-based L2VPN, the CEs appear as bridges to the other devices at the site, and to CEs at other sites. How the CEs perform bridging, with each other, and with other devices at the customer sites, is not within the WG's scope. So the part of the draft that discusses how to create a bridged network over a set of p2p links is out of scope. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 3 09:16:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20556 for ; Thu, 3 Apr 2003 09:16:46 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33EIbJ01871 for ; Thu, 3 Apr 2003 09:18:37 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h33EIKo04361 for ; Thu, 3 Apr 2003 09:18:20 -0500 (EST) Date: Thu, 03 Apr 2003 17:37:07 +0530 From: Pradeep Shastry Subject: Re: who owns this email address? To: "Holger Lambeth" , ppvpn@nortelnetworks.com Message-id: <01e001c2f9d9$8c98aa70$3b04120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_/ab/F77Y6vMs3VHmIrEueA)" X-Priority: 3 X-MSMail-priority: Normal References: <87609AFB433BD5118D5E0002A52CD754054FA88D@zcard0k6.ca.nortel.com> X-SMTP-HELO: mta2 X-SMTP-MAIL-FROM: pshastry@huawei.com X-SMTP-RCPT-TO: holger@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_/ab/F77Y6vMs3VHmIrEueA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable test: who owns this email address? ----- Original Message -----=20 From: Holger Lambeth=20 To: ppvpn@nortelnetworks.com=20 Sent: Tuesday, April 01, 2003 9:36 PM Subject: test: who owns this email address? Hello,=20 Could you reply to this email if you read the ppvpn email account.=20 I would like to make a unix psuedo entry for ppvpn.=20 Holger Lambeth=20 (former) Passport Core Networking, Layer II Functional Project=20 rfc2547 - Carrier IP Services Organization, N=D8RTEL NETWORKS(tm)=20 Phone: +1 (613) 765-3168 or ESN 395-3168=20 Email: holger@nortelnetworks.com=20 --Boundary_(ID_/ab/F77Y6vMs3VHmIrEueA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable test: who owns this email address?
 
----- Original Message -----
From:=20 Holger Lambeth
To: ppvpn@nortelnetworks.com
Sent: Tuesday, April 01, 2003 = 9:36=20 PM
Subject: test: who owns this = email=20 address?

Hello,
Could you=20 reply to this email if you read the ppvpn email account. =
I would like to make a unix psuedo entry for = ppvpn.=20

Holger=20 Lambeth
(former) Passport Core Networking, Layer II Functional = Project=20
rfc2547 - Carrier IP = Services=20 Organization, N=D8RTEL NETWORKS(tm)
Phone: +1 (613) 765-3168 or ESN 395-3168
Email: holger@nortelnetworks.com=20

--Boundary_(ID_/ab/F77Y6vMs3VHmIrEueA)-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 3 18:22: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 SAA19832 for ; Thu, 3 Apr 2003 18:22:59 -0500 (EST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33NMiJ16750 for ; Thu, 3 Apr 2003 18:22:44 -0500 (EST) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h33NMfb23009 for ; Thu, 3 Apr 2003 18:22:41 -0500 (EST) Message-Id: <4.3.2.7.2.20030403141846.01d7b758@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Apr 2003 15:19:46 -0800 To: Cheng-Yin.Lee@alcatel.com, Ali Sajassi From: Ali Sajassi Subject: Re: Ali Sajassi's comments on Hybrid VPLS Cc: ppvpn@nortelnetworks.com In-Reply-To: <3E8B102A.117FD359@alcatel.com> References: <4.3.2.7.2.20030323221501.01dabf08@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 11:30 AM 4/2/2003 -0500, Cheng-Yin Lee wrote: >Ali, >(6) is the issue you raised in the PPVPN meeting. > > > 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. >I think you have misunderstood Hybrid VPLS on this aspect. Customers' >STP is processed by CLEs - PEs, Ps, L2PEs do not process, participate or >even snoop >Customers' BPDUs, there are transparent to PEs, L2PEs, Ps. MAC address >learning and STP are restricted to a customer VPLS only. I was not talking about customer's BPDUs but instead about provider's BPDUs (I hoped this was clear from my reference to provider's access network). >I don't understand your point about one giant flat network. >A customer (CEs) may run STP even when using PE-based VPLS, are you >saying the customer should not run STP then? No, the point which I was making is that the provider's network consists of a number of Metro Ethernet (ME) Networks connected over an MPLS/IP backbone. Each ME network can be either MPLS, IP or QinQ. It is O.K. to run STP within a ME network but running it across all ME networks is something else and can create administrative nightmare the least. I would be very interested to hear from any operator who is considering such topology. >I would agree that building one giant flat network as in VPLS/VLAN >instance switching (and bridging) in the network (i.e. PE/P based VPLS) >is not scalable. I do not know how one can aggregate [VPLS instance, MAC >address] in that case. Even if the MAC addressing is changed to be >aggregatable (reinventing what's already existing), how can one >aggregate [VPLS instance, MAC address]. > > > 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 my response to Eric Rosen's comments on VPWS and VPLS >service in Hybrid VPLS. >I clarified these services in the discussion at IETF-56 PPVPN WG as >well. With respect to terminology, still you should try to use the correct terminology - e.g. AC means demarcation between CE and PE (and not the interface between u-pe and n-pe). Based on framework document, your CLE is u-PE and your PE is then n-PE. > > - please refer to L2VPN framework draft. >If you acknowledge CLEs exist, perhaps a better suggestion is to update >the L2VPN framework draft. you can still use the same terminology as u-PE and n-PE, in your case you have a different distribution of functionality between u-PE and n-PE (e.g., u-PE doing all the bridging functionality and n-PE doing all the PW functionality). > > 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 !!! >As the draft says, Section 2.2 is a migration step (but this can be used >for many end-customers today in the interim) and the draft describes >bridging over virtual ports for the longer term. I hope this point is clear to everyone that the initial step is a non-starter. > > 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. >A bridging expert commented that it would be trivial to specify bridging >over different VLAN Ids. I see that as a positive comment. >You may want to reevaluate your assertion that it is as easy to develop >modified bridge using PWs on CLEs. I would love to hear how the existing Ethernet switches can be "easily" modified to do this !!! Everything is easy at the 10,000 ft level :-) And once this is done, then the difference between this approach and using actual PW is just encapsulation - again at the 10,000 ft level :-) >It would be beneficial to review the issues and requirements with >full-meshed VCs and reverse split horizon forwarding for VPLS in >general. The issues with this are similar to using OSPF NBMA mode, which >a well-respected routing person said should be avoided like the plaque. And that's why for a year and half there are all these drafts on distributed-PE and hierarchical-PE to address this N^^2 scalability issue - there is a difference between full-mesh among edge devices and full-mesh among core devices !! > > 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. >I don't think they are the same. Hybrid VPLS describes a specific >service which allows a CE router with a FR interface to peer on the same >broadcast network as CE routers with Ethernet access. There are easier way of taking care of this type of situations (e.g., ACs with routed encap) - please refer to draft-sajassi-l2vpn-interworking. >IPLS (version 01), Section 10 says: > "In addition to (i) an Ethernet port and (ii) combination of > Ethernet port and a VLAN ID, an Attachment Circuit to IPLS may also > be (iii) an ATM or FR VC carrying encapsulated ***bridged Ethernet*** > frames or (iv) the combination of an ATM or FR VC and a VLAN ID. > > The ATM/FR VC is just used as a way to transport Ethernet frames > between a customer site and the PE. " > >In Router Peering in Hybrid VPLS, the ATM/FR VC transports IP packets >between a customer site and the PE. This is not the same as Router >Peering in Hybrid VPLS. > >For the case where the FR CEs are bridges, Hybrid VPLS leverages >bridging on CEs & CLEs, so PEs need not do bridging (not by distributing >MAC info in the control plane). >In contrast, IPLS says (Section 11): > > However, unlike VPLS, IPLS is restricted to IP traffic only. By > restricting the scope of the service to the predominant type of > traffic in today's environment, IPLS eliminates the need for service > provider edge routers to implement some bridging functions such as > MAC address learning in the data path (by, instead, ***distributing >MAC > information in the control plane***)." > > > 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. >I think the intention of Marco Carugi's solution template (which is used >in the Hybrid VPLS draft)is to allow L2VPN "vertical" solutions to refer >to other documents which can be used for >different L2VPN solutions. >Discovery of tunnel endpoints in this proposal is meant to reduce >provisioning steps at PEs but is not mandatory (a provider may choose to >use a NMS). That's fine. But still the mapping of VLANs to PWs is not part of auto-discovery :-) Cheers, Ali >regards >Cheng-Yin > > > > > > > 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 Sun Apr 6 20:43:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10588 for ; Sun, 6 Apr 2003 20:43:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h370hj517380 for ; Sun, 6 Apr 2003 20:43:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h370hg118561 for ; Sun, 6 Apr 2003 20:43:43 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Sun, 6 Apr 2003 17:41:14 -0700 (PDT) From: shadol michael To: shadolmike@need4speed.com Subject: Investment Reply-To: shadolmike@need4speed.com X-Originating-Ip: [216.252.167.232] Message-Id: <20030407004114.9FF954CBB@sitemail.everyone.net> X-SMTP-HELO: omta02.mta.everyone.net X-SMTP-MAIL-FROM: shadolmike@need4speed.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sitemail3.everyone.net [216.200.145.37] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit It is my pleasure to write you this mail. I am writing you from Accra-Ghana in west Africa. I got your contact from journalist while searching for a foreign partner and contact. I am 23 years old and a Sierra Leonia national. I am looking for an overseas business partner/investor to assist me move and invest US$22million,been money which I inherited from my late father. Rebel fighters in Sierra Leone who are fighting for control of diamond mines killed my late father. My late father was a diamond miner/merchant and a senior chief. He was killed together with all members of my family including my brothers, sisters and mother. As a local diamond miner my father was not involved in diamond export but sell his diamond to foreign merchants who make exports. As a result of increasing rebel attacks and war in my country, he moved all his money and other valuables out of my country to Accra- Ghana for safe keeping in a safe keeping company. I am the only surviving member of my family and have inherited the money another valuables. I am now the beneficiary of my father wealth and my plan now is to move all the money out of here to overseas and invest it there, because I do not wish to invest the money here in Africa, because of the unstable political and economic situation in Africa. There are problems making it difficult for me to move the money overseas on my own alone. The problems are as follows: I am under aged just twenty three years old, have never been to overseas before and have no business or private contact overseas, have not get the required business/banking experience and other logistic reasons to handle the big fund alone. These are the reasons why I need a TRUSTWORTHY and RELIABLE PERSON who will come to ACCRA-GHANA, West Africa here to help me. If you can render your total support to me by coming here to assisting me to move this fund/myself to your country. I will offer you best of how much you will want me to give you, as you will also help me to invest the remaining in any viable and lucrative business in your company/country. My telephone number is+233-20-8142916,or email my address. Looking forward to your reply. God bless you. Yours Sincerely, MICHAEL SHADOL. _____________________________________________________________ Get a free email account (with a cool name!!---> http://www.need4speed.com _____________________________________________________________ Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 7 01:51:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18545 for ; Mon, 7 Apr 2003 01:51:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h375rDr04778 for ; Mon, 7 Apr 2003 01:53:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h375rAW14730 for ; Mon, 7 Apr 2003 01:53:10 -0400 (EDT) Message-ID: <20030407055117.69066.qmail@web41809.mail.yahoo.com> Date: Mon, 7 Apr 2003 06:51:17 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: multiple VRFs association To: mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41809.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41809.mail.yahoo.com [66.218.93.143] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Hello, What i understand till now is that the VRF is not mapped to individual sites in the VPN but to the ports on the PE router. This is so because i can have overlapping VPNs wherein i would want the two different sites to share the same VRF. Thus multiple ports on the PE router can be associated with a single VRF. My doubt is that can i have it the other way around OR putting it in a different way can the same PE router port be associated with two different VRFs? I think is is *only* possible with ethernets where using the concept of VLANs i can have the same physical port be associated with multiple VRFs. PLease let me know if i am correct in my understanding. Thanks a lot ! Regards, John 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 Apr 7 02:38:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02885 for ; Mon, 7 Apr 2003 02:38:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h376eDr12997 for ; Mon, 7 Apr 2003 02:40:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h376eAW05656 for ; Mon, 7 Apr 2003 02:40:10 -0400 (EDT) Reply-To: From: "Shiv Agarwal" To: "'John Smith'" , Cc: Subject: RE: multiple VRFs association Date: Sun, 6 Apr 2003 23:41:01 -0700 Message-ID: <000001c2fcd0$a97501d0$6502a8c0@shiv> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030407055117.69066.qmail@web41809.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 07 Apr 2003 06:35:18.0880 (UTC) FILETIME=[DB611E00:01C2FCCF] X-SMTP-HELO: exch-srv.CoronaNetworks.com X-SMTP-MAIL-FROM: Shiv@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.219.34.104] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit you can do the same thing on ATM ports using sub interfaces, on channelized ports using channel groups, etc etc. -----Original Message----- From: John Smith [mailto:jsmith4112003@yahoo.co.uk] Sent: Sunday, April 06, 2003 10:51 PM To: mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com Subject: multiple VRFs association Hello, What i understand till now is that the VRF is not mapped to individual sites in the VPN but to the ports on the PE router. This is so because i can have overlapping VPNs wherein i would want the two different sites to share the same VRF. Thus multiple ports on the PE router can be associated with a single VRF. My doubt is that can i have it the other way around OR putting it in a different way can the same PE router port be associated with two different VRFs? I think is is *only* possible with ethernets where using the concept of VLANs i can have the same physical port be associated with multiple VRFs. PLease let me know if i am correct in my understanding. Thanks a lot ! Regards, John 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 Apr 7 03:18:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05197 for ; Mon, 7 Apr 2003 03:18:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h377Jvr21029 for ; Mon, 7 Apr 2003 03:19:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h377JsW29902 for ; Mon, 7 Apr 2003 03:19:55 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: dgupta@corporate-access.com X-Msg-Ref: server-9.tower-4.messagelabs.com!1049699866!7758 Message-ID: <57CDB0394A95D411B1B10002A5094B6B01818D63@HCA-XC-01> From: Divesh Gupta To: "'John Smith '" , "'mpls-ops@mplsrc.com '" Cc: "'ppvpn@nortelnetworks.com '" Subject: RE: [MPLS-OPS]: multiple VRFs association Date: Mon, 7 Apr 2003 15:15:38 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: mail4.messagelabs.com X-SMTP-MAIL-FROM: dgupta@corporate-access.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail4.messagelabs.com [212.125.75.12] X-LYRIS-Message-Id: Hi John, Your understanding is correct. However, you cannot have a single router port mapped to multiple VRFs. What you can do is have multiple "virtual" ports defined under a single physical router port ans then have each of these virtual port map to different VRF. Eg: FR ports under a Serial interface/VLAN ports under Ethernet interface etc. Further, you can have multiple virtual links between CPE and PE, each mapped to a different VRF. So in effect you CAN have individual site accosiated to more than ONE VRF. Hope this helps. Rgs Divesh Gupta Hong Kong -----Original Message----- From: John Smith To: mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com Sent: 4/7/03 1:51 PM Subject: [MPLS-OPS]: multiple VRFs association Hello, What i understand till now is that the VRF is not mapped to individual sites in the VPN but to the ports on the PE router. This is so because i can have overlapping VPNs wherein i would want the two different sites to share the same VRF. Thus multiple ports on the PE router can be associated with a single VRF. My doubt is that can i have it the other way around OR putting it in a different way can the same PE router port be associated with two different VRFs? I think is is *only* possible with ethernets where using the concept of VLANs i can have the same physical port be associated with multiple VRFs. PLease let me know if i am correct in my understanding. Thanks a lot ! Regards, John 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 ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 7 03:26: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 DAA05409 for ; Mon, 7 Apr 2003 03:26:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h377Sir24370 for ; Mon, 7 Apr 2003 03:28:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h377SfW04293 for ; Mon, 7 Apr 2003 03:28:41 -0400 (EDT) Message-ID: <3E912813.45FC26EC@cisco.com> Date: Mon, 07 Apr 2003 09:26:11 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Divesh Gupta , "'John Smith '" CC: "'mpls-ops@mplsrc.com '" , "'ppvpn@nortelnetworks.com '" Subject: Re: [MPLS-OPS]: multiple VRFs association References: <57CDB0394A95D411B1B10002A5094B6B01818D63@HCA-XC-01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit All, Let me just indicate that mapping to vrfs does not really has to be tight to physical or logical ports on the PE router any more. Imagine the case where an IP packet is recieved on any port (independent on media), some processing is conducted on it (form of policy based routing for example) then based on the retrived info such a packet is inserted into required vrf. I think that was really John's question ;). R. > Divesh Gupta wrote: > > Hi John, > Your understanding is correct. However, you cannot have a single > router port mapped to multiple VRFs. What you can do is have multiple > "virtual" ports defined under a single physical router port ans then have > each of these virtual port map to different VRF. > Eg: FR ports under a Serial interface/VLAN ports under Ethernet interface > etc. > Further, you can have multiple virtual links between CPE and PE, each mapped > to a different VRF. So in effect you CAN have individual site > accosiated to more than ONE VRF. > Hope this helps. > Rgs > Divesh Gupta > Hong Kong > > -----Original Message----- > From: John Smith > To: mpls-ops@mplsrc.com > Cc: ppvpn@nortelnetworks.com > Sent: 4/7/03 1:51 PM > Subject: [MPLS-OPS]: multiple VRFs association > > Hello, > What i understand till now is that the VRF is not mapped to individual > sites in the VPN > but to the ports on the PE router. This is so because i can have > overlapping VPNs wherein > i would want the two different sites to share the same VRF. Thus > multiple ports on the PE > router can be associated with a single VRF. > > My doubt is that can i have it the other way around OR putting it in a > different way can > the same PE router port be associated with two different VRFs? > > I think is is *only* possible with ethernets where using the concept of > VLANs i can have > the same physical port be associated with multiple VRFs. > > PLease let me know if i am correct in my understanding. > > Thanks a lot ! > > Regards, > John 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 > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs SkyScan > service. For more information on a proactive anti-virus service working > around the clock, around the globe, visit http://www.messagelabs.com > ________________________________________________________________________ > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs SkyScan > service. For more information on a proactive anti-virus service working > around the clock, around the globe, visit http://www.messagelabs.com > ________________________________________________________________________ From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 7 03:46:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06794 for ; Mon, 7 Apr 2003 03:46:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h377mor28015 for ; Mon, 7 Apr 2003 03:48:50 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h377miW10424 for ; Mon, 7 Apr 2003 03:48:44 -0400 (EDT) X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] From: "M. ELK" To: jsmith4112003@yahoo.co.uk, mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com Subject: Re: [MPLS-OPS]: multiple VRFs association Date: Mon, 07 Apr 2003 07:46:15 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Apr 2003 07:46:16.0091 (UTC) FILETIME=[C4DFF6B0:01C2FCD9] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: elkou141061@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: f114.pav1.hotmail.com [64.4.31.114] X-LYRIS-Message-Id: AFAIK ,a single sub-interface have to be associated with single VRF . The only exception is the cisco feature where they could assign recieved packet over a sub-interface to a specific VRF based on source address . http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/products_feature_guide09186a008012db6a.html Quote Feature Overview The VRF Selection feature allows packets arriving on an interface to be switched into the appropriate VRF table based upon the source IP address of the packets. Once the packets have been "selected" into the correct VRF routing table, they are processed normally based upon the destination address and forwarded through the rest of the Multiprotocol Label Switching (MPLS) VPN. In most cases, the VRF Selection feature is a "one way" feature; it works on packets coming from the end users to the PE router. Unquote Note : may be using the wording "Sub-interface" is more appropriate than using "PORT" as the physical port could support several logical port (ex: VLAN , FR ,ATM ..etc ) . Brgds >From: John Smith >To: mpls-ops@mplsrc.com >CC: ppvpn@nortelnetworks.com >Subject: [MPLS-OPS]: multiple VRFs association Date: Mon, 7 Apr 2003 >06:51:17 +0100 (BST) > >Hello, >What i understand till now is that the VRF is not mapped to individual >sites in the VPN >but to the ports on the PE router. This is so because i can have >overlapping VPNs wherein >i would want the two different sites to share the same VRF. Thus multiple >ports on the PE >router can be associated with a single VRF. > >My doubt is that can i have it the other way around OR putting it in a >different way can >the same PE router port be associated with two different VRFs? > >I think is is *only* possible with ethernets where using the concept of >VLANs i can have >the same physical port be associated with multiple VRFs. > >PLease let me know if i am correct in my understanding. > >Thanks a lot ! > >Regards, >John 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 > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 7 06:03:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13543 for ; Mon, 7 Apr 2003 06:03:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h37A4lr26180 for ; Mon, 7 Apr 2003 06:04:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h37A4gW19329 for ; Mon, 7 Apr 2003 06:04:43 -0400 (EDT) Date: Mon, 07 Apr 2003 16:20:27 +0800 From: Du Wenhua Subject: Re: Re: [MPLS-OPS]: multiple VRFs association To: "M. ELK" , "jsmith4112003@yahoo.co.uk" , "mpls-ops@mplsrc.com" Cc: "ppvpn@nortelnetworks.com" Reply-to: duwh@huawei.com Message-id: <0HCY002YKRIM6K@mta0.huawei.com> Organization: Huawei Techlonogies, Co., Ltd MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,M. ELK, True. Much more, some router can do VRF selection based on classification(5 tuples). >-----Original Message----- >From: M. ELK >Sent: 07:46:00,2003-04-07 >To: jsmith4112003 >Subject: Re: [MPLS-OPS]: multiple VRFs association >AFAIK ,a single sub-interface have to be associated with single >VRF . >The only exception is the cisco feature where they could assign >recieved packet over a sub-interface to a specific VRF based on >source address . >http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/products_feature_guide09186a008012db6a.html > >Quote >Feature Overview >The VRF Selection feature allows packets arriving on an interface to be >switched into the appropriate VRF table based upon the source IP address of >the packets. Once the packets have been "selected" into the correct VRF >routing table, they are processed normally based upon the destination >address and forwarded through the rest of the Multiprotocol Label Switching >(MPLS) VPN. > >In most cases, the VRF Selection feature is a "one way" feature; it works on >packets coming from the end users to the PE router. > >Unquote > >Note : may be using the wording "Sub-interface" is more appropriate >than using "PORT" as the physical port could support several >logical port (ex: VLAN , FR ,ATM ..etc ) . > >Brgds > >>From: John Smith >>To: mpls-ops@mplsrc.com >>CC: ppvpn@nortelnetworks.com >>Subject: [MPLS-OPS]: multiple VRFs association Date: Mon, 7 Apr 2003 >>06:51:17 +0100 (BST) >> >>Hello, >>What i understand till now is that the VRF is not mapped to individual >>sites in the VPN >>but to the ports on the PE router. This is so because i can have >>overlapping VPNs wherein >>i would want the two different sites to share the same VRF. Thus multiple >>ports on the PE >>router can be associated with a single VRF. >> >>My doubt is that can i have it the other way around OR putting it in a >>different way can >>the same PE router port be associated with two different VRFs? >> >>I think is is *only* possible with ethernets where using the concept of >>VLANs i can have >>the same physical port be associated with multiple VRFs. >> >>PLease let me know if i am correct in my understanding. >> >>Thanks a lot ! >> >>Regards, >>John 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 >> >>------- >>The MPLS-OPS Mailing List >>Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > >_________________________________________________________________ >Tired of spam? Get advanced junk mail protection with MSN 8. >http://join.msn.com/?page=features/junkmail = = = = = = = = = = = = = = = = = = = = From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 7 07:12:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15186 for ; Mon, 7 Apr 2003 07:12:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h37BE6r06702 for ; Mon, 7 Apr 2003 07:14:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h37BE3W03312 for ; Mon, 7 Apr 2003 07:14:03 -0400 (EDT) Message-Id: <200304071109.HAA14847@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-marques-ppvpn-rt-constrain-00.txt Date: Mon, 07 Apr 2003 07:09:33 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Constrained VPN route distribution Author(s) : R. Bonica et al. Filename : draft-marques-ppvpn-rt-constrain-00.txt Pages : 9 Date : 2003-4-4 This document defines MP-BGP procedures that can be used to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of VPN NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) between different autonomous systems or distinct clusters of the same autonomous system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-marques-ppvpn-rt-constrain-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-marques-ppvpn-rt-constrain-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-marques-ppvpn-rt-constrain-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-4115645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-marques-ppvpn-rt-constrain-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-marques-ppvpn-rt-constrain-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4115645.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 8 06:18: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 GAA04671 for ; Tue, 8 Apr 2003 06:18:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h38AKSm08761 for ; Tue, 8 Apr 2003 06:20:28 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h38AKPc26456 for ; Tue, 8 Apr 2003 06:20:25 -0400 (EDT) Message-Id: <200304081018.h38AIXi29216@zrtps06t.us.nortel.com> From: "DR OWEN GEORGE" Reply-To: owengeorge@latinmail.com To: ppvpn@nortelnetworks.com Date: Tue, 8 Apr 2003 11:17:36 -0700 Subject: BUSINESS PROPOSAL X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: emztd2884.com X-SMTP-MAIL-FROM: owengeorge@latinmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.179.100.59] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA04671 FROM THE DESK OF DR OWEN GEORGE UNION BANK OF NIGERIA TELEPHONE+234-1-7763352 REPLY THROUGH THE NUMBERS ABOVE STRICTLLY A PRIVATE BUSINESS PROPOSAL I AM DR OWEN GEORGE, THE MANAGER, BILLS AND EXCHANGE AT THE FOREIGN REMITTANCE DEPARTMENT OF THE UNION BANK OF NIGERA PLC. I AM WRITING THIS LETTER TO ASK FOR YOUR SUPPORT AND COOPERATION TO CARRY OUT THIS BUSINESS OPPORTUNITY IN MY DEPARTMENT. WE DISCOVERED AN ABANDONED SUM OF $15,000.000.00 (FIFTEEN MILLION UNITED STATES DOLLARS ONLY) IN AN ACCOUNT THAT BELONGS TO ONE OF OUR FOREIGN CUSTOMERS WHO DIED ALONG WITH HIS ENTIRE FAMILY OF A WIFE AND TWO CHILDREN IN NOVEMBER 1997 IN A PLANE CRASH. SINCE WE HARD OF HIS DEATH, WE HAVE BEEN EXPECTING.HIS NEXT-OF-KIN TO COME OVER AND PUT CLAIMS FOR HIS MONEY AS THE HEIR, BECAUSE WE CANNOT RELEASE THE FUND FROM HIS ACCOUNT UNLESS SOMEONE APPLIES FOR CLAIM AS THE NEXT-OF-KIN TO THE DECEASED AS INDICATED IN OUR BANKING GUIDELINES. UNFORTUNATELY, NEITHER THEIR FAMILY MEMBER NOR DISTANT RELATIVE HAS EVER APPEARED TO CLAIM THE SAID FUND. UPON THIS DISCOVERY, I AND OTHER OFFICIALS IN MY DEPARTMENT HAVE AGREED TO MAKE BUSINESS WITH YOU AND RELEASE THE TOTAL AMOUNT INTO YOUR ACCOUNT AS THE HEIR OF THE FUND SINCE NO ONE CAME FOR IT OR DISCOVERED HE MAINTAINED ACCOUNT WITH OUR BANK, OTHERWISE THE FUND WILL BE RETURNED TO THE BANKS TREASURY AS UNCLAIMED FUND. WE HAE AGREED THAT OUR RATIO OF SHARING WILL BE AS STATEDTHUS: 25% FOR YOU AS FOREIGN PARTNER, 65% FOR US THE OFFICAIALS IN MY DEPARTMENT AND 10% FOR THE SETTLEMENT OF ALL LOCAL AND FOREIGN EXPENSES INCURRED BY US AND YOU DURING THE COURSE OF THIS BUSINESS. UPON THE SUCESSFUL COMPLETION OF THIS TRANSFER, I AND ONE OF MY COLLEAGUES WILL COME TO YOUR COUNTRY AND MIND OUR SHARE. IT IS FROM OUR 60% WE INTEND TO IMPORT AGRICULTURAL MACHINERIES INTO MY COUNTRY AS A WAY OF RECYCLING THE FUND. TO COMMENCE THIS TRANSACTION, WE REQUIRE YOU TO IMMEDIATELY INDICATE YOUR INTEREST BY A RETURN E-MAIL AND ENCLOSE YOUR PRIVATE CONTACT TELEPHONE NUMBER, FAX NUMBER FULL NAME AND ADDRESS AND YOUR DESIGNATED BANK COORDINATES TO ENABLE US FILE LETTER OF CLAIM TO THE APPROPRIATE DEPARTMENTS FOR NECESSARY APPROVALS BEFORE THE TRANSFER CAN BE MADE. NOTE ALSO, THIS TRANSACTION MUST BE KEPT STRICTLY CONFIDENTIAL BECAUSE OF ITS NATURE. I LOOK FORWARD TO RECEIVING YOUR PROMPT RESPONSE. DR OWEN GEORGE From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 8 06:44: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 GAA05476 for ; Tue, 8 Apr 2003 06:44:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h38Aksm12740 for ; Tue, 8 Apr 2003 06:46:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h38Akqc04377 for ; Tue, 8 Apr 2003 06:46:52 -0400 (EDT) Message-Id: <200304081045.h38Aj4M04751@zrtps0km.us.nortel.com> From: "DR GEORGE OWEN" Reply-To: georgeowen@latinmail.com To: ppvpn@nortelnetworks.com Date: Tue, 8 Apr 2003 11:44:08 -0700 Subject: BUSINESS PROPOSAL X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: localhst1455.com X-SMTP-MAIL-FROM: georgeowen@latinmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.179.100.59] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA05476 FROM THE DESK OF DR GEORGE OWEN UNION BANK OF NIGERIA TELEPHONE+234-1-7763352 REPLY THROUGH THE NUMBERS ABOVE STRICTLLY A PRIVATE BUSINESS PROPOSAL I AM DR GEORGE OWEN, THE MANAGER, BILLS AND EXCHANGE AT THE FOREIGN REMITTANCE DEPARTMENT OF THE UNION BANK OF NIGERA PLC. I AM WRITING THIS LETTER TO ASK FOR YOUR SUPPORT AND COOPERATION TO CARRY OUT THIS BUSINESS OPPORTUNITY IN MY DEPARTMENT. WE DISCOVERED AN ABANDONED SUM OF $15,000.000.00 (FIFTEEN MILLION UNITED STATES DOLLARS ONLY) IN AN ACCOUNT THAT BELONGS TO ONE OF OUR FOREIGN CUSTOMERS WHO DIED ALONG WITH HIS ENTIRE FAMILY OF A WIFE AND TWO CHILDREN IN NOVEMBER 1997 IN A PLANE CRASH. SINCE WE HARD OF HIS DEATH, WE HAVE BEEN EXPECTING.HIS NEXT-OF-KIN TO COME OVER AND PUT CLAIMS FOR HIS MONEY AS THE HEIR, BECAUSE WE CANNOT RELEASE THE FUND FROM HIS ACCOUNT UNLESS SOMEONE APPLIES FOR CLAIM AS THE NEXT-OF-KIN TO THE DECEASED AS INDICATED IN OUR BANKING GUIDELINES. UNFORTUNATELY, NEITHER THEIR FAMILY MEMBER NOR DISTANT RELATIVE HAS EVER APPEARED TO CLAIM THE SAID FUND. UPON THIS DISCOVERY, I AND OTHER OFFICIALS IN MY DEPARTMENT HAVE AGREED TO MAKE BUSINESS WITH YOU AND RELEASE THE TOTAL AMOUNT INTO YOUR ACCOUNT AS THE HEIR OF THE FUND SINCE NO ONE CAME FOR IT OR DISCOVERED HE MAINTAINED ACCOUNT WITH OUR BANK, OTHERWISE THE FUND WILL BE RETURNED TO THE BANKS TREASURY AS UNCLAIMED FUND. WE HAE AGREED THAT OUR RATIO OF SHARING WILL BE AS STATEDTHUS: 25% FOR YOU AS FOREIGN PARTNER, 65% FOR US THE OFFICAIALS IN MY DEPARTMENT AND 10% FOR THE SETTLEMENT OF ALL LOCAL AND FOREIGN EXPENSES INCURRED BY US AND YOU DURING THE COURSE OF THIS BUSINESS. UPON THE SUCESSFUL COMPLETION OF THIS TRANSFER, I AND ONE OF MY COLLEAGUES WILL COME TO YOUR COUNTRY AND MIND OUR SHARE. IT IS FROM OUR 60% WE INTEND TO IMPORT AGRICULTURAL MACHINERIES INTO MY COUNTRY AS A WAY OF RECYCLING THE FUND. TO COMMENCE THIS TRANSACTION, WE REQUIRE YOU TO IMMEDIATELY INDICATE YOUR INTEREST BY A RETURN E-MAIL AND ENCLOSE YOUR PRIVATE CONTACT TELEPHONE NUMBER, FAX NUMBER FULL NAME AND ADDRESS AND YOUR DESIGNATED BANK COORDINATES TO ENABLE US FILE LETTER OF CLAIM TO THE APPROPRIATE DEPARTMENTS FOR NECESSARY APPROVALS BEFORE THE TRANSFER CAN BE MADE. NOTE ALSO, THIS TRANSACTION MUST BE KEPT STRICTLY CONFIDENTIAL BECAUSE OF ITS NATURE. I LOOK FORWARD TO RECEIVING YOUR PROMPT RESPONSE. DR GEORGE OWEN From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 8 07:04:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06178 for ; Tue, 8 Apr 2003 07:04:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h38B6hm24451 for ; Tue, 8 Apr 2003 07:06:43 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h38B6cc12404 for ; Tue, 8 Apr 2003 07:06:39 -0400 (EDT) Message-Id: <200304081104.h38B4Yi11761@zrtps06t.us.nortel.com> From: "DR GEORGE OWEN" Reply-To: owengeorge@latinmail.com To: ppvpn@nortelnetworks.com Date: Tue, 8 Apr 2003 12:03:36 -0700 Subject: BUSINESS PROPOSAL X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: localhst1538.com X-SMTP-MAIL-FROM: owengeorge@latinmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.179.100.59] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06178 FROM THE DESK OF DR GEORGE OWEN UNION BANK OF NIGERIA TELEPHONE+234-1-7763352 REPLY THROUGH THE NUMBERS ABOVE STRICTLLY A PRIVATE BUSINESS PROPOSAL I AM DR GEORGE OWEN, THE MANAGER, BILLS AND EXCHANGE AT THE FOREIGN REMITTANCE DEPARTMENT OF THE UNION BANK OF NIGERA PLC. I AM WRITING THIS LETTER TO ASK FOR YOUR SUPPORT AND COOPERATION TO CARRY OUT THIS BUSINESS OPPORTUNITY IN MY DEPARTMENT. WE DISCOVERED AN ABANDONED SUM OF $15,000.000.00 (FIFTEEN MILLION UNITED STATES DOLLARS ONLY) IN AN ACCOUNT THAT BELONGS TO ONE OF OUR FOREIGN CUSTOMERS WHO DIED ALONG WITH HIS ENTIRE FAMILY OF A WIFE AND TWO CHILDREN IN NOVEMBER 1997 IN A PLANE CRASH. SINCE WE HARD OF HIS DEATH, WE HAVE BEEN EXPECTING.HIS NEXT-OF-KIN TO COME OVER AND PUT CLAIMS FOR HIS MONEY AS THE HEIR, BECAUSE WE CANNOT RELEASE THE FUND FROM HIS ACCOUNT UNLESS SOMEONE APPLIES FOR CLAIM AS THE NEXT-OF-KIN TO THE DECEASED AS INDICATED IN OUR BANKING GUIDELINES. UNFORTUNATELY, NEITHER THEIR FAMILY MEMBER NOR DISTANT RELATIVE HAS EVER APPEARED TO CLAIM THE SAID FUND. UPON THIS DISCOVERY, I AND OTHER OFFICIALS IN MY DEPARTMENT HAVE AGREED TO MAKE BUSINESS WITH YOU AND RELEASE THE TOTAL AMOUNT INTO YOUR ACCOUNT AS THE HEIR OF THE FUND SINCE NO ONE CAME FOR IT OR DISCOVERED HE MAINTAINED ACCOUNT WITH OUR BANK, OTHERWISE THE FUND WILL BE RETURNED TO THE BANKS TREASURY AS UNCLAIMED FUND. WE HAE AGREED THAT OUR RATIO OF SHARING WILL BE AS STATEDTHUS: 25% FOR YOU AS FOREIGN PARTNER, 65% FOR US THE OFFICAIALS IN MY DEPARTMENT AND 10% FOR THE SETTLEMENT OF ALL LOCAL AND FOREIGN EXPENSES INCURRED BY US AND YOU DURING THE COURSE OF THIS BUSINESS. UPON THE SUCESSFUL COMPLETION OF THIS TRANSFER, I AND ONE OF MY COLLEAGUES WILL COME TO YOUR COUNTRY AND MIND OUR SHARE. IT IS FROM OUR 60% WE INTEND TO IMPORT AGRICULTURAL MACHINERIES INTO MY COUNTRY AS A WAY OF RECYCLING THE FUND. TO COMMENCE THIS TRANSACTION, WE REQUIRE YOU TO IMMEDIATELY INDICATE YOUR INTEREST BY A RETURN E-MAIL AND ENCLOSE YOUR PRIVATE CONTACT TELEPHONE NUMBER, FAX NUMBER FULL NAME AND ADDRESS AND YOUR DESIGNATED BANK COORDINATES TO ENABLE US FILE LETTER OF CLAIM TO THE APPROPRIATE DEPARTMENTS FOR NECESSARY APPROVALS BEFORE THE TRANSFER CAN BE MADE. NOTE ALSO, THIS TRANSACTION MUST BE KEPT STRICTLY CONFIDENTIAL BECAUSE OF ITS NATURE. I LOOK FORWARD TO RECEIVING YOUR PROMPT RESPONSE. DR GEORGE OWEN From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 8 15:58: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 PAA29889 for ; Tue, 8 Apr 2003 15:58:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h38JqKm21696 for ; Tue, 8 Apr 2003 15:52:21 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h38JqHc16021 for ; Tue, 8 Apr 2003 15:52:18 -0400 (EDT) Message-Id: <200304081950.h38Joc214095@zcars0mt.ca.nortel.com> From: "Covenant Academy" To: Subject: Where Knowledge is Power Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 8 Apr 2003 15:48:46 X-SMTP-HELO: edward X-SMTP-MAIL-FROM: kingdomedu@access-4-free.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: as11-ati-ga-1-173.rasserver.net [204.30.146.173] X-LYRIS-Message-Id: Where Knowledge is Power Satisfied

Satisfied with the education your child is receiving? 

 

Make a difference in your children's education 

by staying  in touch 

with what they are learning.

 

S ome parents fail at home schooling for one reason:

Lack of Support!

That's where Covenant Academy steps in.

We offer our home schooling parents a toll free support line with help in guidance, curriculum choice and selection, learning disabilities, and evaluation tests, etc.

Cutting edge curriculum designed for the accelerated student and the educationally challenged, as well.

 

Fully Accredited!

NO ADDITIONAL FEES!  YOUR TUITION COVERS EVERYTHING !

Books, Tests, Progress Reports, Assignments, Curriculum, Report Cards, Grading, Score Keys, Transcripts, Tutorials, Record keeping, Academic Projections, Registration fee.

FREE SHIPPING AND HANDLING!!!

Covenant Academy is a unique home study program designed by a proven leader and specialist in home school education programs.  Covenant Academy delivers a high quality, parent-administered Christian education, from kindergarten through a high school diploma, right to your front door.

Covenant Academy . . . 

an affordable home education program.

 

Recognized by the 

South Carolina Homeschooling Association

 

Call Today!    1-706-935-8540

 

We comply with proposed federal legislation regarding unsolicited commercial e-mail by providing you with a method for your e-mail address to be removed from our database.   To remove your address, please CLICK HERE , and type REMOVE in the subject line. If you do not type the word REMOVE in the subject line, your request to be removed will not be processed.

 

 

From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 9 10:46:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01371 for ; Wed, 9 Apr 2003 10:46:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39EmY514229 for ; Wed, 9 Apr 2003 10:48:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h39EmUN07105 for ; Wed, 9 Apr 2003 10:48:31 -0400 (EDT) Message-ID: <000311e5bb15$cbd60857$44072024@yegpkhq.slp> From: "Harry Ronga" To: Subject: Still up for tuesday?..... 79-2 Date: Wed, 09 Apr 2003 20:22:33 +1000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B0_50E01D3A.C2024A04" X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Importance: Normal X-SMTP-HELO: aol.com X-SMTP-MAIL-FROM: har_rongjqcb@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: OL214-219.fibertel.com.ar [24.232.219.214] X-LYRIS-Message-Id: ------=_NextPart_000_00B0_50E01D3A.C2024A04 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 MDM2OWlRa1c4LTY0NXZpd3EzODUzUmlObzQtNjQ5QmZoejUwMDBpd1ZKMy05 NzdzcXpWMzkyN0pycUQxLTU1M2lrbDYyDQo8aHRtbD4NCjxoZWFkPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCI+ DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KICA8dGFibGUgd2lkdGg9IjUyMyIg aGVpZ2h0PSIyNiI+DQogICAgPHRyPiANCiAgICAgIDx0ZCBoZWlnaHQ9IjIi IGFsaWduPSJjZW50ZXIiIHZhbGlnbj0ibWlkZGxlIiBiZ2NvbG9yPSIjRkZG RkZGIiB3aWR0aD0iNTIxIj4NCiAgICAgICAgPHAgYWxpZ249ImxlZnQiPjxm b250IHNpemU9IjIiIGZhY2U9InZlcmRhbmEiIGNvbG9yPSIjMDAwMDAwIj5I ZXksIEhvdw0KICAgICAgICBkbyB5b3UgbGlrZSB0aGUgc2l0ZSBJIGp1c3Qg Zm91bmQ/PC9mb250PjwvcD4NCiAgICAgIDwvdGQ+DQogICAgPC90cj4NCiAg PC90YWJsZT4NCjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCiAgPGNl bnRlcj4NCiAgPHRhYmxlIGJvcmRlcj0iMCIgd2lkdGg9IjY1JSIgaGVpZ2h0 PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgIDx0 cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTAwJSIgaGVpZ2h0PSIxMTciPg0KICAg ICAgICA8cCBhbGlnbj0iY2VudGVyIj48YSBocmVmPSJodHRwOi8vcmQueWFo b28uY29tLypodHRwOi8vd3d3LmVtYWlsb2ZmZXIudXMvZnMvaW5kZXguaHRt bCI+PGltZyBib3JkZXI9IjAiIHNyYz0iaHR0cDovL3JkLnlhaG9vLmNvbS8q aHR0cDovL3d3dy5lbWFpbG9mZmVyLnVzL2ZzL2ZzMl90b3AuanBnIiB3aWR0 aD0iNTIzIiBoZWlnaHQ9IjE0NiI+PC9hPjwvdGQ+DQogICAgPC90cj4NCiAg ICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjEwMCUiIGhlaWdodD0iMSI+DQog ICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly9yZC55 YWhvby5jb20vKmh0dHA6Ly93d3cuZW1haWxvZmZlci51cy9mcy9pbmRleC5o dG1sIj48aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vcmQueWFob28uY29t LypodHRwOi8vd3d3LmVtYWlsb2ZmZXIudXMvZnMvZnMyX2JvdHRvbS5qcGci IHdpZHRoPSI1MjMiIGhlaWdodD0iMTQ2Ij48L2E+PC90ZD4NCiAgICA8L3Ry Pg0KICA8L3RhYmxlPg0KICA8L2NlbnRlcj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0KMjc3N05wU3o2LTgyM0NaS084MDY1dlFVZjUtMjY4bU9qSTA3 MzZzTGNLMC00ODVaemlCMzAwMENRRlkwLTY4OVBGWVU5NTczSFF4bDcx ------=_NextPart_000_00B0_50E01D3A.C2024A04-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 9 18:17:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17790 for ; Wed, 9 Apr 2003 18:17:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39MJh528375 for ; Wed, 9 Apr 2003 18:19:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h39MJeN26124 for ; Wed, 9 Apr 2003 18:19:40 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Marco Carugi" , Cc: "'Rick Wilder'" Subject: RE: San Francisco PPVPN WG minutes Date: Wed, 9 Apr 2003 15:16:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C2FEAB.03F1B4B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-OriginalArrivalTime: 09 Apr 2003 22:16:43.0505 (UTC) FILETIME=[B3AA6610:01C2FEE5] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C2FEAB.03F1B4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit San Francisco PPVPN WG minutesMarco, Rick, I'd like you to make an official request for whether draft-lasserre-vkompella-ppvpn-vpls-04.txt should become a WG document, since folks might have missed your comment in the minutes. Below is the discussion in the room on the draft relevant to whether it should be a WG document. Thanks. -Vach 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. [snipped] Marco: asked for show of hands to make this a wG draft. Strong interest was shown in room. Further discussion on the list. ------=_NextPart_000_0008_01C2FEAB.03F1B4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable San Francisco PPVPN WG minutes
Marco,=20 Rick,
 
I'd=20 like you to make an official request for whether=20 draft-lasserre-vkompella-ppvpn-vpls-04.txt should become a WG=20 document, since folks might have missed your comment in the=20 minutes.
 
Below=20 is the discussion in the room on the draft relevant to whether it should = be a WG=20 document.
 
Thanks.
 
-Vach
Alex: For a document to become a WG draft, it doesn't have to = be 100%=20 correct.  It can become a WG document if it is a good = start.

Matt: I wanted to make the same=20 comment.  

 
[snipped] 

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

------=_NextPart_000_0008_01C2FEAB.03F1B4B0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 07:49:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15805 for ; Thu, 10 Apr 2003 07:49:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ABpXl20428 for ; Thu, 10 Apr 2003 07:51:33 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ABpUQ20670 for ; Thu, 10 Apr 2003 07:51:30 -0400 (EDT) Message-ID: <20030410114916.12588.qmail@web41812.mail.yahoo.com> Date: Thu, 10 Apr 2003 12:49:16 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Route Distinguisher and Route Target To: mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41812.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41812.mail.yahoo.com [66.218.93.146] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Hello, Is there any direct co-relation between the Route Distinguisher (RD) that i configure on my system with the ROute targets that i may set in the VRF? My question is - does the RD automatically get inserted in my import route target list? Also, suppose i advertise a VPN4 route using BGP from PE1 to PE2. Also suppose that PE2 accepts this because of the import Route Target configured on it. Now what does it do with the RD which has been inserted in front of the actual IPv4 prefix? AFAIK it will simply throw it away and advertise that route to all the CE routers in that VRF. Am i correct in my understanding? Thanks for any help in this! 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 Thu Apr 10 08:22:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17220 for ; Thu, 10 Apr 2003 08:22:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ACO5l00429 for ; Thu, 10 Apr 2003 08:24:05 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ACO2Q19825 for ; Thu, 10 Apr 2003 08:24:02 -0400 (EDT) Date: Thu, 10 Apr 2003 09:18:53 -0300 (EST) From: Marcel Cavalcanti De Castro To: ppvpn@nortelnetworks.com, mpls-ops@mplsrc.com Subject: Implementation of RFC2547bis on Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ariadne.dt.fee.unicamp.br id IAA02803 X-SMTP-HELO: ariadne.dt.fee.unicamp.br X-SMTP-MAIL-FROM: castro@dt.fee.unicamp.br X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ariadne.dt.fee.unicamp.br [143.106.12.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA17220 Hi All Are there any implementation of RFC2547bis based on linux? Thanks for your attention @> /()\ -^^--------------------------------------------------------- Marcel Cavalcanti de Castro Departamento de Telemática - DT Universidade Estadual de Campinas - UNICAMP www.dt.fee.unicamp.br/~castro ICQ: 131702293 ----------------------------------------------------------- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 09:54:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20243 for ; Thu, 10 Apr 2003 09:54:05 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ADu7l21654 for ; Thu, 10 Apr 2003 09:56:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ADu4Q08967 for ; Thu, 10 Apr 2003 09:56:04 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF725DC5@zbl6c004.corpeast.baynetworks.com> From: "Ramasamy Jesuraj" To: "'John Smith'" , mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com Subject: RE: Route Distinguisher and Route Target Date: Thu, 10 Apr 2003 09:54:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF68.767A35BC" 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_01C2FF68.767A35BC Content-Type: text/plain RD and RT are used for different purposes. There should not be any co-relation. --JJ -----Original Message----- From: John Smith [mailto:jsmith4112003@yahoo.co.uk] Sent: Thursday, April 10, 2003 7:49 AM To: mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com Subject: Route Distinguisher and Route Target Hello, Is there any direct co-relation between the Route Distinguisher (RD) that i configure on my system with the ROute targets that i may set in the VRF? My question is - does the RD automatically get inserted in my import route target list? Also, suppose i advertise a VPN4 route using BGP from PE1 to PE2. Also suppose that PE2 accepts this because of the import Route Target configured on it. Now what does it do with the RD which has been inserted in front of the actual IPv4 prefix? AFAIK it will simply throw it away and advertise that route to all the CE routers in that VRF. Am i correct in my understanding? Thanks for any help in this! 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_01C2FF68.767A35BC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Route Distinguisher and Route Target

RD and RT are used for different purposes. There = should not be any co-relation.

--JJ

-----Original Message-----
From: John Smith [mailto:jsmith4112003@yahoo.co.= uk]
Sent: Thursday, April 10, 2003 7:49 AM
To: mpls-ops@mplsrc.com
Cc: ppvpn@nortelnetworks.com
Subject: Route Distinguisher and Route Target


Hello,
Is there any direct co-relation between the Route = Distinguisher (RD) that i configure on my system with the ROute targets = that i may set in the VRF?

My question is - does the RD automatically get = inserted in my import route target list?

Also, suppose i advertise a VPN4 route using BGP from = PE1 to PE2. Also suppose that PE2 accepts this because of the import = Route Target configured on it. Now what does it do with the RD which = has been inserted in front of the actual IPv4 prefix?

AFAIK it will simply throw it away and advertise that = route to all the CE routers in that VRF.

Am i correct in my understanding?

Thanks for any help in this!

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_01C2FF68.767A35BC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 11:04:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23244 for ; Thu, 10 Apr 2003 11:04:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AF69l20850 for ; Thu, 10 Apr 2003 11:06:09 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3AF64Q23814 for ; Thu, 10 Apr 2003 11:06:04 -0400 (EDT) Date: Thu, 10 Apr 2003 11:00:44 -0400 (EDT) From: Siddharth Aanand X-X-Sender: saanand@boysenberry To: =?iso-8859-1?q?John=20Smith?= cc: mpls-ops@mplsrc.com, Subject: Re: Route Distinguisher and Route Target In-Reply-To: <20030410114916.12588.qmail@web41812.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: saanand@pit.comms.marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Smith > > Also, suppose i advertise a VPN4 route using BGP from PE1 to PE2. Also > suppose that PE2 > accepts this because of the import Route Target configured on it. Now > what does it do > with the RD which has been inserted in front of the actual IPv4 prefix? > > AFAIK it will simply throw it away and advertise that route to > all the CE routers in that VRF. > > Am i correct in my understanding? Yes. The last paragraph of section 4.3 of the RFC says that on the far-end PEs, the received VPN-IPv4 addresses are converted back to IP routes and "imported" into the VRFs. -Sidd Aanand Marconi Comms. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 11:15:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23500 for ; Thu, 10 Apr 2003 11:15:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AFHOl25986 for ; Thu, 10 Apr 2003 11:17:24 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3AFHKQ05091 for ; Thu, 10 Apr 2003 11:17:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RES: [MPLS-OPS]: Implementation of RFC2547bis on Linux Date: Thu, 10 Apr 2003 12:08:09 -0300 Message-ID: <5BA4300ABA254E4CA8D3994568E52EE3281E7B@MAILSRV1.aquarius.cpqd.com.br> Thread-Topic: [MPLS-OPS]: Implementation of RFC2547bis on Linux Thread-Index: AcL/Yv4QACIjSD6KSky/tWX1+CxNIgAEBPCg From: =?iso-8859-1?Q?Lavoisier_Jos=E9_Leite_Farias?= To: "Marcel Cavalcanti De Castro" , , X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SMTP-HELO: conde.cpqd.com.br X-SMTP-MAIL-FROM: lfarias@cpqd.com.br X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: conde.cpqd.com.br [200.231.0.49] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA23500 Marcel, Please take a look on the site right below. Hopefully you can find some implementation right there. http://sourceforge.net/ Best Regards, Lavoisier J.L.Farias Telecom System Engineer CPqD Telecom & IT Solutions Telefone : +55-19-3705-5758 / Fax +55-19-3705-6630 lfarias@cpqd.com.br www.cpqd.com.br www.cpqdusa.com -----Mensagem original----- De: Marcel Cavalcanti De Castro [mailto:castro@dt.fee.unicamp.br] Enviada em: quinta-feira, 10 de abril de 2003 09:19 Para: ppvpn@nortelnetworks.com; mpls-ops@mplsrc.com Assunto: [MPLS-OPS]: Implementation of RFC2547bis on Linux Hi All Are there any implementation of RFC2547bis based on linux? Thanks for your attention @> /()\ -^^--------------------------------------------------------- Marcel Cavalcanti de Castro Departamento de Telemática - DT Universidade Estadual de Campinas - UNICAMP www.dt.fee.unicamp.br/~castro ICQ: 131702293 ----------------------------------------------------------- ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 11:21:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23682 for ; Thu, 10 Apr 2003 11:21:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AFNTl29146 for ; Thu, 10 Apr 2003 11:23:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3AFNPQ09722 for ; Thu, 10 Apr 2003 11:23:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: draft-lasserre-vkompella-ppvpn-vpls as working group draft Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF74.B36BD887" Date: Thu, 10 Apr 2003 11:20:21 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> Thread-Topic: draft-lasserre-vkompella-ppvpn-vpls as working group draft thread-index: AcL/dLNYtXmgS02YQIiAxf1Hzqs03A== From: "Rick Wilder" To: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FF74.B36BD887 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As noted in the minutes, at the San Francisco meeting strong interest was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We agreed to finalize that decision only after the WG participants who weren't there could have a say. =20 So, if there are opinions that have not been heard, now is the time, and this list is the place. Let's set a one-week limit to conclude this issue. =20 Rick =20 ------------------------------------------------------------------------ ------------------------------------------------------------------------ --- From the minutes: =20 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. =20 =20 [snipped]=20 Marco: asked for show of hands to make this a wG draft.=20 Strong interest was shown in room. Further discussion on the list.=20 =20 ------_=_NextPart_001_01C2FF74.B36BD887 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As noted in the minutes, at the = San Francisco meeting strong interest = was expressed in pursuing the “draft-lasserre-vkompella-ppvpn-vpls” as a working group draft. We agreed to finalize that decision only after = the WG participants who weren’t there could have a say.

 

So, if there are opinions that have not been heard, now is the = time, and this list is the place. Let’s set a one-week limit to conclude = this issue.

 

Rick

 

------------------------------------------------------= -------------------------------------------------------------------------= --------------------

From the minutes:

 

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.  

 
[snipped] 

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

 

=00 ------_=_NextPart_001_01C2FF74.B36BD887-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 12:48:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26250 for ; Thu, 10 Apr 2003 12:48:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AGoTl28058 for ; Thu, 10 Apr 2003 12:50:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3AGoQQ06730 for ; Thu, 10 Apr 2003 12:50:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16021.41040.120150.21757@harjus.eng.song.fi> Date: Thu, 10 Apr 2003 19:48:16 +0300 To: "Rick Wilder" Cc: Subject: draft-lasserre-vkompella-ppvpn-vpls as working group draft In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> References: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> X-Mailer: VM 7.03 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick Wilder writes: > As noted in the minutes, at the San Francisco meeting strong interest > was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a > working group draft. We agreed to finalize that decision only after the > WG participants who weren't there could have a say. there was also lots of support in s.f. regarding the radius discovery draft and i got the impression that confirmation about its wg status was suppose to happen after the meeting on the mailing list. i have a new version written, but i would like to publish it as a wg, rather than an individual document. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 13:28:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27332 for ; Thu, 10 Apr 2003 13:28:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AHUQl14722 for ; Thu, 10 Apr 2003 13:30:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3AHUNQ23406 for ; Thu, 10 Apr 2003 13:30:23 -0400 (EDT) Date: Thu, 10 Apr 2003 10:27:13 -0700 (PDT) From: Kireeti Kompella Message-Id: <200304101727.h3AHRDo24513@kummer.juniper.net> To: ppvpn@nortelnetworks.com, rwilder@masergy.com Subject: progressing docs ... In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hi Rick, If you are going down the path of progressing VPLS docs, could you also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a PPVPN WG doc? Thanks, Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 14:52: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 OAA00723 for ; Thu, 10 Apr 2003 14:52:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AIs8l06050 for ; Thu, 10 Apr 2003 14:54:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3AIs5Q06670 for ; Thu, 10 Apr 2003 14:54:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16021.48498.983660.480880@harjus.eng.song.fi> Date: Thu, 10 Apr 2003 21:52:34 +0300 To: ppvpn@nortelnetworks.com Subject: new radius discovery draft X-Mailer: VM 7.03 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit i have written (but not submitted yet) a new version of the radius discovery draft. it doesn't include any major changes, but just clarifications and complete details of the required new radius attributes (in fact, there is only one). it should thus contain enough detail to be implementable both at the radius server and at the pe. the former should take only a few hours or at most a week if also a web based provisioning system is included. my proposal is that this new version would become a working group document rather than the -03 version that is available in the official archives. the url of the new version is ftp://lohi.eng.song.fi/tmp/draft-heinanen-radius-pe-discovery-04.txt the directory is not listable. comments are of course appreciated. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 15:28:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03534 for ; Thu, 10 Apr 2003 15:28:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AJUul22744 for ; Thu, 10 Apr 2003 15:30:56 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3AJUqQ28342 for ; Thu, 10 Apr 2003 15:30:53 -0400 (EDT) Reply-To: From: "himanshu shah" To: "'Kireeti Kompella'" , , Subject: RE: progressing docs ... Date: Thu, 10 Apr 2003 15:28:41 -0400 Message-ID: <001001c2ff97$652f04c0$021ea8c0@HSHAH700> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200304101727.h3AHRDo24513@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-SMTP-HELO: smtp02.mrf.mail.rcn.net X-SMTP-MAIL-FROM: hshah@rcn.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp02.mrf.mail.rcn.net [207.172.4.61] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ditto for draft-shah-ppvpn-ipls-01.txt. /himanshu -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, April 10, 2003 1:27 PM To: ppvpn@nortelnetworks.com; rwilder@masergy.com Subject: progressing docs ... Hi Rick, If you are going down the path of progressing VPLS docs, could you also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a PPVPN WG doc? Thanks, Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 21:25:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14501 for ; Thu, 10 Apr 2003 21:24:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3B1R3l06666 for ; Thu, 10 Apr 2003 21:27:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3B1R0Q18687 for ; Thu, 10 Apr 2003 21:27:00 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6AA9@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "Marco Carugi" , "'Rick Wilder'" Cc: ppvpn@nortelnetworks.com Subject: progressing docs Date: Thu, 10 Apr 2003 21:25:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FFC9.2B495210" 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_01C2FFC9.2B495210 Content-Type: text/plain Marco/Rick, Following the increasing interest of the SPs in the VPLS distributed model, based on various successful trails of such type of solution in large SP networks, and backup by a handful of vendors that are supporting the GVPLS solution, I would like to request "draft-radoaca-ppvpn-gvpls-01.txt" to be validated as a WG document. We believe that paying attention to such model, will provide a good long term solution, where non-distributed and distributed models can coexist and complement each other in a consistent way. Cheers Vasile ------_=_NextPart_001_01C2FFC9.2B495210 Content-Type: text/html Content-Transfer-Encoding: quoted-printable progressing docs

Marco/Rick,

Following  the increasing = interest of the SPs in the VPLS distributed model, based on various = successful trails of such type of solution in large SP networks, and = backup by a handful of vendors that are supporting the GVPLS solution, = I would like  to request   = "draft-radoaca-ppvpn-gvpls-01.txt" to be validated as a WG = document.

We believe that paying attention to = such model, will provide a good long term solution, where = non-distributed and distributed models can coexist and complement each = other in a consistent way.

Cheers
   Vasile
 

------_=_NextPart_001_01C2FFC9.2B495210-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 10 22:46:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15987 for ; Thu, 10 Apr 2003 22:46:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3B2m4l15902 for ; Thu, 10 Apr 2003 22:48:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3B2m1Q20799 for ; Thu, 10 Apr 2003 22:48:01 -0400 (EDT) Date: Thu, 10 Apr 2003 22:39:42 -0400 From: Ron Bonica Subject: RE: progressing docs ... In-reply-to: <200304101727.h3AHRDo24513@kummer.juniper.net> To: Kireeti Kompella , ppvpn@nortelnetworks.com, rwilder@masergy.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: dgesmtp02.wcom.com X-SMTP-MAIL-FROM: Ronald.P.Bonica@wcom.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dgesmtp02.wcom.com [199.249.16.17] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick, I would like to voice support for draft-kompella-ppvpn-vpls-01. If we use BGP to distribute VPN information in L3VPNs, there is a certain elegance in using the same tools to solve the same problem at lower layers. Ron > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, April 10, 2003 1:27 PM > To: ppvpn@nortelnetworks.com; rwilder@masergy.com > Subject: progressing docs ... > > > Hi Rick, > > If you are going down the path of progressing VPLS docs, could you > also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > PPVPN WG doc? > > Thanks, > Kireeti. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 11 02:17: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 CAA00484 for ; Fri, 11 Apr 2003 02:17:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3B6JLj05754 for ; Fri, 11 Apr 2003 02:19:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3B6JIR14072 for ; Fri, 11 Apr 2003 02:19:18 -0400 (EDT) Date: Fri, 11 Apr 2003 15:14:40 +0900 (JST) Message-Id: <20030411.151440.130186686.suzuki.muneyoshi@lab.ntt.co.jp> To: rwilder@masergy.com, "Marco Carugi" Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft From: Muneyoshi Suzuki In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> References: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick and Marco, According to your slide in the March meeting, L2 FW doc is requested to review by IEEE 802.1 WG. How did they commented on the L2 FW doc? IMHO, before moving forward, the WG should verify consistency with existing LAN/Bridge implementations and standards in architecture level, because architecture level error is usually fatal and beyond recall, as I pointed out in the PWE3 WG. I thinks it is not late to decide/select something after we receive comments from experts of LAN technology area. Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 11 04:25: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 EAA03564 for ; Fri, 11 Apr 2003 04:25:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3B8R6j17205 for ; Fri, 11 Apr 2003 04:27:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3B8R2R25041 for ; Fri, 11 Apr 2003 04:27:03 -0400 (EDT) Date: Fri, 11 Apr 2003 10:25:00 +0200 (MEST) From: Javier Achirica X-Sender: To: Subject: RE: progressing docs ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: tudela.mad.ttd.net X-SMTP-MAIL-FROM: achirica@telefonica.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tudela.mad.ttd.net [194.179.1.233] X-LYRIS-Message-Id: I'd also like to support that draft for the same reason. Javier Achirica On Thu, 10 Apr 2003, Ron Bonica wrote: > Rick, > > I would like to voice support for draft-kompella-ppvpn-vpls-01. If we use > BGP to distribute VPN information in L3VPNs, there is a certain > elegance in using the same tools to solve the same problem at lower layers. > > Ron > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Thursday, April 10, 2003 1:27 PM > > To: ppvpn@nortelnetworks.com; rwilder@masergy.com > > Subject: progressing docs ... > > > > > > Hi Rick, > > > > If you are going down the path of progressing VPLS docs, could you > > also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > > PPVPN WG doc? > > > > Thanks, > > Kireeti. > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 11 05:25: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 FAA04852 for ; Fri, 11 Apr 2003 05:25:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3B9S1j00883 for ; Fri, 11 Apr 2003 05:28:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3B9RwR04840 for ; Fri, 11 Apr 2003 05:27:58 -0400 (EDT) Message-ID: From: "Marco Carugi" To: "'Muneyoshi Suzuki'" Cc: ppvpn@nortelnetworks.com, rwilder@masergy.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Fri, 11 Apr 2003 11:25:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3000C.572F0E18" 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_01C3000C.572F0E18 Content-Type: text/plain; charset="iso-8859-1" Muneyoshi, we haven't received feedback from .1 up to now. I'll ping again the 802.1 chair on the topic. Marco > -----Original Message----- > From: Muneyoshi Suzuki [mailto:suzuki.muneyoshi@lab.ntt.co.jp] > Sent: vendredi 11 avril 2003 08:15 > To: rwilder@masergy.com; Carugi, Marco [CTF:0000:EXCH] > Cc: ppvpn@nortelnetworks.com; suzuki.muneyoshi@lab.ntt.co.jp > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working > group draft > > > > Rick and Marco, > > According to your slide in the March meeting, L2 FW doc is requested > to review by IEEE 802.1 WG. How did they commented on the L2 FW doc? > > IMHO, before moving forward, the WG should verify consistency with > existing LAN/Bridge implementations and standards in > architecture level, > because architecture level error is usually fatal and beyond recall, > as I pointed out in the PWE3 WG. > > I thinks it is not late to decide/select something after we receive > comments from experts of LAN technology area. > > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. > ------_=_NextPart_001_01C3000C.572F0E18 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-lasserre-vkompella-ppvpn-vpls as working group = draft

Muneyoshi,

we haven't received feedback from .1 up to = now.
I'll ping again the 802.1 chair on the topic.



Marco

> -----Original Message-----
> From: Muneyoshi Suzuki [mailto:suzuki.muneyoshi@l= ab.ntt.co.jp]
> Sent: vendredi 11 avril 2003 08:15
> To: rwilder@masergy.com; Carugi, Marco = [CTF:0000:EXCH]
> Cc: ppvpn@nortelnetworks.com; = suzuki.muneyoshi@lab.ntt.co.jp
> Subject: Re: = draft-lasserre-vkompella-ppvpn-vpls as working
> group draft
>
>
>
> Rick and Marco,
>
> According to your slide in the March meeting, = L2 FW doc is requested
> to review by IEEE 802.1 WG. How did they = commented on the L2 FW doc?
>
> IMHO, before moving forward, the WG should = verify consistency with
> existing LAN/Bridge implementations and = standards in
> architecture level,
> because architecture level error is usually = fatal and beyond recall,
> as I pointed out in the PWE3 WG.
>
> I thinks it is not late to decide/select = something after we receive
> comments from experts of LAN technology = area.
>
>
> Muneyoshi Suzuki
> Nippon Telegraph and Telephone Corp.
>

------_=_NextPart_001_01C3000C.572F0E18-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 11 08:12:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09077 for ; Fri, 11 Apr 2003 08:12:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3BCEfj18657 for ; Fri, 11 Apr 2003 08:14:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3BCEcR04297 for ; Fri, 11 Apr 2003 08:14:38 -0400 (EDT) Message-ID: <37701240971DD31193970000F6CCB9F704649AD8@duke.datcon.co.uk> From: Ben Miller To: castro@dt.fee.unicamp.br Cc: ppvpn@nortelnetworks.com, mpls-ops@mplsrc.com Subject: RE: Implementation of RFC2547bis on Linux Date: Fri, 11 Apr 2003 13:12:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: miles.dataconnection.com X-SMTP-MAIL-FROM: BMM@dataconnection.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp2.dataconnection.com [192.91.191.8] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA09077 Marcel Data Connection (DCL) a UK based software company (where I work) can provide this software. However, this is a commercial product that requires license fees. It is not open-source (although we do provide source code to our customers). Please let me know if you want any more information or check at www.dataconnection.com//iprouting/vpn.htm . Ben > -----Original Message----- > From: Marcel Cavalcanti De Castro [mailto:castro@dt.fee.unicamp.br] > Sent: 10 April 2003 13:19 > To: ppvpn@nortelnetworks.com; mpls-ops@mplsrc.com > Subject: Implementation of RFC2547bis on Linux > > > Hi All > > Are there any implementation of RFC2547bis based on linux? > > Thanks for your attention > > > @> > /()\ > -^^--------------------------------------------------------- > Marcel Cavalcanti de Castro > Departamento de Telemática - DT > Universidade Estadual de Campinas - UNICAMP > www.dt.fee.unicamp.br/~castro > ICQ: 131702293 > ----------------------------------------------------------- > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 11 08:51:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10641 for ; Fri, 11 Apr 2003 08:51:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3BCrTj24953 for ; Fri, 11 Apr 2003 08:53:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3BCrRR18339 for ; Fri, 11 Apr 2003 08:53:27 -0400 (EDT) Message-ID: From: "Marco Carugi" To: "'Muneyoshi Suzuki'" Cc: "Marco Carugi" , ppvpn@nortelnetworks.com Subject: FW: draft-ietf-ppvpn-l2-framework-03.txt Date: Fri, 11 Apr 2003 14:51:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30028.DF340ACC" 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_01C30028.DF340ACC Content-Type: text/plain; charset="iso-8859-1" FYI Marco -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: vendredi 11 avril 2003 13:13 To: Carugi, Marco [CTF:0000:EXCH] Cc: Mick Seaman; 'erosen@cisco.com' Subject: RE: draft-ietf-ppvpn-l2-framework-03.txt Marco - I will remind 802.1 that they were asked to comment. If you don't see anything by early next week, I guess you can assume that there are no issues. Regards, Tony At 12:29 11/04/2003 +0200, Marco Carugi wrote: Tony, Mick, we didn't receive comments up to now from 802.1 about draft-ietf-ppvpn-l2-framework-03.txt. Can we assume .1 is fine with the current text ? Otherwise, please address any issue as soon as possible (early next week) on the PPVPN Working Group mailing list, ppvpn@nortelnetworks.com. Thanks, Marco Carugi > -----Original Message----- > From: Eric Rosen [ mailto:erosen@cisco.com ] > Sent: mardi 4 mars 2003 15:49 > To: Tony Jeffree; Mick Seaman > Cc: Carugi, Marco [CTF:0000:EXCH] > Subject: draft-ietf-ppvpn-l2-framework-03.txt > > > Gentlemen, > > Marco Carugi has asked me to bring this document to your > attention, so that > we may receive comments from the 802.1 group. Please > address your comments > to the PPVPN Working Group mailing list, ppvpn@nortelnetworks.com. > > Eric Rosen ------_=_NextPart_001_01C30028.DF340ACC Content-Type: text/html; charset="iso-8859-1"
FYI
 
Marco 
 
 -----Original Message-----
From: Tony Jeffree [mailto:tony@jeffree.co.uk]
Sent: vendredi 11 avril 2003 13:13
To: Carugi, Marco [CTF:0000:EXCH]
Cc: Mick Seaman; 'erosen@cisco.com'
Subject: RE: draft-ietf-ppvpn-l2-framework-03.txt

Marco -

I will remind 802.1 that they were asked to comment. If you don't see anything by early next week, I guess you can assume that there are no issues.

Regards,
Tony

At 12:29 11/04/2003 +0200, Marco Carugi wrote:

Tony, Mick,

we didn't receive comments up to now from 802.1 about draft-ietf-ppvpn-l2-framework-03.txt.
Can we assume .1 is fine with the current text ?
Otherwise, please address any issue as soon as possible (early next week) on the PPVPN Working Group mailing list, ppvpn@nortelnetworks.com.

Thanks, Marco Carugi 

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: mardi 4 mars 2003 15:49
> To: Tony Jeffree; Mick Seaman
> Cc: Carugi, Marco [CTF:0000:EXCH]
> Subject: draft-ietf-ppvpn-l2-framework-03.txt
>
>
> Gentlemen,
>
> Marco Carugi has asked me to  bring this document to your
> attention, so that
> we may receive comments from  the 802.1 group.  Please
> address your comments
> to the PPVPN Working Group mailing list, ppvpn@nortelnetworks.com.
>
> Eric Rosen
------_=_NextPart_001_01C30028.DF340ACC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 11 18:47: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 SAA04224 for ; Fri, 11 Apr 2003 18:47:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3BMnGj24002 for ; Fri, 11 Apr 2003 18:49:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3BMnCR23436 for ; Fri, 11 Apr 2003 18:49:12 -0400 (EDT) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" Cc: "Marco Carugi" , "'Rick Wilder'" Subject: PPVPN L2 space : action plan (check for consensus expressed in SF meeting and other open points) Date: Sat, 12 Apr 2003 00:47:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3007C.4A66D024" 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_01C3007C.4A66D024 Content-Type: text/plain; charset="iso-8859-1" Hello. As follow up to recent messages on the list about L2 solution drafts, this is a summary of the various items discussed in SF in the L2 space, including those where consensus was expressed in the room and has to be checked on this list, and those where no consensus was expressed or determined in SF and we require further discussion on the list to determine consensus. 1. The L2 requirements draft (product of the L2 design team) requires wider review by the WG. Action plan : a draft update is expected soon (based on some comments by L2 team members). The intention is to submit this draft to the WG review in around 10-15 days from now (comments on scalability considerations will be particularly appreciated). Target for L2 requirements and L2 framework submission to IESG is May (current April milestone will not be met). 2. L2 Solutions Documents A. Consensus expressed in SF: - VPLS draft-lasserre-vkompella-ppvpn-vpls-04.txt : request to make it a WG doc with strong support in the room. A week has been allocated to receive further input (support, objections) prior to final decision to make this a WG document. - Radius for PE-Based VPN Discovery : strong interest in the room to progress this approach. A new version of the draft has just been published on the mail list, and a week is also allocated to receive further input (support, objections) prior to final decision to make this a WG document. B. Other drafts to be considered for WG document status: - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : no request to make it a WG doc in SF, but author has later requested that on the list. - VPLS draft-kompella-ppvpn-vpls-01: no request to make it a WG doc in SF, but author has later requested that on the list. - IPLS draft-shah-ppvpn-ipls-01.txt : no request to make it a WG doc in SF, but author has later requested that on the list. For these drafts it is up to the authors to generate enough support to warrant WG document status. It is also incumbent on list members to offer their input about these drafts (support, objections) on the list. A one-week period is allocated for now for this discussion. Note: ALL other authors claiming their solution draft should be promoted to WG doc status have to explicitly request this ASAP (early next week) on this list. C. Other issues - Reqts compliance section : To facilitate the WG discussion and future progress in the solution space, we identified the value of a requirements compliance section in each solution ID (claiming to become WG document), indicating how the solution satisfies reqts expressed in the L2 reqts draft. It is requested that solution draft authors update ASAP their ID with this reqts compliance section (and possibly - this is optional - restructuring the document according to a common template (draft-carugi-ppvpn-l2solution-doc-guidelines-01.txt)). The requirements compliance section is not a mandatory requirement to be a WG document, but will need to be added prior to progress towards a proposed standard or experimental standard. - Experimental vs. Standards Track : The issue was raised in the L2 team (which includes the authors of main solution drafts), the experimental option having received the preference by team members, but not unanimously. Different opinions by meeting participants were registered in SF. A separate thread will be opened up on the list for continued discussion of these alternatives concerning progress of L2 solution drafts. Marco and Rick ------_=_NextPart_001_01C3007C.4A66D024 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PPVPN L2 space : action plan (check for consensus expressed in = SF meeting and other open points)

Hello.

As follow up to recent messages on the = list about L2 solution drafts, this is a summary of the various items = discussed in SF in the L2 space, including those where consensus was = expressed in the room and has to be checked on this list, and those = where no consensus was expressed or determined in SF and we require = further discussion on the list to determine consensus.   =

1.  The L2 requirements draft = (product of the L2 design team) requires wider review by the WG. =
Action plan : a draft update is = expected soon (based on some comments by L2 team members). The = intention is to submit this draft to the WG review in around 10-15 days = from now (comments on scalability considerations will be particularly = appreciated).
Target for L2 requirements and L2 framework submission to IESG is May = (current April milestone will not be met).
2. L2 Solutions Documents
A. Consensus expressed in SF:
- VPLS  = draft-lasserre-vkompella-ppvpn-vpls-04.txt : request to make it a WG = doc with strong support in the room. 
A week has been allocated to receive = further input (support, objections) prior to final decision to make = this a WG document.


- Radius for PE-Based VPN Discovery : = strong interest in the room to progress this approach.
A new version of the draft has just = been published on the mail list, and a week is also allocated to = receive further input (support, objections) prior to final decision to = make this a WG document.

B. Other drafts to be considered for = WG document status:
- GVPLS/LPE = draft-radoaca-ppvpn-gvpls-01.txt : no request to make it a WG doc in = SF, but author has later requested that on the list.

- VPLS draft-kompella-ppvpn-vpls-01: = no request to make it a WG doc in SF, but author has later requested = that on the list.

- IPLS draft-shah-ppvpn-ipls-01.txt : = no request to make it a WG doc in SF, but author has later requested = that on the list.

For these drafts it is up to the = authors to generate enough support to warrant WG document status. It is = also incumbent on list members to offer their input about these drafts = (support, objections) on the list. A one-week period is allocated for = now for this discussion.

Note: ALL other authors claiming their = solution draft should be promoted to WG doc status have to explicitly = request this ASAP (early next week) on this list.

C. Other issues
- Reqts compliance section :
To facilitate the WG discussion and = future progress in the solution space, we identified the value of a = requirements compliance section in each solution ID  (claiming to = become WG document), indicating how the solution satisfies reqts = expressed in the L2 reqts draft. It is requested that solution draft = authors update ASAP their ID with this reqts compliance section (and = possibly - this is optional - restructuring the document according to a = common template (draft-carugi-ppvpn-l2solution-doc-guidelines-01.txt)). = The requirements compliance section is not a mandatory requirement to = be a WG document, but will need to be added prior to progress towards a = proposed standard or experimental standard.

- Experimental vs. Standards Track = :
The issue was raised in the L2 team = (which includes the authors of main solution drafts), the experimental = option having received the preference by team members, but not = unanimously. Different opinions by meeting participants were registered = in SF. A separate thread will be opened up on the list for continued = discussion of these alternatives concerning progress of L2 solution = drafts.
Marco and Rick

------_=_NextPart_001_01C3007C.4A66D024-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 12 21:43: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 VAA09420 for ; Sat, 12 Apr 2003 21:43:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3D1jO720431 for ; Sat, 12 Apr 2003 21:45:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3D1jKw03944 for ; Sat, 12 Apr 2003 21:45:21 -0400 (EDT) Message-Id: <200304130142.h3D1gou71751@merlot.juniper.net> To: Ron Bonica cc: Kireeti Kompella , ppvpn@nortelnetworks.com, rwilder@masergy.com Subject: Re: progressing docs ... In-Reply-To: Your message of "Thu, 10 Apr 2003 22:39:42 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78116.1050198170.1@juniper.net> Date: Sat, 12 Apr 2003 18:42:50 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Ron, > Rick, > > I would like to voice support for draft-kompella-ppvpn-vpls-01. If we use > BGP to distribute VPN information in L3VPNs, there is a certain > elegance in using the same tools to solve the same problem at lower layers. I'd like to add my support for this as well. Yakov. > > Ron > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Thursday, April 10, 2003 1:27 PM > > To: ppvpn@nortelnetworks.com; rwilder@masergy.com > > Subject: progressing docs ... > > > > > > Hi Rick, > > > > If you are going down the path of progressing VPLS docs, could you > > also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > > PPVPN WG doc? > > > > Thanks, > > Kireeti. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 12 22:36:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09976 for ; Sat, 12 Apr 2003 22:36:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3D2cI728249 for ; Sat, 12 Apr 2003 22:38:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3D2cFw20634 for ; Sat, 12 Apr 2003 22:38:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: progressing docs ... Date: Sat, 12 Apr 2003 22:35:50 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C436@m-va-bsod03.add0.masergy.com> Thread-Topic: progressing docs ... thread-index: AcMBXgPC3TTMNs9BQyapIwTAo5FGTgAB1Zo3 From: "Rick Wilder" To: "Yakov Rekhter" , "Ron Bonica" Cc: "Kireeti Kompella" , X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA09976 Noted. Thanks for your input. Rick -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Sat 4/12/2003 9:42 PM To: Ron Bonica Cc: Kireeti Kompella; ppvpn@nortelnetworks.com; Rick Wilder Subject: Re: progressing docs ... Ron, > Rick, > > I would like to voice support for draft-kompella-ppvpn-vpls-01. If we use > BGP to distribute VPN information in L3VPNs, there is a certain > elegance in using the same tools to solve the same problem at lower layers. I'd like to add my support for this as well. Yakov. > > Ron > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Thursday, April 10, 2003 1:27 PM > > To: ppvpn@nortelnetworks.com; rwilder@masergy.com > > Subject: progressing docs ... > > > > > > Hi Rick, > > > > If you are going down the path of progressing VPLS docs, could you > > also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > > PPVPN WG doc? > > > > Thanks, > > Kireeti. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Apr 13 23:07: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 XAA10935 for ; Sun, 13 Apr 2003 23:07:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3E3A3r23222 for ; Sun, 13 Apr 2003 23:10:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3E39wZ21562 for ; Sun, 13 Apr 2003 23:09:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20030413145204.01bc6ec8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 13 Apr 2003 20:06:47 -0700 To: ppvpn@nortelnetworks.com, pwe3@ietf.org From: Ali Sajassi Subject: Issues with draft-kompella-ppvpn-vpls-01.txt Cc: Ali Sajassi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: There are several issues with this draft which I would like to be addressed first before being considered as WG document. I am copying PWE3 here as well because one of the issue is pertinent to them. 1) PW Signaling: The draft suggests using BGP as signaling mechanism for Point-to-Point PWs of type Ethernet. The encapsulation and setup of PtP Ethernet PWs are already covered in the PWE3 and LDP-based signaling is the recommended signaling mechanism for PtP PWs in MPLS network. I don't see any benefits of introducing yet another signaling mechanism for this propose; however, the drawback of it are: i) intertwining signaling mechanism w/ auto-discovery restricts the service provider to using BGP auto-discovery only - e.g. if a SP wants to use non-BGP auto-discovery mechanism (such as directory-based radius), then BGP signaling is useless. However LDP-based signaling based on PWE3 draft (draft-ietf-pwe3-control-protocol-02.txt) is independent from auto-discovery mechanism and both BGP and non-BGP auto-discovery can be used by it. ii) inter-operability issues: having two different signaling mechanism for the same PW type and network type (e.g., EoMPLS PW), would necessitate the need for interworking (either at the control plane or at the date plane). This is an unnecessary complication which is not needed. If the interworking is done at the signaling level, it is tedious and unprecedented. And if it is done at the data-plane level, then it creates unnecessary scalability issues for the ASBRs. iii) it limits all the PWs in a VPLS set to have the same characteristics. 2) MAC address flush: This mechanism is inconsistent with 802.1D and the new proposals for 802.1ad. The PE should NOT signal MAC address withdrawal upon link failure but instead it should signal it upon link activation (in case of multiple redundant links). The reason for this is to avoid unnecessary flooding of customer packets when a link failure happens without having redundant links. 3) Customer's BPDUs There is no description of how customers BPDUs are tunneled and in case of back-door connection by customer, how these BPDUs are handled by the SP. These is important in order for the customer's network to operate properly. Among these three issues, the PW signaling for MPLS is the bigger issue and I would like it to be addressed first in the PWE3 before reinventing it in a different form for PPVPN. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Apr 13 23:25: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 XAA11249 for ; Sun, 13 Apr 2003 23:25:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3E3Rwr26789 for ; Sun, 13 Apr 2003 23:27:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3E3RtZ27917 for ; Sun, 13 Apr 2003 23:27:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20030413192710.01bdc2e0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 13 Apr 2003 20:09:29 -0700 To: ppvpn@nortelnetworks.com From: Ali Sajassi Subject: Issues with draft-radoaca-ppvpn-gvpls-01.txt Cc: Ali Sajassi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: One one the main issues with GVPLS is the use of different PWs for unknown unicast frames versus known unicast frames (e.g., using PtMP PWs for unknown unicast and MPtP PWs for known unicast). I raised my concern during the WG meeting and I will reiterate it here again. In regular LAN network, in absence of failure, there is NO possibility for packet re-ordering. However, with the use of different PWs for unicast frames in GVPLS, the possibility of re-ordering customer's Ethernet frames exists even in absence of any failures (e.g., during steady state network operation). This out-of-sequencing happens when a customer destination MAC address is not learnt and customer's frames gets flooded via PtMP PW. Now if after transmission of the first frame, the PE learns the destination MAC address, then the subsequent frames go over a different PW (e.g., MPtP). Since two consecutive frames can go over different PWs and these different PWs can take different path w/ different delays in the network, the two frames can arrive out-of-order at the destination PE and some protocols can be susceptible to this out-of-ordering of the packets. I'd like to know how this packet out-of-ordering will be addressed in GVPLS. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 04:41:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28105 for ; Mon, 14 Apr 2003 04:41:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3E8hte24130 for ; Mon, 14 Apr 2003 04:43:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3E8hpN06700 for ; Mon, 14 Apr 2003 04:43:52 -0400 (EDT) Subject: RE: Implementation of RFC2547bis on Linux Date: Mon, 14 Apr 2003 14:10:27 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4D148FEC6C003445B94D5B264288DBE972C255@blr-k1-msg.wipro.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Implementation of RFC2547bis on Linux Thread-Index: AcL/XFTZWWAbNxJyTeOeHox9xhYpVADBNg2A From: "Shankar Ananthanarayanan Kambat" To: "Marcel Cavalcanti De Castro" , , X-OriginalArrivalTime: 14 Apr 2003 08:40:32.0126 (UTC) FILETIME=[8283B9E0:01C30261] X-SMTP-HELO: wiproecmx2.wipro.com X-SMTP-MAIL-FROM: shankar.kambat@wipro.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: wiproecmx2.wipro.com [164.164.31.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA28105 Hi, Wipro Technologies has an implementation and can provide this software. However, this is a commercial product and not an open source. Let me know if you want more information. - Shankar K A -----Original Message----- From: Marcel Cavalcanti De Castro [mailto:castro@dt.fee.unicamp.br] Sent: Thursday, April 10, 2003 5:49 PM To: ppvpn@nortelnetworks.com; mpls-ops@mplsrc.com Subject: Implementation of RFC2547bis on Linux Hi All Are there any implementation of RFC2547bis based on linux? Thanks for your attention @> /()\ -^^--------------------------------------------------------- Marcel Cavalcanti de Castro Departamento de Telemática - DT Universidade Estadual de Campinas - UNICAMP www.dt.fee.unicamp.br/~castro ICQ: 131702293 ----------------------------------------------------------- **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. *************************************************************************** From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 06:34:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29983 for ; Mon, 14 Apr 2003 06:34:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EAaxe12226 for ; Mon, 14 Apr 2003 06:37:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EAauN23314 for ; Mon, 14 Apr 2003 06:36:57 -0400 (EDT) Content-return: prohibited Date: Mon, 14 Apr 2003 19:35:48 +0900 From: "yuichiro wada" Subject: Re: progressing docs ... In-reply-to: <200304130142.h3D1gou71751@merlot.juniper.net> To: "Yakov Rekhter" , "Ron Bonica" Cc: "Kireeti Kompella" , ppvpn@nortelnetworks.com, rwilder@masergy.com Message-id: <4.0.1-J.20030414192819.0115cf00@mail.ntt.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <"Your message of Thu, 10 Apr 2003 22:39:42 EDT." X-SMTP-HELO: mgw2.noc.ntt.com X-SMTP-MAIL-FROM: yuichiro.wada@ntt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mgw2.noc.ntt.com [210.163.32.69] X-LYRIS-Message-Id: Hi, I would like to add support for this draft as well, in order to advance further discussions on vpls specification. --- yuichiro wada NTT Communications > Ron, > > > Rick, > > > > I would like to voice support for draft-kompella-ppvpn-vpls-01. If we use > > BGP to distribute VPN information in L3VPNs, there is a certain > > elegance in using the same tools to solve the same problem at lower laye rs. > > I'd like to add my support for this as well. > > Yakov. > > > > > Ron > > > > > > > -----Original Message----- > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Sent: Thursday, April 10, 2003 1:27 PM > > > To: ppvpn@nortelnetworks.com; rwilder@masergy.com > > > Subject: progressing docs ... > > > > > > > > > Hi Rick, > > > > > > If you are going down the path of progressing VPLS docs, could you > > > also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > > > PPVPN WG doc? > > > > > > Thanks, > > > Kireeti. > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 07:39:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01196 for ; Mon, 14 Apr 2003 07:39:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EBg2e21469 for ; Mon, 14 Apr 2003 07:42:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EBfvN15494 for ; Mon, 14 Apr 2003 07:41:58 -0400 (EDT) Reply-To: From: "himanshu shah" To: "'Ali Sajassi'" , Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt Date: Mon, 14 Apr 2003 07:39:27 -0400 Message-ID: <000d01c3027a$81c876d0$021ea8c0@HSHAH700> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4.3.2.7.2.20030413192710.01bdc2e0@airborne.cisco.com> X-SMTP-HELO: smtp02.mrf.mail.rcn.net X-SMTP-MAIL-FROM: hshah@rcn.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp02.mrf.mail.rcn.net [207.172.4.61] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit response in line. -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com] Sent: Sunday, April 13, 2003 11:09 PM To: ppvpn@nortelnetworks.com Cc: Ali Sajassi Subject: Issues with draft-radoaca-ppvpn-gvpls-01.txt One one the main issues with GVPLS is the use of different PWs for unknown unicast frames versus known unicast frames (e.g., using PtMP PWs for unknown unicast and MPtP PWs for known unicast). I raised my concern during the WG meeting and I will reiterate it here again. In regular LAN network, in absence of failure, there is NO possibility for packet re-ordering. However, with the use of different PWs for unicast frames in GVPLS, the possibility of re-ordering customer's Ethernet frames exists even in absence of any failures (e.g., during steady state network operation). HS> This may not be entirely true. One can expect, unknown/broadcast frame HS> to arrive out-of-order even in LAN Network. This happens due to how HS> frame processing is architected in a given box. The flooding frame HS> (i.e. broadcast/unknown) within the box may be treated differently HS> than a known frame going out on a single port (e.g. separate queue). This out-of-sequencing happens when a customer destination MAC address is not learnt and customer's frames gets flooded via PtMP PW. Now if after transmission of the first frame, the PE learns the destination MAC address, then the subsequent frames go over a different PW (e.g., MPtP). HS> This is possible but rare. Note that in order to have this happen HS> that remote unknown station has simultaneously generated a frame which HS> causes the local PE to learn its address AND there is a second frame HS> generated by the source without having to get a response back on the HS> frame sent earlier AND this second frame gets through the network over HS> the other PW just enough faster to beat to the first frame AND this HS> second frame is important enough to have it arrive in order. The point HS> is that this is rare enough to be insignificant. Since two consecutive frames can go over different PWs and these different PWs can take different path w/ different delays in the network, the two frames can arrive out-of-order at the destination PE and some protocols can be susceptible to this out-of-ordering of the packets. HS> If one is using LDP for outer tunneling (most common case), both pseudowires HS> maps to same path for a given two PE endpoints. Actually, there is HS> a greater and more common risk of out-of-sequence of packets HS> in a single pseudowire due to network topology changes, fast reroute, etc. HS> Also, most protocols are capable of handling packets received out-of-order, HS> especially, when that occurs during session initiation time. regards, himanshu I'd like to know how this packet out-of-ordering will be addressed in GVPLS. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 09:56: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 JAA05825 for ; Mon, 14 Apr 2003 09:56:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EDwQe17590 for ; Mon, 14 Apr 2003 09:58:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EDwNN29055 for ; Mon, 14 Apr 2003 09:58:23 -0400 (EDT) Message-Id: <200304141355.h3EDtmu59315@merlot.juniper.net> To: Ali Sajassi cc: ppvpn@nortelnetworks.com, pwe3@ietf.org Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Sun, 13 Apr 2003 20:06:47 PDT." <4.3.2.7.2.20030413145204.01bc6ec8@airborne.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97155.1050328548.1@juniper.net> Date: Mon, 14 Apr 2003 06:55:48 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Ali, > There are several issues with this draft which I would like to be addressed > first before being considered as WG document. I am copying PWE3 here as > well because one of the issue is pertinent to them. > > 1) PW Signaling: > The draft suggests using BGP as signaling mechanism for Point-to-Point PWs > of type Ethernet. The encapsulation and setup of PtP Ethernet PWs are > already covered in the PWE3 and LDP-based signaling is the recommended > signaling mechanism for PtP PWs in MPLS network. I don't see any benefits > of introducing yet another signaling mechanism for this propose; however, > the drawback of it are: You didn't mention one important point. Namely, that the draft uses BGP for auto-discovery, and piggybacks label information (signaling) on top of auto-discovery. So, instead of one protocol for signaling (LDP), and another for auto-discovery (BGP) the draft accomplishes both with a single protocol. So, why two protocols (LDP + BGP) is any better than one (BGP) ? In addition, using BGP for both auto-discovery and signaling, instead of using BGP for auto-discovery and LDP for signaling, simplifies inter-provider operations, fits into a common framework for both L2 and 2547 VPNs, etc.... Furthermore, perhaps rereading recently posted e-mails from from several service providers who support draft-kompella-ppvpn-vpls-01.txt may also help you to understand the benefits of the approach described in draft-kompella-ppvpn-vpls-01.txt. > i) intertwining signaling mechanism w/ auto-discovery restricts the service > provider to using BGP auto-discovery only - e.g. if a SP wants to use > non-BGP auto-discovery mechanism (such as directory-based radius), then BGP > signaling is useless. That is correct. But paraphrasing you one could also say that if a SP wants to use a non-MPLS signaling mechanism, then LDP signaling, as described in draft-lasserre-vkompella-ppvpn-vpls-04.txt, is useless. > However LDP-based signaling based on PWE3 draft > (draft-ietf-pwe3-control-protocol-02.txt) is independent from > auto-discovery mechanism and both BGP and non-BGP auto-discovery can be > used by it. > > ii) inter-operability issues: having two different signaling mechanism for > the same PW type and network type (e.g., EoMPLS PW), would necessitate the > need for interworking (either at the control plane or at the date plane). > This is an unnecessary complication which is not needed. If the > interworking is done at the signaling level, it is tedious and > unprecedented. And if it is done at the data-plane level, then it creates > unnecessary scalability issues for the ASBRs. I am really glad you brought up the inter-operability issue, as draft-lasserre-vkompella-ppvpn-vpls-04.txt does not prescribe any auto-discovery mechanism, while listing "three potential candidates, [BGP-DISC], [DNS-DISC], [LDP-DISC]." Perhaps you could explain to the rest of us how inter-operability could be accomplished in this case (e.g., one vendor implements BGP auto-discovery, and another vendor implements Radius-based auto-discovery). > iii) it limits all the PWs in a VPLS set to have the same characteristics. And why exactly this is a problem of *practical* significance in the context of VPLS ? Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 11:33: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 LAA09459 for ; Mon, 14 Apr 2003 11:33:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EFZRe20898 for ; Mon, 14 Apr 2003 11:35:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EFZNN24333 for ; Mon, 14 Apr 2003 11:35:23 -0400 (EDT) Message-Id: <5.2.1.1.0.20030414113145.036c6eb8@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 14 Apr 2003 11:32:08 -0400 To: "Rick Wilder" From: "Andrew G. Malis" Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.ma sergy.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5093093==.ALT" X-OriginalArrivalTime: 14 Apr 2003 15:32:28.0560 (UTC) FILETIME=[0EA84100:01C3029B] X-SMTP-HELO: ns2.vivacenetworks.com X-SMTP-MAIL-FROM: Andy.Malis@vivacenetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.221.212.135] X-LYRIS-Message-Id: --=====================_5093093==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Rick, I would like to support making this a WG draft. Thanks, Andy ------- At 4/10/2003 11:20 AM -0400, Rick Wilder wrote: >As noted in the minutes, at the San Francisco meeting strong interest was >expressed in pursuing the draft-lasserre-vkompella-ppvpn-vplsas a working >group draft. We agreed to finalize that decision only after the WG >participants who werent there could have a say. > > > >So, if there are opinions that have not been heard, now is the time, and >this list is the place. Lets set a one-week limit to conclude this issue. > > > >Rick > > > >--------------------------------------------------------------------------------------------------------------------------------------------------- > > From the minutes: > > > >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. > > >[snipped] > > Marco: asked for show of hands to make this a wG draft. >Strong interest was shown in room. Further discussion on the list. > > --=====================_5093093==.ALT Content-Type: text/html; charset="us-ascii" Rick,

I would like to support making this a WG draft.

Thanks,
Andy

-------

At 4/10/2003 11:20 AM -0400, Rick Wilder wrote:

As noted in the minutes, at the San Francisco meeting strong interest was expressed in pursuing the draft-lasserre-vkompella-ppvpn-vplsas a working group draft. We agreed to finalize that decision only after the WG participants who werent there could have a say.

 

So, if there are opinions that have not been heard, now is the time, and this list is the place. Lets set a one-week limit to conclude this issue.

 

Rick

 

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

From the minutes:

 

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.

 
[snipped]

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

 
--=====================_5093093==.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 12:05:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10437 for ; Mon, 14 Apr 2003 12:05:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EG79e10647 for ; Mon, 14 Apr 2003 12:07:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EG71N29317 for ; Mon, 14 Apr 2003 12:07:01 -0400 (EDT) Message-ID: <002201c3029f$16641820$f858ea0c@Amita> From: "amita" To: , "Ali Sajassi" Cc: "Ali Sajassi" References: <4.3.2.7.2.20030413192710.01bdc2e0@airborne.cisco.com> Subject: Re: Issues with draft-radoaca-ppvpn-gvpls-01.txt Date: Mon, 14 Apr 2003 09:01:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: rwcrmhc51.attbi.com X-SMTP-MAIL-FROM: a.patil@attbi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rwcrmhc51.attbi.com [204.127.198.38] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Response inline. regards, -Amita ----- Original Message ----- From: "Ali Sajassi" To: Cc: "Ali Sajassi" Sent: Sunday, April 13, 2003 8:09 PM Subject: Issues with draft-radoaca-ppvpn-gvpls-01.txt > > > One one the main issues with GVPLS is the use of different PWs for unknown > unicast frames versus known unicast frames (e.g., using PtMP PWs for > unknown unicast and MPtP PWs for known unicast). I raised my concern > during the WG meeting and I will reiterate it here again. > > In regular LAN network, in absence of failure, there is NO possibility for > packet re-ordering. *********************************** Not entirely true.There is a possibility (may be rare) of frame re-ordering in L2 networks , when the switch architecture supports separate unicast and multicast queues. The queue arbitration for multicast and unicast queues could cause the similar situation that you are describing below, when the slower unicast frame can arrive after the destination MAC is learnt. 802.1D does not mandate frame ordering between the unicast and multicast destination MAC. *********************************** > However, with the use of different PWs for unicast > frames in GVPLS, the possibility of re-ordering customer's Ethernet frames > exists even in absence of any failures (e.g., during steady state network > operation). This out-of-sequencing happens when a customer destination MAC > address is not learnt and customer's frames gets flooded via PtMP PW. >Now > if after transmission of the first frame, the PE learns the destination MAC > address, then the subsequent frames go over a different PW (e.g., MPtP). > Since two consecutive frames can go over different PWs and these different > PWs can take different path w/ different delays in the network, the two > frames can arrive out-of-order at the destination PE and some protocols can > be susceptible to this out-of-ordering of the packets. > ************************************************** This could very much happen . As far as final delivery of frames is concerened at the End Point equipment , it is a responsibility of the protocol operation to ensure that single path is used between the source and destination station pair.( as per 802.1D ). It is possible to ensure that by always using the same tunnel LSP between PEs for unicast and multicast PWs within a VPN. ************************************************** > I'd like to know how this packet out-of-ordering will be addressed in GVPLS. > > -Ali > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 12:18:53 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10723 for ; Mon, 14 Apr 2003 12:18:52 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EGKxe13247 for ; Mon, 14 Apr 2003 12:20:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EGKpN05253 for ; Mon, 14 Apr 2003 12:20:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414083405.01ca6548@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 08:55:26 -0700 To: , "'Ali Sajassi'" , From: Ali Sajassi Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt In-Reply-To: <000d01c3027a$81c876d0$021ea8c0@HSHAH700> References: <4.3.2.7.2.20030413192710.01bdc2e0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: > >In regular LAN network, in absence of failure, there is NO possibility for >packet re-ordering. However, with the use of different PWs for unicast >frames in GVPLS, the possibility of re-ordering customer's Ethernet frames >exists even in absence of any failures (e.g., during steady state network >operation). > > >HS> This may not be entirely true. One can expect, unknown/broadcast frame >HS> to arrive out-of-order even in LAN Network. This happens due to how >HS> frame processing is architected in a given box. The flooding frame >HS> (i.e. broadcast/unknown) within the box may be treated differently >HS> than a known frame going out on a single port (e.g. separate queue). That would exasperate the problem even more. So if some of the existing platforms have different internal processing path that would result in packet re-ordering between unknown unicast versus known unicast, then we should fix the problem instead of amplifying it by allowing it to be done everywhere in the network (both edge and core). Also I would like to know where in IEEE standards, it allows for such behavior. We can take this discussion to IEEE list. >This out-of-sequencing happens when a customer destination MAC >address is not learnt and customer's frames gets flooded via PtMP PW. Now >if after transmission of the first frame, the PE learns the destination MAC >address, then the subsequent frames go over a different PW (e.g., MPtP). > > >HS> This is possible but rare. Note that in order to have this happen >HS> that remote unknown station has simultaneously generated a frame which >HS> causes the local PE to learn its address AND there is a second frame >HS> generated by the source without having to get a response back on the >HS> frame sent earlier AND this second frame gets through the network over >HS> the other PW just enough faster to beat to the first frame AND this >HS> second frame is important enough to have it arrive in order. The point >HS> is that this is rare enough to be insignificant. With the simultaneous transmission by the end-points, this situation is not as rare as you may think !! Are you implying that with this type of VPLS service, we should allow different SLA based on the transmission. >Since two consecutive frames can go over different PWs and these different >PWs can take different path w/ different delays in the network, the two >frames can arrive out-of-order at the destination PE and some protocols can >be susceptible to this out-of-ordering of the packets. > >HS> If one is using LDP for outer tunneling (most common case), both >pseudowires >HS> maps to same path for a given two PE endpoints. Even with this, you can still have out-of-ordering because of ECMP !! >Actually, there is >HS> a greater and more common risk of out-of-sequence of packets >HS> in a single pseudowire due to network topology changes, fast reroute, >etc. >HS> Also, most protocols are capable of handling packets received >out-of-order, >HS> especially, when that occurs during session initiation time. As I said before, this out-of-ordering happens in steady state for GVPLS which is different from existing LAN operations. Given this is a LAN emulation service, lets see if this is acceptable by IEEE folks. -Ali >regards, >himanshu > >I'd like to know how this packet out-of-ordering will be addressed in GVPLS. > >-Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 12:43:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11462 for ; Mon, 14 Apr 2003 12:43:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EGk1e20660 for ; Mon, 14 Apr 2003 12:46:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EGjuN25975 for ; Mon, 14 Apr 2003 12:45:56 -0400 (EDT) Reply-To: From: "himanshu shah" To: "'Ali Sajassi'" , Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt Date: Mon, 14 Apr 2003 12:42:48 -0400 Message-ID: <000001c302a4$e25bb960$021ea8c0@HSHAH700> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20030414083405.01ca6548@airborne.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: smtp02.mrf.mail.rcn.net X-SMTP-MAIL-FROM: hshah@rcn.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp02.mrf.mail.rcn.net [207.172.4.61] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit responses in line........ -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com] Sent: Monday, April 14, 2003 11:55 AM To: hshah@rcn.com; 'Ali Sajassi'; ppvpn@nortelnetworks.com Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt > >In regular LAN network, in absence of failure, there is NO possibility for >packet re-ordering. However, with the use of different PWs for unicast >frames in GVPLS, the possibility of re-ordering customer's Ethernet frames >exists even in absence of any failures (e.g., during steady state network >operation). > > >HS> This may not be entirely true. One can expect, unknown/broadcast frame >HS> to arrive out-of-order even in LAN Network. This happens due to how >HS> frame processing is architected in a given box. The flooding frame >HS> (i.e. broadcast/unknown) within the box may be treated differently >HS> than a known frame going out on a single port (e.g. separate queue). That would exasperate the problem even more. So if some of the existing platforms have different internal processing path that would result in packet re-ordering between unknown unicast versus known unicast, then we should fix the problem instead of amplifying it by allowing it to be done everywhere in the network (both edge and core). Also I would like to know where in IEEE standards, it allows for such behavior. We can take this discussion to IEEE list. HS> Out-of-order packets between unknown-unicast/multicast and HS> known unicast is well known and well accepted fact. Perhaps HS> you should inquire this on IEEE mailing list. >This out-of-sequencing happens when a customer destination MAC >address is not learnt and customer's frames gets flooded via PtMP PW. Now >if after transmission of the first frame, the PE learns the destination MAC >address, then the subsequent frames go over a different PW (e.g., MPtP). > > >HS> This is possible but rare. Note that in order to have this happen >HS> that remote unknown station has simultaneously generated a frame which >HS> causes the local PE to learn its address AND there is a second frame >HS> generated by the source without having to get a response back on the >HS> frame sent earlier AND this second frame gets through the network over >HS> the other PW just enough faster to beat to the first frame AND this >HS> second frame is important enough to have it arrive in order. The point >HS> is that this is rare enough to be insignificant. With the simultaneous transmission by the end-points, this situation is not as rare as you may think !! Are you implying that with this type of VPLS service, we should allow different SLA based on the transmission. HS> Perhaps you would like to give an example of a particular protocol/scenario HS> that you are thinking of where such simultaneous transmission HS> at session initiation is so problematic for a rare possibility HS> of out-of-order? >Since two consecutive frames can go over different PWs and these different >PWs can take different path w/ different delays in the network, the two >frames can arrive out-of-order at the destination PE and some protocols can >be susceptible to this out-of-ordering of the packets. > >HS> If one is using LDP for outer tunneling (most common case), both >pseudowires >HS> maps to same path for a given two PE endpoints. Even with this, you can still have out-of-ordering because of ECMP !! HS> Thank you. You give one more example of how an out-of-order HS> delievery could occur even when traffic is going over single HS> pseudowire. >Actually, there is >HS> a greater and more common risk of out-of-sequence of packets >HS> in a single pseudowire due to network topology changes, fast reroute, >etc. >HS> Also, most protocols are capable of handling packets received >out-of-order, >HS> especially, when that occurs during session initiation time. As I said before, this out-of-ordering happens in steady state for GVPLS which is different from existing LAN operations. Given this is a LAN emulation service, lets see if this is acceptable by IEEE folks. HS> The point is out-of-order can happen in GVPLS in very rare HS> circumstances. If you look at RSTP, out-of-order is mentioned HS> as a possibility during topo changes as an acceptable risk against HS> greater benefits. I suppose one can apply same logic here. regards, Himanshu -Ali >regards, >himanshu > >I'd like to know how this packet out-of-ordering will be addressed in GVPLS. > >-Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 12:58:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11966 for ; Mon, 14 Apr 2003 12:58:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EH0Xe03838 for ; Mon, 14 Apr 2003 13:00:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EH0RN10117 for ; Mon, 14 Apr 2003 13:00:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 09:56:33 -0700 To: Yakov Rekhter , Ali Sajassi From: Ali Sajassi Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org In-Reply-To: <200304141355.h3EDtmu59315@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Yakov, Please see the reply inline ... At 06:55 AM 4/14/2003 -0700, Yakov Rekhter wrote: >Ali, > > > There are several issues with this draft which I would like to be > addressed > > first before being considered as WG document. I am copying PWE3 here as > > well because one of the issue is pertinent to them. > > > > 1) PW Signaling: > > The draft suggests using BGP as signaling mechanism for Point-to-Point PWs > > of type Ethernet. The encapsulation and setup of PtP Ethernet PWs are > > already covered in the PWE3 and LDP-based signaling is the recommended > > signaling mechanism for PtP PWs in MPLS network. I don't see any benefits > > of introducing yet another signaling mechanism for this propose; however, > > the drawback of it are: > >You didn't mention one important point. Namely, that the draft uses >BGP for auto-discovery, and piggybacks label information (signaling) >on top of auto-discovery. So, instead of one protocol for signaling >(LDP), and another for auto-discovery (BGP) the draft accomplishes >both with a single protocol. So, why two protocols (LDP + BGP) is >any better than one (BGP) ? In addition, using BGP for both >auto-discovery and signaling, instead of using BGP for auto-discovery >and LDP for signaling, simplifies inter-provider operations, fits >into a common framework for both L2 and 2547 VPNs, etc.... Yes, with tightly coupling (intertwining) auto-discovery with signaling, you can use one protocol for both at the expense of overloading that protocol even more. However, that is not my point. My point is we already have a singling mechanism for PtP PW as prescribed in PWE3 which is more flexible and more appropriate for PtP PWs and why do we need yet another one which doesn't offer any clear benefit and that signaling would only be applicable to BGP auto-discovery and doesn't work w/ any other types of auto-discovery. With respect to 2547 VPN, at the surface it may look that both are similar but looking at it in more details, we see that 2547 uses MPtP PWs; whereas VPLS does not (it uses PtP). So we are talking about apple and oranges although it may look like apples at first :-) >Furthermore, perhaps rereading recently posted e-mails from from >several service providers who support draft-kompella-ppvpn-vpls-01.txt >may also help you to understand the benefits of the approach >described in draft-kompella-ppvpn-vpls-01.txt. There might be some support because lumping the signaling and auto-discovery together may result in quicker implementation but I would question the long term viability of it. I would also be interested in knowing how many other vendors are planning to support this draft because that is another factor for SPs to consider. > > i) intertwining signaling mechanism w/ auto-discovery restricts the > service > > provider to using BGP auto-discovery only - e.g. if a SP wants to use > > non-BGP auto-discovery mechanism (such as directory-based radius), then > BGP > > signaling is useless. > >That is correct. But paraphrasing you one could also say that >if a SP wants to use a non-MPLS signaling mechanism, then LDP signaling, >as described in draft-lasserre-vkompella-ppvpn-vpls-04.txt, is useless. That is not a good analogy. MPLS and IP are two different technologies; however, within the same MPLS technology having two different ways of doing the same thing is at best redundant and at worst useless. > > > However LDP-based signaling based on PWE3 draft > > (draft-ietf-pwe3-control-protocol-02.txt) is independent from > > auto-discovery mechanism and both BGP and non-BGP auto-discovery can be > > used by it. > > > > ii) inter-operability issues: having two different signaling mechanism for > > the same PW type and network type (e.g., EoMPLS PW), would necessitate the > > need for interworking (either at the control plane or at the date plane). > > This is an unnecessary complication which is not needed. If the > > interworking is done at the signaling level, it is tedious and > > unprecedented. And if it is done at the data-plane level, then it creates > > unnecessary scalability issues for the ASBRs. > >I am really glad you brought up the inter-operability issue, as >draft-lasserre-vkompella-ppvpn-vpls-04.txt does not prescribe any >auto-discovery mechanism, while listing "three potential candidates, >[BGP-DISC], [DNS-DISC], [LDP-DISC]." Perhaps you could explain to >the rest of us how inter-operability could be accomplished in this case >(e.g., one vendor implements BGP auto-discovery, and another vendor >implements Radius-based auto-discovery). Decoupling signaling and auto-discovery helps in this case since as long as the PEs have the endpoints identifiers, tunnels and PWs can be established using the same signaling mechanism. The endpoints ID can be a) configured manually or b) configured into the auto-discovery mechanism (e.g., into the DNS/Radius records). > > iii) it limits all the PWs in a VPLS set to have the same characteristics. > >And why exactly this is a problem of *practical* significance in >the context of VPLS ? in case you need different SLAs for different PWs - e.g., PWs between different sites have different QoS requirements. Again I would like to reiterate that if we are introducing a new signaling for the same PW type, it should first get approved by PWE3 (since their charter covers maintenance/setup of PWs). -Ali >Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 13:07:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12313 for ; Mon, 14 Apr 2003 13:07:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EH9ae14958 for ; Mon, 14 Apr 2003 13:09:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EH9WN03943 for ; Mon, 14 Apr 2003 13:09:32 -0400 (EDT) Message-Id: <200304141700.h3EH0rB0009721@rtp-core-1.cisco.com> To: Kireeti Kompella cc: ppvpn@nortelnetworks.com, rwilder@masergy.com Subject: Re: progressing docs ... In-reply-to: Your message of Thu, 10 Apr 2003 10:27:13 -0700. <200304101727.h3AHRDo24513@kummer.juniper.net> 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, 14 Apr 2003 13:00:52 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Kireeti> If you are going down the path of progressing VPLS docs, could you Kireeti> also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a Kireeti> PPVPN WG doc? I think this document is a very different case than draft-lasserre- vkompella. The Lasserre/VKompella draft is a valuable basis for VPLS work primarily because of its specification of the way the data plane works for flat VPLS and hierarchical VPLS. The signaling it proposes to use is basically PWE3 signaling, with some extensions, and it is not dependent on any particular auto-discovery scheme. I don't think that draft-kompella-ppvpn-vpls adds anything significant to the other draft's discussion of the data plane, and we certainly don't need two documents serving as the base specification for VPLS forwarding. Draft-kompella-ppvpn-vpls specifies the use of BGP as an auto-discovery protocol, which I think is fine. However, BGP-based auto-discovery could be used as well with the PWE3-based signaling of the other draft. This piece could be taken out and presented as a separate auto-discovery specification, possibly incorporated into draft-ietf-ppvpn-bgpvpn-auto. The other area covered in draft-kompella-vpls is the specification of how to use BGP for use as a signaling protocol to set up p2p circuits. I think this is a rather poor idea (BGP as a mechanism for p2p communication !?), and we should not accept it as a WG document. At least, not without discussing the pros and cons in some detail. (I've tried to start this discussion several times in the past, without generating much interest either way.) From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 13:23: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 NAA12843 for ; Mon, 14 Apr 2003 13:23:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EHPoe21107 for ; Mon, 14 Apr 2003 13:25:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EHPkN13785 for ; Mon, 14 Apr 2003 13:25:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414170921.05123f88@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 17:17:19 +0200 To: "Marco Carugi" , Rick Wilder From: "Michael H. Behringer" Subject: draft-behringer-mpls-vpn-auth-02.txt a WG doc? Cc: PPVPN@nortelnetworks.com, Jim Guichard , Pedro Roque Marques Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: mbehring@cisco.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Marco, Rick, In San Francisco we got the chance to present our work on L3 VPN import/export verification, and I asked whether the WG would consider this draft as a WG document, for which there seemed to be interest. Now we have updated the draft, and we would like to ask here whether the WG is interested in making this document a WG draft. Thanks for your feedback, Michael --- Subject: I-D ACTION:draft-behringer-mpls-vpn-auth-02.txt Date: Fri, 11 Apr 2003 11:57:49 +0000 (UTC) From: Internet-Drafts@ietf.org Organization: A Cisco EMS InterNetNews site Newsgroups: cisco.external.ietf.announce A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS VPN Import/Export Verification Author(s) : M. Behringer, J. Guichard, P. Marques Filename : draft-behringer-mpls-vpn-auth-02.txt Pages : 9 Date : 2003-4-10 Configuration errors on Provider Edge (PE) routers in Layer-3 VPN networks based on [RFC2547] can lead to security breaches of the connected VPNs. For example, the PE router could be mistakenly configured such that a connected Customer Edge (CE) router belongs to an incorrect VPN. Here we propose a scheme that verifies local and remote routing information received by the PE router before it installs new VPN routes into the Virtual Routing & Forwarding Instance (VRF). The proposed changes affect only the PE routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-behringer-mpls-vpn-auth-02.txt From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 13:25: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 NAA12904 for ; Mon, 14 Apr 2003 13:25:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EHRWe22752 for ; Mon, 14 Apr 2003 13:27:33 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EHRRN15909 for ; Mon, 14 Apr 2003 13:27:27 -0400 (EDT) Message-Id: <200304141713.h3EHDCB0013147@rtp-core-1.cisco.com> To: ppvpn@nortelnetworks.com Subject: On the subject of WG docs ... 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, 14 Apr 2003 13:13:12 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: If everybody is pitching their docs to become WG docs, I might as well join the club and make a pitch for draft-rosen-ppvpn-l2-signaling-02.txt. - The part of that doc that specifies LDP-based signaling extensions has been incorporated into the PWE3 WG draft draft-ietf-pwe3-control-protocol- 02.txt. So my plan would be to recast the document slightly into a specification of how to use PWE3 signaling to support the variety of provisioning models which are being considered by this WG. - There is a draft in the l2tpext group (draft-luo-l2tpext-l2vpn-signaling) which applies the same concepts to L2TP-based signaling. While that document has a number of detailed differences, I would expect these to get resolved into a single PPVPN document. - Support for these concepts has been expressed by a number of people who are active in this WG. - The main opposition to this proposal, one V. Kompella, now seems somewhat more tolerant of it, if one might judge from a recent thread. There is still some ongoing argument about the properties, syntax, and semantics, which the"generalized identifiers" of this draft need to have, but this draft seems to me like a good basis for future work. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 13: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 NAA13044 for ; Mon, 14 Apr 2003 13:29:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EHVxe26525 for ; Mon, 14 Apr 2003 13:31:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EHVtN21482 for ; Mon, 14 Apr 2003 13:31:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414101113.01caa130@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 10:16:17 -0700 To: "amita" , , "Ali Sajassi" From: Ali Sajassi Subject: Re: Issues with draft-radoaca-ppvpn-gvpls-01.txt In-Reply-To: <002201c3029f$16641820$f858ea0c@Amita> References: <4.3.2.7.2.20030413192710.01bdc2e0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: > > > > One one the main issues with GVPLS is the use of different PWs for unknown > > unicast frames versus known unicast frames (e.g., using PtMP PWs for > > unknown unicast and MPtP PWs for known unicast). I raised my concern > > during the WG meeting and I will reiterate it here again. > > > > In regular LAN network, in absence of failure, there is NO possibility for > > packet re-ordering. >*********************************** >Not entirely true.There is a possibility (may be rare) of frame re-ordering >in L2 networks , when the switch architecture supports separate unicast and >multicast queues. >The queue arbitration for multicast and unicast queues could cause the >similar situation that you are describing below, when the slower unicast >frame can arrive after the destination MAC is learnt. >802.1D does not mandate frame ordering between the unicast and multicast >destination MAC. We are talking about frame ordering for unicast destination MAC (known versus unknown). >*********************************** > > However, with the use of different PWs for unicast > > frames in GVPLS, the possibility of re-ordering customer's Ethernet frames > > exists even in absence of any failures (e.g., during steady state network > > operation). This out-of-sequencing happens when a customer destination MAC > > address is not learnt and customer's frames gets flooded via PtMP PW. > > >Now > > if after transmission of the first frame, the PE learns the destination >MAC > > address, then the subsequent frames go over a different PW (e.g., MPtP). > > Since two consecutive frames can go over different PWs and these different > > PWs can take different path w/ different delays in the network, the two > > frames can arrive out-of-order at the destination PE and some protocols >can > > be susceptible to this out-of-ordering of the packets. > > >************************************************** >This could very much happen . >As far as final delivery of frames is concerened at the End Point equipment >, it is a responsibility of the protocol operation to ensure that single >path is used between the source and destination station pair.( as per >802.1D ). >It is possible to ensure that by always using the same tunnel LSP between >PEs for unicast and multicast PWs within a VPN. However, you cannot ensure a single path even if you use the same tunnel LSP because of load balancing for ECMP as I indicated previously. -Ali >************************************************** > > I'd like to know how this packet out-of-ordering will be addressed in >GVPLS. > > > > -Ali > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 13:39: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 NAA13655 for ; Mon, 14 Apr 2003 13:39:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EHg5e01015 for ; Mon, 14 Apr 2003 13:42:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EHfsN00860 for ; Mon, 14 Apr 2003 13:41:57 -0400 (EDT) Message-Id: <200304141733.h3EHXbB0019121@rtp-core-1.cisco.com> To: "Vasile Radoaca" cc: "Marco Carugi" , "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: Re: progressing docs In-reply-to: Your message of Thu, 10 Apr 2003 21:25:00 -0400. <8B888AAAAB0FD31189590008C79184430C7A6AA9@zbl6c002.corpeast.baynetworks.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, 14 Apr 2003 13:33:36 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: > draft-radoaca-ppvpn-gvpls-01.txt I support accepting this as a WG document, even though, like any other WG document, it may have a number of open issues and/or flaws. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 13:51:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13948 for ; Mon, 14 Apr 2003 13:51:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EHrIe06559 for ; Mon, 14 Apr 2003 13:53:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EHrEN11880 for ; Mon, 14 Apr 2003 13:53:14 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Ali Sajassi , Yakov Rekhter Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org Subject: RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Mon, 14 Apr 2003 13:37:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C302AC.8DAEA7D0" 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_01C302AC.8DAEA7D0 Content-Type: text/plain; charset="iso-8859-1" Ali, [clipped...] > > That is not a good analogy. MPLS and IP are two different > technologies; > however, within the same MPLS technology having two different > ways of doing > the same thing is at best redundant and at worst useless. > Maybe a good analogy (within the same MPLS technology) is to look at the existence of multiple ways of distributing MPLS label that includes the use of BGP (and even RFC3031 captured that: "THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols have also been defined for the explicit purpose of distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP]."). Although one may conclude that having multiple ways of distributing labels can be redundant, I don't think it was useless (since later on such approach - of using BGP - was useful in rfc2547). Hamid. ------_=_NextPart_001_01C302AC.8DAEA7D0 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt

Ali,

[clipped...]

>
> That is not a good analogy. MPLS and IP are two different
> technologies;
> however, within the same MPLS technology having two different
> ways of doing
> the same thing is at best redundant and at worst useless.
>

Maybe a good analogy (within the same MPLS technology)
is to look at the existence of multiple ways of distributing
MPLS label that includes the use of BGP (and even RFC3031
captured that:

"THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
   DISTRIBUTION PROTOCOL.  In fact, a number of different label
   distribution protocols are being standardized.  Existing protocols
   have been extended so that label distribution can be piggybacked on
   them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]).  New protocols
   have also been defined for the explicit purpose of distributing
   labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].").

Although one may conclude that having multiple ways of
distributing labels can be redundant, I don't think it was useless
(since later on such approach - of using BGP - was useful
in rfc2547).

Hamid.






------_=_NextPart_001_01C302AC.8DAEA7D0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 13:55: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 NAA14137 for ; Mon, 14 Apr 2003 13:55:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EHvle10213 for ; Mon, 14 Apr 2003 13:57:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EHvcN16688 for ; Mon, 14 Apr 2003 13:57:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414101949.01ca51f8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 10:44:12 -0700 To: , "'Ali Sajassi'" , From: Ali Sajassi Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt In-Reply-To: <000001c302a4$e25bb960$021ea8c0@HSHAH700> References: <4.3.2.7.2.20030414083405.01ca6548@airborne.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_87459850==_.ALT" X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: --=====================_87459850==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable >That would exasperate the problem even more. So if some of the existing >platforms have different internal processing path that would result in >packet re-ordering between unknown unicast versus known unicast, then we >should fix the problem instead of amplifying it by allowing it to be done >everywhere in the network (both edge and core). Also I would like to know >where in IEEE standards, it allows for such behavior. We can take this >discussion to IEEE list. > > >HS> Out-of-order packets between unknown-unicast/multicast and >HS> known unicast is well known and well accepted fact. Perhaps >HS> you should inquire this on IEEE mailing list. Not for the steady state. If you look at the IEEE 802.1D standards it says: "NOTE 1 =97The Forwarding Process in Bridges (7.7)does not mis-order or=20 duplicate frames. Where Bridges in a Bridged LAN are capable of connecting the individual=20 MACs in such a way that multiple paths between any source station =96destination station pairs=20 exist,the operation of a protocol is required to ensure that a single path= =20 is used. NOTE 2 =97Frame misordering and duplication (6.3.4) does not occur during=20 normal operation." It clearly states that during normal operation misordering DOES NOT OCCUR !! >Even with this, you can still have out-of-ordering because of ECMP !! > > >HS> Thank you. You give one more example of how an out-of-order >HS> delievery could occur even when traffic is going over single >HS> pseudowire. No !!! traffic doesn't get re-order when a single PW is used in case of=20 ECMP. It can get re-order when there are multiple PWs are involved for the= =20 same flow (as in the case of GVPLS). >HS> The point is out-of-order can happen in GVPLS in very rare >HS> circumstances. If you look at RSTP, out-of-order is mentioned >HS> as a possibility during topo changes as an acceptable risk against >HS> greater benefits. I suppose one can apply same logic here. As mentioned before, IEEE 802.1D standards allows for possibility of=20 reordering in case of topology changes but not in steady state operation. Regards, Ali --=====================_87459850==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That would exasperate the problem even more. So if some of the existing
platforms have different internal processing path that would result in
packet re-ordering between unknown unicast versus known unicast, then we
should fix the problem instead of amplifying it by allowing it to be done
everywhere in the network (both edge and core).  Also I would like to know
where in IEEE standards, it allows for such behavior. We can take this
discussion to IEEE list.


HS> Out-of-order packets between unknown-unicast/multicast and
HS> known unicast is well known and well accepted fact. Perhaps
HS> you should inquire this on IEEE mailing list.

Not for the steady state. If you look at the IEEE 802.1D standards it says:

"NOTE 1 =97The Forwardin= g Process in Bridges (7.7)does not mis-order or duplicate frames.
Where Bridges in a Bridged LAN are capable of connecting the individual MACs in such a way that
multiple paths between any source station =96destination station pairs exist,the operation of a protocol is required to ensure that a single path is used.
NOTE 2 =97Frame misordering and duplication (6.3.4) does not occur during normal operation."

It clearly states that during normal operation misordering DOES NOT OCCUR !!


Even with this, you can still have out-of-ordering because of ECMP !!


HS> Thank you. You give one more example of how an out-of-order
HS> delievery could occur even when traffic is going over single
HS> pseudowire.

No !!! traffic doesn't get re-order when a single PW is used in case of ECMP. It can get re-order when there are multiple PWs are involved for the same flow  (as in the case of GVPLS).

HS> The point is out-of-order can happen in GVPLS in very rare
HS> circumstances.  If you look at RSTP, out-of-order is mentioned
HS> as a possibility during topo changes as an acceptable risk against
HS> greater benefits. I suppose one can apply same logic here.

As mentioned before, IEEE 802.1D standards allows for possibility of reordering in case of topology changes but not in steady state operation.

Regards,
Ali

--=====================_87459850==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 14:07:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14664 for ; Mon, 14 Apr 2003 14:07:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EI9Je14598 for ; Mon, 14 Apr 2003 14:09:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EI9FN18416 for ; Mon, 14 Apr 2003 14:09:16 -0400 (EDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 14 Apr 2003 10:48:12 -0700 (PDT) From: Kireeti Kompella To: Ali Sajassi cc: Yakov Rekhter , "" , "" Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-Reply-To: <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> Message-ID: <20030414100850.X40151@kummer.juniper.net> References: <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hi Ali, On Mon, 14 Apr 2003, Ali Sajassi wrote: > Yes, with tightly coupling (intertwining) auto-discovery with signaling, > you can use one protocol for both at the expense of overloading that > protocol even more. If you use BGP for auto-discovery, adding signaling information is a minor addition with major benefits: o a single advertisement accomplishes both auto-discovery and signaling; o there is no inter-protocol dependency, and attendant complexity of both code and deployment/debugging/...; o one gets a complete solution, instead of promises to add enough to LDP/radius/... to complete that solution. If the issue is "overloading BGP", it is clear that 2547 overloads BGP far more significantly. And implementations have proven that BGP is nonetheless perfectly happy; deployments have shown that this "overloading" has not resulted in any practical problems. The fact that people who bring up this "overloading" argument forget is that in the end, all relevant information must be communicated. The "overloading" of the PE in doing so does *not* decrease if you use BGP+LDP (or radius+LDP or whatever) -- it only increases. If you compare the protocol state, the use of memory/CPU, the inter-protocol interactions, etc. -- if you use any measurable criteria for the complexity of a solution, on all these measures, the solution proposed in draft-kompella-ppvpn-vpls is clearly superior. > However, that is not my point. My point is we already > have a singling mechanism for PtP PW as prescribed in PWE3 which is more > flexible and more appropriate for PtP PWs and why do we need yet another > one which doesn't offer any clear benefit and that signaling would only be > applicable to BGP auto-discovery and doesn't work w/ any other types of > auto-discovery. First of all, there are several clear benefits. Just ask the Service Providers who responded. Second, a proposal that only shows how to do signaling is clearly inferior -- so to turn your argument around, one might suggest that the PWE3 work be scrapped in favor of a complete solution :-) I have no desire to suggest this, but your argument doesn't hold water. > With respect to 2547 VPN, at the surface it may look that both are similar > but looking at it in more details, we see that 2547 uses MPtP PWs; whereas > VPLS does not (it uses PtP). So we are talking about apple and oranges > although it may look like apples at first :-) Instead of playing semantic games. if you look at the service offered, you see strong parallels -- any-to-any connectivity, learned forwarding (as opposed to static mapping in the case of PWs). And there are strong parallels in how a BGP-based VPLS service and a BGP-based IP VPN service are deployed. > There might be some support because lumping the signaling and > auto-discovery together may result in quicker implementation but I would > question the long term viability of it. I would also be interested in > knowing how many other vendors are planning to support this draft because > that is another factor for SPs to consider. "Lumping the signaling and auto-discovery together" actually results in a more coordinated implementation, not a quicker one. And instead of imputing reasons why SPs may like this, just read their emails and see what they say. Finally, to address your issues in your first email, we are not asking that this doc be made an RFC -- just that it be made a WG doc. As Alex said: "For a document to become a WG draft, it doesn't have to be 100% correct." Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 14:18:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15150 for ; Mon, 14 Apr 2003 14:18:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EIKse19239 for ; Mon, 14 Apr 2003 14:20:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EIKoN18602 for ; Mon, 14 Apr 2003 14:20:50 -0400 (EDT) Message-Id: <200304141805.h3EI5sB0029591@rtp-core-1.cisco.com> To: "Hamid Ould-Brahim" cc: Ali Sajassi , Yakov Rekhter , ppvpn@nortelnetworks.com, pwe3@ietf.org Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Mon, 14 Apr 2003 13:37:43 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.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, 14 Apr 2003 14:05:53 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Hamid> Maybe a good analogy (within the same MPLS technology) is to look at Hamid> the existence of multiple ways of distributing MPLS label Hamid> Although one may conclude that having multiple ways of distributing Hamid> labels can be redundant, I don't think it was useless (since later on Hamid> such approach - of using BGP - was useful in rfc2547). Generally, we use LDP to distribute labels that correspond to IGP routes, and we use BGP to distribute labels that correspond to BGP routes. I guess you could call this "multiple ways of distributing labels", but I think a better thing to call it would be "distribute the label in the way which is most suited to its application". For a given application, an example of multiple ways to distribute labels would be RSVP-TE and CR-LDP. Did we need both ways? Apparently not. The argument that CR-LDP is better because LDP + CR-LDP = one protocol,while LDP + RSVP-TE is two protocols, now just seems quaint. Unfortunately, bad arguments tend to recur over and over again ;-) From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 14:30:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15393 for ; Mon, 14 Apr 2003 14:30:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EIWue23882 for ; Mon, 14 Apr 2003 14:32:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EIWqN20366 for ; Mon, 14 Apr 2003 14:32:52 -0400 (EDT) Message-Id: <200304141819.h3EIJRu80435@merlot.juniper.net> To: erosen@cisco.com cc: "Hamid Ould-Brahim" , Ali Sajassi , ppvpn@nortelnetworks.com, pwe3@ietf.org Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Mon, 14 Apr 2003 14:05:53 EDT." <200304141805.h3EI5sB0029591@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48057.1050344367.1@juniper.net> Date: Mon, 14 Apr 2003 11:19:27 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Eric, > Hamid> Maybe a good analogy (within the same MPLS technology) is to look at > Hamid> the existence of multiple ways of distributing MPLS label > > Hamid> Although one may conclude that having multiple ways of distributing > Hamid> labels can be redundant, I don't think it was useless (since later on > Hamid> such approach - of using BGP - was useful in rfc2547). > > Generally, we use LDP to distribute labels that correspond to IGP routes, > and we use BGP to distribute labels that correspond to BGP routes. I guess > you could call this "multiple ways of distributing labels", but I think a > better thing to call it would be "distribute the label in the way which is > most suited to its application". We use BGP to distribute labels that correspond to the information (e.g., routes) carried in BGP. We use RSVP to distribute labels that correspond to the information carried in RSVP. We use LDP when piggybacking is not possible. And if you insist that LDP is used to distribute labels that correspond to IGP routes, then LDP should not be used to carry label information across AS boundaries - this should be done with BGP. > For a given application, an example of multiple ways to distribute labels > would be RSVP-TE and CR-LDP. Did we need both ways? Apparently not. The > argument that CR-LDP is better because LDP + CR-LDP = one protocol,while > LDP + RSVP-TE is two protocols, now just seems quaint. This is a rather poor analogy, as in the context of VPLS we are talking not just about multiple ways of distributing labels, but whether one always have to have one protocol for distributing labels, and another for auto-discovery, or one protocol for both would be enough. > Unfortunately, bad arguments tend to recur over and over again ;-) On that I agree with you - we just disagree on what are these bad arguments :-) Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 14:42: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 OAA15772 for ; Mon, 14 Apr 2003 14:42:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EIide28447 for ; Mon, 14 Apr 2003 14:44:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EIiVN03105 for ; Mon, 14 Apr 2003 14:44:32 -0400 (EDT) Message-Id: <200304141822.h3EIMhu80734@merlot.juniper.net> To: erosen@cisco.com cc: Kireeti Kompella , ppvpn@nortelnetworks.com, rwilder@masergy.com Subject: Re: progressing docs ... In-Reply-To: Your message of "Mon, 14 Apr 2003 13:00:52 EDT." <200304141700.h3EH0rB0009721@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48876.1050344563.1@juniper.net> Date: Mon, 14 Apr 2003 11:22:43 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Eric, > Kireeti> If you are going down the path of progressing VPLS docs, could you > Kireeti> also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > Kireeti> PPVPN WG doc? > > I think this document is a very different case than draft-lasserre- > vkompella. > > The Lasserre/VKompella draft is a valuable basis for VPLS work primarily > because of its specification of the way the data plane works for flat VPLS > and hierarchical VPLS. The signaling it proposes to use is basically PWE3 > signaling, with some extensions, and it is not dependent on any particular > auto-discovery scheme. > > I don't think that draft-kompella-ppvpn-vpls adds anything significant to > the other draft's discussion of the data plane, and we certainly don't need > two documents serving as the base specification for VPLS forwarding. The fact that the two drafts share the same data plane is a feaure, not a bug. > Draft-kompella-ppvpn-vpls specifies the use of BGP as an auto-discovery > protocol, which I think is fine. However, BGP-based auto-discovery could be > used as well with the PWE3-based signaling of the other draft. This piece > could be taken out and presented as a separate auto-discovery specification, > possibly incorporated into draft-ietf-ppvpn-bgpvpn-auto. Or it could be left in draft-kompella-ppvpn-vpls. > The other area covered in draft-kompella-vpls is the specification of how to > use BGP for use as a signaling protocol to set up p2p circuits. I think > this is a rather poor idea (BGP as a mechanism for p2p communication !?), On this we should probably agree to disagree. > and we should not accept it as a WG document. At least, not without > discussing the pros and cons in some detail. (I've tried to start this > discussion several times in the past, without generating much interest > either way.) Perhaps the fact that it didn't generate much interest either way could be taken as an indication of the *practical* relevance of this discussion... Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 15:06: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 PAA17281 for ; Mon, 14 Apr 2003 15:06:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EJ8he27995 for ; Mon, 14 Apr 2003 15:08:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EJ8bN14557 for ; Mon, 14 Apr 2003 15:08:38 -0400 (EDT) Reply-To: From: "himanshu shah" To: "'Ali Sajassi'" , Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt Date: Mon, 14 Apr 2003 14:41:51 -0400 Message-ID: <000b01c302b5$845dc5e0$021ea8c0@HSHAH700> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C30293.FD4C25E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20030414101949.01ca51f8@airborne.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: smtp02.mrf.mail.rcn.net X-SMTP-MAIL-FROM: hshah@rcn.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp02.mrf.mail.rcn.net [207.172.4.61] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C30293.FD4C25E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit response in line. -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com] Sent: Monday, April 14, 2003 1:44 PM To: hshah@rcn.com; 'Ali Sajassi'; ppvpn@nortelnetworks.com Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt That would exasperate the problem even more. So if some of the existing platforms have different internal processing path that would result in packet re-ordering between unknown unicast versus known unicast, then we should fix the problem instead of amplifying it by allowing it to be done everywhere in the network (both edge and core). Also I would like to know where in IEEE standards, it allows for such behavior. We can take this discussion to IEEE list. HS> Out-of-order packets between unknown-unicast/multicast and HS> known unicast is well known and well accepted fact. Perhaps HS> you should inquire this on IEEE mailing list. Not for the steady state. If you look at the IEEE 802.1D standards it says: "NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or duplicate frames. Where Bridges in a Bridged LAN are capable of connecting the individual MACs in such a way that multiple paths between any source station -destination station pairs exist,the operation of a protocol is required to ensure that a single path is used. NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during normal operation." It clearly states that during normal operation misordering DOES NOT OCCUR !! [himanshu shah] Despite what it says, today in normal bridges, broadcast (unknown unicast frame is a flood and hence it is a broadcast) and unicast frames between two stations may get out of order for the reasons I described before; irrespective of the state of the network. Again, I invite you to site an example where a miniscule possibility of such an out-of-order spells disaster for a protocol (at session initiation time). Even with this, you can still have out-of-ordering because of ECMP !! HS> Thank you. You give one more example of how an out-of-order HS> delievery could occur even when traffic is going over single HS> pseudowire. No !!! traffic doesn't get re-order when a single PW is used in case of ECMP. It can get re-order when there are multiple PWs are involved for the same flow (as in the case of GVPLS). [himanshu shah] If one was to do ECMP using the bottom most label, then it is true that out-of-order would not occur for a single PW. However, is it mandated that ECMP must be done on bottom-most label (i.e. PW label which technically could be below several labels)? Lets for a moment accept that such out-of-order would occur for 2 PWs. I would like to see an example where a rare case of mis-order between broadcast-path frame and unicast-path frame. HS> The point is out-of-order can happen in GVPLS in very rare HS> circumstances. If you look at RSTP, out-of-order is mentioned HS> as a possibility during topo changes as an acceptable risk against HS> greater benefits. I suppose one can apply same logic here. As mentioned before, IEEE 802.1D standards allows for possibility of reordering in case of topology changes but not in steady state operation. [himanshu shah] topo changes in small bridged network as compared to topo changes in big-I network are at quite different scale. If one was to compare the number of out-of-order packets due to topo-changes in big-I network to out-of-order packets due to 2 PW, one would wonder where the real problem is. Regards, Ali ------=_NextPart_000_000C_01C30293.FD4C25E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
response in line.
-----Original Message-----
From: Ali Sajassi=20 [mailto:sajassi@cisco.com]
Sent: Monday, April 14, 2003 1:44 = PM
To: hshah@rcn.com; 'Ali Sajassi';=20 ppvpn@nortelnetworks.com
Subject: RE: Issues with=20 draft-radoaca-ppvpn-gvpls-01.txt

That would exasperate the problem = even more.=20 So if some of the existing
platforms have different internal = processing=20 path that would result in
packet re-ordering between unknown = unicast=20 versus known unicast, then we
should fix the problem instead of=20 amplifying it by allowing it to be done
everywhere in the network = (both=20 edge and core).  Also I would like to know
where in IEEE = standards,=20 it allows for such behavior. We can take this
discussion to IEEE=20 list.


HS> Out-of-order packets between=20 unknown-unicast/multicast and
HS> known unicast is well known = and well=20 accepted fact. Perhaps
HS> you should inquire this on IEEE = mailing=20 list.

Not for the steady state. If you look at the IEEE 802.1D = standards it=20 says:

"NOTE 1 = -The=20 Forwarding Process in Bridges (7.7)does not mis-order or duplicate=20 frames.
Where Bridges = in a=20 Bridged LAN are capable of connecting the individual MACs in such a = way=20 that
multiple paths between any source station -destination station = pairs=20 exist,the operation of a protocol is required to ensure that a single = path is=20 used.
NOTE 2 = -Frame=20 misordering and duplication (6.3.4) does not occur during normal=20 operation."

It clearly states that during normal = operation=20 misordering DOES NOT OCCUR !!


[himanshu shah] Despite = what it says,=20 today in normal bridges, broadcast (unknown unicast frame is a flood = and hence=20 it is a broadcast) and unicast frames between two stations may get out = of=20 order for the reasons I described before; irrespective of the state of = the=20 network. Again, I invite you to site an example where a miniscule = possibility=20 of such an out-of-order spells disaster for a protocol (at session = initiation=20 time).
 
Even with this, you can still have = out-of-ordering because of ECMP !!


HS> Thank you. You = give one=20 more example of how an out-of-order
HS> delievery could occur = even=20 when traffic is going over single
HS> = pseudowire.

No !!!=20 traffic doesn't get re-order when a single PW is used in case of ECMP. = It can=20 get re-order when there are multiple PWs are involved for the same = flow =20 (as in the case of GVPLS).
[himanshu shah] If one was to do = ECMP using the=20 bottom most label, then it is true that out-of-order would not occur = for a=20 single PW. However, is it mandated that ECMP must be done on = bottom-most label=20 (i.e. PW label which technically could be below several = labels)? Lets for=20 a moment accept that such out-of-order would occur for 2 PWs. I would = like to=20 see an example where a rare case of mis-order between broadcast-path = frame and=20 unicast-path frame.

HS> The point is out-of-order = can happen=20 in GVPLS in very rare
HS> circumstances.  If you look at = RSTP,=20 out-of-order is mentioned
HS> as a possibility during topo = changes as=20 an acceptable risk against
HS> greater benefits. I suppose one = can=20 apply same logic here.

As mentioned before, IEEE = 802.1D=20 standards allows for possibility of reordering in case of topology = changes but=20 not in steady state operation.
[himanshu shah] topo = changes in small=20 bridged network as compared to topo changes in big-I network are = at quite=20 different scale. If one was to compare the number=20 of out-of-order packets due to topo-changes in big-I = network to=20 out-of-order packets due to 2 PW, one would wonder where the real = problem=20 = is.

Regards,
Ali

------=_NextPart_000_000C_01C30293.FD4C25E0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 15:17:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18679 for ; Mon, 14 Apr 2003 15:17:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EJJge02546 for ; Mon, 14 Apr 2003 15:19:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EJJRN17483 for ; Mon, 14 Apr 2003 15:19:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414112425.01cf7698@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 11:33:42 -0700 To: "Hamid Ould-Brahim" , Ali Sajassi , Yakov Rekhter From: Ali Sajassi Subject: RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_90429711==_.ALT" X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: --=====================_90429711==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hamid, In case of RFC2547 that you are giving as an example of using BGP for delivery of MPLS label, it was done for a different PW type. RFC 2547 uses multipoint signaling mechanism for the setup of MPtP PW; whereas, for VPLS we are talking about using a multipoint signaling to setup PtP PW which frankly doesn't make sense to me. Also, we shouldn't use the argument that if in the past we have developed multiple standards for doing the same thing, we should keep doing it in the future. -Ali At 01:37 PM 4/14/2003 -0400, Hamid Ould-Brahim wrote: >Ali, > >[clipped...] > > > > > That is not a good analogy. MPLS and IP are two different > > technologies; > > however, within the same MPLS technology having two different > > ways of doing > > the same thing is at best redundant and at worst useless. > > > >Maybe a good analogy (within the same MPLS technology) >is to look at the existence of multiple ways of distributing >MPLS label that includes the use of BGP (and even RFC3031 >captured that: > >"THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL > DISTRIBUTION PROTOCOL. In fact, a number of different label > distribution protocols are being standardized. Existing protocols > have been extended so that label distribution can be piggybacked on > them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols > have also been defined for the explicit purpose of distributing > labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP]."). > >Although one may conclude that having multiple ways of >distributing labels can be redundant, I don't think it was useless >(since later on such approach - of using BGP - was useful >in rfc2547). > >Hamid. > > > > --=====================_90429711==_.ALT Content-Type: text/html; charset="us-ascii" Hamid,

In case of RFC2547 that you are giving as an example of using BGP for delivery of MPLS label, it was done for a different PW type. RFC 2547 uses multipoint signaling mechanism for the setup of MPtP PW; whereas, for VPLS we are talking about using a multipoint signaling to setup PtP PW which frankly doesn't make sense to me. Also, we shouldn't use the argument that if in the past we have developed multiple standards for doing the same thing, we should keep doing it in the future.

-Ali

At 01:37 PM 4/14/2003 -0400, Hamid Ould-Brahim wrote:

Ali,

[clipped...]

>
> That is not a good analogy. MPLS and IP are two different
> technologies;
> however, within the same MPLS technology having two different
> ways of doing
> the same thing is at best redundant and at worst useless.
>

Maybe a good analogy (within the same MPLS technology)
is to look at the existence of multiple ways of distributing
MPLS label that includes the use of BGP (and even RFC3031
captured that:

"THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
   DISTRIBUTION PROTOCOL.  In fact, a number of different label
   distribution protocols are being standardized.  Existing protocols
   have been extended so that label distribution can be piggybacked on
   them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]).  New protocols
   have also been defined for the explicit purpose of distributing
   labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].").

Although one may conclude that having multiple ways of
distributing labels can be redundant, I don't think it was useless
(since later on such approach - of using BGP - was useful
in rfc2547).

Hamid.




--=====================_90429711==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 15:24: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 PAA18986 for ; Mon, 14 Apr 2003 15:24:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EJQke06602 for ; Mon, 14 Apr 2003 15:26:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EJQdN06956 for ; Mon, 14 Apr 2003 15:26:40 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Mon, 14 Apr 2003 14:55:52 -0400 From: "Gary Warner" To: Subject: support for draft kompella ppvpn vpls 01 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline X-SMTP-HELO: HAI.COM X-SMTP-MAIL-FROM: GWarner@HAI.COM X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.hai.com [207.124.17.25] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA18986 I support draft-kompella-ppvpn-vpls-01 for the following reasons. 1. It provides the ability to auto provision new clients to a VLAN. (Without having to manually configure LSP) 2. BGP is already used for distribution of Layer 3 VPN information. Gary Warner Network Engineering Manager Senior Communications Engineer Houston Associates, INC From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 15:30: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 PAA19241 for ; Mon, 14 Apr 2003 15:30:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EJWie10487 for ; Mon, 14 Apr 2003 15:32:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EJWcN19365 for ; Mon, 14 Apr 2003 15:32:38 -0400 (EDT) Message-Id: <200304141858.h3EIwaB0015936@rtp-core-1.cisco.com> To: Kireeti Kompella cc: Ali Sajassi , Yakov Rekhter , "" , "" Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Mon, 14 Apr 2003 10:48:12 -0700. <20030414100850.X40151@kummer.juniper.net> 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, 14 Apr 2003 14:58:35 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Kireeti> If you use BGP for auto-discovery, adding signaling information is Kireeti> a minor addition Yeah, that's what people used to say about adding traffic engineering to LDP ;-) When I look at the PWE3 signaling docs, I see that the signaling involves quite a bit more than just sending a label. I think you need to look at everything which can be signaled in PWE3 and say how you would handle it in BGP, or else say why it is not needed. I also think that VPLS signaling needs to be general enough to handle certain mix and match cases, such as connecting a p2p pseudowire into an emulated LAN. I can see how this can be done with PWE3 signaling, but I'm not sure I see how the BGP-based signaling could handle it. Kireeti> there is no inter-protocol dependency If you are planning to use BGP to set up the PE-PE tunnels as well as the pseudowires, I haven't seen the proposal for that. Otherwise, there's no avoiding inter-protocol dependencies. In any event, auto-discovery and signaling are well-layered from each other, and do not introduce any sort of ugly dependencies. Kireeti> If the issue is "overloading BGP", it is clear that 2547 overloads Kireeti> BGP far more significantly. I don't believe in the "overloading BGP" argument myself, though it is clear that that argument has many adherents. To my mind, the issue is really whether BGP is a good protocol for the kind of signaling that needs to be done. Sure, "with enough thrust, even pigs can fly". In 2547, we chose to use BGP not because it was there, but because it is a good protocol for distributing a large amount of routing information that originates from other routing domains. I like BGP for auto-discovery because in auto-discovery, we want a protocol that provides a point-to-multipoint capability and allows an originator to update and withdraw information at will; BGP as a protocol seems like a good match. Is it a good match for point-to-point signaling? That's a lot more of a stretch. Kireeti> if you use any measurable criteria for the complexity of a Kireeti> solution, on all these measures, Well, that's the claim. Let's see, suppose you need to resynchronize the sequence numbers on a particular PE-PE pseudowire. How efficient is BGP at doing that? Suppose there is some problem in getting data from one PE to another? Does the fact that the control plane goes through a third party (route reflector) make it easier to troubleshoot that problem, or more difficult? Kireeti> First of all, there are several clear benefits. Just ask the Kireeti> Service Providers who responded. You're referring to the benefit of "elegance"? Kireeti> Finally, to address your issues in your first email, we are not Kireeti> asking that this doc be made an RFC -- just that it be made a WG Kireeti> doc. As Alex said: "For a document to become a WG draft, it Kireeti> doesn't have to be 100% correct." Adopting your document as a WG doc would be an expression by the WG of support for using BGP as a way to do p2p signaling. The WG should be very sure that it wants to do that before adopting your doc. Kireeti> if you look at the service offered, you see strong parallels -- Kireeti> any-to-any connectivity, learned forwarding If you compare bridging to routing, you'll see the very same parallels, yet the technologies are very different, have very different applicabilities, and require very different solutions. Kireeti> a proposal that only shows how to do signaling is clearly inferior Certainly what is needed is a complete solution, rather than just a piece. However, when the solution contains multiple identifiable components, proper layering generally results in more long term simplicity and flexibility. If the proposal is to use BGP for signaling pseudowires, I think the technical discussion should focus on its suitability for that purpose. Yakov> in the context of VPLS we are talking not just about multiple ways of Yakov> distributing labels, but whether one always have to have one protocol Yakov> for distributing labels, and another for auto-discovery, or one Yakov> protocol for both would be enough. Well, I don't really see how this is different than the "CR-LDP isn't another protocol" argument. The arguments are being repeated almost word for word, albeit not by the same set of people ;-) You seem to be arguing that "given a protocol to do X, if we need to do Y, it is better to piggyback Y on the X-protocol than to use a protocol that is designed to do Y." In general, this argument form is not valid, it really is a matter of how suitable the X protocol is for Y. Yakov> The fact that the two drafts [kompella and lasserre/vkompella] share Yakov> the same data plane is a feature, not a bug. Of course, I never said otherwise. But the specification of that data plane should not be in both places, one doc should reference the other. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 15:36:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19430 for ; Mon, 14 Apr 2003 15:36:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EJcKe14290 for ; Mon, 14 Apr 2003 15:38:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EJcHN24987 for ; Mon, 14 Apr 2003 15:38:17 -0400 (EDT) Message-Id: <200304141908.h3EJ8ru85864@merlot.juniper.net> To: erosen@cisco.com cc: Kireeti Kompella , Ali Sajassi , Yakov Rekhter , "" , "" Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Mon, 14 Apr 2003 14:58:35 EDT." <200304141858.h3EIwaB0015936@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67093.1050347333.1@juniper.net> Date: Mon, 14 Apr 2003 12:08:53 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Eric, [clipped...] > Yakov> in the context of VPLS we are talking not just about multiple ways of > Yakov> distributing labels, but whether one always have to have one protocol > Yakov> for distributing labels, and another for auto-discovery, or one > Yakov> protocol for both would be enough. > > Well, I don't really see how this is different than the "CR-LDP isn't > another protocol" argument. The arguments are being repeated almost word > for word, albeit not by the same set of people ;-) > > You seem to be arguing that "given a protocol to do X, if we need to do Y, > it is better to piggyback Y on the X-protocol than to use a protocol that is > designed to do Y. In general, this argument form is not valid, it really > is a matter of how suitable the X protocol is for Y. Agreed. I guess all we arguing about is whether in the case where BGP is used for auto-discovery BGP is also suitable for distributing labels (note we are *not* arguing on suitability of BGP for distributing labels when some other than BGP mechanism is used for auto-discovery). > Yakov> The fact that the two drafts [kompella and lasserre/vkompella] share > Yakov> the same data plane is a feature, not a bug. > > Of course, I never said otherwise. But the specification of that data plane > should not be in both places, one doc should reference the other. That would be fine with me. Or the data plane could be pulled into a separate document... Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 16:18:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20360 for ; Mon, 14 Apr 2003 16:18:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EKL1e14059 for ; Mon, 14 Apr 2003 16:21:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EKKuN19249 for ; Mon, 14 Apr 2003 16:20:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414120526.01c8d2e0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 13:13:04 -0700 To: Kireeti Kompella , Ali Sajassi From: Ali Sajassi Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt Cc: Yakov Rekhter , "" , "" In-Reply-To: <20030414100850.X40151@kummer.juniper.net> References: <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> <4.3.2.7.2.20030414085848.01bce2f0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Hi Kireeti, Please refer to my comments inline ... At 10:48 AM 4/14/2003 -0700, Kireeti Kompella wrote: >Hi Ali, > >On Mon, 14 Apr 2003, Ali Sajassi wrote: > > > Yes, with tightly coupling (intertwining) auto-discovery with signaling, > > you can use one protocol for both at the expense of overloading that > > protocol even more. > >If you use BGP for auto-discovery, adding signaling information is a minor >addition with major benefits: > o a single advertisement accomplishes both auto-discovery and signaling; > o there is no inter-protocol dependency, and attendant complexity of > both code and deployment/debugging/...; > o one gets a complete solution, instead of promises to add enough to > LDP/radius/... to complete that solution. Although BGP is a very legitimate approach for auto-discovery and a proven way for doing MPtP PW signaling, I don't see any benefits for VPLS type application where it requires signaling for PtP PWs. One can use BGP auto-discovery with existing LDP signaling (per PWE3) and get all the benefits plus more (more in the sense of having the flexibility to use different SLAs and QoS for different PWs. Also having the flexibility to offer different auto-discovery mechanism to the SPs. >If the issue is "overloading BGP", it is clear that 2547 overloads BGP >far more significantly. And implementations have proven that BGP is >nonetheless perfectly happy; deployments have shown that this >"overloading" has not resulted in any practical problems. When I talked about overloading BGP, I was referring to overloading it more than we have to. 2547 is a different application with different requirements and it makes sense to use multipoint signaling for multipoint PWs but for VPLS application, the PW is of type PtP and the associated signaling as described in PWE3 works well for this type of PW. So using BGP as auto-discovery, doesn't mean overloading it for signaling as well. >The fact that people who bring up this "overloading" argument forget is >that in the end, all relevant information must be communicated. The >"overloading" of the PE in doing so does *not* decrease if you use >BGP+LDP (or radius+LDP or whatever) -- it only increases. If you >compare the protocol state, the use of memory/CPU, the inter-protocol >interactions, etc. -- if you use any measurable criteria for the >complexity of a solution, on all these measures, the solution proposed >in draft-kompella-ppvpn-vpls is clearly superior. I didn't talk about overloading the PE but instead about the protocol more than we have to. If we don't use route reflector, then BGP has even higher overhead than LDP for PtP signaling. And even with route reflector, there is a trade off between number of connections versus number of messages need to be processed between BGP and LDP signaling - so BGP has higher overhead in terms of packet processing than LDP !! Also what you're going to do for the SP who don't want to use BGP auto-discovery (e.g., they prefer directory-based) ? Are you going to force them to use BGP ? > > However, that is not my point. My point is we already > > have a singling mechanism for PtP PW as prescribed in PWE3 which is more > > flexible and more appropriate for PtP PWs and why do we need yet another > > one which doesn't offer any clear benefit and that signaling would only be > > applicable to BGP auto-discovery and doesn't work w/ any other types of > > auto-discovery. > >First of all, there are several clear benefits. Just ask the Service >Providers who responded. I would like to ask those service providers to explain the benefits of using BGP for PtP signaling in VPLS applications instead of LDP as recommended in PWE3 ? Again I am not talking about BGP usage for auto-discovery as it can serve well for auto-discovery. >Second, a proposal that only shows how to do signaling is clearly >inferior -- so to turn your argument around, one might suggest that >the PWE3 work be scrapped in favor of a complete solution :-) I have >no desire to suggest this, but your argument doesn't hold water. There is a difference between a draft containing all the pieces of a solution versus all the pieces of a solution being available and can be nicely referenced in a draft (e.g., functional decomposition). So if there are drafts that describe PW signaling and auto-discovery, then I don't see any point in lumping them all in one draft. In fact we should avoid this as much as possible. > > With respect to 2547 VPN, at the surface it may look that both are similar > > but looking at it in more details, we see that 2547 uses MPtP PWs; whereas > > VPLS does not (it uses PtP). So we are talking about apple and oranges > > although it may look like apples at first :-) > >Instead of playing semantic games. if you look at the service offered, >you see strong parallels -- any-to-any connectivity, learned forwarding >(as opposed to static mapping in the case of PWs). And there are strong >parallels in how a BGP-based VPLS service and a BGP-based IP VPN service >are deployed. There are also significant differences - e.g., control-plane learning vesus data-plane learning and connectivity among FIBs between the two. So lets not make a general statement that they are the same. As the matter of fact the PW between a pair of FIB in VPLS look exactly the same as for PW PtP operation (VPWS) but you cannot say the same thing for 2547. > > There might be some support because lumping the signaling and > > auto-discovery together may result in quicker implementation but I would > > question the long term viability of it. I would also be interested in > > knowing how many other vendors are planning to support this draft because > > that is another factor for SPs to consider. > >"Lumping the signaling and auto-discovery together" actually results >in a more coordinated implementation, not a quicker one. And instead >of imputing reasons why SPs may like this, just read their emails and >see what they say. O.K., I would like to hear from them to describe the reasons in details. >Finally, to address your issues in your first email, we are not asking >that this doc be made an RFC -- just that it be made a WG doc. As >Alex said: "For a document to become a WG draft, it doesn't have to be >100% correct." Yes but I am concern about PPVPN group try to duplicate the effort of other WG and as I said the signaling portion of PtP PW falls within the charter of PWE3. -Ali >Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 16:54: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 QAA21527 for ; Mon, 14 Apr 2003 16:54:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EKuse20300 for ; Mon, 14 Apr 2003 16:56:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EKuqN11792 for ; Mon, 14 Apr 2003 16:56:52 -0400 (EDT) Message-Id: <200304142050.h3EKoeu94310@merlot.juniper.net> To: Ali Sajassi cc: Kireeti Kompella , "" , "" Subject: Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Mon, 14 Apr 2003 13:13:04 PDT." <4.3.2.7.2.20030414120526.01c8d2e0@airborne.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93174.1050353440.1@juniper.net> Date: Mon, 14 Apr 2003 13:50:40 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Ali, > Please refer to my comments inline ... > > At 10:48 AM 4/14/2003 -0700, Kireeti Kompella wrote: > >Hi Ali, > > > >On Mon, 14 Apr 2003, Ali Sajassi wrote: > > > > > Yes, with tightly coupling (intertwining) auto-discovery with signaling, > > > you can use one protocol for both at the expense of overloading that > > > protocol even more. > > > >If you use BGP for auto-discovery, adding signaling information is a minor > >addition with major benefits: > > o a single advertisement accomplishes both auto-discovery and signaling; > > o there is no inter-protocol dependency, and attendant complexity of > > both code and deployment/debugging/...; > > o one gets a complete solution, instead of promises to add enough to > > LDP/radius/... to complete that solution. > > Although BGP is a very legitimate approach for auto-discovery and a proven > way for doing MPtP PW signaling, I don't see any benefits for VPLS type > application where it requires signaling for PtP PWs. That is quite clear :-( > One can use BGP > auto-discovery with existing LDP signaling (per PWE3) and get all the > benefits plus more (more in the sense of having the flexibility to use > different SLAs and QoS for different PWs. You've yet to show that in the context of VPLS this flexibility is of any *practical* significance. > Also having the flexibility to > offer different auto-discovery mechanism to the SPs. This seems like trying to optimize from a vendor's perspective. So, just say so. However, one may also consider trying to optimize from a service provider perspective (the two are not always the same). > >If the issue is "overloading BGP", it is clear that 2547 overloads BGP > >far more significantly. And implementations have proven that BGP is > >nonetheless perfectly happy; deployments have shown that this > >"overloading" has not resulted in any practical problems. > > When I talked about overloading BGP, I was referring to overloading it more > than we have to. 2547 is a different application with different > requirements and it makes sense to use multipoint signaling for multipoint > PWs but for VPLS application, the PW is of type PtP and the associated > signaling as described in PWE3 works well for this type of PW. So using BGP > as auto-discovery, doesn't mean overloading it for signaling as well. > > > >The fact that people who bring up this "overloading" argument forget is > >that in the end, all relevant information must be communicated. The > >"overloading" of the PE in doing so does *not* decrease if you use > >BGP+LDP (or radius+LDP or whatever) -- it only increases. If you > >compare the protocol state, the use of memory/CPU, the inter-protocol > >interactions, etc. -- if you use any measurable criteria for the > >complexity of a solution, on all these measures, the solution proposed > >in draft-kompella-ppvpn-vpls is clearly superior. > > I didn't talk about overloading the PE but instead about the protocol more > than we have to. If we don't use route reflector, then BGP has even higher > overhead than LDP for PtP signaling. And even with route reflector, there > is a trade off between number of connections versus number of messages need > to be processed between BGP and LDP signaling - so BGP has higher overhead > in terms of packet processing than LDP !! To get the overall picture one needs to compare BGP for both auto-discovery and signaling vs BGP for auto-discovery + LDP for signaling, and *not* BGP vs LDP just for signaling. Comparing just BGP for signaling vs LDP for signaling is quite misleading, as it ignores the fact that auto-discovery is an essential part of VPLS. > Also what you're going to do for the SP who don't want to use BGP > auto-discovery (e.g., they prefer directory-based) ? Are you going to force > them to use BGP ? draft-kompella-ppvpn-vpls-01.txt isn't intended to be "all things for all people". But paraphrasing your question, what you're going to do for the SPs who don't want to use LDP for signaling (e.g., they prefer BGP, as they use BGP for auto-discovery) ? Are you going to force them to use LDP ? As I said before, it is time to realize that "one size doesn't fit all". Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 17:23:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22631 for ; Mon, 14 Apr 2003 17:23:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ELQ3e07142 for ; Mon, 14 Apr 2003 17:26:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ELQ0N00079 for ; Mon, 14 Apr 2003 17:26:01 -0400 (EDT) Message-ID: <82F679A6A377F84B8F665D8F90D12B8DD8F209@sc-msexch-05.extremenetworks.com> From: Olen Stokes To: "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Mon, 14 Apr 2003 14:19:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C302CB.7E76D700" X-SMTP-HELO: mail3.extremenetworks.com X-SMTP-MAIL-FROM: ostokes@extremenetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sc-f100-01.extremenetworks.com [63.251.106.30] X-LYRIS-Message-Id: 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_01C302CB.7E76D700 Content-Type: text/plain; charset="iso-8859-1" I would also like to support making this a working group draft. Cheers, Olen -----Original Message----- From: Rick Wilder [mailto:rwilder@masergy.com] Sent: Thursday, April 10, 2003 11:20 AM To: ppvpn@nortelnetworks.com Subject: draft-lasserre-vkompella-ppvpn-vpls as working group draft As noted in the minutes, at the San Francisco meeting strong interest was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We agreed to finalize that decision only after the WG participants who weren't there could have a say. So, if there are opinions that have not been heard, now is the time, and this list is the place. Let's set a one-week limit to conclude this issue. Rick ---------------------------------------------------------------------------- ----------------------------------------------------------------------- From the minutes: 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. [snipped] Marco: asked for show of hands to make this a wG draft. Strong interest was shown in room. Further discussion on the list. ------_=_NextPart_001_01C302CB.7E76D700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 would also like to support making this a working group=20 draft.
 
Cheers,
Olen
-----Original Message-----
From: Rick Wilder=20 [mailto:rwilder@masergy.com]
Sent: Thursday, April 10, 2003 = 11:20=20 AM
To: ppvpn@nortelnetworks.com
Subject:=20 draft-lasserre-vkompella-ppvpn-vpls as working group=20 draft

As noted in the = minutes, at the=20 San=20 Francisco meeting strong = interest was=20 expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a working = group draft.=20 We agreed to finalize that decision only after the WG participants = who weren't=20 there could have a say.

 

So, if there are opinions that have not = been heard,=20 now is the time, and this list is the place. Let's set a one-week = limit to=20 conclude this issue.

 

Rick

 

-----------------------------------------------------------------= ------------------------------------------------------------------------= ----------

From the=20 minutes:

 

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

Matt: I wanted to make = the same=20 comment.  


[snipped] 

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

 

------_=_NextPart_001_01C302CB.7E76D700-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 18:07:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24055 for ; Mon, 14 Apr 2003 18:07:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EM9he18608 for ; Mon, 14 Apr 2003 18:09:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EM9dN19412 for ; Mon, 14 Apr 2003 18:09:39 -0400 (EDT) Message-ID: <9D42C6E086250248810DCADA39CE7EFC972409@nimbus> From: John Drake To: "'Kireeti Kompella'" , ppvpn@nortelnetworks.com, rwilder@masergy.com Subject: RE: progressing docs ... Date: Mon, 14 Apr 2003 15:06:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: lightwave.chromisys.com X-SMTP-MAIL-FROM: jdrake@calient.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lightwave.chromisys.com [63.102.55.206] X-LYRIS-Message-Id: I'd like to support making this a WG doc > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, April 10, 2003 10:27 AM > To: ppvpn@nortelnetworks.com; rwilder@masergy.com > Subject: progressing docs ... > > > Hi Rick, > > If you are going down the path of progressing VPLS docs, could you > also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > PPVPN WG doc? > > Thanks, > Kireeti. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 18:48:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25938 for ; Mon, 14 Apr 2003 18:48:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EMoIe22841 for ; Mon, 14 Apr 2003 18:50:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3EMo9N29263 for ; Mon, 14 Apr 2003 18:50:09 -0400 (EDT) Date: Tue, 15 Apr 2003 06:47:32 +0800 From: Du Wenhua Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft To: Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDC00ILUV8YR6@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA25938 Hi,Rick Wilder, I support it to become a WG draft. BTW, one qustion as follow: In setction 11 of the draft-lasserre-vkompella-ppvpn-vpls-04.txt, it say: * 11. Hierarchical VPLS model using Ethernet Access Network ..... * One approach of tunneling a customer?s Ethernet traffic via an * Ethernet access network is to add an additional VLAN tag to the * customer?s data (either tagged or untagged). The additional tag is * referred to as Provider?s VLAN (P-VLAN). Inside the provider?s * network each P-VLAN designates a customer or more specifically a VPLS ** instance for that customer. Therefore, there is a one to one ** correspondence between a P-VLAN and a VPLS instance. In my option, the last sentece in above is not true. There is also a many-to-one correspondence between a P-VLAN and a VPLS instance, not only a one-to-one. i.e, a customer with P-VLAN 3 and another customer with P-VLAN 4 belong to the same VPLS. Muchmore, to PE-rs the ethernet port is not a traditional standard port. When flooding, PE-rs need to send more than one copy in one ehternet port, because there are serveral custumers in one ethernet port each have different P-VLAN. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua >As noted in the minutes, at the San Francisco meeting strong interest >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a >working group draft. We agreed to finalize that decision only after the >WG participants who weren't there could have a say. > >So, if there are opinions that have not been heard, now is the time, and >this list is the place. Let's set a one-week limit to conclude this >issue. > >Rick > >------------------------------------------------------------------------ >------------------------------------------------------------------------ >--- >From the minutes: > >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. > >[snipped] > Marco: asked for show of hands to make this a wG draft. >Strong interest was shown in room. Further discussion on the list. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 19:13:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26402 for ; Mon, 14 Apr 2003 19:13:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ENG3e05385 for ; Mon, 14 Apr 2003 19:16:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ENFpN06864 for ; Mon, 14 Apr 2003 19:15:52 -0400 (EDT) Date: Mon, 14 Apr 2003 16:12:08 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@u43 To: Eric Rosen Cc: ppvpn@nortelnetworks.com Subject: Re: On the subject of WG docs ... In-Reply-To: <200304141713.h3EHDCB0013147@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, On Mon, 14 Apr 2003, Eric Rosen wrote: > If everybody is pitching their docs to become WG docs, I might as well join > the club and make a pitch for draft-rosen-ppvpn-l2-signaling-02.txt. > > - The part of that doc that specifies LDP-based signaling extensions has > been incorporated into the PWE3 WG draft draft-ietf-pwe3-control-protocol- > 02.txt. So my plan would be to recast the document slightly into a > specification of how to use PWE3 signaling to support the variety of > provisioning models which are being considered by this WG. > > - There is a draft in the l2tpext group (draft-luo-l2tpext-l2vpn-signaling) > which applies the same concepts to L2TP-based signaling. While that > document has a number of detailed differences, I would expect these to get > resolved into a single PPVPN document. > Will this single PPVPN doc be : - draft-rosen-ppvpn-l2-signaling-02.txt, or - a) a common PPVPN doc for the identifier and b) draft-rosen-ppvpn-l2-signaling-02.txt for the provisioning models ? If the idea is to move forward with draft-rosen-ppvpn-l2-signaling-02.txt, such that it spells out provisioning models for both LDP and L2TP based signaling, I support it as a WG doc. Spelling out the identifier format in this doc or a separate doc is an open question. Regards, rahul > - Support for these concepts has been expressed by a number of people who > are active in this WG. > > - The main opposition to this proposal, one V. Kompella, now seems somewhat > more tolerant of it, if one might judge from a recent thread. > > There is still some ongoing argument about the properties, syntax, and > semantics, which the"generalized identifiers" of this draft need to have, > but this draft seems to me like a good basis for future work. > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 19:35:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26821 for ; Mon, 14 Apr 2003 19:35:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ENbQe09387 for ; Mon, 14 Apr 2003 19:37:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ENbHN16677 for ; Mon, 14 Apr 2003 19:37:18 -0400 (EDT) Date: Mon, 14 Apr 2003 16:34:43 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@u43 To: ppvpn@nortelnetworks.com Subject: Regarding progressing VPLS docs 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 Marco and Rick, I would like to add my support for making both: draft-lasserre-vkompella-ppvpn-vpls-04.txt draft-kompella-ppvpn-vpls-01.txt as WG docs with the caveat that the common parts should not be repeated. draft-lasserre may be a good place to keep the common portion. In particular the data plane description that is common to these specs can be left in draft-lasserre and pulled out of draft-kompella. Its possible to have a never ending discussion on the pros and cons of each. The bottomline is that LDP signaling + protocol X auto-discovery or BGP signaling + BGP auto-discovery, both have their own applicability. If down the road we figure out that one of these solutions doesn't have deployment traction, the respective doc doesn't have to be moved to RFC status. Thanks, rahul From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 20:32:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28373 for ; Mon, 14 Apr 2003 20:32:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3F0YZe22721 for ; Mon, 14 Apr 2003 20:34:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3F0YQN14095 for ; Mon, 14 Apr 2003 20:34:26 -0400 (EDT) Message-ID: <02bf01c302e6$6f73cea0$30acf880@SHASHANK> From: "Shashank Khanvilkar" To: Subject: Reg. Missing references. Date: Mon, 14 Apr 2003 19:32:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: birch.cc.uic.edu X-SMTP-MAIL-FROM: shashank@evl.uic.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: birch.cc.uic.edu [128.248.155.162] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi, I had been reading a few IETF's drafts available on the IETF PPVPN charter page. I came across the following references in "Guidelines of Applicability Statements for PPVPNs" and "Generic Requirements for Provider Provisioned VPN" that i could not find on that page. I will appreciate if someone can let me know if these have "expired and replaced by new ones" or should I search for them on google. [L2 REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", work in progress [TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider Provisioned Virtual Private Networks", work in progress. Regards Shashank http://mia.ece.uic.edu/~papers From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 21:26:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29552 for ; Mon, 14 Apr 2003 21:26:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3F1SIe03282 for ; Mon, 14 Apr 2003 21:28:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3F1SFN07061 for ; Mon, 14 Apr 2003 21:28:15 -0400 (EDT) Date: Tue, 15 Apr 2003 10:16:19 +0900 (JST) Message-Id: <20030415.101619.74691626.suzuki.muneyoshi@lab.ntt.co.jp> To: shashank@evl.uic.edu Cc: ppvpn@nortelnetworks.com Subject: Re: Reg. Missing references. From: Muneyoshi Suzuki In-Reply-To: <02bf01c302e6$6f73cea0$30acf880@SHASHANK> References: <02bf01c302e6$6f73cea0$30acf880@SHASHANK> 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 Shashank, > [L2 REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements > for Layer 2 Provider Provisioned Virtual Private Networks", work > in progress draft-augustyn-ppvpn-l2vpn-requirements-02.txt > [TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider > Provisioned Virtual Private Networks", work in progress. draft-andersson-ppvpn-terminology-02.txt Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 14 23:35: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 XAA02072 for ; Mon, 14 Apr 2003 23:35:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3F3YHe15122 for ; Mon, 14 Apr 2003 23:34:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3F3YEN21731 for ; Mon, 14 Apr 2003 23:34:14 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6ACF@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'hshah@rcn.com'" , "'Ali Sajassi'" , ppvpn@nortelnetworks.com Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt Date: Mon, 14 Apr 2003 23:31:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C302FF.915049E0" 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_01C302FF.915049E0 Content-Type: text/plain Ali, Your observation about packet re-ordering in GVPLS has a point. However, as Himanshu said it is a very low probability and this in the case when the VPLS core is not well design. In Himanshu's example the remote unicast packet needs to travel twice the speed of the multicast packet, along the Unicast PW(s), in order to arrive before the multicast packet, at the remote destination. Also, we don't need to forget the U-PE devices are most of the time connected with low speed connections to the PE, if we compare with the high speed core links, and most of the time via L2 devices. The Remote packet and local unicast packet need to traverse twice such connections in order to get the unicast packet in front of the multicast packet. As it was suggested, in most of the cases, the Unicast PW and M-P2P PW share the same Tunnel between two PEs. Other option, is to do a better design of the M-P2P PWs using TE or other Qos techniques that can give a better response time (for example, a typical VPLS design is to combine a VPN pipe model in the VPLS core, with the VPLS hose model between the VPN Members). In GVPLS, the M-P2P PWs are treated as an optimization for the multicast traffic and are defined per VPN (regular Unicast VC-Labels can be used also). In the VPLS scope the multicast or unknown traffic needs to be very careful design - is easy to proof that in scalable VPLS configurations (with thousand of VPLSs ), the multicast traffic that can be generated can block the unicast traffic and jeopardize, overall, the QoS of the VPLS Services. The idea of the M2-P2P PWs is to provide a kind of "Multicast tree" where the packets are replicated as minimum as possible between U-PE and N-PE devices. If the packet re-ordering is a key component of a given application (a given VPLS context) and all the tools that are available are not enough to lower the probability of the packet re-ordering, then the replication can be done using the Unicast PWs in the VPLS scope. The VPLS forwarding engine is transparent to the use of a VC-M-Label or a regular VC-Label. In general the Multicast issue is a complex one in the VPLS scope - I belive that the current proposal is is a starting point in providing a good solution. Cheers Vasile -----Original Message----- From: himanshu shah [mailto:hshah@rcn.com] Sent: Monday, April 14, 2003 2:42 PM To: 'Ali Sajassi'; ppvpn@nortelnetworks.com Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt response in line. -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com] Sent: Monday, April 14, 2003 1:44 PM To: hshah@rcn.com; 'Ali Sajassi'; ppvpn@nortelnetworks.com Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt That would exasperate the problem even more. So if some of the existing platforms have different internal processing path that would result in packet re-ordering between unknown unicast versus known unicast, then we should fix the problem instead of amplifying it by allowing it to be done everywhere in the network (both edge and core). Also I would like to know where in IEEE standards, it allows for such behavior. We can take this discussion to IEEE list. HS> Out-of-order packets between unknown-unicast/multicast and HS> known unicast is well known and well accepted fact. Perhaps HS> you should inquire this on IEEE mailing list. Not for the steady state. If you look at the IEEE 802.1D standards it says: "NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or duplicate frames. Where Bridges in a Bridged LAN are capable of connecting the individual MACs in such a way that multiple paths between any source station -destination station pairs exist,the operation of a protocol is required to ensure that a single path is used. NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during normal operation." It clearly states that during normal operation misordering DOES NOT OCCUR !! [himanshu shah] Despite what it says, today in normal bridges, broadcast (unknown unicast frame is a flood and hence it is a broadcast) and unicast frames between two stations may get out of order for the reasons I described before; irrespective of the state of the network. Again, I invite you to site an example where a miniscule possibility of such an out-of-order spells disaster for a protocol (at session initiation time). Even with this, you can still have out-of-ordering because of ECMP !! HS> Thank you. You give one more example of how an out-of-order HS> delievery could occur even when traffic is going over single HS> pseudowire. No !!! traffic doesn't get re-order when a single PW is used in case of ECMP. It can get re-order when there are multiple PWs are involved for the same flow (as in the case of GVPLS). [himanshu shah] If one was to do ECMP using the bottom most label, then it is true that out-of-order would not occur for a single PW. However, is it mandated that ECMP must be done on bottom-most label (i.e. PW label which technically could be below several labels)? Lets for a moment accept that such out-of-order would occur for 2 PWs. I would like to see an example where a rare case of mis-order between broadcast-path frame and unicast-path frame. HS> The point is out-of-order can happen in GVPLS in very rare HS> circumstances. If you look at RSTP, out-of-order is mentioned HS> as a possibility during topo changes as an acceptable risk against HS> greater benefits. I suppose one can apply same logic here. As mentioned before, IEEE 802.1D standards allows for possibility of reordering in case of topology changes but not in steady state operation. [himanshu shah] topo changes in small bridged network as compared to topo changes in big-I network are at quite different scale. If one was to compare the number of out-of-order packets due to topo-changes in big-I network to out-of-order packets due to 2 PW, one would wonder where the real problem is. Regards, Ali ------_=_NextPart_001_01C302FF.915049E0 Content-Type: text/html Message
         Ali,
 
             Your observation about packet re-ordering in GVPLS has a point. However, as Himanshu said
             it is a very low probability  and this in the case when the VPLS core is not well design. 
             In Himanshu's example the remote unicast packet needs to travel twice the speed of the multicast
             packet, along the Unicast PW(s), in order to arrive before the multicast packet, at the remote destination.
 
             Also, we don't need to forget  the U-PE devices are most of the time connected with low speed
             connections to the PE, if we compare with the high speed core links, and most of the time via L2
             devices. The Remote packet and local unicast packet need to traverse twice such connections in order
             to get the unicast packet in front of the multicast packet.
 
             As it was suggested, in most of the cases, the Unicast PW and M-P2P PW  share the same
             Tunnel between two PEs.  Other option, is to  do a better design of the M-P2P PWs using TE or other
             Qos techniques that can give   a better response time (for example, a typical VPLS design is to combine
             a VPN pipe model in the VPLS core, with the VPLS hose model between the VPN Members).
 
             In GVPLS,  the M-P2P PWs are treated as an optimization for the multicast traffic and are defined per VPN
             (regular Unicast  VC-Labels can be used also).
             In the VPLS scope the multicast or unknown traffic needs to be very careful design - is easy to proof
              that in scalable VPLS configurations (with thousand of VPLSs ), the multicast traffic that can be generated  can
             block  the unicast traffic  and jeopardize, overall, the QoS of the VPLS Services.
             The idea of the M2-P2P PWs is to provide a kind of "Multicast tree" where the packets are replicated
             as minimum as possible between U-PE and N-PE devices. 
 
             If the packet re-ordering is a key component of a given application (a given VPLS context) and all the
             tools that are available are not enough to lower the probability  of the packet re-ordering, then the replication
             can  be done using the Unicast PWs in the VPLS scope.
             The VPLS forwarding engine is transparent to the use of a VC-M-Label or a regular VC-Label.
             
             In general the Multicast issue is a complex one in the VPLS scope - I belive that the current proposal is
             is a starting point  in providing  a good  solution.
 
          Cheers
                Vasile
-----Original Message-----
From: himanshu shah [mailto:hshah@rcn.com]
Sent: Monday, April 14, 2003 2:42 PM
To: 'Ali Sajassi'; ppvpn@nortelnetworks.com
Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt

response in line.
-----Original Message-----
From: Ali Sajassi [mailto:sajassi@cisco.com]
Sent: Monday, April 14, 2003 1:44 PM
To: hshah@rcn.com; 'Ali Sajassi'; ppvpn@nortelnetworks.com
Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt

That would exasperate the problem even more. So if some of the existing
platforms have different internal processing path that would result in
packet re-ordering between unknown unicast versus known unicast, then we
should fix the problem instead of amplifying it by allowing it to be done
everywhere in the network (both edge and core).  Also I would like to know
where in IEEE standards, it allows for such behavior. We can take this
discussion to IEEE list.


HS> Out-of-order packets between unknown-unicast/multicast and
HS> known unicast is well known and well accepted fact. Perhaps
HS> you should inquire this on IEEE mailing list.

Not for the steady state. If you look at the IEEE 802.1D standards it says:

"NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or duplicate frames.
Where Bridges in a Bridged LAN are capable of connecting the individual MACs in such a way that
multiple paths between any source station -destination station pairs exist,the operation of a protocol is required to ensure that a single path is used.
NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during normal operation."

It clearly states that during normal operation misordering DOES NOT OCCUR !!


[himanshu shah] Despite what it says, today in normal bridges, broadcast (unknown unicast frame is a flood and hence it is a broadcast) and unicast frames between two stations may get out of order for the reasons I described before; irrespective of the state of the network. Again, I invite you to site an example where a miniscule possibility of such an out-of-order spells disaster for a protocol (at session initiation time).

 
Even with this, you can still have out-of-ordering because of ECMP !!


HS> Thank you. You give one more example of how an out-of-order
HS> delievery could occur even when traffic is going over single
HS> pseudowire.

No !!! traffic doesn't get re-order when a single PW is used in case of ECMP. It can get re-order when there are multiple PWs are involved for the same flow  (as in the case of GVPLS).
[himanshu shah] If one was to do ECMP using the bottom most label, then it is true that out-of-order would not occur for a single PW. However, is it mandated that ECMP must be done on bottom-most label (i.e. PW label which technically could be below several labels)? Lets for a moment accept that such out-of-order would occur for 2 PWs. I would like to see an example where a rare case of mis-order between broadcast-path frame and unicast-path frame.

HS> The point is out-of-order can happen in GVPLS in very rare
HS> circumstances.  If you look at RSTP, out-of-order is mentioned
HS> as a possibility during topo changes as an acceptable risk against
HS> greater benefits. I suppose one can apply same logic here.

As mentioned before, IEEE 802.1D standards allows for possibility of reordering in case of topology changes but not in steady state operation.
[himanshu shah] topo changes in small bridged network as compared to topo changes in big-I network are at quite different scale. If one was to compare the number of out-of-order packets due to topo-changes in big-I network to out-of-order packets due to 2 PW, one would wonder where the real problem is.

Regards,
Ali

------_=_NextPart_001_01C302FF.915049E0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 00:09:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02646 for ; Tue, 15 Apr 2003 00:09:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3F4BCq23357 for ; Tue, 15 Apr 2003 00:11:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3F4B8C15370 for ; Tue, 15 Apr 2003 00:11:09 -0400 (EDT) Message-ID: <00a301c30304$ae3ea740$f858ea0c@Amita> From: "amita" To: , "Ali Sajassi" References: <4.3.2.7.2.20030413192710.01bdc2e0@airborne.cisco.com> <4.3.2.7.2.20030414101113.01caa130@airborne.cisco.com> Subject: Re: Issues with draft-radoaca-ppvpn-gvpls-01.txt Date: Mon, 14 Apr 2003 21:08:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: rwcrmhc53.attbi.com X-SMTP-MAIL-FROM: a.patil@attbi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rwcrmhc53.attbi.com [204.127.198.39] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Just to close on the clarification for this email thread ... ( .. response inline ) regards, -Amita ----- Original Message ----- From: "Ali Sajassi" To: "amita" ; ; "Ali Sajassi" Sent: Monday, April 14, 2003 10:16 AM Subject: Re: Issues with draft-radoaca-ppvpn-gvpls-01.txt > > > > > > > One one the main issues with GVPLS is the use of different PWs for unknown > > > unicast frames versus known unicast frames (e.g., using PtMP PWs for > > > unknown unicast and MPtP PWs for known unicast). I raised my concern > > > during the WG meeting and I will reiterate it here again. > > > > > > In regular LAN network, in absence of failure, there is NO possibility for > > > packet re-ordering. > >*********************************** > >Not entirely true.There is a possibility (may be rare) of frame re-ordering > >in L2 networks , when the switch architecture supports separate unicast and > >multicast queues. > >The queue arbitration for multicast and unicast queues could cause the > >similar situation that you are describing below, when the slower unicast > >frame can arrive after the destination MAC is learnt. > >802.1D does not mandate frame ordering between the unicast and multicast > >destination MAC. > > We are talking about frame ordering for unicast destination MAC (known > versus unknown). > [Amita ] Sure , I meant unknown unicast MAC that gets translated to VLAN flooding , the traffic that goes on multicast queues in some architectures. > >*********************************** > > > However, with the use of different PWs for unicast > > > frames in GVPLS, the possibility of re-ordering customer's Ethernet frames > > > exists even in absence of any failures (e.g., during steady state network > > > operation). This out-of-sequencing happens when a customer destination MAC > > > address is not learnt and customer's frames gets flooded via PtMP PW. > > > > >Now > > > if after transmission of the first frame, the PE learns the destination > >MAC > > > address, then the subsequent frames go over a different PW (e.g., MPtP). > > > Since two consecutive frames can go over different PWs and these different > > > PWs can take different path w/ different delays in the network, the two > > > frames can arrive out-of-order at the destination PE and some protocols > >can > > > be susceptible to this out-of-ordering of the packets. > > > > >************************************************** > >This could very much happen . > >As far as final delivery of frames is concerened at the End Point equipment > >, it is a responsibility of the protocol operation to ensure that single > >path is used between the source and destination station pair.( as per > >802.1D ). > >It is possible to ensure that by always using the same tunnel LSP between > >PEs for unicast and multicast PWs within a VPN. > > However, you cannot ensure a single path even if you use the same tunnel > LSP because of load balancing for ECMP as I indicated previously. > > -Ali > > > >************************************************** > > > I'd like to know how this packet out-of-ordering will be addressed in > >GVPLS. > > > > > > -Ali > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 00:12:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02683 for ; Tue, 15 Apr 2003 00:12:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3F4EFq26643 for ; Tue, 15 Apr 2003 00:14:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3F4EBC19214 for ; Tue, 15 Apr 2003 00:14:11 -0400 (EDT) Message-ID: <00a401c30304$b264aa40$f858ea0c@Amita> From: "amita" To: , "Vasile Radoaca" Cc: "Marco Carugi" , "'Rick Wilder'" , References: <200304141733.h3EHXbB0019121@rtp-core-1.cisco.com> Subject: Re: progressing docs Date: Mon, 14 Apr 2003 21:08:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: rwcrmhc53.attbi.com X-SMTP-MAIL-FROM: a.patil@attbi.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rwcrmhc53.attbi.com [204.127.198.39] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I would like to support draft-radoaca-ppvpn-gvpls-01.txt as a WG document for the following reasons : 1 . It incorporates non-distributed as well as distributed model , very flexible ,hence can address architectural concerns for wider variety of vendors who would want to support VPLS. 2. Supports BGP and LDP signaling. 3. Facilitates multi-vendor interoperability. 4. Can support unified provisioning model. Though some issues ,it provides good text to start discussing as a WG doc. thanks, -Amita ----- Original Message ----- From: "Eric Rosen" To: "Vasile Radoaca" Cc: "Marco Carugi" ; "'Rick Wilder'" ; Sent: Monday, April 14, 2003 10:33 AM Subject: Re: progressing docs > > > draft-radoaca-ppvpn-gvpls-01.txt > > I support accepting this as a WG document, even though, like any other WG > document, it may have a number of open issues and/or flaws. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 05:04: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 FAA19595 for ; Tue, 15 Apr 2003 05:04:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3F96xq00910 for ; Tue, 15 Apr 2003 05:07:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3F96tC24550 for ; Tue, 15 Apr 2003 05:06:55 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A14649701494945@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: ppvpn@nortelnetworks.com Subject: RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Tue, 15 Apr 2003 11:03:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3032D.E78A7B90" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3032D.E78A7B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I fully support draft-kompella-ppvpn-vpls-01 BGP as VPLS Signaling protocol isn't only an elegant solution :-), it is a natural solution when 2 SPs would like to extand their VPLS = domains. If you push back BGP VPLS Signaling, how will this Carrier's Carriers = VPLS implementation will be done if one of this SP don't want to activate = LDP inside his network, BGP being already enabled on all PE routers? If a vendor could explain me how using 2 differents protocols for = Control Plane (signaling and auto-discovery) will be more efficient (technical argumentations please and not philosophical ones) than when using only = one protocol (MP-BGP). Mourad -----Message d'origine----- De : Eric Rosen [mailto:erosen@cisco.com] Envoy=E9 : lundi 14 avril 2003 20:59 =C0 : Kireeti Kompella Cc : Ali Sajassi; Yakov Rekhter; ppvpn@nortelnetworks.com; = pwe3@ietf.org Objet : Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt I don't believe in the "overloading BGP" argument myself, though it is = clear that that argument has many adherents. To my mind, the issue is = really whether BGP is a good protocol for the kind of signaling that needs = to be done. Sure, "with enough thrust, even pigs can fly". In 2547, we = chose to use BGP not because it was there, but because it is a good = protocol for distributing a large amount of routing information that originates = from other routing domains. I like BGP for auto-discovery = because in auto-discovery, we want a protocol that provides a = point-to-multipoint capability and allows an originator to update and withdraw = information at will; BGP as a protocol seems like a good match. Is it a good = match for point-to-point signaling? That's a lot more of a stretch.=20 Kireeti> if you use any measurable criteria for the complexity = of a Kireeti> solution, on all these measures,=20 Well, that's the claim. Let's see, suppose you need to = resynchronize the sequence numbers on a particular PE-PE pseudowire. How efficient is = BGP at doing that? Suppose there is some problem in getting data from one = PE to another? Does the fact that the control plane goes through a third = party (route reflector) make it easier to troubleshoot that problem, or = more difficult?=20 Kireeti> First of all, there are several clear benefits. Just ask = the Kireeti> Service Providers who responded.=20 You're referring to the benefit of "elegance"? =20 Kireeti> Finally, to address your issues in your first email, we = are not Kireeti> asking that this doc be made an RFC -- just that it be made = a WG Kireeti> doc. As Alex said: "For a document to become a WG = draft, it Kireeti> doesn't have to be 100% correct."=20 Adopting your document as a WG doc would be an expression by the = WG of support for using BGP as a way to do p2p signaling. The WG should be = very sure that it wants to do that before adopting your doc.=20 Kireeti> if you look at the service offered, you see strong = parallels -- Kireeti> any-to-any connectivity, learned forwarding=20 If you compare bridging to routing, you'll see the very same = parallels, yet the technologies are very different, have very different = applicabilities, and require very different solutions. Kireeti> a proposal that only shows how to do signaling is clearly = inferior=20 Certainly what is needed is a complete solution, rather than just a = piece. However, when the solution contains multiple identifiable components, = proper layering generally results in more long term simplicity and = flexibility.=20 If the proposal is to use BGP for signaling pseudowires, I think = the technical discussion should focus on its suitability for that purpose.=20 Yakov> in the context of VPLS we are talking not just about multiple = ways of Yakov> distributing labels, but whether one always have to have one = protocol Yakov> for distributing labels, and another for auto-discovery, or = one Yakov> protocol for both would be enough. Well, I don't really see how this is different than the "CR-LDP = isn't another protocol" argument. The arguments are being repeated almost = word for word, albeit not by the same set of people ;-) You seem to be arguing that "given a protocol to do X, if we need to = do Y, it is better to piggyback Y on the X-protocol than to use a protocol = that is designed to do Y." In general, this argument form is not valid, it = really is a matter of how suitable the X protocol is for Y.=20 Yakov> The fact that the two drafts [kompella and lasserre/vkompella] = share Yakov> the same data plane is a feature, not a bug. Of course, I never said otherwise. But the specification of that data = plane should not be in both places, one doc should reference the other. ------_=_NextPart_001_01C3032D.E78A7B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Re: Issues with = draft-kompella-ppvpn-vpls-01.txt

I fully support draft-kompella-ppvpn-vpls-01

BGP as VPLS Signaling protocol isn't only an elegant = solution :-),
it is a natural solution when 2 SPs would like to = extand their VPLS domains. If you push back BGP VPLS Signaling, how = will this Carrier's Carriers VPLS implementation will be done if one of = this SP don't want to activate LDP inside his network, BGP being = already enabled on all PE routers?

If a vendor could explain me how using 2 differents = protocols for Control Plane (signaling and auto-discovery) will be more = efficient (technical argumentations please and not philosophical ones) = than when using only one protocol (MP-BGP).

Mourad

-----Message d'origine-----
De : Eric Rosen [mailto:erosen@cisco.com]
Envoy=E9 : lundi 14 avril 2003 20:59
=C0 : Kireeti Kompella
Cc : Ali Sajassi; Yakov Rekhter; = ppvpn@nortelnetworks.com; pwe3@ietf.org
Objet : Re: [PWE3] Re: Issues with = draft-kompella-ppvpn-vpls-01.txt


I don't believe in the "overloading BGP" = argument myself, though it is clear
that that  argument has  many = adherents.   To my mind,  the issue  is = really
whether BGP is  a good protocol for  the = kind of signaling that  needs to be
done.  Sure, "with enough thrust, = even  pigs can fly".  In 2547, we chose to
use BGP  not because it  was there,  = but because it  is a good  protocol for
distributing  a large  amount of  = routing information  that  originates from
other  routing   domains.   = I  like   BGP  for  auto-discovery   = because  in
auto-discovery,  we  want a  = protocol  that  provides a  point-to-multipoint
capability and  allows an originator  to = update and withdraw  information at
will; BGP  as a protocol seems  like a = good match.   Is it a  good match for
point-to-point signaling?  That's a lot more of = a stretch.

Kireeti> if  you  use  any  = measurable  criteria for  the  complexity  of  = a
Kireeti> solution, on all these measures,

Well, that's  the claim.  Let's see,  = suppose you need  to resynchronize the
sequence numbers on a particular  PE-PE = pseudowire.  How efficient is BGP at
doing that?   Suppose there is some = problem  in getting data from  one PE to
another?  Does  the fact that the  = control plane goes through  a third party
(route  reflector) make  it easier  = to  troubleshoot that  problem, or  more
difficult?

Kireeti> First  of all,  there are  = several  clear benefits.   Just ask  the
Kireeti> Service Providers who responded.

You're referring to the benefit of = "elegance"? 

Kireeti> Finally, to  address your  = issues in your  first email, we  are not
Kireeti> asking that this  doc be made an = RFC  -- just that it be  made a WG
Kireeti> doc.   As Alex  said: = "For  a  document to  become a  WG = draft,  it
Kireeti> doesn't have to be 100% correct." =

Adopting your  document as  a WG  doc = would be  an expression  by the  WG of
support for using BGP  as a way to do p2p = signaling.   The WG should be very
sure that it wants to do that before adopting your = doc.

Kireeti> if you  look at  the service = offered,  you see strong  parallels --
Kireeti> any-to-any connectivity, learned = forwarding

If you compare bridging to routing,  you'll see = the very same parallels, yet
the technologies  are very  different, = have very  different applicabilities,
and require very different solutions.

Kireeti> a proposal that only shows how to do = signaling is clearly inferior

Certainly what is  needed is a complete = solution, rather  than just a piece.
However, when the solution contains multiple = identifiable components, proper
layering generally results in more long term = simplicity and flexibility.

If  the proposal  is  to use  = BGP  for signaling  pseudowires,  I think  = the
technical discussion should focus on its suitability = for that purpose.

Yakov> in the context of VPLS we are talking not = just about multiple ways of
Yakov> distributing labels, but whether one = always have to have one protocol
Yakov> for  distributing  labels, = and  another  for  auto-discovery, or  one
Yakov> protocol for both would be enough.

Well,  I don't  really see  how  = this is  different than  the "CR-LDP  isn't
another protocol"  argument.  The = arguments  are being repeated  almost word
for word, albeit not by the same set of people = ;-)

You seem to be  arguing that "given a = protocol to do X, if  we need to do Y,
it is better to piggyback Y on the X-protocol than = to use a protocol that is
designed to do  Y."  In general, this = argument form is  not valid, it really
is a matter of how suitable the X protocol is for Y. =

Yakov> The fact that the  two drafts = [kompella and lasserre/vkompella] share
Yakov> the same data plane is a feature, not a = bug.

Of course, I never said otherwise.  But the = specification of that data plane
should not  be in both  places, one = doc  should reference the other.




------_=_NextPart_001_01C3032D.E78A7B90-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 06:34:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21011 for ; Tue, 15 Apr 2003 06:34:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FAajq14541 for ; Tue, 15 Apr 2003 06:36:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FAagC00869 for ; Tue, 15 Apr 2003 06:36:42 -0400 (EDT) Message-ID: <014c01c3033a$f08c0300$81c802c0@alok> From: "alok" To: Subject: RD in 2547 bis Date: Tue, 15 Apr 2003 16:06:43 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Hi, I know this has been asked time and again, but its still confusing me what is the purpose of RD ? -rgds Alok From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 06:51:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21340 for ; Tue, 15 Apr 2003 06:51:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FArHq18223 for ; Tue, 15 Apr 2003 06:53:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FArEC07135 for ; Tue, 15 Apr 2003 06:53:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RD in 2547 bis Date: Tue, 15 Apr 2003 12:50:24 +0200 Message-ID: <3DB5279B525005439410B5EF3911EE736AC1B1@TMS041MB.tcad.telia.se> Thread-Topic: RD in 2547 bis Thread-Index: AcMDOqfF4R1qe0//Q1mekb9pnM1IxgAAclDg From: To: , X-OriginalArrivalTime: 15 Apr 2003 10:50:24.0726 (UTC) FILETIME=[D1ADDF60:01C3033C] X-SMTP-HELO: tms002bb.han.telia.se X-SMTP-MAIL-FROM: Nhat.T.Hoang@telia.se X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: tms002bb.han.telia.se [131.115.230.133] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA21340 Hi, The purpose of RD is simply resolve the overlapping address problem in VPN context. regards, /Nhat Thanh -----Original Message----- From: alok [mailto:alok.dube@apara.com] Sent: den 15 april 2003 12:37 To: ppvpn@lyris.nortelnetworks.com Subject: RD in 2547 bis Hi, I know this has been asked time and again, but its still confusing me what is the purpose of RD ? -rgds Alok From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 06:54:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21425 for ; Tue, 15 Apr 2003 06:54:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FAuAq21579 for ; Tue, 15 Apr 2003 06:56:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FAu7C11251 for ; Tue, 15 Apr 2003 06:56:07 -0400 (EDT) Message-ID: <019701c3033d$6cd829a0$81c802c0@alok> From: "alok" To: References: <3DB5279B525005439410B5EF3911EE736AC1B1@TMS041MB.tcad.telia.se> Subject: Re: RD in 2547 bis Date: Tue, 15 Apr 2003 16:24:34 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: what is the "overlapping address problem"? why isnt RT sufficient to identify the ipv4 prefix uniquely? why "both"? ----- Original Message ----- From: To: ; Sent: Tuesday, April 15, 2003 4:20 PM Subject: RE: RD in 2547 bis > Hi, > > The purpose of RD is simply resolve the overlapping address problem in > VPN context. > > regards, > > /Nhat Thanh > > -----Original Message----- > From: alok [mailto:alok.dube@apara.com] > Sent: den 15 april 2003 12:37 > To: ppvpn@lyris.nortelnetworks.com > Subject: RD in 2547 bis > > > Hi, > > I know this has been asked time and again, but its still confusing me > > what is the purpose of RD ? > > -rgds > Alok > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 07:01:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21587 for ; Tue, 15 Apr 2003 07:01:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FB3rq05857 for ; Tue, 15 Apr 2003 07:03:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FB3nC16487 for ; Tue, 15 Apr 2003 07:03:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RD in 2547 bis Date: Tue, 15 Apr 2003 13:01:20 +0200 Message-ID: <3DB5279B525005439410B5EF3911EE7313B46F@TMS041MB.tcad.telia.se> Thread-Topic: RD in 2547 bis Thread-Index: AcMDPUJ89DScyux8THiFhFOeXFfovQAACuew From: To: , X-OriginalArrivalTime: 15 Apr 2003 11:01:21.0367 (UTC) FILETIME=[59115670:01C3033E] X-SMTP-HELO: tms002bb.han.telia.se X-SMTP-MAIL-FROM: Nhat.T.Hoang@telia.se X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: tms002bb.han.telia.se [131.115.230.133] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA21587 Hi, The overlapping address problem is that different VPNs that is provided by one operator can have the same private address space. For instance, two VPNs may have several identical addresses. The RD makes VPN routes unique for each VPN. The RT is used to determine how to import and export the VPN routes into the relevant VRFs. There are many in mailing list who can answer better and more pedogical then me. Regards, Nhat Thanh -----Original Message----- From: alok [mailto:alok.dube@apara.com] Sent: den 15 april 2003 12:55 To: ppvpn@lyris.nortelnetworks.com Subject: Re: RD in 2547 bis what is the "overlapping address problem"? why isnt RT sufficient to identify the ipv4 prefix uniquely? why "both"? ----- Original Message ----- From: To: ; Sent: Tuesday, April 15, 2003 4:20 PM Subject: RE: RD in 2547 bis > Hi, > > The purpose of RD is simply resolve the overlapping address problem > in VPN context. > > regards, > > /Nhat Thanh > > -----Original Message----- > From: alok [mailto:alok.dube@apara.com] > Sent: den 15 april 2003 12:37 > To: ppvpn@lyris.nortelnetworks.com > Subject: RD in 2547 bis > > > Hi, > > I know this has been asked time and again, but its still confusing me > > what is the purpose of RD ? > > -rgds > Alok > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 07:06: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 HAA21661 for ; Tue, 15 Apr 2003 07:06:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FB8Pq09867 for ; Tue, 15 Apr 2003 07:08:25 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FB8MC21383 for ; Tue, 15 Apr 2003 07:08:23 -0400 (EDT) Message-ID: <01d001c3033f$536ed020$81c802c0@alok> From: "alok" To: References: <3DB5279B525005439410B5EF3911EE7313B46F@TMS041MB.tcad.telia.se> Subject: Re: RD in 2547 bis Date: Tue, 15 Apr 2003 16:37:52 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: lets assume there was no RT could we filter on RD? if we can do that, then why not vice versa? ----- Original Message ----- From: To: ; Sent: Tuesday, April 15, 2003 4:31 PM Subject: RE: RD in 2547 bis > Hi, > > The overlapping address problem is that different VPNs that is provided > by one operator can have the same private address space. For instance, > two VPNs may have several identical addresses. The RD makes VPN routes > unique for each VPN. > > The RT is used to determine how to import and export the VPN routes into > the relevant VRFs. > > There are many in mailing list who can answer better and more pedogical > then me. > > Regards, > > Nhat Thanh > > -----Original Message----- > From: alok [mailto:alok.dube@apara.com] > Sent: den 15 april 2003 12:55 > To: ppvpn@lyris.nortelnetworks.com > Subject: Re: RD in 2547 bis > > > what is the "overlapping address problem"? > > why isnt RT sufficient to identify the ipv4 prefix uniquely? > > why "both"? > > ----- Original Message ----- > From: > To: ; > Sent: Tuesday, April 15, 2003 4:20 PM > Subject: RE: RD in 2547 bis > > > > Hi, > > > > The purpose of RD is simply resolve the overlapping address problem > > in VPN context. > > > > regards, > > > > /Nhat Thanh > > > > -----Original Message----- > > From: alok [mailto:alok.dube@apara.com] > > Sent: den 15 april 2003 12:37 > > To: ppvpn@lyris.nortelnetworks.com > > Subject: RD in 2547 bis > > > > > > Hi, > > > > I know this has been asked time and again, but its still confusing me > > > > what is the purpose of RD ? > > > > -rgds > > Alok > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 07:31:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23207 for ; Tue, 15 Apr 2003 07:31:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FBY3q13796 for ; Tue, 15 Apr 2003 07:34:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FBY0C29187 for ; Tue, 15 Apr 2003 07:34:00 -0400 (EDT) Message-ID: <11D2868F916DD411982D00508B694F431CE7CD60@syd-xch2.cisco.com> From: "Apcar, Jeff" To: alok , ppvpn@lyris.nortelnetworks.com Subject: RE: RD in 2547 bis Date: Tue, 15 Apr 2003 21:31:27 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: syd-msg-core-1.cisco.com X-SMTP-MAIL-FROM: japcar@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: syd-msg-core-1.cisco.com [64.104.193.198] X-LYRIS-Message-Id: In 2547bis the mechansim to pass VPN addresses with between PE routers is MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but it is not interested in what VPN these addresses belong to. YOu need the RD to make the VPN addresses unique to MP-BGP, and consequently to the SP domain. For example, suppose you had VPN RED and VPN GREEN on different PE-routers and they both originated an address from RFC1918, like 10.2.1.0/24, then if they were not uniquely identified by an RD, when the two 10.2.1.0/24 addresses arrived at the same remote PE-router, BGP would simply do its best path selection algorithm on the two addresses and only pick one. Hence you would lose the other. If they are both unique with an RD then it is called a VPNv4 address. BGP will see them as unique and the MP-BGP peer on the remote PE-router would accept both. Then to decide which VPN to place the received address in we use the RT, which is an extended community attribute. You need the RD to make the VPN addresses to unique MP-BGP you need the RT to select which VPN to include the address (the RT allows you to create Intranets, Extranets etc...) > -----Original Message----- > From: alok [mailto:alok.dube@apara.com] > Sent: Tuesday, 15 April 2003 9:08 PM > To: ppvpn@lyris.nortelnetworks.com > Subject: Re: RD in 2547 bis > > > lets assume there was no RT > > could we filter on RD? > > if we can do that, then why not vice versa? > > ----- Original Message ----- > From: > To: ; > Sent: Tuesday, April 15, 2003 4:31 PM > Subject: RE: RD in 2547 bis > > > > Hi, > > > > The overlapping address problem is that different VPNs that > is provided > > by one operator can have the same private address space. > For instance, > > two VPNs may have several identical addresses. The RD > makes VPN routes > > unique for each VPN. > > > > The RT is used to determine how to import and export the > VPN routes into > > the relevant VRFs. > > > > There are many in mailing list who can answer better and > more pedogical > > then me. > > > > Regards, > > > > Nhat Thanh > > > > -----Original Message----- > > From: alok [mailto:alok.dube@apara.com] > > Sent: den 15 april 2003 12:55 > > To: ppvpn@lyris.nortelnetworks.com > > Subject: Re: RD in 2547 bis > > > > > > what is the "overlapping address problem"? > > > > why isnt RT sufficient to identify the ipv4 prefix uniquely? > > > > why "both"? > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Tuesday, April 15, 2003 4:20 PM > > Subject: RE: RD in 2547 bis > > > > > > > Hi, > > > > > > The purpose of RD is simply resolve the overlapping > address problem > > > in VPN context. > > > > > > regards, > > > > > > /Nhat Thanh > > > > > > -----Original Message----- > > > From: alok [mailto:alok.dube@apara.com] > > > Sent: den 15 april 2003 12:37 > > > To: ppvpn@lyris.nortelnetworks.com > > > Subject: RD in 2547 bis > > > > > > > > > Hi, > > > > > > I know this has been asked time and again, but its still > confusing me > > > > > > what is the purpose of RD ? > > > > > > -rgds > > > Alok > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 08:05: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 IAA24673 for ; Tue, 15 Apr 2003 08:05:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FC7Xq06855 for ; Tue, 15 Apr 2003 08:07:33 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FC7SC03640 for ; Tue, 15 Apr 2003 08:07:29 -0400 (EDT) Message-ID: <030901c30347$1ec9aa40$81c802c0@alok> From: "alok" To: References: <3DB5279B525005439410B5EF3911EE7313B46F@TMS041MB.tcad.telia.se> <01d001c3033f$536ed020$81c802c0@alok> <3E9BF3B3.43CE4CDD@alcatel.be> Subject: Re: RD in 2547 bis Date: Tue, 15 Apr 2003 17:33:58 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: no...its still not clear...... what is the "scalability"? ----- Original Message ----- From: To: alok Cc: Sent: Tuesday, April 15, 2003 5:27 PM Subject: Re: RD in 2547 bis > rfc 2547bis, section 4.3.1 says: > > " > Note that a route can only have one RD, but it can have multiple > Route Targets. In BGP, scalability is improved if one has a single > route with multiple attributes, as opposed to multiple routes. One > could eliminate the Route Target attribute by creating more routes > (i.e., using more RDs), but the scaling properties would be less > favorable. > " > > maybe this answers your question ? > > Jeremy. > -- > +=================== > > alok wrote: > > > > lets assume there was no RT > > > > could we filter on RD? > > > > if we can do that, then why not vice versa? > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Tuesday, April 15, 2003 4:31 PM > > Subject: RE: RD in 2547 bis > > > > > Hi, > > > > > > The overlapping address problem is that different VPNs that is provided > > > by one operator can have the same private address space. For instance, > > > two VPNs may have several identical addresses. The RD makes VPN routes > > > unique for each VPN. > > > > > > The RT is used to determine how to import and export the VPN routes into > > > the relevant VRFs. > > > > > > There are many in mailing list who can answer better and more pedogical > > > then me. > > > > > > Regards, > > > > > > Nhat Thanh > > > > > > -----Original Message----- > > > From: alok [mailto:alok.dube@apara.com] > > > Sent: den 15 april 2003 12:55 > > > To: ppvpn@lyris.nortelnetworks.com > > > Subject: Re: RD in 2547 bis > > > > > > > > > what is the "overlapping address problem"? > > > > > > why isnt RT sufficient to identify the ipv4 prefix uniquely? > > > > > > why "both"? > > > > > > ----- Original Message ----- > > > From: > > > To: ; > > > Sent: Tuesday, April 15, 2003 4:20 PM > > > Subject: RE: RD in 2547 bis > > > > > > > > > > Hi, > > > > > > > > The purpose of RD is simply resolve the overlapping address problem > > > > in VPN context. > > > > > > > > regards, > > > > > > > > /Nhat Thanh > > > > > > > > -----Original Message----- > > > > From: alok [mailto:alok.dube@apara.com] > > > > Sent: den 15 april 2003 12:37 > > > > To: ppvpn@lyris.nortelnetworks.com > > > > Subject: RD in 2547 bis > > > > > > > > > > > > Hi, > > > > > > > > I know this has been asked time and again, but its still confusing me > > > > > > > > what is the purpose of RD ? > > > > > > > > -rgds > > > > Alok > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 08:09: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 IAA24760 for ; Tue, 15 Apr 2003 08:09:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FCBOq10397 for ; Tue, 15 Apr 2003 08:11:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FCBJC13167 for ; Tue, 15 Apr 2003 08:11:19 -0400 (EDT) Message-ID: <3E9BF609.1080406@acm.org> Date: Tue, 15 Apr 2003 08:07:37 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: "'Rick Wilder'" CC: ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft References: <82F679A6A377F84B8F665D8F90D12B8DD8F209@sc-msexch-05.extremenetworks.com> In-Reply-To: <82F679A6A377F84B8F665D8F90D12B8DD8F209@sc-msexch-05.extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit The Laserre/VKompella draft should definitely progress as a working group draft. Its a solid technical contribution with a lot of support behind it. - Matt Olen Stokes wrote: > I would also like to support making this a working group draft. > > Cheers, > Olen > > -----Original Message----- > *From:* Rick Wilder [mailto:rwilder@masergy.com] > *Sent:* Thursday, April 10, 2003 11:20 AM > *To:* ppvpn@nortelnetworks.com > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group draft > > As noted in the minutes, at the San Francisco meeting strong > interest was expressed in pursuing the > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > agreed to finalize that decision only after the WG participants who > weren't there could have a say. > > > > So, if there are opinions that have not been heard, now is the time, > and this list is the place. Let's set a one-week limit to conclude > this issue. > > > > Rick > > > > --------------------------------------------------------------------------------------------------------------------------------------------------- > > From the minutes: > > > > 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. > > > [snipped] > > Marco: asked for show of hands to make this a wG draft. > Strong interest was shown in room. Further discussion on the list. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 08:09:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24813 for ; Tue, 15 Apr 2003 08:09:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FCBtq10851 for ; Tue, 15 Apr 2003 08:11:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FCBqC14549 for ; Tue, 15 Apr 2003 08:11:52 -0400 (EDT) Message-ID: <3E9BF3B3.43CE4CDD@alcatel.be> Date: Tue, 15 Apr 2003 13:57:39 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: alok CC: ppvpn@lyris.nortelnetworks.com Subject: Re: RD in 2547 bis References: <3DB5279B525005439410B5EF3911EE7313B46F@TMS041MB.tcad.telia.se> <01d001c3033f$536ed020$81c802c0@alok> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/15/2003 13:57:40, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/15/2003 13:57:41, Serialize complete at 04/15/2003 13:57:41 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@lyris.nortelnetworks.com X-SMTP-PEER-INFO: alc239.alcatel.be [195.207.101.239] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit rfc 2547bis, section 4.3.1 says: " Note that a route can only have one RD, but it can have multiple Route Targets. In BGP, scalability is improved if one has a single route with multiple attributes, as opposed to multiple routes. One could eliminate the Route Target attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable. " maybe this answers your question ? Jeremy. -- +=================== alok wrote: > > lets assume there was no RT > > could we filter on RD? > > if we can do that, then why not vice versa? > > ----- Original Message ----- > From: > To: ; > Sent: Tuesday, April 15, 2003 4:31 PM > Subject: RE: RD in 2547 bis > > > Hi, > > > > The overlapping address problem is that different VPNs that is provided > > by one operator can have the same private address space. For instance, > > two VPNs may have several identical addresses. The RD makes VPN routes > > unique for each VPN. > > > > The RT is used to determine how to import and export the VPN routes into > > the relevant VRFs. > > > > There are many in mailing list who can answer better and more pedogical > > then me. > > > > Regards, > > > > Nhat Thanh > > > > -----Original Message----- > > From: alok [mailto:alok.dube@apara.com] > > Sent: den 15 april 2003 12:55 > > To: ppvpn@lyris.nortelnetworks.com > > Subject: Re: RD in 2547 bis > > > > > > what is the "overlapping address problem"? > > > > why isnt RT sufficient to identify the ipv4 prefix uniquely? > > > > why "both"? > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Tuesday, April 15, 2003 4:20 PM > > Subject: RE: RD in 2547 bis > > > > > > > Hi, > > > > > > The purpose of RD is simply resolve the overlapping address problem > > > in VPN context. > > > > > > regards, > > > > > > /Nhat Thanh > > > > > > -----Original Message----- > > > From: alok [mailto:alok.dube@apara.com] > > > Sent: den 15 april 2003 12:37 > > > To: ppvpn@lyris.nortelnetworks.com > > > Subject: RD in 2547 bis > > > > > > > > > Hi, > > > > > > I know this has been asked time and again, but its still confusing me > > > > > > what is the purpose of RD ? > > > > > > -rgds > > > Alok > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 08:11:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24919 for ; Tue, 15 Apr 2003 08:11:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FCDlq12698 for ; Tue, 15 Apr 2003 08:13:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FCDhC17875 for ; Tue, 15 Apr 2003 08:13:43 -0400 (EDT) Message-ID: <02df01c30346$817c31e0$81c802c0@alok> From: "alok" To: References: <11D2868F916DD411982D00508B694F431CE7CD60@syd-xch2.cisco.com> Subject: Re: RD in 2547 bis Date: Tue, 15 Apr 2003 17:29:34 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: hi, am still confused.... I would like to know 1. can RD be used to filter ...if not why.... 2. i say a VPNv4 route = IPv4+RT ... why not? -rgds Alok ----- Original Message ----- From: Apcar, Jeff To: alok ; Sent: Tuesday, April 15, 2003 5:01 PM Subject: RE: RD in 2547 bis > In 2547bis the mechansim to pass VPN addresses with between PE routers is > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but it is not > interested in what VPN these addresses belong to. YOu need the RD to make > the VPN addresses unique to MP-BGP, and consequently to the SP domain. For > example, suppose you had VPN RED and VPN GREEN on different PE-routers and > they both originated an address from RFC1918, like 10.2.1.0/24, then if they > were not uniquely identified by an RD, when the two 10.2.1.0/24 addresses > arrived at the same remote PE-router, BGP would simply do its best path > selection algorithm on the two addresses and only pick one. Hence you would > lose the other. If they are both unique with an RD then it is called a VPNv4 > address. BGP will see them as unique and the MP-BGP peer on the remote > PE-router would accept both. Then to decide which VPN to place the received > address in we use the RT, which is an extended community attribute. > > You need the RD to make the VPN addresses to unique MP-BGP you need the RT > to select which VPN to include the address (the RT allows you to create > Intranets, Extranets etc...) > > > -----Original Message----- > > From: alok [mailto:alok.dube@apara.com] > > Sent: Tuesday, 15 April 2003 9:08 PM > > To: ppvpn@lyris.nortelnetworks.com > > Subject: Re: RD in 2547 bis > > > > > > lets assume there was no RT > > > > could we filter on RD? > > > > if we can do that, then why not vice versa? > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Tuesday, April 15, 2003 4:31 PM > > Subject: RE: RD in 2547 bis > > > > > > > Hi, > > > > > > The overlapping address problem is that different VPNs that > > is provided > > > by one operator can have the same private address space. > > For instance, > > > two VPNs may have several identical addresses. The RD > > makes VPN routes > > > unique for each VPN. > > > > > > The RT is used to determine how to import and export the > > VPN routes into > > > the relevant VRFs. > > > > > > There are many in mailing list who can answer better and > > more pedogical > > > then me. > > > > > > Regards, > > > > > > Nhat Thanh > > > > > > -----Original Message----- > > > From: alok [mailto:alok.dube@apara.com] > > > Sent: den 15 april 2003 12:55 > > > To: ppvpn@lyris.nortelnetworks.com > > > Subject: Re: RD in 2547 bis > > > > > > > > > what is the "overlapping address problem"? > > > > > > why isnt RT sufficient to identify the ipv4 prefix uniquely? > > > > > > why "both"? > > > > > > ----- Original Message ----- > > > From: > > > To: ; > > > Sent: Tuesday, April 15, 2003 4:20 PM > > > Subject: RE: RD in 2547 bis > > > > > > > > > > Hi, > > > > > > > > The purpose of RD is simply resolve the overlapping > > address problem > > > > in VPN context. > > > > > > > > regards, > > > > > > > > /Nhat Thanh > > > > > > > > -----Original Message----- > > > > From: alok [mailto:alok.dube@apara.com] > > > > Sent: den 15 april 2003 12:37 > > > > To: ppvpn@lyris.nortelnetworks.com > > > > Subject: RD in 2547 bis > > > > > > > > > > > > Hi, > > > > > > > > I know this has been asked time and again, but its still > > confusing me > > > > > > > > what is the purpose of RD ? > > > > > > > > -rgds > > > > Alok > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 09:30:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26931 for ; Tue, 15 Apr 2003 09:30:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FDWTq24138 for ; Tue, 15 Apr 2003 09:32:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FDWPC16600 for ; Tue, 15 Apr 2003 09:32:26 -0400 (EDT) Message-ID: <20030415132808.42391.qmail@web41806.mail.yahoo.com> Date: Tue, 15 Apr 2003 14:28:08 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: RE: RD in 2547 bis To: "Apcar, Jeff" , alok , ppvpn@lyris.nortelnetworks.com In-Reply-To: <11D2868F916DD411982D00508B694F431CE7CD60@syd-xch2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41806.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web41806.mail.yahoo.com [66.218.93.140] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Jeff, > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but it is not > interested in what VPN these addresses belong to. YOu need the RD to make > the VPN addresses unique to MP-BGP, and consequently to the SP domain. Very Right. > > You need the RD to make the VPN addresses to unique MP-BGP you need the RT > to select which VPN to include the address (the RT allows you to create Instead of using the RT why cant RD work out as the RT. One can decide which route goes into which VRF by looking at the RD rather than at the RT. I guess this is the confusion which Mr. Alok has. JS __________________________________________________ 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 Tue Apr 15 09:39: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 JAA27183 for ; Tue, 15 Apr 2003 09:39:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FDfMq00671 for ; Tue, 15 Apr 2003 09:41:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FDfJC28210 for ; Tue, 15 Apr 2003 09:41:19 -0400 (EDT) Message-ID: <04c201c30354$94ace1c0$81c802c0@alok> From: "alok" To: References: <200304151412.h3FECW329323@mail.apara.com> Subject: Re: Date: Tue, 15 Apr 2003 19:10:19 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: then what does "VPN of origin attribute" indicate? ----- Original Message ----- From: Sent: Tuesday, April 15, 2003 7:42 PM > Microsoft Mail Internet Headers Version 2.0 > X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 > content-class: urn:content-classes:message > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > Subject: RE: > Date: Tue, 15 Apr 2003 14:36:04 +0100 > Message-ID: > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > Thread-Index: AcMDUO31DVnmqpEkTb+89O6PCkAKYAAAH1Jg > From: > To: > Return-Path: richard.spencer@bt.com > X-OriginalArrivalTime: 15 Apr 2003 13:36:05.0242 (UTC) FILETIME=[F6B03DA0:01C30353] > > Alok, > > The IPv4 address + RD =3D VPNv4 address and is carried in MP-BGP as a = > 96-bit route prefix.=20 > > The RT is not appended to the IPv4 address, instead it is carried in an = > extended BGP community with a value of 2 for the high-order 16 bits = > meaning MPLS VPN RT. > > For the VPN mechanism to work: > > 1. The customer address must be made globally unique (to support = > overlapping addresses) so must have a 64-bit value (lets call it "Value = > X") prepended to it. > > 2. There must be a way of identifying which VPN a route belongs to.=20 > > Now, there is nothing stopping someone writing an implementation which = > uses Value-X for filtering to determine which VPN the route belongs to = > instead of using an extended BGP community. However, because there is a = > 1:1 mapping between the route and the VPN, the route could only be = > imported into one VPN and therefore each customer could only be a = > member of one VPN. > > Regards, > > Richard > > > > > -----Original Message----- > From: alok [mailto:alok.dube@apara.com] > Sent: 15 April 2003 14:17 > To: Spencer,R,Richard,XGH5 R > Subject: Re:=20 > > > i want to know why not.. > im not questioning what was made...im asking about what is "being = > made"... > > -rgds > Alok > ----- Original Message ----- > From: > Sent: Tuesday, April 15, 2003 7:05 PM > > > > Microsoft Mail Internet Headers Version 2.0 > > X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 > > content-class: urn:content-classes:message > > MIME-Version: 1.0 > > Content-Type: text/plain; > > charset=3D"iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > Subject: RE: RD in 2547 bis > > Date: Tue, 15 Apr 2003 13:59:07 +0100 > > Message-ID: > > > X-MS-Has-Attach: > > X-MS-TNEF-Correlator: > > Thread-Topic: RD in 2547 bis > > Thread-Index: AcMDSI6WQTL6q5dkQtaxcNV/MIBniwAAZgpA > > From: > > To: , > > > > Return-Path: richard.spencer@bt.com > > X-OriginalArrivalTime: 15 Apr 2003 12:59:08.0312 (UTC) > FILETIME=3D[CD4B9180:01C3034E] > > > > Alok > > > > 1. The ONLY purpose of the RD is to transform non-unique 32-bit =3D > > customer IPv4 addresses into unique 96-bit VPNv4 addresses. The RD = > =3D > > COULD be used to filter (i.e. be used as a VPN identifier) but this = > =3D > > would not allow support for customers belonging to multiple VPNs. > > > > The ONLY purpose of the RT is to indicate which VPN a customer = > address =3D > > belongs to. Any number of RT's can be attached to a single VPNv4 = > route =3D > > to identify multiple VPN memberships but ONLY 1 RD can be attached to = > a =3D > > customer route. > > > > 2. A VPNv4 route DOES NOT =3D3D IPv4 + RT. A VPNv4 route =3D3D IPv4 + = > RD. > > > > If you are still confused the mechanisms described in 2547 are well = > =3D > > documented within the IETF pages and elsewhere on the net. > > > > Richard > > > > -----Original Message----- > > From: alok [mailto:alok.dube@apara.com] > > Sent: 15 April 2003 13:00 > > To: ppvpn@lyris.nortelnetworks.com > > Subject: Re: RD in 2547 bis > > > > > > hi, > > > > am still confused.... > > > > I would like to know > > 1. can RD be used to filter ...if not why.... > > 2. i say a VPNv4 route =3D3D IPv4+RT ... why not? > > > > -rgds > > Alok > > ----- Original Message ----- > > From: Apcar, Jeff > > To: alok ; > > Sent: Tuesday, April 15, 2003 5:01 PM > > Subject: RE: RD in 2547 bis > > > > > > > In 2547bis the mechansim to pass VPN addresses with between PE =3D > > routers is > > > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but = > it =3D > > is > > not > > > interested in what VPN these addresses belong to. YOu need the RD = > to =3D > > make > > > the VPN addresses unique to MP-BGP, and consequently to the SP =3D > > domain. For > > > example, suppose you had VPN RED and VPN GREEN on different =3D > > PE-routers and > > > they both originated an address from RFC1918, like 10.2.1.0/24, = > then =3D > > if > > they > > > were not uniquely identified by an RD, when the two 10.2.1.0/24 =3D > > addresses > > > arrived at the same remote PE-router, BGP would simply do its best = > =3D > > path > > > selection algorithm on the two addresses and only pick one. Hence = > you > > would > > > lose the other. If they are both unique with an RD then it is = > called =3D > > a > > VPNv4 > > > address. BGP will see them as unique and the MP-BGP peer on the =3D > > remote > > > PE-router would accept both. Then to decide which VPN to place the > > received > > > address in we use the RT, which is an extended community attribute. > > > > > > You need the RD to make the VPN addresses to unique MP-BGP you need = > =3D > > the RT > > > to select which VPN to include the address (the RT allows you to = > =3D > > create > > > Intranets, Extranets etc...) > > > > > > > -----Original Message----- > > > > From: alok [mailto:alok.dube@apara.com] > > > > Sent: Tuesday, 15 April 2003 9:08 PM > > > > To: ppvpn@lyris.nortelnetworks.com > > > > Subject: Re: RD in 2547 bis > > > > > > > > > > > > lets assume there was no RT > > > > > > > > could we filter on RD? > > > > > > > > if we can do that, then why not vice versa? > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: ; > > > > Sent: Tuesday, April 15, 2003 4:31 PM > > > > Subject: RE: RD in 2547 bis > > > > > > > > > > > > > Hi, > > > > > > > > > > The overlapping address problem is that different VPNs that > > > > is provided > > > > > by one operator can have the same private address space. > > > > For instance, > > > > > two VPNs may have several identical addresses. The RD > > > > makes VPN routes > > > > > unique for each VPN. > > > > > > > > > > The RT is used to determine how to import and export the > > > > VPN routes into > > > > > the relevant VRFs. > > > > > > > > > > There are many in mailing list who can answer better and > > > > more pedogical > > > > > then me. > > > > > > > > > > Regards, > > > > > > > > > > Nhat Thanh > > > > > > > > > > -----Original Message----- > > > > > From: alok [mailto:alok.dube@apara.com] > > > > > Sent: den 15 april 2003 12:55 > > > > > To: ppvpn@lyris.nortelnetworks.com > > > > > Subject: Re: RD in 2547 bis > > > > > > > > > > > > > > > what is the "overlapping address problem"? > > > > > > > > > > why isnt RT sufficient to identify the ipv4 prefix uniquely? > > > > > > > > > > why "both"? > > > > > > > > > > ----- Original Message ----- > > > > > From: > > > > > To: ; > > > > > Sent: Tuesday, April 15, 2003 4:20 PM > > > > > Subject: RE: RD in 2547 bis > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > The purpose of RD is simply resolve the overlapping > > > > address problem > > > > > > in VPN context. > > > > > > > > > > > > regards, > > > > > > > > > > > > /Nhat Thanh > > > > > > > > > > > > -----Original Message----- > > > > > > From: alok [mailto:alok.dube@apara.com] > > > > > > Sent: den 15 april 2003 12:37 > > > > > > To: ppvpn@lyris.nortelnetworks.com > > > > > > Subject: RD in 2547 bis > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I know this has been asked time and again, but its still > > > > confusing me > > > > > > > > > > > > what is the purpose of RD ? > > > > > > > > > > > > -rgds > > > > > > Alok > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 09:40: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 JAA27211 for ; Tue, 15 Apr 2003 09:40:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FDg7q01446 for ; Tue, 15 Apr 2003 09:42:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FDg2C29195 for ; Tue, 15 Apr 2003 09:42:03 -0400 (EDT) Message-ID: <04a701c30354$43f0da20$81c802c0@alok> From: "alok" To: "John Smith" , "Apcar, Jeff" , References: <20030415132808.42391.qmail@web41806.mail.yahoo.com> Subject: Re: RD in 2547 bis Date: Tue, 15 Apr 2003 19:08:03 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Yes, thanks for articulating it John, Thats my confusion. -rgds Alok ----- Original Message ----- From: John Smith To: Apcar, Jeff ; alok ; Sent: Tuesday, April 15, 2003 6:58 PM Subject: RE: RD in 2547 bis > Jeff, > > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but it is not > > interested in what VPN these addresses belong to. YOu need the RD to make > > the VPN addresses unique to MP-BGP, and consequently to the SP domain. > > Very Right. > > > > > You need the RD to make the VPN addresses to unique MP-BGP you need the RT > > to select which VPN to include the address (the RT allows you to create > > Instead of using the RT why cant RD work out as the RT. One can decide which route goes > into which VRF by looking at the RD rather than at the RT. > > I guess this is the confusion which Mr. Alok has. > > JS > > > __________________________________________________ > 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 Tue Apr 15 10:34:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29727 for ; Tue, 15 Apr 2003 10:34:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FEaYq26755 for ; Tue, 15 Apr 2003 10:36:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FEaUC25793 for ; Tue, 15 Apr 2003 10:36:31 -0400 (EDT) Subject: Re: progressing docs To: "Marco Carugi" , "'Rick Wilder'" Cc: ppvpn@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: Alain.Vedrenne@equant.com Date: Tue, 15 Apr 2003 16:32:13 +0200 X-MIMETrack: Serialize by Router on Nice1/Nice/SITA/WW(Release 5.0.9a |January 7, 2002) at 04/15/2003 04:32:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SMTP-HELO: mx1.sita.int X-SMTP-MAIL-FROM: Alain.Vedrenne@equant.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: mx1.sita.int [57.250.224.237] X-LYRIS-Message-Id: I support GVPLS (draft-radoaca-ppvpn-gvpls-01.txt) as working document. It is a generic VPLS model that is scalable to interconnect customers LAN switches and it supports both BGP and LDP signaling. For a service provider such as Equant operating a large BGP/MPLS VPN network for IP VPN it makes a lot of sense to use BGP both as a discovery and signaling protocol for VPLS. That is why I also support draft-kompella-ppvpn-vpls-01 as WG document. It is a clear and simple solution that answers global SP requirements wanting primarily to offer VPLS for Customers routers interconnection. Note draft-lasserre-vkompella-ppvpn-vpls is a good solution also when used with BGP for autodiscovery and single-sided LDP for signaling. Several SP already mentioned their interest in using BGP signaling for VPLS so implementations should leave the door open to both LDP and BGP signaling. Alain Vedrenne Equant "amita" 15/04/2003 06:08 To: , "Vasile Radoaca" cc: "Marco Carugi" , "'Rick Wilder'" , bcc: Subject: Re: progressing docs I would like to support draft-radoaca-ppvpn-gvpls-01.txt as a WG document for the following reasons : 1 . It incorporates non-distributed as well as distributed model , very flexible ,hence can address architectural concerns for wider variety of vendors who would want to support VPLS. 2. Supports BGP and LDP signaling. 3. Facilitates multi-vendor interoperability. 4. Can support unified provisioning model. Though some issues ,it provides good text to start discussing as a WG doc. thanks, -Amita ----- Original Message ----- From: "Eric Rosen" To: "Vasile Radoaca" Cc: "Marco Carugi" ; "'Rick Wilder'" ; Sent: Monday, April 14, 2003 10:33 AM Subject: Re: progressing docs > > > draft-radoaca-ppvpn-gvpls-01.txt > > I support accepting this as a WG document, even though, like any other WG > document, it may have a number of open issues and/or flaws. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 11:04:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00613 for ; Tue, 15 Apr 2003 11:03:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FF66q14711 for ; Tue, 15 Apr 2003 11:06:06 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FF60C27216 for ; Tue, 15 Apr 2003 11:06:01 -0400 (EDT) Message-ID: <9D42C6E086250248810DCADA39CE7EFC97240D@nimbus> From: John Drake To: "'Rahul Aggarwal'" , ppvpn@nortelnetworks.com Subject: RE: Regarding progressing VPLS docs Date: Tue, 15 Apr 2003 08:00:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: lightwave.chromisys.com X-SMTP-MAIL-FROM: jdrake@calient.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lightwave.chromisys.com [63.102.55.206] X-LYRIS-Message-Id: I think Rahul's proposal is sensible > -----Original Message----- > From: Rahul Aggarwal [mailto:rahul@redback.com] > Sent: Monday, April 14, 2003 4:35 PM > To: ppvpn@nortelnetworks.com > Subject: Regarding progressing VPLS docs > > > > Hi Marco and Rick, > > I would like to add my support for making both: > > draft-lasserre-vkompella-ppvpn-vpls-04.txt > draft-kompella-ppvpn-vpls-01.txt > > as WG docs with the caveat that the common parts should not be > repeated. draft-lasserre may be a good place to keep the common > portion. In particular the data plane description that is > common to these > specs can be left in draft-lasserre and pulled out of draft-kompella. > > Its possible to have a never ending discussion on the pros and cons of > each. The bottomline is that LDP signaling + protocol X > auto-discovery or > BGP signaling + BGP auto-discovery, both have their own > applicability. If > down the road we figure out that one of these solutions doesn't have > deployment traction, the respective doc doesn't have to be > moved to RFC > status. > > Thanks, > rahul > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 11:08:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00794 for ; Tue, 15 Apr 2003 11:08:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FFAnq18545 for ; Tue, 15 Apr 2003 11:10:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FFAiC08857 for ; Tue, 15 Apr 2003 11:10:45 -0400 (EDT) Message-ID: <9D42C6E086250248810DCADA39CE7EFC97240E@nimbus> From: John Drake To: "'erosen@cisco.com'" , ppvpn@nortelnetworks.com Subject: RE: On the subject of WG docs ... Date: Tue, 15 Apr 2003 08:03:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: lightwave.chromisys.com X-SMTP-MAIL-FROM: jdrake@calient.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lightwave.chromisys.com [63.102.55.206] X-LYRIS-Message-Id: I'd like to support this > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, April 14, 2003 10:13 AM > To: ppvpn@nortelnetworks.com > Subject: On the subject of WG docs ... > > > If everybody is pitching their docs to become WG docs, I > might as well join > the club and make a pitch for draft-rosen-ppvpn-l2-signaling-02.txt. > > - The part of that doc that specifies LDP-based signaling > extensions has > been incorporated into the PWE3 WG draft > draft-ietf-pwe3-control-protocol- > 02.txt. So my plan would be to recast the document > slightly into a > specification of how to use PWE3 signaling to support > the variety of > provisioning models which are being considered by this WG. > > - There is a draft in the l2tpext group > (draft-luo-l2tpext-l2vpn-signaling) > which applies the same concepts to L2TP-based > signaling. While that > document has a number of detailed differences, I would > expect these to get > resolved into a single PPVPN document. > > - Support for these concepts has been expressed by a number > of people who > are active in this WG. > > - The main opposition to this proposal, one V. Kompella, now > seems somewhat > more tolerant of it, if one might judge from a recent thread. > > There is still some ongoing argument about the > properties, syntax, and > semantics, which the"generalized identifiers" of this draft > need to have, > but this draft seems to me like a good basis for future work. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 11:16:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01030 for ; Tue, 15 Apr 2003 11:16:09 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FFIFq22808 for ; Tue, 15 Apr 2003 11:18:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FFI9C25924 for ; Tue, 15 Apr 2003 11:18:10 -0400 (EDT) Message-ID: <065e01c30361$b2c26060$81c802c0@alok> From: "alok" To: "John Smith" , "Apcar, Jeff" , Subject: Re: RD in 2547 bis Date: Tue, 15 Apr 2003 20:44:13 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: ...and incase RD is not scalable, why not just RT and no RD? -rgds Alok ----- Original Message ----- From: alok To: John Smith ; Apcar, Jeff ; Sent: Tuesday, April 15, 2003 7:08 PM Subject: Re: RD in 2547 bis > Yes, > > thanks for articulating it John, > > Thats my confusion. > > -rgds > Alok > ----- Original Message ----- > From: John Smith > To: Apcar, Jeff ; alok ; > > Sent: Tuesday, April 15, 2003 6:58 PM > Subject: RE: RD in 2547 bis > > > > Jeff, > > > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but it is > not > > > interested in what VPN these addresses belong to. YOu need the RD to > make > > > the VPN addresses unique to MP-BGP, and consequently to the SP domain. > > > > Very Right. > > > > > > > > You need the RD to make the VPN addresses to unique MP-BGP you need the > RT > > > to select which VPN to include the address (the RT allows you to create > > > > Instead of using the RT why cant RD work out as the RT. One can decide > which route goes > > into which VRF by looking at the RD rather than at the RT. > > > > I guess this is the confusion which Mr. Alok has. > > > > JS > > > > > > __________________________________________________ > > 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 Tue Apr 15 11:29: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 LAA01401 for ; Tue, 15 Apr 2003 11:29:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FFV7q27621 for ; Tue, 15 Apr 2003 11:31:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FFV2C20421 for ; Tue, 15 Apr 2003 11:31:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415065310.01d2adb8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 08:23:10 -0700 To: Du Wenhua , Rick Wilder From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDC00ILUV8YR6@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01401 At 06:47 AM 4/15/2003 +0800, Du Wenhua wrote: >Hi,Rick Wilder, > I support it to become a WG draft. > >BTW, one qustion as follow: >In setction 11 of the draft-lasserre-vkompella-ppvpn-vpls-04.txt, it say: > >* 11. Hierarchical VPLS model using Ethernet Access Network > ..... >* One approach of tunneling a customer?s Ethernet traffic via an >* Ethernet access network is to add an additional VLAN tag to the >* customer?s data (either tagged or untagged). The additional tag is >* referred to as Provider?s VLAN (P-VLAN). Inside the provider?s >* network each P-VLAN designates a customer or more specifically a VPLS >** instance for that customer. Therefore, there is a one to one >** correspondence between a P-VLAN and a VPLS instance. > > In my option, the last sentece in above is not true. There is also a > many-to-one correspondence between a P-VLAN and a VPLS instance, not only > a one-to-one. i.e, a customer with P-VLAN 3 and another customer with > P-VLAN 4 belong to the same VPLS. > Muchmore, to PE-rs the ethernet port is not a traditional standard > port. When flooding, PE-rs need to send more than one copy in one > ehternet port, because there are serveral custumers in one ethernet port > each have different P-VLAN. If two customer share the same VPLS instance, then you would use a single P-VLAN for both of those customers - e.g., there is one-to-one mapping between P-VLAN and VPLS within a given access domain (different QinQ domain). If you're talking about different access domain, then there can be different P-VLANs maps into the same VPLS and if that's your comment, then I would agree and we can clarify the text. -Ali > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua > > > > > > >As noted in the minutes, at the San Francisco meeting strong interest > >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a > >working group draft. We agreed to finalize that decision only after the > >WG participants who weren't there could have a say. > > > >So, if there are opinions that have not been heard, now is the time, and > >this list is the place. Let's set a one-week limit to conclude this > >issue. > > > >Rick > > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------ > >--- > >From the minutes: > > > >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. > > > >[snipped] > > Marco: asked for show of hands to make this a wG draft. > >Strong interest was shown in room. Further discussion on the list. > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 11:38:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01673 for ; Tue, 15 Apr 2003 11:38:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FFeGq02078 for ; Tue, 15 Apr 2003 11:40:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FFeBC00875 for ; Tue, 15 Apr 2003 11:40:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415071905.01bc2200@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 08:10:25 -0700 To: , "'Ali Sajassi'" , From: Ali Sajassi Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt In-Reply-To: <000b01c302b5$845dc5e0$021ea8c0@HSHAH700> References: <4.3.2.7.2.20030414101949.01ca51f8@airborne.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_164628773==_.ALT" X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: --=====================_164628773==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >Not for the steady state. If you look at the IEEE 802.1D standards it says: > >"NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or >duplicate frames. >Where Bridges in a Bridged LAN are capable of connecting the individual >MACs in such a way that >multiple paths between any source station -destination station pairs >exist,the operation of a protocol is required to ensure that a single path >is used. >NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during >normal operation." > >It clearly states that during normal operation misordering DOES NOT OCCUR !! > > > >[himanshu shah] Despite what it says, today in normal bridges, broadcast >(unknown unicast frame is a flood and hence it is a broadcast) and unicast >frames between two stations may get out of order for the reasons I >described before; irrespective of the state of the network. Again, I >invite you to site an example where a miniscule possibility of such an >out-of-order spells disaster for a protocol (at session initiation time). So, you're acknowledging that it is in violation of IEEE standards but you're saying that it is not a big deal because some of the existing switches currently do that and so it is O.K. to use different paths for (unknown and known unicast) within the network. There are holes in this argument: a) bridges come in all different price range and if some low-cost bridges don't adhere to IEEE standards that's a different thing b) what is important is the differential delay between the two paths. So, inside a bridge, the differential delay can be in order of micro-seconds or milliseconds; whereas, in the network the differential delay path can be much larger (function of network and path congestion). And the larger the delay path, the bigger the issue. c) now the re-ordering is a function of not only network availability (failure) but also a function of network congestion (which is more frequent) Also although IP protocols are not susceptible to packet re-ordering, there are legacy protocols (e.g., NetBEUI) that are susceptible to this re-ordering. We can take this discussion to IEEE to find out what is the tolerable differential delay in such cases. >No !!! traffic doesn't get re-order when a single PW is used in case of >ECMP. It can get re-order when there are multiple PWs are involved for the >same flow (as in the case of GVPLS). >[himanshu shah] If one was to do ECMP using the bottom most label, then it >is true that out-of-order would not occur for a single PW. However, is it >mandated that ECMP must be done on bottom-most label (i.e. PW label which >technically could be below several labels)? Lets for a moment accept that >such out-of-order would occur for 2 PWs. I would like to see an example >where a rare case of mis-order between broadcast-path frame and >unicast-path frame. There are currently deployed routers that perform load balancing based on PWs. >>HS> The point is out-of-order can happen in GVPLS in very rare >>HS> circumstances. If you look at RSTP, out-of-order is mentioned >>HS> as a possibility during topo changes as an acceptable risk against >>HS> greater benefits. I suppose one can apply same logic here. >As mentioned before, IEEE 802.1D standards allows for possibility of >reordering in case of topology changes but not in steady state operation. >[himanshu shah] topo changes in small bridged network as compared to topo >changes in big-I network are at quite different scale. If one was to >compare the number of out-of-order packets due to topo-changes in big-I >network to out-of-order packets due to 2 PW, one would wonder where the >real problem is. Topology changes in SP core as well as SP access networks are function of link/node failure which is tied up with end-to-end availability numbers; however, intermittent path/node congestion in steady state is lot more frequent than the link/node failure. -Ali --=====================_164628773==_.ALT Content-Type: text/html; charset="us-ascii"
Not for the steady state. If you look at the IEEE 802.1D standards it says:

"NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or duplicate frames.
Where Bridges in a Bridged LAN are capable of connecting the individual MACs in such a way that
multiple paths between any source station -destination station pairs exist,the operation of a protocol is required to ensure that a single path is used.
NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during normal operation."
It clearly states that during normal operation misordering DOES NOT OCCUR !!



[himanshu shah] Despite what it says, today in normal bridges, broadcast (unknown unicast frame is a flood and hence it is a broadcast) and unicast frames between two stations may get out of order for the reasons I described before; irrespective of the state of the network. Again, I invite you to site an example where a miniscule possibility of such an out-of-order spells disaster for a protocol (at session initiation time).

So, you're acknowledging that it is in violation of IEEE standards but you're saying that it is not a big deal because some of the existing switches currently do that and so it is O.K. to use different paths for (unknown and known unicast) within the network. There are holes in this argument:
a) bridges come in all different price range and if some low-cost bridges don't adhere to IEEE standards that's a different thing
b) what is important is the differential delay between the two paths. So, inside a bridge, the differential delay can be in order of micro-seconds or milliseconds; whereas, in the network the differential delay path can be much larger (function of network and path congestion). And the larger the delay path, the bigger the issue.
c) now the re-ordering is a function of not only network availability (failure) but also a function of network congestion (which is more frequent)

Also although IP protocols are not susceptible to packet re-ordering, there are legacy protocols (e.g., NetBEUI) that are susceptible to this re-ordering. We can take this discussion to IEEE to find out what is the tolerable differential delay in such cases.


No !!! traffic doesn't get re-order when a single PW is used in case of ECMP. It can get re-order when there are multiple PWs are involved for the same flow  (as in the case of GVPLS).
[himanshu shah] If one was to do ECMP using the bottom most label, then it is true that out-of-order would not occur for a single PW. However, is it mandated that ECMP must be done on bottom-most label (i.e. PW label which technically could be below several labels)? Lets for a moment accept that such out-of-order would occur for 2 PWs. I would like to see an example where a rare case of mis-order between broadcast-path frame and unicast-path frame.

There are currently deployed routers that perform load balancing based on PWs.

HS> The point is out-of-order can happen in GVPLS in very rare
HS> circumstances.  If you look at RSTP, out-of-order is mentioned
HS> as a possibility during topo changes as an acceptable risk against
HS> greater benefits. I suppose one can apply same logic here.
As mentioned before, IEEE 802.1D standards allows for possibility of reordering in case of topology changes but not in steady state operation.
[himanshu shah] topo changes in small bridged network as compared to topo changes in big-I network are at quite different scale. If one was to compare the number of out-of-order packets due to topo-changes in big-I network to out-of-order packets due to 2 PW, one would wonder where the real problem is.

Topology changes in SP core as well as SP access networks are function of link/node failure which is tied up with end-to-end availability numbers; however, intermittent path/node congestion in steady state is lot more frequent than the link/node failure.

-Ali

--=====================_164628773==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 12:04:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02522 for ; Tue, 15 Apr 2003 12:04:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FG6cq00090 for ; Tue, 15 Apr 2003 12:06:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FG6ZC04385 for ; Tue, 15 Apr 2003 12:06:35 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6ADC@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Ali Sajassi'" , Du Wenhua , Rick Wilder Cc: ppvpn@nortelnetworks.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Tue, 15 Apr 2003 12:02:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30368.717812C4" 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_01C30368.717812C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable my comments below. Vasile -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com]=20 Sent: Tuesday, April 15, 2003 11:23 AM To: Du Wenhua; Rick Wilder Cc: ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft At 06:47 AM 4/15/2003 +0800, Du Wenhua wrote: >Hi,Rick Wilder, > I support it to become a WG draft. > >BTW, one qustion as follow: >In setction 11 of the draft-lasserre-vkompella-ppvpn-vpls-04.txt, it=20 >say: > >* 11. Hierarchical VPLS model using Ethernet Access Network > ..... >* One approach of tunneling a customer?s Ethernet traffic via an >* Ethernet access network is to add an additional VLAN tag to the >* customer?s data (either tagged or untagged). The additional tag is >* referred to as Provider?s VLAN (P-VLAN). Inside the provider?s >* network each P-VLAN designates a customer or more specifically a = VPLS >** instance for that customer. Therefore, there is a one to one >** correspondence between a P-VLAN and a VPLS instance. > > In my option, the last sentece in above is not true. There is also = > a > many-to-one correspondence between a P-VLAN and a VPLS instance, not = only=20 > a one-to-one. i.e, a customer with P-VLAN 3 and another customer = with=20 > P-VLAN 4 belong to the same VPLS. > Muchmore, to PE-rs the ethernet port is not a traditional = standard=20 > port. When flooding, PE-rs need to send more than one copy in one=20 > ehternet port, because there are serveral custumers in one ethernet = port=20 > each have different P-VLAN. If two customer share the same VPLS instance, then you would use a = single=20 P-VLAN for both of those customers - e.g., there is one-to-one mapping=20 between P-VLAN and VPLS within a given access domain (different QinQ=20 domain). If you're talking about different access domain, then there = can be=20 different P-VLANs maps into the same VPLS and if that's your comment, = then=20 I would agree and we can clarify the text. >> So you are saying that in the same Q-in-Q access domain P-VLAN is = one >> to one mapping with VPLS instance? If this you are talking then I do = have >> a problem. In general, the requirement is to support Many P-VLANs = per VPLS >> on the same access domain or access domain& VPLS-MPLS. Vasile -Ali > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua > > > > > > >As noted in the minutes, at the San Francisco meeting strong = interest=20 > >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls"=20 > >as a working group draft. We agreed to finalize that decision only=20 > >after the WG participants who weren't there could have a say. > > > >So, if there are opinions that have not been heard, now is the time, = > >and this list is the place. Let's set a one-week limit to conclude=20 > >this issue. > > > >Rick > > > = >--------------------------------------------------------------------- > >--- > = >-----------------------------------------------------------------------= - > >--- > >From the minutes: > > > >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. > > > >[snipped] > > Marco: asked for show of hands to make this a wG draft. Strong=20 > >interest was shown in room. Further discussion on the list. > > > > ------_=_NextPart_001_01C30368.717812C4 Content-Type: text/html; charset="iso-8859-1" RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft

my comments below.

Vasile

-----Original Message-----
From: Ali Sajassi [mailto:sajassi@cisco.com]
Sent: Tuesday, April 15, 2003 11:23 AM
To: Du Wenhua; Rick Wilder
Cc: ppvpn@nortelnetworks.com
Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft


At 06:47 AM 4/15/2003 +0800, Du Wenhua wrote:
>Hi,Rick Wilder,
>    I support it to become a WG draft.
>
>BTW, one qustion as follow:
>In setction 11 of the draft-lasserre-vkompella-ppvpn-vpls-04.txt, it
>say:
>
>*   11.  Hierarchical VPLS model using Ethernet Access Network
>      .....
>*   One approach of tunneling a customer?s Ethernet traffic via an
>*   Ethernet access network is to add an additional VLAN tag to the
>*   customer?s data (either tagged or untagged). The additional tag is
>*   referred to as Provider?s VLAN (P-VLAN). Inside the provider?s
>*   network each P-VLAN designates a customer or more specifically a VPLS
>**   instance for that customer. Therefore, there is a one to one
>**   correspondence between a P-VLAN and a VPLS instance.
>
>    In my option, the last sentece in above is not true. There is also
> a
> many-to-one correspondence between a P-VLAN and a VPLS instance, not only
> a one-to-one.  i.e, a customer with P-VLAN 3 and another customer with
> P-VLAN 4 belong to the same VPLS.
>     Muchmore,  to PE-rs the ethernet port is not a traditional standard
> port. When flooding, PE-rs need to send more than one copy in one
> ehternet port, because there are serveral custumers in one ethernet port
> each have different P-VLAN.

If two customer share the same VPLS instance, then you would use a single
P-VLAN for both of those customers - e.g., there is one-to-one mapping
between P-VLAN and VPLS within a given access domain (different QinQ
domain). If you're talking about different access domain, then there can be
different P-VLANs maps into the same VPLS and if that's your comment, then
I would agree and we can clarify the text.

>> So you are saying that in the same Q-in-Q access domain P-VLAN is one
>> to one mapping with VPLS instance? If this you are talking then I do have
>> a problem. In general, the requirement is to support Many P-VLANs per VPLS
>> on the same access domain or access domain& VPLS-MPLS.

Vasile




-Ali


>  ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua
>
>
>
>
>
> >As noted in the minutes, at the San Francisco meeting strong interest
> >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls"
> >as a working group draft. We agreed to finalize that decision only
> >after the WG participants who weren't there could have a say.
> >
> >So, if there are opinions that have not been heard, now is the time,
> >and this list is the place. Let's set a one-week limit to conclude
> >this issue.
> >
> >Rick
> >
> >---------------------------------------------------------------------
> >---
> >------------------------------------------------------------------------
> >---
> >From the minutes:
> >
> >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.
> >
> >[snipped]
> > Marco: asked for show of hands to make this a wG draft. Strong
> >interest was shown in room. Further discussion on the list.
> >
>
>


------_=_NextPart_001_01C30368.717812C4-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 12:12:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02722 for ; Tue, 15 Apr 2003 12:12:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FGE9q04208 for ; Tue, 15 Apr 2003 12:14:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FGE6C25014 for ; Tue, 15 Apr 2003 12:14:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415082345.01c8a008@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 08:41:11 -0700 To: "Vasile Radoaca" , "'hshah@rcn.com'" , "'Ali Sajassi'" , ppvpn@nortelnetworks.com From: Ali Sajassi Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6ACF@zbl6c002.corpeast .baynetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_166474507==_.ALT" X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: --=====================_166474507==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Vasile, At 11:31 PM 4/14/2003 -0400, Vasile Radoaca wrote: > Ali, > > Your observation about packet re-ordering in GVPLS has a > point. However, as Himanshu said > it is a very low probability and this in the case when the > VPLS core is not well design. > In Himanshu's example the remote unicast packet needs to > travel twice the speed of the multicast > packet, along the Unicast PW(s), in order to arrive before > the multicast packet, at the remote destination. Yes, I would acknowledge the probability of it being low but it is much higher than packet re-ordering during topology change because network congestion can happen more frequently in the network than network topology and network congestion can result in significant path differential delay. And in case of simultaneous transmission, the multicast path doesn't need to be twice the delay of unicast path. > > Also, we don't need to forget the U-PE devices are most of > the time connected with low speed > connections to the PE, if we compare with the high speed > core links, and most of the time via L2 > devices. The Remote packet and local unicast packet need to > traverse twice such connections in order > to get the unicast packet in front of the multicast packet. > > As it was suggested, in most of the cases, the Unicast PW > and M-P2P PW share the same > Tunnel between two PEs. Other option, is to do a better > design of the M-P2P PWs using TE or other > Qos techniques that can give a better response time (for > example, a typical VPLS design is to combine > a VPN pipe model in the VPLS core, with the VPLS hose model > between the VPN Members). Even when both are sent through the same tunnel with the same QoS, it can get our of order at the egress due to load balancing of ECMP. > > In GVPLS, the M-P2P PWs are treated as an optimization for > the multicast traffic and are defined per VPN > (regular Unicast VC-Labels can be used also). > In the VPLS scope the multicast or unknown traffic needs to > be very careful design - is easy to proof > that in scalable VPLS configurations (with thousand of > VPLSs ), the multicast traffic that can be generated can > block the unicast traffic and jeopardize, overall, the QoS > of the VPLS Services. > The idea of the M2-P2P PWs is to provide a kind of > "Multicast tree" where the packets are replicated > as minimum as possible between U-PE and N-PE devices. > > If the packet re-ordering is a key component of a given > application (a given VPLS context) and all the > tools that are available are not enough to lower the > probability of the packet re-ordering, then the replication > can be done using the Unicast PWs in the VPLS scope. > The VPLS forwarding engine is transparent to the use of a > VC-M-Label or a regular VC-Label. As two different PWs are used for unicast and multicast, there is a chance for this packet re-ordering even if you build your unicast out of PtP PWs. > > In general the Multicast issue is a complex one in the VPLS > scope - I belive that the current proposal is > is a starting point in providing a good solution. I think there is definitely a merit for having a solution based on MPtP PW and the discussion in here is just to highlight the issue with such solutions. My answer to the whole discussion is simple - we are doing LAN emulation and not exactly LAN so it is O.K. not to be exact. We just need to document it and make sure that IEEE 802.1 group doesn't have strong objection. -Ali > > Cheers > Vasile >-----Original Message----- >From: himanshu shah [mailto:hshah@rcn.com] >Sent: Monday, April 14, 2003 2:42 PM >To: 'Ali Sajassi'; ppvpn@nortelnetworks.com >Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt > >response in line. >-----Original Message----- >From: Ali Sajassi [mailto:sajassi@cisco.com] >Sent: Monday, April 14, 2003 1:44 PM >To: hshah@rcn.com; 'Ali Sajassi'; ppvpn@nortelnetworks.com >Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt >>That would exasperate the problem even more. So if some of the existing >>platforms have different internal processing path that would result in >>packet re-ordering between unknown unicast versus known unicast, then we >>should fix the problem instead of amplifying it by allowing it to be done >>everywhere in the network (both edge and core). Also I would like to know >>where in IEEE standards, it allows for such behavior. We can take this >>discussion to IEEE list. >> >> >> >>HS> Out-of-order packets between unknown-unicast/multicast and >>HS> known unicast is well known and well accepted fact. Perhaps >>HS> you should inquire this on IEEE mailing list. >Not for the steady state. If you look at the IEEE 802.1D standards it says: > >"NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or >duplicate frames. >Where Bridges in a Bridged LAN are capable of connecting the individual >MACs in such a way that >multiple paths between any source station -destination station pairs >exist,the operation of a protocol is required to ensure that a single path >is used. >NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during >normal operation." > >It clearly states that during normal operation misordering DOES NOT OCCUR !! > > > >[himanshu shah] Despite what it says, today in normal bridges, broadcast >(unknown unicast frame is a flood and hence it is a broadcast) and unicast >frames between two stations may get out of order for the reasons I >described before; irrespective of the state of the network. Again, I >invite you to site an example where a miniscule possibility of such an >out-of-order spells disaster for a protocol (at session initiation time). > > >>Even with this, you can still have out-of-ordering because of ECMP !! >> >> >> >>HS> Thank you. You give one more example of how an out-of-order >>HS> delievery could occur even when traffic is going over single >>HS> pseudowire. >No !!! traffic doesn't get re-order when a single PW is used in case of >ECMP. It can get re-order when there are multiple PWs are involved for the >same flow (as in the case of GVPLS). >[himanshu shah] If one was to do ECMP using the bottom most label, then it >is true that out-of-order would not occur for a single PW. However, is it >mandated that ECMP must be done on bottom-most label (i.e. PW label which >technically could be below several labels)? Lets for a moment accept that >such out-of-order would occur for 2 PWs. I would like to see an example >where a rare case of mis-order between broadcast-path frame and >unicast-path frame. > >>HS> The point is out-of-order can happen in GVPLS in very rare >>HS> circumstances. If you look at RSTP, out-of-order is mentioned >>HS> as a possibility during topo changes as an acceptable risk against >>HS> greater benefits. I suppose one can apply same logic here. >As mentioned before, IEEE 802.1D standards allows for possibility of >reordering in case of topology changes but not in steady state operation. >[himanshu shah] topo changes in small bridged network as compared to topo >changes in big-I network are at quite different scale. If one was to >compare the number of out-of-order packets due to topo-changes in big-I >network to out-of-order packets due to 2 PW, one would wonder where the >real problem is. >Regards, >Ali --=====================_166474507==_.ALT Content-Type: text/html; charset="us-ascii" Vasile,

At 11:31 PM 4/14/2003 -0400, Vasile Radoaca wrote:
         Ali,
 
             Your observation about packet re-ordering in GVPLS has a point. However, as Himanshu said
             it is a very low probability  and this in the case when the VPLS core is not well design.
             In Himanshu's example the remote unicast packet needs to travel twice the speed of the multicast
             packet, along the Unicast PW(s), in order to arrive before the multicast packet, at the remote destination.

Yes, I would acknowledge the probability of it being low but it is much higher than packet re-ordering during topology change because network congestion can happen more frequently in the network than network topology and network congestion can result in significant path differential delay. And in case of simultaneous transmission, the multicast path doesn't need to be twice the delay of unicast path.

 
             Also, we don't need to forget  the U-PE devices are most of the time connected with low speed
             connections to the PE, if we compare with the high speed core links, and most of the time via L2
             devices. The Remote packet and local unicast packet need to traverse twice such connections in order
             to get the unicast packet in front of the multicast packet.
 
             As it was suggested, in most of the cases, the Unicast PW and M-P2P PW  share the same
             Tunnel between two PEs.  Other option, is to  do a better design of the M-P2P PWs using TE or other
             Qos techniques that can give   a better response time (for example, a typical VPLS design is to combine
             a VPN pipe model in the VPLS core, with the VPLS hose model between the VPN Members).

Even when both are sent through the same tunnel with the same QoS, it can get our of order at the egress due to load balancing of ECMP.

 
             In GVPLS,  the M-P2P PWs are treated as an optimization for the multicast traffic and are defined per VPN
             (regular Unicast  VC-Labels can be used also).
             In the VPLS scope the multicast or unknown traffic needs to be very careful design - is easy to proof
              that in scalable VPLS configurations (with thousand of VPLSs ), the multicast traffic that can be generated  can
             block  the unicast traffic  and jeopardize, overall, the QoS of the VPLS Services.
             The idea of the M2-P2P PWs is to provide a kind of "Multicast tree" where the packets are replicated
             as minimum as possible between U-PE and N-PE devices.
 
             If the packet re-ordering is a key component of a given application (a given VPLS context) and all the
             tools that are available are not enough to lower the probability of the packet re-ordering, then the replication
             can  be done using the Unicast PWs in the VPLS scope.
             The VPLS forwarding engine is transparent to the use of a VC-M-Label or a regular VC-Label.

As two different PWs are used for unicast and multicast, there is a chance for this packet re-ordering even if you build your unicast out of PtP PWs.

            
             In general the Multicast issue is a complex one in the VPLS scope - I belive that the current proposal is
             is a starting point  in providing  a good  solution.

I think there is definitely a merit for having a solution based on MPtP PW and the discussion in here is just to highlight the issue with such solutions. My answer to the whole discussion is simple - we are doing LAN emulation and not exactly LAN so it is O.K. not to be exact. We just need to document it and make sure that IEEE 802.1 group doesn't have strong objection.

-Ali

 
          Cheers
                Vasile
-----Original Message-----
From: himanshu shah [mailto:hshah@rcn.com]
Sent: Monday, April 14, 2003 2:42 PM
To: 'Ali Sajassi'; ppvpn@nortelnetworks.com
Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt
response in line.
-----Original Message-----
From: Ali Sajassi [mailto:sajassi@cisco.com]
Sent: Monday, April 14, 2003 1:44 PM
To: hshah@rcn.com; 'Ali Sajassi'; ppvpn@nortelnetworks.com
Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt
That would exasperate the problem even more. So if some of the existing
platforms have different internal processing path that would result in
packet re-ordering between unknown unicast versus known unicast, then we
should fix the problem instead of amplifying it by allowing it to be done
everywhere in the network (both edge and core).  Also I would like to know
where in IEEE standards, it allows for such behavior. We can take this
discussion to IEEE list.



HS> Out-of-order packets between unknown-unicast/multicast and
HS> known unicast is well known and well accepted fact. Perhaps
HS> you should inquire this on IEEE mailing list.
Not for the steady state. If you look at the IEEE 802.1D standards it says:

"NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or duplicate frames.
Where Bridges in a Bridged LAN are capable of connecting the individual MACs in such a way that
multiple paths between any source station -destination station pairs exist,the operation of a protocol is required to ensure that a single path is used.
NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during normal operation."
It clearly states that during normal operation misordering DOES NOT OCCUR !!



[himanshu shah] Despite what it says, today in normal bridges, broadcast (unknown unicast frame is a flood and hence it is a broadcast) and unicast frames between two stations may get out of order for the reasons I described before; irrespective of the state of the network. Again, I invite you to site an example where a miniscule possibility of such an out-of-order spells disaster for a protocol (at session initiation time).

 
Even with this, you can still have out-of-ordering because of ECMP !!



HS> Thank you. You give one more example of how an out-of-order
HS> delievery could occur even when traffic is going over single
HS> pseudowire.
No !!! traffic doesn't get re-order when a single PW is used in case of ECMP. It can get re-order when there are multiple PWs are involved for the same flow  (as in the case of GVPLS).
[himanshu shah] If one was to do ECMP using the bottom most label, then it is true that out-of-order would not occur for a single PW. However, is it mandated that ECMP must be done on bottom-most label (i.e. PW label which technically could be below several labels)? Lets for a moment accept that such out-of-order would occur for 2 PWs. I would like to see an example where a rare case of mis-order between broadcast-path frame and unicast-path frame.

HS> The point is out-of-order can happen in GVPLS in very rare
HS> circumstances.  If you look at RSTP, out-of-order is mentioned
HS> as a possibility during topo changes as an acceptable risk against
HS> greater benefits. I suppose one can apply same logic here.
As mentioned before, IEEE 802.1D standards allows for possibility of reordering in case of topology changes but not in steady state operation.
[himanshu shah] topo changes in small bridged network as compared to topo changes in big-I network are at quite different scale. If one was to compare the number of out-of-order packets due to topo-changes in big-I network to out-of-order packets due to 2 PW, one would wonder where the real problem is.
Regards,
Ali
--=====================_166474507==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 12:18: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 MAA02977 for ; Tue, 15 Apr 2003 12:18:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FGKwq08163 for ; Tue, 15 Apr 2003 12:20:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FGKsC13703 for ; Tue, 15 Apr 2003 12:20:55 -0400 (EDT) Message-ID: <3E9C2F59.C64C8A46@cisco.com> Date: Tue, 15 Apr 2003 18:12:09 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: alok CC: John Smith , "Apcar, Jeff" , ppvpn@lyris.nortelnetworks.com Subject: Re: RD in 2547 bis References: <065e01c30361$b2c26060$81c802c0@alok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Alok, Yes you could use only one, yes you could filter with RDs etc ... but you will have to bind A) making the prefix uniqe with B) the import/export policy which would be much less flexible in assinging routes to VPN memberships then using RD just to make the vpn prefix uniqe (mostly on RRs/ASBRs) and a list of route-targets attached to each vpn route to decide where this route should be imported to. No magic behind just more flexibility and decomposition of functions. Cheers, R. > alok wrote: > > ...and incase RD is not scalable, why not just RT and no RD? > > -rgds > Alok > ----- Original Message ----- > From: alok > To: John Smith ; Apcar, Jeff ; > > Sent: Tuesday, April 15, 2003 7:08 PM > Subject: Re: RD in 2547 bis > > > Yes, > > > > thanks for articulating it John, > > > > Thats my confusion. > > > > -rgds > > Alok > > ----- Original Message ----- > > From: John Smith > > To: Apcar, Jeff ; alok ; > > > > Sent: Tuesday, April 15, 2003 6:58 PM > > Subject: RE: RD in 2547 bis > > > > > > > Jeff, > > > > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but it > is > > not > > > > interested in what VPN these addresses belong to. YOu need the RD to > > make > > > > the VPN addresses unique to MP-BGP, and consequently to the SP domain. > > > > > > Very Right. > > > > > > > > > > > You need the RD to make the VPN addresses to unique MP-BGP you need > the > > RT > > > > to select which VPN to include the address (the RT allows you to > create > > > > > > Instead of using the RT why cant RD work out as the RT. One can decide > > which route goes > > > into which VRF by looking at the RD rather than at the RT. > > > > > > I guess this is the confusion which Mr. Alok has. > > > > > > JS > > > > > > > > > __________________________________________________ > > > 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 Tue Apr 15 12:41: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 MAA03535 for ; Tue, 15 Apr 2003 12:41:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FGf5q13850 for ; Tue, 15 Apr 2003 12:41:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FGevC13565 for ; Tue, 15 Apr 2003 12:40:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415091211.01cd1bf0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 09:20:59 -0700 To: "Vasile Radoaca" , "'Ali Sajassi'" , Du Wenhua , Rick Wilder From: Ali Sajassi Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: ppvpn@nortelnetworks.com In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6ADC@zbl6c002.corpeast .baynetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_168862551==_.ALT" X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: --=====================_168862551==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable >If two customer share the same VPLS instance, then you would use a single >P-VLAN for both of those customers - e.g., there is one-to-one mapping >between P-VLAN and VPLS within a given access domain (different QinQ >domain). If you're talking about different access domain, then there can be >different P-VLANs maps into the same VPLS and if that's your comment, then >I would agree and we can clarify the text. > > >> So you are saying that in the same Q-in-Q access domain P-VLAN is one > >> to one mapping with VPLS instance? If this you are talking then I do= have > >> a problem. In general, the requirement is to support Many P-VLANs per= =20 > VPLS > >> on the same access domain or access domain& VPLS-MPLS. I think there is misunderstanding in here. P-VLAN is just to represent a=20 VPLS-id inside the QinQ domain - e.g., VPLS-id can be a 32-bit id for MPLS= =20 domain and can be a 12-bit id for QinQ domain. P-VLAN is different from a=20 customer vlans (C-VLANs) and as MPLS domain where several C-VLANs map into= =20 the same VPLS instance (represented by an ID), for QinQ domain several=20 C-VLANs map into the same VPLS instance (represented by a 12-bit field). -Ali >Vasile > > > >-Ali > > > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua > > > > > > > > > > > > >As noted in the minutes, at the San Francisco meeting strong interest > > >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" > > >as a working group draft. We agreed to finalize that decision only > > >after the WG participants who weren't there could have a say. > > > > > >So, if there are opinions that have not been heard, now is the time, > > >and this list is the place. Let's set a one-week limit to conclude > > >this issue. > > > > > >Rick > > > > > >--------------------------------------------------------------------- > > >--- > >= >------------------------------------------------------------------------ > > >--- > > >From the minutes: > > > > > >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. > > > > > >[snipped] > > > Marco: asked for show of hands to make this a wG draft. Strong > > >interest was shown in room. Further discussion on the list. > > > > > > > --=====================_168862551==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If two customer share the same VPLS instance, then you would use a single
P-VLAN for both of those customers - e.g., there is one-to-one mapping
between P-VLAN and VPLS within a given access domain (different QinQ
domain). If you're talking about different access domain, then there can be
different P-VLANs maps into the same VPLS and if that's your comment, then
I would agree and we can clarify the text.

>> So you are saying that in the same Q-in-Q access domain P-VLAN is one
>> to one mapping with VPLS instance? If this you are talking then I do have
>> a problem. In general, the requirement is to support Many P-VLANs per VPLS
>> on the same access domain or access domain& VPLS-MPLS.

I think there is misunderstanding in here. P-VLAN is just to represent a VPLS-id inside the QinQ domain - e.g., VPLS-id can be a 32-bit id for MPLS domain and can be a 12-bit id for QinQ domain. P-VLAN is different from a customer vlans (C-VLANs) and as MPLS domain where several C-VLANs map into the same VPLS instance (represented by an ID), for QinQ domain several C-VLANs map into the same VPLS instance (represented by a 12-bit field).

-Ali


Vasile



-Ali

>  =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du= Wenhua
>
>
>
>
>
> >As noted in the minutes, at the San Francisco meeting strong interest
> >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls"
> >as a working group draft. We agreed to finalize that decision only
> >after the WG participants who weren't there could have a say.
> >
> >So, if there are opinions that have not been heard, now is the time,
> >and this list is the place. Let's set a one-week limit to conclude
> >this issue.
> >
> >Rick
> >
> >---------------------------------------------------------------------
> >---
> >------------------------------------------------------------------------=
> >---
> >From the minutes:
> >
> >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.
> >
> >[snipped]
> > Marco: asked for show of hands to make this a wG= draft. Strong
> >interest was shown in room. Further discussion on= the list.
> >
>
>
--=====================_168862551==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 12:42:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03566 for ; Tue, 15 Apr 2003 12:42:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FGicq17028 for ; Tue, 15 Apr 2003 12:44:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FGiYC17344 for ; Tue, 15 Apr 2003 12:44:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415113306.0226a988@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 12:28:42 -0400 To: John Smith From: Rajiv Asati Subject: RE: RD in 2547 bis Cc: "Apcar, Jeff" , alok , ppvpn@lyris.nortelnetworks.com In-Reply-To: <20030415132808.42391.qmail@web41806.mail.yahoo.com> References: <11D2868F916DD411982D00508B694F431CE7CD60@syd-xch2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: rajiva@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: John, At 09:28 AM 4/15/2003, John Smith wrote: >Jeff, > > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but it > is not > > interested in what VPN these addresses belong to. YOu need the RD to make > > the VPN addresses unique to MP-BGP, and consequently to the SP domain. > >Very Right. > > > > > You need the RD to make the VPN addresses to unique MP-BGP you need the RT > > to select which VPN to include the address (the RT allows you to create > >Instead of using the RT why cant RD work out as the RT. One can decide >which route goes >into which VRF by looking at the RD rather than at the RT. > >I guess this is the confusion which Mr. Alok has. Please keep in mind that RD is unique to a customer. Now, when we get to the extranet, in which the customer1 and customer2 exchange the routing information, it becomes much easier to control the routing information based on RT. Also, with RT, we can simply check for one RT attribute and decide whether we want 100s of MP_NLRI or not (the way BGP update is packed). If we had to do this based on RD, then we really would have to go through each VPNv4 prefix to find out whether it was a candidate for the import or not. I think it comes down to what gives us more granularity and control over what we want to do. Cheers, Rajiv >JS > > >__________________________________________________ >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 Tue Apr 15 12:48:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03669 for ; Tue, 15 Apr 2003 12:48:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FGoAq20848 for ; Tue, 15 Apr 2003 12:50:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FGnwC22935 for ; Tue, 15 Apr 2003 12:49:58 -0400 (EDT) Message-ID: <39469E08BD83D411A3D900204840EC55D7BB75@vie-msgusr-01.dc.fore.com> From: "Ju, Yu" To: ppvpn@lyris.nortelnetworks.com Subject: two BGP best routes with different RD, but same IPv4 prefix Date: Tue, 15 Apr 2003 12:33:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: Yu.Ju@marconi.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Hi, If a PE router receive two VPN-IPv4 routes with different RD and the same IPv4 prefix, suppose both pass the RT import checking and both are the best BGP route, should BGP install both routes (have the same IPv4 prefix) in the VRF routing table? Thanks, Yu From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 13:00:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04018 for ; Tue, 15 Apr 2003 13:00:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FH2Tq15078 for ; Tue, 15 Apr 2003 13:02:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FH2IC08869 for ; Tue, 15 Apr 2003 13:02:19 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: draft-kompella-ppvpn-vpls-01.txt Date: Tue, 15 Apr 2003 18:50:31 +0200 Message-ID: Thread-Topic: draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMDbyA0ckILbaTCSQKq9XC9mHQJBA== From: "DECRAENE Bruno FTRD/DAC/ISS" To: Cc: "FONDEVIOLE Benoit FTRD/DAC/ISS" , "JACQUET David FTRD/DAC/ISS" X-OriginalArrivalTime: 15 Apr 2003 16:50:31.0757 (UTC) FILETIME=[207927D0:01C3036F] X-SMTP-HELO: p-mail2 X-SMTP-MAIL-FROM: bruno.decraene@rd.francetelecom.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: p-mail2.rd.francetelecom.com [195.101.245.16] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04018 We would like to support draft-kompella-ppvpn-vpls-01.txt, making this a working group draft. Regarding management, the less work, the better. - Using one -well known- protocol (MP-BGP) for discovery and signalling is easier to manage than two protocols (LDP + MP-BGP/RADIUS/DNS/?) - BGP RR greatly reduces the number of sessions to monitor: o(N) vs o(N*N) - With the large scale deployment of 2547 VPN, we gained valuable experience with MP-BGP (managing, scaling,...). Seems fine to re-use it. As Rahul said, both drafts are interesting for various SP/customers. It would be better if -at least- the data plane description were the same. Regards, Benoît, David, Bruno > -----Original Message----- > From: Rahul Aggarwal [mailto:rahul@redback.com] > Sent: Monday, April 14, 2003 4:35 PM > To: ppvpn@nortelnetworks.com > Subject: Regarding progressing VPLS docs > > > > Hi Marco and Rick, > > I would like to add my support for making both: > > draft-lasserre-vkompella-ppvpn-vpls-04.txt > draft-kompella-ppvpn-vpls-01.txt > > as WG docs with the caveat that the common parts should not be > repeated. draft-lasserre may be a good place to keep the common > portion. In particular the data plane description that is > common to these > specs can be left in draft-lasserre and pulled out of draft-kompella. > > Its possible to have a never ending discussion on the pros and cons of > each. The bottomline is that LDP signaling + protocol X > auto-discovery or > BGP signaling + BGP auto-discovery, both have their own > applicability. If > down the road we figure out that one of these solutions doesn't have > deployment traction, the respective doc doesn't have to be > moved to RFC > status. > > Thanks, > rahul > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 13:17:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04555 for ; Tue, 15 Apr 2003 13:17:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FHJmq26517 for ; Tue, 15 Apr 2003 13:19:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FHJeC28401 for ; Tue, 15 Apr 2003 13:19:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415130138.022768f0@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 13:09:14 -0400 To: "Ju, Yu" From: Rajiv Asati Subject: Re: two BGP best routes with different RD, but same IPv4 prefix Cc: ppvpn@lyris.nortelnetworks.com In-Reply-To: <39469E08BD83D411A3D900204840EC55D7BB75@vie-msgusr-01.dc.fo re.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: rajiva@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Yu, By default, only one best path gets selected to be inserted into the RIB. With MP-BGP multipath, this default behavior can be changed. Cheers, Rajiv At 12:33 PM 4/15/2003, Ju, Yu wrote: >Hi, > >If a PE router receive two VPN-IPv4 routes with different RD and the same >IPv4 prefix, suppose both pass the RT import checking and both are the best >BGP route, should BGP install both routes (have the same IPv4 prefix) in the >VRF routing table? > >Thanks, > >Yu From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 13:41:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05162 for ; Tue, 15 Apr 2003 13:41:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FHi4q04321 for ; Tue, 15 Apr 2003 13:44:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FHhxC10101 for ; Tue, 15 Apr 2003 13:43:59 -0400 (EDT) Date: Wed, 16 Apr 2003 01:38:24 +0800 From: Du Wenhua Subject: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft To: Ali Sajassi , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDE00L28BLHNN@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05162 Hi, Ali Sajassi See my comment bellow. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-16 >>At 06:47 AM 4/15/2003 +0800, Du Wenhua wrote: >>Hi,Rick Wilder, >> I support it to become a WG draft. >> >>BTW, one qustion as follow: >>In setction 11 of the draft-lasserre-vkompella-ppvpn-vpls-04.txt, it say: >> >>* 11. Hierarchical VPLS model using Ethernet Access Network >> ..... >>* One approach of tunneling a customer?s Ethernet traffic via an >>* Ethernet access network is to add an additional VLAN tag to the >>* customer?s data (either tagged or untagged). The additional tag is >>* referred to as Provider?s VLAN (P-VLAN). Inside the provider?s >>* network each P-VLAN designates a customer or more specifically a VPLS >>** instance for that customer. Therefore, there is a one to one >>** correspondence between a P-VLAN and a VPLS instance. >> >> In my option, the last sentece in above is not true. There is also a >> many-to-one correspondence between a P-VLAN and a VPLS instance, not only >> a one-to-one. i.e, a customer with P-VLAN 3 and another customer with >> P-VLAN 4 belong to the same VPLS. >> Muchmore, to PE-rs the ethernet port is not a traditional standard >> port. When flooding, PE-rs need to send more than one copy in one >> ehternet port, because there are serveral custumers in one ethernet port >> each have different P-VLAN. > >If two customer share the same VPLS instance, then you would use a single >P-VLAN for both of those customers - e.g., there is one-to-one mapping >between P-VLAN and VPLS within a given access domain (different QinQ Not always true. You can use one P-VLAN for two customer in most case. But for managerment and security reason, the provider want to use different P-VLANs for different customers in same domain. For example , the provider want to isolate the two customer's traffic, and do different rate-limit in PE-rs. Another example, the provider do not want the two customer talk with each other, so then can apply access list in the PE-rs. The fact is that, ethernet access network are made up of some low price switchs, which are poor in value-add service, such as access list control, rate limit, statistic. The PE-rs is high price device. There is many value-add service, such as access list control, rate limit,subscriber managerment. So if you want different service for different customer, you need to use different P-VLANs. In one word, P-VLAN is the service delimiter of a customer. Different customers need different delimiters, because they need differnet services in PE-rs. >domain). If you're talking about different access domain, then there can be >different P-VLANs maps into the same VPLS and if that's your comment, then >I would agree and we can clarify the text. True. In different domain, same VPLS maybe use different P-VLAN. > >-Ali > > >> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua >> >> >> >> >> >> >As noted in the minutes, at the San Francisco meeting strong interest >> >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a >> >working group draft. We agreed to finalize that decision only after the >> >WG participants who weren't there could have a say. >> > >> >So, if there are opinions that have not been heard, now is the time, and >> >this list is the place. Let's set a one-week limit to conclude this >> >issue. >> > >> >Rick >> > >> >------------------------------------------------------------------------ >> >------------------------------------------------------------------------ >> >--- >> >From the minutes: >> > >> >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. >> > >> >[snipped] >> > Marco: asked for show of hands to make this a wG draft. >> >Strong interest was shown in room. Further discussion on the list. >> > >> >> From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 14:08:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05802 for ; Tue, 15 Apr 2003 14:08:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FIAFq29309 for ; Tue, 15 Apr 2003 14:10:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FIA8C06552 for ; Tue, 15 Apr 2003 14:10:08 -0400 (EDT) Date: Wed, 16 Apr 2003 02:04:59 +0800 From: Du Wenhua Subject: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft To: Ali Sajassi , "Vasile Radoaca" , "'Ali Sajassi'" , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDE00KGGCTSMJ@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA05802 Hi, Ali Sajassi Thanks for comment. See my comments bellow. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-16 >>>If two customer share the same VPLS instance, then you would use a single >>P-VLAN for both of those customers - e.g., there is one-to-one mapping >>between P-VLAN and VPLS within a given access domain (different QinQ >>domain). If you're talking about different access domain, then there can be >>different P-VLANs maps into the same VPLS and if that's your comment, then >>I would agree and we can clarify the text. >> >> >> So you are saying that in the same Q-in-Q access domain P-VLAN is one >> >> to one mapping with VPLS instance? If this you are talking then I do have >> >> a problem. In general, the requirement is to support Many P-VLANs per >> VPLS >> >> on the same access domain or access domain& VPLS-MPLS. > >I think there is misunderstanding in here. P-VLAN is just to represent a >VPLS-id inside the QinQ domain - e.g., VPLS-id can be a 32-bit id for MPLS >domain and can be a 12-bit id for QinQ domain. P-VLAN is different from a >customer vlans (C-VLANs) and as MPLS domain where several C-VLANs map into >the same VPLS instance (represented by an ID), for QinQ domain several >C-VLANs map into the same VPLS instance (represented by a 12-bit field). In this draft, there are two way to treat C-VLAN in MTU-rs: 1)if C-VLAN are not used as service delimiter, add P-VLAN. In this way, the isssue is that if two C-VLAN map into same P-VLAN, the PE-rs can only distinguish two customer by C-VLANs. But, the C-VLAN is untrusted, is not service delimiter. It is wrong for PE-rs to apply different value-add service for different C-VLANs. So it is better to map into different P-VLANs for differnent custom if the PE-rs want to distinguish them. 2)if C-VLAN are used as service delimiter, translating C-VLAN to a P-VLAN In this way, the issue is that if two C-VLAN are tranlated to one P-VLAN, the PE-rs will couldn't distinguish two customer. So it is better way to use different P-VLANs for different customers. > >-Ali > > >>Vasile >> >> >> >>-Ali >> >> > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua >> > >> > >> > >> > >> > >> > >As noted in the minutes, at the San Francisco meeting strong interest >> > >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" >> > >as a working group draft. We agreed to finalize that decision only >> > >after the WG participants who weren't there could have a say. >> > > >> > >So, if there are opinions that have not been heard, now is the time, >> > >and this list is the place. Let's set a one-week limit to conclude >> > >this issue. >> > > >> > >Rick >> > > >> > >--------------------------------------------------------------------- >> > >--- >> > >------------------------------------------------------------------------ >> > >--- >> > >From the minutes: >> > > >> > >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. >> > > >> > >[snipped] >> > > Marco: asked for show of hands to make this a wG draft. Strong >> > >interest was shown in room. Further discussion on the list. >> > > >> > >> > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 16:14:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10154 for ; Tue, 15 Apr 2003 16:14:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FKGgq02283 for ; Tue, 15 Apr 2003 16:16:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FKGcC15885 for ; Tue, 15 Apr 2003 16:16:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415124045.01c64298@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 13:11:42 -0700 To: Du Wenhua , Ali Sajassi , Rick Wilder From: Ali Sajassi Subject: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDE00L28BLHNN@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10154 > >If two customer share the same VPLS instance, then you would use a single > >P-VLAN for both of those customers - e.g., there is one-to-one mapping > >between P-VLAN and VPLS within a given access domain (different QinQ > Not always true. > You can use one P-VLAN for two customer in most case. But for > managerment and security reason, the provider want to use different > P-VLANs for different customers in same domain. For example , the > provider want to isolate the two customer's traffic, and do different > rate-limit in PE-rs. Another example, the provider do not want the two > customer talk with each other, so then can apply access list in the PE-rs. > The fact is that, ethernet access network are made up of some low > price switchs, which are poor in value-add service, such as access list > control, rate limit, statistic. The PE-rs is high price device. There is > many value-add service, such as access list control, rate > limit,subscriber managerment. So if you want different service for > different customer, you need to use different P-VLANs. > In one word, P-VLAN is the service delimiter of a customer. Different > customers need different delimiters, because they need differnet services > in PE-rs. You should read the draft again and also try to keep up with what is going on in 802.1ad. P-VLAN is a way to identify the VPLS instance within the QinQ access network. There are two learning modes, qualified and unqualified learning. In unqualified mode, all customer's VLANs is mapped into a single VPLS instance and the P-VLAN represents that VPLS instance (THIS HAS NOTHING TO DO WITH SERVICE DELIMITER). In case of qualified mode, each customer VLAN serves as service delimiter and each customer VLAN correspond to a VPLS instance. Furthermore, each customer VLAN can map to a P-VLAN. This mapping functionality is performed by the edge device and are transparent to the intermediate switches. -Ali > >domain). If you're talking about different access domain, then there can be > >different P-VLANs maps into the same VPLS and if that's your comment, then > >I would agree and we can clarify the text. >True. In different domain, same VPLS maybe use different P-VLAN. > > > >-Ali > > > > > > > > >> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua > >> > >> > >> > >> > >> > >> >As noted in the minutes, at the San Francisco meeting strong interest > >> >was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a > >> >working group draft. We agreed to finalize that decision only after the > >> >WG participants who weren't there could have a say. > >> > > >> >So, if there are opinions that have not been heard, now is the time, and > >> >this list is the place. Let's set a one-week limit to conclude this > >> >issue. > >> > > >> >Rick > >> > > >> >------------------------------------------------------------------------ > >> >------------------------------------------------------------------------ > >> >--- > >> >From the minutes: > >> > > >> >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. > >> > > >> >[snipped] > >> > Marco: asked for show of hands to make this a wG draft. > >> >Strong interest was shown in room. Further discussion on the list. > >> > > >> > >> > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 16:23:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10426 for ; Tue, 15 Apr 2003 16:23:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FKPgq06270 for ; Tue, 15 Apr 2003 16:25:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FKPdC22958 for ; Tue, 15 Apr 2003 16:25:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415131526.01c53ea8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 13:22:15 -0700 To: Du Wenhua , Ali Sajassi , "Vasile Radoaca" , Rick Wilder From: Ali Sajassi Subject: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDE00KGGCTSMJ@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: > >I think there is misunderstanding in here. P-VLAN is just to represent a > >VPLS-id inside the QinQ domain - e.g., VPLS-id can be a 32-bit id for MPLS > >domain and can be a 12-bit id for QinQ domain. P-VLAN is different from a > >customer vlans (C-VLANs) and as MPLS domain where several C-VLANs map into > >the same VPLS instance (represented by an ID), for QinQ domain several > >C-VLANs map into the same VPLS instance (represented by a 12-bit field). > >In this draft, there are two way to treat C-VLAN in MTU-rs: >1)if C-VLAN are not used as service delimiter, add P-VLAN. > In this way, the isssue is that if two C-VLAN map into same P-VLAN, > the PE-rs can only distinguish two customer by C-VLANs. But, the C-VLAN > is untrusted, is not service delimiter. It is wrong for PE-rs to apply > different value-add service for different C-VLANs. > So it is better to map into different P-VLANs for differnent custom > if the PE-rs want to distinguish them. >2)if C-VLAN are used as service delimiter, translating C-VLAN to a P-VLAN > In this way, the issue is that if two C-VLAN are tranlated to one > P-VLAN, the PE-rs will couldn't distinguish two customer. > So it is better way to use different P-VLANs for different customers. I thought this has already been explained in the draft. If not it might have been lost during editing. I will double check on this. Thanks, Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 18:15: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 SAA14511 for ; Tue, 15 Apr 2003 18:15:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FMI5q03993 for ; Tue, 15 Apr 2003 18:18:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FMI1C03790 for ; Tue, 15 Apr 2003 18:18:01 -0400 (EDT) Date: Wed, 16 Apr 2003 06:12:20 +0800 From: Du Wenhua Subject: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft To: Ali Sajassi , Ali Sajassi , "Vasile Radoaca" , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDE00H6MOA8SC@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA14511 Hi, Ali Sajassi ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-16 At 13:22:00 2003-04-15, Ali Sajassi wrote: >>> >I think there is misunderstanding in here. P-VLAN is just to represent a >> >VPLS-id inside the QinQ domain - e.g., VPLS-id can be a 32-bit id for MPLS >> >domain and can be a 12-bit id for QinQ domain. P-VLAN is different from a >> >customer vlans (C-VLANs) and as MPLS domain where several C-VLANs map into >> >the same VPLS instance (represented by an ID), for QinQ domain several >> >C-VLANs map into the same VPLS instance (represented by a 12-bit field). >> >>In this draft, there are two way to treat C-VLAN in MTU-rs: >>1)if C-VLAN are not used as service delimiter, add P-VLAN. >> In this way, the isssue is that if two C-VLAN map into same P-VLAN, >> the PE-rs can only distinguish two customer by C-VLANs. But, the C-VLAN >> is untrusted, is not service delimiter. It is wrong for PE-rs to apply >> different value-add service for different C-VLANs. >> So it is better to map into different P-VLANs for differnent custom >> if the PE-rs want to distinguish them. >>2)if C-VLAN are used as service delimiter, translating C-VLAN to a P-VLAN >> In this way, the issue is that if two C-VLAN are tranlated to one >> P-VLAN, the PE-rs will couldn't distinguish two customer. >> So it is better way to use different P-VLANs for different customers. > >I thought this has already been explained in the draft. If not it might >have been lost during editing. I will double check on this. > OK. Hope to add it, thanks. To PE-rs, P-VLAN is just looked as a AC , not be look as PW. Many ACs can be map to one VPLS-instance. So, many P-VLAN can map to one VPLS-instance also, even if these P-VLANs in one physical port. If the MTU just map each customer to each P-VLAN, it become a VPWS/VLL. MAC learning is removed in MTU. >Thanks, >Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 18:45:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15274 for ; Tue, 15 Apr 2003 18:45:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FMlYq07821 for ; Tue, 15 Apr 2003 18:47:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FMlSC15384 for ; Tue, 15 Apr 2003 18:47:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415152650.01cd0f88@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 15:44:34 -0700 To: Du Wenhua , Ali Sajassi , "Vasile Radoaca" , Rick Wilder From: Ali Sajassi Subject: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDE00H6MOA8SC@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: At 06:12 AM 4/16/2003 +0800, Du Wenhua wrote: >Hi, Ali Sajassi > > >>In this draft, there are two way to treat C-VLAN in MTU-rs: > >>1)if C-VLAN are not used as service delimiter, add P-VLAN. > >> In this way, the isssue is that if two C-VLAN map into same P-VLAN, > >> the PE-rs can only distinguish two customer by C-VLANs. But, the C-VLAN > >> is untrusted, is not service delimiter. It is wrong for PE-rs to apply > >> different value-add service for different C-VLANs. > >> So it is better to map into different P-VLANs for differnent custom > >> if the PE-rs want to distinguish them. > >>2)if C-VLAN are used as service delimiter, translating C-VLAN to a P-VLAN > >> In this way, the issue is that if two C-VLAN are tranlated to one > >> P-VLAN, the PE-rs will couldn't distinguish two customer. > >> So it is better way to use different P-VLANs for different customers. > > > >I thought this has already been explained in the draft. If not it might > >have been lost during editing. I will double check on this. > > >OK. Hope to add it, thanks. >To PE-rs, P-VLAN is just looked as a AC , not be look as PW. Many ACs >can be map to one VPLS-instance. So, many P-VLAN can map to one >VPLS-instance also, even if these P-VLANs in one physical port. >If the MTU just map each customer to each P-VLAN, it become a VPWS/VLL. >MAC learning is removed in MTU. No, that's not correct. Lets go over it one more time. 1) Unqualified learning: all traffic from a given customer is tagged by P-VLAN, so if a customer is connected to a given access network through 10 different ACs (and through several different MTU-s), then all those ACs will be tagged by the same P-VLAN. The P-VLAN as mentioned before corresponds to a single VPLS instance. Thus, all C-VLANs for a that customer share the same MAC address domain and broadcast domain. 2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g., VLAN-100) and that P-VLAN corresponds to a single VPLS instance. Therefore, in both cases, a single P-VLAN correspond to a single VPLS instance and vise versa - e.g., one-to-one mapping. -Ali > > > > > > >Thanks, > >Ali > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 18:50: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 SAA15369 for ; Tue, 15 Apr 2003 18:50:24 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FMqVq11235 for ; Tue, 15 Apr 2003 18:52:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FMqQC19615 for ; Tue, 15 Apr 2003 18:52:27 -0400 (EDT) Message-ID: <3E9C8C96.1FF565D8@alcatel.com> Date: Tue, 15 Apr 2003 18:49:58 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rick Wilder , "Marco Carugi" CC: ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft References: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick, Marco, Before considering progressing VPLS solutions as WG drafts, I think it is useful to understand how the different solutions meet the requirements in http://www.ietf.org/internet-drafts/draft-augustyn-ppvpn-l2vpn-requirements-02.txt (at least for some of the basic LAN emulation service requirements, if not all). Ignoring some of these requirements may render a solution not useful to end customers. For e.g. if the following requirements are not met, an operator may not be able to provide a functional service and as a result, some end customers may choose to setup their own virtual private LAN instead, and provider provisioned VPLS may not become as successful as hoped. 1) Traffic Looping +---------------- | +------+ +---------| PE | | |device| | +------+ +------+ | | CE | | |device| | SP network +------+ | | +------+ | | PE | +---------|device| +------+ | +---------------- (a) If CE is a hub, does lasserre-vkompella support this valid configuration requirement (to make the service more resilient to PE or MTU-S failure)? How to prevent traffic from looping in the e.g. above taken from the requirements document? I think loop issues were first brought up in 2001, but it has not been addressed. (I don't think the answer is rate-limiting of customer traffic ;-)). In the case of Hierarchical VPLS, the above configuration cannot be supported either. If this configuration cannot be supported, then if a PE-rs is down, all CEs & MTU-S connected to the PE-rs are partitioned from the VPLS network. +---------------- | +------+ +---------| MTU-S|------------------PE-rs | |device| | | +------+ | +------+ | | CE | | |device| SP network | +------+ | | +------+ | | | MTU-S| | +---------|device|------------------PE-rs +------+ | +--------------------- For e.g. (if one were to attempt to use the above configuration requirement for Hierarchical VPLS) : Traffic will loop as well (for different customers connected to MTU-S devices in this fashion) and VPLS cannot be enabled for these customers. If however, the MTU-S are connected directly and the PE-rs removed, the MTU-S (if they are IEEE 802.1d/q bridges) can form a spanning tree and loops are avoided, i.e. the VPLS service can be enabled then. I think the fundamental problem here is PE bridges customer traffic but have no means to prevent loops in the forwarding path. 2) Improper LAN Emulation If a VC in a full-mesh failed and cannot be restored, CE routers in the VPLS do not have a consistent view of all CE routers. CEA---PEA--------PEB---CEB \ / \ / \ / \/ PEC | CEC E.g. if the link between PEA and PEB fails: If there are routers using the emulated LAN or if CEs are routers, then I don't see how customer routing protocol like OSPF will work. CEA will not see CEB, but CEC sees CEA & CEB, and vice-versa. The consequence is that, I don't think CEC can route to CEA or CEB at all if PEA-PEB link is down. If STP is used instead of full-meshed reverse split horizon forwarding, at least CEC can still route to CEB (and CEA, if PEA-PEC link becomes active), i.e. at least some sites can still reach each other. In the case of solutions using full-meshed including Hierarchical VPLS, while a link/VC between two PEs is down or cannot be recovered, customers VPLS services for all sites will become dysfunctional. This will affect CE routers, CE bridges as well as MTU-S devices operation. When it affects MTU-S devices, all customers VPLS with connectivity to the MTU-S devices will be affected as well. In the above cases, full-meshed reverse split horizon forwarding is not functional and the related solutions cannot be used. I hope these issues will not be disregarded or trivialized because it is unlikely end customers will. There are other important issues that need to be addressed as well, but it's useful to understand how these problems are handled to start with. Thanks Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 19:40:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16723 for ; Tue, 15 Apr 2003 19:40:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FNgdq27202 for ; Tue, 15 Apr 2003 19:42:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3FNgaC29516 for ; Tue, 15 Apr 2003 19:42:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415161651.01630ac8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 16:40:08 -0700 To: Du Wenhua , Ali Sajassi , "Vasile Radoaca" , Rick Wilder From: Ali Sajassi Subject: Re: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDE00HRGQEGMJ@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: > > >1) Unqualified learning: all traffic from a given customer is tagged by > >P-VLAN, so if a customer is connected to a given access network through 10 > >different ACs (and through several different MTU-s), then all those ACs > >will be tagged by the same P-VLAN. The P-VLAN as mentioned before > >corresponds to a single VPLS instance. Thus, all C-VLANs for a that > >customer share the same MAC address domain and broadcast domain. > > > >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given > >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g., > >VLAN-100) and that P-VLAN corresponds to a single VPLS instance. > > > >Therefore, in both cases, a single P-VLAN correspond to a single VPLS > >instance and vise versa - e.g., one-to-one mapping. > > > >No. You misunderstand my point. I'm not talking about learning, I'm >talking about value-add service, such as rate-limited, access list control. >For learning,I agree with you, one P-VLAN to one VPLS-instance is enough. >But for value-add service, it is not enough, require many P-VLANs to one >VPLS-instance. For unqualified learning, customer's VLANs are transparent to the SP. And as the matter of fact there is single MAC address domain and broadcast domain for all the VLAN of that customer. So what that means is the customer's MAC addresses need to be unique across all the VLANs or else unqualified learning would not work for that customer. So, given that all MAC addresses of a given customer are unique, then you can run ACL based on customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified learning, then you simply copy the CoS bits of the inner tag to he outer tag and perform QoS on the P-VLAN tag. The situation for qualified learning, should be clear since there is no outer-tag and P-VLAN is just a mapping of the C-VLAN. If this is yet not clear to you, please clearly state the issue with an example. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 21:03:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18699 for ; Tue, 15 Apr 2003 21:03:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G15Lq11053 for ; Tue, 15 Apr 2003 21:05:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G15FC16239 for ; Tue, 15 Apr 2003 21:05:15 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6AE3@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'Ali Sajassi'" , Du Wenhua , Rick Wilder Cc: ppvpn@nortelnetworks.com Subject: RE: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working gr oup draft Date: Tue, 15 Apr 2003 20:59:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C303B3.67405BEA" 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_01C303B3.67405BEA Content-Type: text/plain; charset="iso-8859-1" Ali, Let's consider the following relationships Many C-VLANs - to one PVLAN -> one access domain many PVLANs - to one VPLS instance I agree with Du Wenhua that suporting many PVLANs per one VPLS instance it is very valuable and it should not be restricted by your model. A PVLAN can be seen as an aggretae VPN member in the VPLS port, where different polcies can be applied. However, I don't see in the draft how the PVLAN/CVLAN information is sent in the Control plan, so the mapping and re-mapping in the access doamins can be done correctly. The current VFEC doesn't work for this type of access domain. Cheers Vasile -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com] Sent: Tuesday, April 15, 2003 7:40 PM To: Du Wenhua; Ali Sajassi; Radoaca, Vasile [BL60:X624:EXCH]; Rick Wilder Cc: ppvpn@nortelnetworks.com Subject: Re: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > >1) Unqualified learning: all traffic from a given customer is tagged by > >P-VLAN, so if a customer is connected to a given access network through 10 > >different ACs (and through several different MTU-s), then all those ACs > >will be tagged by the same P-VLAN. The P-VLAN as mentioned before > >corresponds to a single VPLS instance. Thus, all C-VLANs for a that > >customer share the same MAC address domain and broadcast domain. > > > >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given > >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g., > >VLAN-100) and that P-VLAN corresponds to a single VPLS instance. > > > >Therefore, in both cases, a single P-VLAN correspond to a single VPLS > >instance and vise versa - e.g., one-to-one mapping. > > > >No. You misunderstand my point. I'm not talking about learning, I'm >talking about value-add service, such as rate-limited, access list control. >For learning,I agree with you, one P-VLAN to one VPLS-instance is enough. >But for value-add service, it is not enough, require many P-VLANs to one >VPLS-instance. For unqualified learning, customer's VLANs are transparent to the SP. And as the matter of fact there is single MAC address domain and broadcast domain for all the VLAN of that customer. So what that means is the customer's MAC addresses need to be unique across all the VLANs or else unqualified learning would not work for that customer. So, given that all MAC addresses of a given customer are unique, then you can run ACL based on customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified learning, then you simply copy the CoS bits of the inner tag to he outer tag and perform QoS on the P-VLAN tag. The situation for qualified learning, should be clear since there is no outer-tag and P-VLAN is just a mapping of the C-VLAN. If this is yet not clear to you, please clearly state the issue with an example. -Ali ------_=_NextPart_001_01C303B3.67405BEA Content-Type: text/html; charset="iso-8859-1" RE: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft

Ali,

 Let's consider the following relationships

 Many C-VLANs   - to one PVLAN -> one access domain
 many PVLANs    - to one VPLS instance

 I agree with Du Wenhua that suporting many PVLANs per one VPLS instance
 it is very valuable and it should not be restricted by your model.
 A PVLAN can be seen as an aggretae VPN member in the VPLS port, where
 different polcies can be applied.

 However, I don't see in the draft how the PVLAN/CVLAN information is
 sent in the Control plan, so the mapping and re-mapping in the access
 doamins can be done correctly. The current VFEC doesn't work for this
 type of access domain.


Cheers
   Vasile

-----Original Message-----
From: Ali Sajassi [mailto:sajassi@cisco.com]
Sent: Tuesday, April 15, 2003 7:40 PM
To: Du Wenhua; Ali Sajassi; Radoaca, Vasile [BL60:X624:EXCH]; Rick
Wilder
Cc: ppvpn@nortelnetworks.com
Subject: Re: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working
group draft



>
> >1) Unqualified learning: all traffic from a given customer is tagged by
> >P-VLAN, so if a customer is connected to a given access network through 10
> >different ACs (and through several different MTU-s), then all those ACs
> >will be tagged by the same P-VLAN. The P-VLAN as mentioned before
> >corresponds to a single VPLS instance. Thus, all C-VLANs for a that
> >customer share the same MAC address domain and broadcast domain.
> >
> >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given
> >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g.,
> >VLAN-100) and that P-VLAN corresponds to a single VPLS instance.
> >
> >Therefore, in both cases, a single P-VLAN correspond to a single VPLS
> >instance and vise versa - e.g., one-to-one mapping.
> >
>
>No. You misunderstand my point. I'm not talking about learning, I'm
>talking about value-add service, such as rate-limited, access list control.
>For learning,I agree with you, one P-VLAN to one VPLS-instance is enough.
>But for value-add service, it is not enough, require many P-VLANs to one
>VPLS-instance.

For unqualified learning, customer's VLANs are transparent to the SP. And
as the matter of fact there is single MAC address domain and broadcast
domain for all the VLAN of that customer. So what that means is the
customer's MAC addresses need to be unique across all the VLANs or else
unqualified learning would not work for that customer. So, given that all
MAC addresses of a given customer are unique, then you can run ACL based on
customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified
learning, then you simply copy the CoS bits of the inner tag to he outer
tag and perform QoS on the P-VLAN tag.

The situation for qualified learning, should be clear since there is no
outer-tag and P-VLAN is just a mapping of the C-VLAN.

If this is yet not clear to you, please clearly state the issue with an
example.

-Ali


------_=_NextPart_001_01C303B3.67405BEA-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 21:04: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 VAA18740 for ; Tue, 15 Apr 2003 21:04:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G16Sq11751 for ; Tue, 15 Apr 2003 21:06:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G16NC17431 for ; Tue, 15 Apr 2003 21:06:24 -0400 (EDT) Date: Wed, 16 Apr 2003 06:58:13 +0800 From: Du Wenhua Subject: Re: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft To: Ali Sajassi , Ali Sajassi , "Vasile Radoaca" , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDE00HRGQEGMJ@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA18740 Hi, Ali Sajassi See my comments. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-16 At 15:44:00 2003-04-15, Ali Sajassi wrote: >>At 06:12 AM 4/16/2003 +0800, Du Wenhua wrote: >>Hi, Ali Sajassi >> >> >>In this draft, there are two way to treat C-VLAN in MTU-rs: >> >>1)if C-VLAN are not used as service delimiter, add P-VLAN. >> >> In this way, the isssue is that if two C-VLAN map into same P-VLAN, >> >> the PE-rs can only distinguish two customer by C-VLANs. But, the C-VLAN >> >> is untrusted, is not service delimiter. It is wrong for PE-rs to apply >> >> different value-add service for different C-VLANs. >> >> So it is better to map into different P-VLANs for differnent custom >> >> if the PE-rs want to distinguish them. >> >>2)if C-VLAN are used as service delimiter, translating C-VLAN to a P-VLAN >> >> In this way, the issue is that if two C-VLAN are tranlated to one >> >> P-VLAN, the PE-rs will couldn't distinguish two customer. >> >> So it is better way to use different P-VLANs for different customers. >> > >> >I thought this has already been explained in the draft. If not it might >> >have been lost during editing. I will double check on this. >> > >>OK. Hope to add it, thanks. >>To PE-rs, P-VLAN is just looked as a AC , not be look as PW. Many ACs >>can be map to one VPLS-instance. So, many P-VLAN can map to one >>VPLS-instance also, even if these P-VLANs in one physical port. >>If the MTU just map each customer to each P-VLAN, it become a VPWS/VLL. >>MAC learning is removed in MTU. > >No, that's not correct. Lets go over it one more time. > >1) Unqualified learning: all traffic from a given customer is tagged by >P-VLAN, so if a customer is connected to a given access network through 10 >different ACs (and through several different MTU-s), then all those ACs >will be tagged by the same P-VLAN. The P-VLAN as mentioned before >corresponds to a single VPLS instance. Thus, all C-VLANs for a that >customer share the same MAC address domain and broadcast domain. > >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g., >VLAN-100) and that P-VLAN corresponds to a single VPLS instance. > >Therefore, in both cases, a single P-VLAN correspond to a single VPLS >instance and vise versa - e.g., one-to-one mapping. > No. You misunderstand my point. I'm not talking about learning, I'm talking about value-add service, such as rate-limited, access list control. For learning,I agree with you, one P-VLAN to one VPLS-instance is enough. But for value-add service, it is not enough, require many P-VLANs to one VPLS-instance. >-Ali > >> >> >> >> >> >> >Thanks, >> >Ali >> >> >> From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 21:20:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18949 for ; Tue, 15 Apr 2003 21:19:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G1M7q15135 for ; Tue, 15 Apr 2003 21:22:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G1M3C22940 for ; Tue, 15 Apr 2003 21:22:04 -0400 (EDT) Date: Wed, 16 Apr 2003 10:16:48 +0900 (JST) Message-Id: <20030416.101648.07580390.suzuki.muneyoshi@lab.ntt.co.jp> To: sajassi@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft From: Muneyoshi Suzuki In-Reply-To: <4.3.2.7.2.20030415152650.01cd0f88@airborne.cisco.com> References: <0HDE00H6MOA8SC@mta0.huawei.com> <4.3.2.7.2.20030415152650.01cd0f88@airborne.cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, > Therefore, in both cases, a single P-VLAN correspond to a single VPLS > instance and vise versa - e.g., one-to-one mapping. I'm not sure what is a VPLS instance in the above context, but if it means frame forwarding based on the P-VLAN ID value, I think, it may violate in-sequence delivery of frames. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 15 21:45:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19498 for ; Tue, 15 Apr 2003 21:45:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G1lcq18519 for ; Tue, 15 Apr 2003 21:47:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G1lZC02189 for ; Tue, 15 Apr 2003 21:47:35 -0400 (EDT) Date: Wed, 16 Apr 2003 10:41:10 +0900 (JST) Message-Id: <20030416.104110.71147346.suzuki.muneyoshi@lab.ntt.co.jp> To: ppvpn@nortelnetworks.com Cc: suzuki.muneyoshi@lab.ntt.co.jp Subject: Comments on the L2 VPN framework and solutions documents 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 I have a couple of comments on Emulated LAN which consists of VPLS forwarders and full mesh pseudo wires with split-horizon forwarding scheme, proposed in the L2 VPN framework as well as related solutions documents, such as draft-lasserre-vkompella-ppvpn-vpls-04.txt and draft-kompella-ppvpn-vpls-01.txt. (1) Protection racing This scheme does not terminate STP, so if a pseudo wire in the mesh fails, it may be restored with a MPLS protection mechanism. In this case, there is a possibility that the recovery time of the protection mechanism may affect failure detection of user-STP. For example, if an LSP in the mesh fails, LSP protection mechanism may recover it, however, if user-STP detects the failure simultaneously, then it re-organize the L2 topology in a few minutes; but after the re-organization, it also detects recovery of the failed LSP, then user-STP restore the original L2 topology in a few minutes. Finally, this wastes twice time of STP topology change and spoils fast MPLS protection mechanism. It is too unrealistic and dangerous to prohibit user-STP, it may leads broadcast loop, thus, I think interworking between user-STP and MPLS protection mechanism is needed. Note that, the above discussion assumes that the user-STP is working properly in the above situation. However, this assumption is doubtful. See the next comment. (2) Black hole From a viewpoint user-STP, Emulated LAN, which consists of VPLS forwarders and full mesh pseudo wires, is logically equivalent with a hub-repeater. Assume that the single SP network consists of PE Bridges and a single hub-repeater, and a PE Bridge port is connected to a port in the hub-repeater. In this case, if the hub-repeater entirely fails (that is, *all* LSPs fail at the same time), user-STP detects it and may re-organize user L2 topology, if possible (e.g., the user has a back door link). If a single port in the hub-repeater fails (that is, *all* LSPs connected to a single PE fail at the same time), user-STP also detects it and may re-organize the topology. However, failure of a single LSP in the mesh is logically equivalent with the situation that the communications between two ports in the hub- repeater fail, *but the remains are normal*. I'm not sure what happens in this case, because I think this kind of failure is not assumed in STP protocol design. I do not rigidly quantify what happens, but think there will be a black hole. MPLS protection/FRR mechanism does not solve this issue, because it can minimize probability of partial failure, but it does not eliminate the possibility. If the LSP recovery is unsuccessful, the user will encounter fatal situation. I believe the VPLS solution must be robust, that is, it must recover or lead the network to a safe status automatically however the network encounters a rare but fatal error. To enable large scale deployment, it must not force the operators and users to reboot boxes even if the worst case. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 02:09:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03566 for ; Wed, 16 Apr 2003 02:09:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G6AFn18410 for ; Wed, 16 Apr 2003 02:10:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G6AC313211 for ; Wed, 16 Apr 2003 02:10:12 -0400 (EDT) Message-ID: <013901c303de$eaded140$81c802c0@alok> From: "alok" To: "John Smith" , "Rajiv Asati" Cc: "Apcar, Jeff" , References: <11D2868F916DD411982D00508B694F431CE7CD60@syd-xch2.cisco.com> <4.3.2.7.2.20030415113306.0226a988@dingdong.cisco.com> Subject: Re: RD in 2547 bis Date: Wed, 16 Apr 2003 11:40:30 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Hi Rajiv/Robert, thanks for your reply, please see inline.... > Please keep in mind that RD is unique to a customer. > Now, when we get to the extranet, in which the customer1 and customer2 > exchange the routing information, it becomes much easier to control the > routing information based on RT. agreed....so it means you never use RD at *any point* but the local routing table? > > Also, with RT, we can simply check for one RT attribute and decide whether > we want 100s of MP_NLRI or not (the way BGP update is packed). If we had to > do this based on RD, then we really would have to go through each VPNv4 > prefix to find out whether it was a candidate for the import or not. i agree... so essentially, lets reframe my question as "why do we need to *propogate* both RD and RT to the MBGP peers, why not just RD"? RD is local to the router /used to distinguish VPNv4 routes locally, is my understanding. If an implementation choose to use a different "key" other than RD to identify a route locally, then? (you could say i am not > > I think it comes down to what gives us more granularity and control over > what we want to do. > > Cheers, > Rajiv > for Robert's comments: > Alok, > > Yes you could use only one, yes you could filter with RDs etc ... but > you will have to bind A) making the prefix uniqe with B) the > import/export policy which would be much less flexible in assinging > routes to VPN memberships then using RD just to make the vpn prefix > uniqe (mostly on RRs/ASBRs) and a list of route-targets attached to each > vpn route to decide where this route should be imported to. > isnt the use of "RD" local to the router? if an implementation choose a different "key" to uniquely identify the route, would it be wrong......? i still cant see why does one need to advertise RD? it may have a local significance in the router, but thats about it...... -Alok From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 02:26: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 CAA15900 for ; Wed, 16 Apr 2003 02:26:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G6Smn25411 for ; Wed, 16 Apr 2003 02:28:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G6Sg324668 for ; Wed, 16 Apr 2003 02:28:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416021745.0209f3e8@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 02:23:59 -0400 To: "alok" From: Rajiv Asati Subject: Re: RD in 2547 bis Cc: "John Smith" , "Apcar, Jeff" , In-Reply-To: <013901c303de$eaded140$81c802c0@alok> References: <11D2868F916DD411982D00508B694F431CE7CD60@syd-xch2.cisco.com> <4.3.2.7.2.20030415113306.0226a988@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: rajiva@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Alok, At 02:10 AM 4/16/2003, alok wrote: >Hi Rajiv/Robert, > >thanks for your reply, > >please see inline.... > > > Please keep in mind that RD is unique to a customer. > > Now, when we get to the extranet, in which the customer1 and customer2 > > exchange the routing information, it becomes much easier to control the > > routing information based on RT. > >agreed....so it means you never use RD at *any point* but the local routing >table? We shouldn't forget the presence of Route-Reflector in the network, and the RR also runs the best-path algorithm to select one best path before reflecting to its clients. > > > > Also, with RT, we can simply check for one RT attribute and decide whether > > we want 100s of MP_NLRI or not (the way BGP update is packed). If we had >to > > do this based on RD, then we really would have to go through each VPNv4 > > prefix to find out whether it was a candidate for the import or not. > >i agree... so essentially, lets reframe my question as "why do we need to >*propogate* both RD and RT to the MBGP peers, why not just RD"? Keep in mind that RD is not an attribute, where RT is. >RD is local to the router /used to distinguish VPNv4 routes locally, is my >understanding. RD becomes crucial with the presence of RRs. >If an implementation choose to use a different "key" other than RD to >identify a route locally, then? (you could say i am not As long as you can carry that all the way to the RR, so that even RR can treat each of the overlapping prefix distinctively, you should be fine. Let me repeat what I said earlier - > > I think it comes down to what gives us more granularity and control over > > what we want to do. Hope this helps. Cheers, Rajiv > > > > I think it comes down to what gives us more granularity and control over > > what we want to do. > > > > Cheers, > > Rajiv > > > >for Robert's comments: > > > Alok, > > > > Yes you could use only one, yes you could filter with RDs etc ... but > > you will have to bind A) making the prefix uniqe with B) the > > import/export policy which would be much less flexible in assinging > > routes to VPN memberships then using RD just to make the vpn prefix > > uniqe (mostly on RRs/ASBRs) and a list of route-targets attached to each > > vpn route to decide where this route should be imported to. > > >isnt the use of "RD" local to the router? if an implementation choose a >different "key" to uniquely identify the route, would it be wrong......? > >i still cant see why does one need to advertise RD? it may have a local >significance in the router, but thats about it...... > >-Alok From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 02:30:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16734 for ; Wed, 16 Apr 2003 02:30:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G6WIn28832 for ; Wed, 16 Apr 2003 02:32:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G6WE329004 for ; Wed, 16 Apr 2003 02:32:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416022609.022bd0e8@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 02:29:05 -0400 To: "alok" From: Rajiv Asati Subject: Re: two BGP best routes with different RD, but same IPv4 prefix Cc: In-Reply-To: <020c01c303e0$e7c04140$81c802c0@alok> References: <39469E08BD83D411A3D900204840EC55D7BB75@vie-msgusr-01.dc.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: rajiva@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Alok, This requirement usually comes when the customer site is multihomed to the provider's network. One such topology shown below - x.x.x.x------CE1----PE1----------mpls-----PE3------CE3 |___PE2---------| Cheers, Rajiv At 02:24 AM 4/16/2003, alok wrote: >if ur doing that, u are assuming that you can have 2 hosts with IP >a.b.c.d/32 in ur network... > >i dont think its right to be doing so in the 1st place. > >-rgds >Alok >----- Original Message ----- >From: Ju, Yu >To: >Sent: Tuesday, April 15, 2003 10:03 PM >Subject: two BGP best routes with different RD, but same IPv4 prefix > > > > Hi, > > > > If a PE router receive two VPN-IPv4 routes with different RD and the same > > IPv4 prefix, suppose both pass the RT import checking and both are the >best > > BGP route, should BGP install both routes (have the same IPv4 prefix) in >the > > VRF routing table? > > > > Thanks, > > > > Yu > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 02:30: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 CAA17167 for ; Wed, 16 Apr 2003 02:30:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G6Wvn29552 for ; Wed, 16 Apr 2003 02:32:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G6Wq329785 for ; Wed, 16 Apr 2003 02:32:53 -0400 (EDT) Message-ID: <020c01c303e0$e7c04140$81c802c0@alok> From: "alok" To: References: <39469E08BD83D411A3D900204840EC55D7BB75@vie-msgusr-01.dc.fore.com> Subject: Re: two BGP best routes with different RD, but same IPv4 prefix Date: Wed, 16 Apr 2003 11:54:48 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: if ur doing that, u are assuming that you can have 2 hosts with IP a.b.c.d/32 in ur network... i dont think its right to be doing so in the 1st place. -rgds Alok ----- Original Message ----- From: Ju, Yu To: Sent: Tuesday, April 15, 2003 10:03 PM Subject: two BGP best routes with different RD, but same IPv4 prefix > Hi, > > If a PE router receive two VPN-IPv4 routes with different RD and the same > IPv4 prefix, suppose both pass the RT import checking and both are the best > BGP route, should BGP install both routes (have the same IPv4 prefix) in the > VRF routing table? > > Thanks, > > Yu > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 02:37:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19921 for ; Wed, 16 Apr 2003 02:37:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G6dhn02157 for ; Wed, 16 Apr 2003 02:39:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G6dc303461 for ; Wed, 16 Apr 2003 02:39:39 -0400 (EDT) Message-ID: <024401c303e3$0d32d300$81c802c0@alok> From: "alok" To: "Rajiv Asati" Cc: References: <39469E08BD83D411A3D900204840EC55D7BB75@vie-msgusr-01.dc.fore.com> <4.3.2.7.2.20030416022609.022bd0e8@dingdong.cisco.com> Subject: Re: two BGP best routes with different RD, but same IPv4 prefix Date: Wed, 16 Apr 2003 12:10:09 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Hi Rajiv, am a bit lost... different RD???? please explain the defination of RD .. (as stated by you in the previous mail).. i assumed you said it "helps identify the VPN the customer belongs too etc.." are you saying the same customer can be "multihomed" 2 routers and we would give him different "RD" on each end? -rgds Alok ----- Original Message ----- From: Rajiv Asati To: alok Cc: Sent: Wednesday, April 16, 2003 11:59 AM Subject: Re: two BGP best routes with different RD, but same IPv4 prefix > Alok, > > This requirement usually comes when the customer site is multihomed to the > provider's network. > One such topology shown below - > > x.x.x.x------CE1----PE1----------mpls-----PE3------CE3 > |___PE2---------| > > Cheers, > Rajiv > > At 02:24 AM 4/16/2003, alok wrote: > >if ur doing that, u are assuming that you can have 2 hosts with IP > >a.b.c.d/32 in ur network... > > > >i dont think its right to be doing so in the 1st place. > > > >-rgds > >Alok > >----- Original Message ----- > >From: Ju, Yu > >To: > >Sent: Tuesday, April 15, 2003 10:03 PM > >Subject: two BGP best routes with different RD, but same IPv4 prefix > > > > > > > Hi, > > > > > > If a PE router receive two VPN-IPv4 routes with different RD and the same > > > IPv4 prefix, suppose both pass the RT import checking and both are the > >best > > > BGP route, should BGP install both routes (have the same IPv4 prefix) in > >the > > > VRF routing table? > > > > > > Thanks, > > > > > > Yu > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 02:48:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20338 for ; Wed, 16 Apr 2003 02:48:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G6oen05644 for ; Wed, 16 Apr 2003 02:50:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G6oa308925 for ; Wed, 16 Apr 2003 02:50:36 -0400 (EDT) Message-ID: <026601c303e4$91f6c000$81c802c0@alok> From: "alok" To: "Rajiv Asati" Cc: "John Smith" , "Apcar, Jeff" , References: <11D2868F916DD411982D00508B694F431CE7CD60@syd-xch2.cisco.com><4.3.2.7.2.20030415113306.0226a988@dingdong.cisco.com> <4.3.2.7.2.20030416021745.0209f3e8@dingdong.cisco.com> Subject: Re: RD in 2547 bis Date: Wed, 16 Apr 2003 12:20:59 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Hi Rajiv, > >Hi Rajiv/Robert, > > > >thanks for your reply, > > > >please see inline.... > > > > > Please keep in mind that RD is unique to a customer. > > > Now, when we get to the extranet, in which the customer1 and customer2 > > > exchange the routing information, it becomes much easier to control the > > > routing information based on RT. > > > >agreed....so it means you never use RD at *any point* but the local routing > >table? > > > We shouldn't forget the presence of Route-Reflector in the network, and the > RR also runs the best-path algorithm to select one best path before > reflecting to its clients. > agreed......... but RD is a key "local" to the router? its just a "router's local way" of distinguishing routes? could you elaborate your "best path algorithm"... > > > > > > > Also, with RT, we can simply check for one RT attribute and decide whether > > > we want 100s of MP_NLRI or not (the way BGP update is packed). If we had > >to > > > do this based on RD, then we really would have to go through each VPNv4 > > > prefix to find out whether it was a candidate for the import or not. > > > >i agree... so essentially, lets reframe my question as "why do we need to > >*propogate* both RD and RT to the MBGP peers, why not just RD"? > > Keep in mind that RD is not an attribute, where RT is. > > this point got me thinking.... are you saying that BGP decisions are made solely on NLRI values and not on attributes? and AFAIK, the ADJ_RIB_IN defination says "it contains all *unprocessed* information learnt from peers. > > RD becomes crucial with the presence of RRs. please explain please tell me what happens if i dont "propogate" RD? isnt the RD nothing but a "local KEY" to identify routes? which are anyways propogated/imported/exported with RT? cant i use a different "key" which is "local to the router"... my point being that since the significance of RD is local to the router (as far as my understanding goes) why should it be "propogated" or even mentioned in a signalling draft? > > > >If an implementation choose to use a different "key" other than RD to > >identify a route locally, then? (you could say i am not > > As long as you can carry that all the way to the RR, so that even RR can > treat each of the overlapping prefix distinctively, you should be fine. > err no, the RR would have RT to look at, wouldnt it? and then use a "local" tag/key? my point is that why should it be "carried at all" are you planning to have multiple hosts in the same VPN with the same IPv4 address??? > Let me repeat what I said earlier - > > > > I think it comes down to what gives us more granularity and control over > > > what we want to do. why does one need to carry the same? i would tag via "RT" (since RD is too small as stated in 2547)... i understand and appreciate the point that "more parameters" mean "more flexibility".... but i want to know how RT doesnt give one the same flexibility... would appreciate if you could clarify... -thanks & rgds Alok From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 04:43: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 EAA22669 for ; Wed, 16 Apr 2003 04:43:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G8jan04105 for ; Wed, 16 Apr 2003 04:45:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G8jX324334 for ; Wed, 16 Apr 2003 04:45:33 -0400 (EDT) Message-ID: <20030416084307.62922.qmail@web41807.mail.yahoo.com> Date: Wed, 16 Apr 2003 09:43:07 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Re: RD in 2547 bis To: rajiva@cisco.com Cc: ppvpn@lyris.nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41807.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web41807.mail.yahoo.com [66.218.93.141] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Rajiv, comments inline .. > > We shouldn't forget the presence of Route-Reflector in the network, and the > RR also runs the best-path algorithm to select one best path before > reflecting to its clients. AFAIK there are no special requirements which arise in case of Route Reflector deployments wrt RDs. All we need to ensure is that we must have no unneccessary advertisements of routes to any PE routers which dont import any one of them. We need to split the network into multiple RR clusters, each servicing some number of VPNs. The PE router clients of these RRs will then receive only routes that belong to the relevant VPNs that they service. > > > > > > > > Also, with RT, we can simply check for one RT attribute and decide whether > > > we want 100s of MP_NLRI or not (the way BGP update is packed). If we had > >to > > > do this based on RD, then we really would have to go through each VPNv4 > > > prefix to find out whether it was a candidate for the import or not. > > Agree with this point of yours. > > > >RD is local to the router /used to distinguish VPNv4 routes locally, is my > >understanding. > > RD becomes crucial with the presence of RRs. How come? Can you please give me some pointers as to how RD becomes "crucial" in presence of RRs. > > > > I think it comes down to what gives us more granularity and control over > > > what we want to do. I think this is it. And nothing else. We can also work out with having just one RT but then having both gives us some greater control over what we want to do! JS __________________________________________________ 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 Wed Apr 16 04:47:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22857 for ; Wed, 16 Apr 2003 04:47:24 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3G8nUn07604 for ; Wed, 16 Apr 2003 04:49:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3G8nR328740 for ; Wed, 16 Apr 2003 04:49:27 -0400 (EDT) Message-ID: <20030416084654.63548.qmail@web41807.mail.yahoo.com> Date: Wed, 16 Apr 2003 09:46:54 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Re: two BGP best routes with different RD, but same IPv4 prefix To: rajiva@cisco.com Cc: ppvpn@lyris.nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41807.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web41807.mail.yahoo.com [66.218.93.141] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Rajiv, Can you please explain this to us some more. I think it is illegal to advertise the same IPv4 prefix using different RDs. What use will it be? Thanks, JS ----- Original Message ----- From: "Rajiv Asati" To: "alok" Cc: Sent: Wednesday, April 16, 2003 11:59 AM Subject: Re: two BGP best routes with different RD, but same IPv4 prefix > Alok, > > This requirement usually comes when the customer site is multihomed to the > provider's network. > One such topology shown below - > > x.x.x.x------CE1----PE1----------mpls-----PE3------CE3 > |___PE2---------| > > Cheers, > Rajiv > > At 02:24 AM 4/16/2003, alok wrote: > >if ur doing that, u are assuming that you can have 2 hosts with IP > >a.b.c.d/32 in ur network... > > > >i dont think its right to be doing so in the 1st place. > > > >-rgds > >Alok > >----- Original Message ----- > >From: Ju, Yu > >To: > >Sent: Tuesday, April 15, 2003 10:03 PM > >Subject: two BGP best routes with different RD, but same IPv4 prefix > > > > > > > Hi, > > > > > > If a PE router receive two VPN-IPv4 routes with different RD and the same > > > IPv4 prefix, suppose both pass the RT import checking and both are the > >best > > > BGP route, should BGP install both routes (have the same IPv4 prefix) in > >the > > > VRF routing table? > > > > > > Thanks, > > > > > > Yu > > > > > > > > > > > __________________________________________________ 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 Wed Apr 16 06:23:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24392 for ; Wed, 16 Apr 2003 06:23:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GAP7n28192 for ; Wed, 16 Apr 2003 06:25:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GAP3304863 for ; Wed, 16 Apr 2003 06:25:04 -0400 (EDT) X-Originating-IP: [203.124.140.97] X-Originating-Email: [sylvia_sugar@hotmail.com] From: "Sylvia Sugar" To: ppvpn@lyris.nortelnetworks.com Subject: Re: RD in 2547 bis Date: Wed, 16 Apr 2003 10:22:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2003 10:22:42.0019 (UTC) FILETIME=[1D0AAB30:01C30402] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: sylvia_sugar@hotmail.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: bay1-f170.bay1.hotmail.com [65.54.245.170] X-LYRIS-Message-Id: Hello, We were involved in an MPLS design for a service provider here. I would like to know the following: > > > > Also, with RT, we can simply check for one RT attribute and decide >whether > > > > we want 100s of MP_NLRI or not (the way BGP update is packed). If we >had > > >to > > > > do this based on RD, then we really would have to go through each >VPNv4 > > > > prefix to find out whether it was a candidate for the import or not. > > > > >Agree with this point of yours. This is what is confusing me. From what my book says authored by cisco press, use route targets to assign routes to put routes into a VRF. So we anyways use the "Route Target attribute" for this. > > > > > >RD is local to the router /used to distinguish VPNv4 routes >locally, is my > > >understanding. > > > RD becomes crucial with the presence of RRs. > >How come? Can you please give me some pointers as to how RD becomes >"crucial" in presence >of RRs. > > > > > > I think it comes down to what gives us more granularity and >control over > > > > what we want to do. > >I think this is it. And nothing else. We can also work out with having just >one RT but >then having both gives us some greater control over what we want to do! > Yes Mr Smith, but how does not having Route Distinguisher affect things. I have no example in this book which shows me how to use "Route Distinguisher" can help. It doesnt get used to filter routes either. It seems to be nothing but local. Maybe its not in this book. Can someone please suggest some good book to read to clarify this? Can you please explain the "what we want to do" bit? -SylviaXO _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 06:48:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24778 for ; Wed, 16 Apr 2003 06:48:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GAobn02659 for ; Wed, 16 Apr 2003 06:50:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GAoX317195 for ; Wed, 16 Apr 2003 06:50:33 -0400 (EDT) Message-ID: <20030416104717.4661.qmail@web41803.mail.yahoo.com> Date: Wed, 16 Apr 2003 11:47:17 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Re: RD in 2547 bis To: Sylvia Sugar , ppvpn@lyris.nortelnetworks.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41803.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web41803.mail.yahoo.com [66.218.93.137] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Sugar, > > This is what is confusing me. > From what my book says authored by cisco press, use route targets to assign > routes to put routes into a VRF. So we anyways use the "Route Target > attribute" for this. Righto! What i agreed to was that searching for which prefixes need to be inserted in which VRFs by looking at the RDs is not only unpractical .. but down right stupidity and brain dead also! How? Let me explain you. Suppose you decide one day to look at the RD to decide which routes should go into which VRF. The problem is that if a BGP peer sends you 10,000 prefixes then you will need to lookup 10000 times to insert routes into your VRF. With the RT concept, all the routes are tagged with just one RT extended community attribute and you by looking at this can decide which VRF to insert the routes to. This does increase the scalability and also gives you more control over the routes which are advertised using BGP. > > > > > > > >RD is local to the router /used to distinguish VPNv4 routes > >locally, is my > > > >understanding. > > > > RD becomes crucial with the presence of RRs. > > > >How come? Can you please give me some pointers as to how RD becomes > >"crucial" in presence > >of RRs. > > > > > > > > I think it comes down to what gives us more granularity and > >control over > > > > > what we want to do. > > > >I think this is it. And nothing else. We can also work out with having just > >one RT but > >then having both gives us some greater control over what we want to do! > > > > > Yes Mr Smith, but how does not having Route Distinguisher affect things. Did i ever say that Sugar? > > I have no example in this book which shows me how to use "Route > Distinguisher" can help. It doesnt get used to filter routes either. It > seems to be nothing but local. > > Maybe its not in this book. Can someone please suggest some good book to > read to clarify this? Try one by Ivan Pepelnjak and Jim Guichard > > Can you please explain the "what we want to do" bit? couldnt get you? JS __________________________________________________ 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 Wed Apr 16 07:37:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25953 for ; Wed, 16 Apr 2003 07:37:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GBdgn14785 for ; Wed, 16 Apr 2003 07:39:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GBdd323997 for ; Wed, 16 Apr 2003 07:39:39 -0400 (EDT) Message-ID: <059901c3040c$f3f2cc40$81c802c0@alok> From: "alok" To: References: <20030416104717.4661.qmail@web41803.mail.yahoo.com> Subject: Re: RD in 2547 bis Date: Wed, 16 Apr 2003 17:10:06 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Hi John, ----- Original Message ----- From: John Smith To: Sylvia Sugar ; Sent: Wednesday, April 16, 2003 4:17 PM Subject: Re: RD in 2547 bis > Sugar, > > > > > This is what is confusing me. > > From what my book says authored by cisco press, use route targets to assign > > routes to put routes into a VRF. So we anyways use the "Route Target > > attribute" for this. > > Righto! What i agreed to was that searching for which prefixes need to be inserted in > which VRFs by looking at the RDs is not only unpractical .. but down right stupidity and > brain dead also! > > How? > > Let me explain you. > > Suppose you decide one day to look at the RD to decide which routes should go into which > VRF. The problem is that if a BGP peer sends you 10,000 prefixes then you will need to > lookup 10000 times to insert routes into your VRF. > > With the RT concept, all the routes are tagged with just one RT extended community > attribute and you by looking at this can decide which VRF to insert the routes to. > > This does increase the scalability and also gives you more control over the routes which > are advertised using BGP. > thanks for clarifying this. *I never realised* that we dont look at "MBGP NLRIs- *one by one*" for BGP decision process to compare things with the existing entries in the LOCAL_RIB. thanks again, Alok From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 08:46:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28421 for ; Wed, 16 Apr 2003 08:46:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GCmjn29162 for ; Wed, 16 Apr 2003 08:48:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GCmg308874 for ; Wed, 16 Apr 2003 08:48:42 -0400 (EDT) Message-Id: <200304161246.h3GCk4B0023726@rtp-core-1.cisco.com> To: John Smith cc: rajiva@cisco.com, ppvpn@lyris.nortelnetworks.com Subject: Re: two BGP best routes with different RD, but same IPv4 prefix In-reply-to: Your message of Wed, 16 Apr 2003 09:46:54 +0100. <20030416084654.63548.qmail@web41807.mail.yahoo.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: Wed, 16 Apr 2003 08:46:04 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: The RD does not in any way identify the VPN the customer belongs to. One possible deployment methodology is to use a distinct RD for each VRF. Then if a customer site is multi-homed, each IPv4 address prefix from that site will appear in the BGP tables as two VPN-IP address prefixes. Those two VPN-IP prefixes likely have the same set of RTs, and hence are importable into the same set of VRFs. Of course, they can't both be imported into any given VRF. The relevant internet-drafts are not quite explicit about how you choose which one gets into the VRF. Perhaps this is something that needs to be clarified. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 12:28: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 MAA07637 for ; Wed, 16 Apr 2003 12:28:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GGUKn05555 for ; Wed, 16 Apr 2003 12:30:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GGUH313045 for ; Wed, 16 Apr 2003 12:30:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416084523.01b8d2b8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 09:08:57 -0700 To: "Vasile Radoaca" , "'Ali Sajassi'" , Du Wenhua , Rick Wilder From: Ali Sajassi Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working gr oup draft Cc: ppvpn@nortelnetworks.com In-Reply-To: <8B888AAAAB0FD31189590008C79184430C7A6AE3@zbl6c002.corpeast .baynetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3139975==_.ALT" X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: --=====================_3139975==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:59 PM 4/15/2003 -0400, Vasile Radoaca wrote: >Ali, > > Let's consider the following relationships > > Many C-VLANs - to one PVLAN -> one access domain > many PVLANs - to one VPLS instance As I said before, you can HAVE many PVLANs in different access domain mapping to the same VPLS (each access domain is independent from other access domains and thus each access domain can assign its own PVLAN independent from the others). However, the issue was whether there can be many PVLANs in the same access domain mapping to a single VPLS instance. And the answer is NO. As I have repeated many times, PVLAN is just a VPLS-id within a QinQ domain and thus there is a one-to-one relationship in a given access domain. > I agree with Du Wenhua that suporting many PVLANs per one VPLS instance > it is very valuable and it should not be restricted by your model. There is no restriction in model what so ever !!! If you think there is, then elaborate !! > A PVLAN can be seen as an aggretae VPN member in the VPLS port, where > different polcies can be applied. Are we talking about qualified and unqualified learning or something else !!! unqualified learning is: one VPLS instance for all customer's traffic (tagged and untagged) qualified learning is one VPLS instance per customer VLAN and in both cases, the VPLS instance is represented by a P-VLAN (in each access domain). Now, what is the problem ??? > However, I don't see in the draft how the PVLAN/CVLAN information is > sent in the Control plan, so the mapping and re-mapping in the access > doamins can be done correctly. The current VFEC doesn't work for this > type of access domain. PVLAN configuration is NOT the issue here. So please lets not convolute the issue at hand (PVLAN can easily be configured through NMS as it is done today). -Ali >Cheers > Vasile > >-----Original Message----- >From: Ali Sajassi [mailto:sajassi@cisco.com] >Sent: Tuesday, April 15, 2003 7:40 PM >To: Du Wenhua; Ali Sajassi; Radoaca, Vasile [BL60:X624:EXCH]; Rick >Wilder >Cc: ppvpn@nortelnetworks.com >Subject: Re: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working >group draft > > > > > > >1) Unqualified learning: all traffic from a given customer is tagged by > > >P-VLAN, so if a customer is connected to a given access network > through 10 > > >different ACs (and through several different MTU-s), then all those ACs > > >will be tagged by the same P-VLAN. The P-VLAN as mentioned before > > >corresponds to a single VPLS instance. Thus, all C-VLANs for a that > > >customer share the same MAC address domain and broadcast domain. > > > > > >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a > given > > >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN > (e.g., > > >VLAN-100) and that P-VLAN corresponds to a single VPLS instance. > > > > > >Therefore, in both cases, a single P-VLAN correspond to a single VPLS > > >instance and vise versa - e.g., one-to-one mapping. > > > > > > >No. You misunderstand my point. I'm not talking about learning, I'm > >talking about value-add service, such as rate-limited, access list control. > >For learning,I agree with you, one P-VLAN to one VPLS-instance is enough. > >But for value-add service, it is not enough, require many P-VLANs to one > >VPLS-instance. > >For unqualified learning, customer's VLANs are transparent to the SP. And >as the matter of fact there is single MAC address domain and broadcast >domain for all the VLAN of that customer. So what that means is the >customer's MAC addresses need to be unique across all the VLANs or else >unqualified learning would not work for that customer. So, given that all >MAC addresses of a given customer are unique, then you can run ACL based on >customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified >learning, then you simply copy the CoS bits of the inner tag to he outer >tag and perform QoS on the P-VLAN tag. > >The situation for qualified learning, should be clear since there is no >outer-tag and P-VLAN is just a mapping of the C-VLAN. > >If this is yet not clear to you, please clearly state the issue with an >example. > >-Ali --=====================_3139975==_.ALT Content-Type: text/html; charset="us-ascii" At 08:59 PM 4/15/2003 -0400, Vasile Radoaca wrote:

Ali,

 Let's consider the following relationships

 Many C-VLANs   - to one PVLAN -> one access domain
 many PVLANs    - to one VPLS instance

As I said before, you can HAVE many PVLANs in different access domain mapping to the same VPLS (each access domain is independent from other access domains and thus each access domain can assign its own PVLAN independent from the others).
However, the issue was whether there can be many PVLANs in the same access domain mapping to a single VPLS instance. And the answer is NO.
As I have repeated many times, PVLAN is just a VPLS-id within a QinQ domain and thus there is a one-to-one relationship in a given access domain.


 I agree with Du Wenhua that suporting many PVLANs per one VPLS instance
 it is very valuable and it should not be restricted by your model.

There is no restriction in model what so ever !!! If you think there is, then elaborate !!

 A PVLAN can be seen as an aggretae VPN member in the VPLS port, where
 different polcies can be applied.

Are we talking about qualified and unqualified learning or something else !!!
unqualified learning is: one VPLS instance for all customer's traffic (tagged and untagged)
qualified learning is one VPLS instance per customer VLAN
and in both cases, the VPLS instance is represented by a P-VLAN (in each access domain). Now, what is the problem ???


 However, I don't see in the draft how the PVLAN/CVLAN information is
 sent in the Control plan, so the mapping and re-mapping in the access
 doamins can be done correctly. The current VFEC doesn't work for this
 type of access domain.

PVLAN configuration is NOT the issue here. So please lets not convolute the issue at hand (PVLAN can easily be configured through NMS as it is done today).

-Ali


Cheers
   Vasile

-----Original Message-----
From: Ali Sajassi [mailto:sajassi@cisco.com]
Sent: Tuesday, April 15, 2003 7:40 PM
To: Du Wenhua; Ali Sajassi; Radoaca, Vasile [BL60:X624:EXCH]; Rick
Wilder
Cc: ppvpn@nortelnetworks.com
Subject: Re: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working
group draft


>
> >1) Unqualified learning: all traffic from a given customer is tagged by
> >P-VLAN, so if a customer is connected to a given access network through 10
> >different ACs (and through several different MTU-s), then all those ACs
> >will be tagged by the same P-VLAN. The P-VLAN as mentioned before
> >corresponds to a single VPLS instance. Thus, all C-VLANs for a that
> >customer share the same MAC address domain and broadcast domain.
> >
> >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given
> >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g.,
> >VLAN-100) and that P-VLAN corresponds to a single VPLS instance.
> >
> >Therefore, in both cases, a single P-VLAN correspond to a single VPLS
> >instance and vise versa - e.g., one-to-one mapping.
> >
>
>No. You misunderstand my point. I'm not talking about learning, I'm
>talking about value-add service, such as rate-limited, access list control.
>For learning,I agree with you, one P-VLAN to one VPLS-instance is enough.
>But for value-add service, it is not enough, require many P-VLANs to one
>VPLS-instance.

For unqualified learning, customer's VLANs are transparent to the SP. And
as the matter of fact there is single MAC address domain and broadcast
domain for all the VLAN of that customer. So what that means is the
customer's MAC addresses need to be unique across all the VLANs or else
unqualified learning would not work for that customer. So, given that all
MAC addresses of a given customer are unique, then you can run ACL based on
customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified
learning, then you simply copy the CoS bits of the inner tag to he outer
tag and perform QoS on the P-VLAN tag.

The situation for qualified learning, should be clear since there is no
outer-tag and P-VLAN is just a mapping of the C-VLAN.

If this is yet not clear to you, please clearly state the issue with an
example.

-Ali
--=====================_3139975==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 12:29:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07683 for ; Wed, 16 Apr 2003 12:29:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GGVZn06901 for ; Wed, 16 Apr 2003 12:31:35 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GGVV314777 for ; Wed, 16 Apr 2003 12:31:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416091152.0161acd0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 09:21:05 -0700 To: Muneyoshi Suzuki , sajassi@cisco.com From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp In-Reply-To: <20030416.101648.07580390.suzuki.muneyoshi@lab.ntt.co.jp> References: <4.3.2.7.2.20030415152650.01cd0f88@airborne.cisco.com> <0HDE00H6MOA8SC@mta0.huawei.com> <4.3.2.7.2.20030415152650.01cd0f88@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 10:16 AM 4/16/2003 +0900, Muneyoshi Suzuki wrote: >Ali, > > > Therefore, in both cases, a single P-VLAN correspond to a single VPLS > > instance and vise versa - e.g., one-to-one mapping. > >I'm not sure what is a VPLS instance in the above context, but if it >means frame forwarding based on the P-VLAN ID value, I think, it may >violate in-sequence delivery of frames. For a description of VPLS instance in context of qualified and unqualified learning and its relationship to customer VLANs, please refer to sec. 8.1.1 of the draft and then tell me why "it may violate in-sequence delivery". P-VLAN id just like a VPLS-instance id identifies a given FIB and the forwarding is done based on customer's MAC addresses within that FIB. -Ali >Thanks, > > >Muneyoshi Suzuki >Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 12:31: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 MAA07792 for ; Wed, 16 Apr 2003 12:31:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GGXfn09178 for ; Wed, 16 Apr 2003 12:33:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GGXc317539 for ; Wed, 16 Apr 2003 12:33:38 -0400 (EDT) Date: Thu, 17 Apr 2003 00:19:52 +0800 From: Du Wenhua Subject: Re: Re: Re: Re: RE: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft To: Ali Sajassi , Ali Sajassi , "Vasile Radoaca" , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDG00JDE2MJUK@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07792 Hi, Ali Sajassi See my comment bellow. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-16 At 16:40:00 2003-04-15, Ali Sajassi wrote: >>> >> >1) Unqualified learning: all traffic from a given customer is tagged by >> >P-VLAN, so if a customer is connected to a given access network through 10 >> >different ACs (and through several different MTU-s), then all those ACs >> >will be tagged by the same P-VLAN. The P-VLAN as mentioned before >> >corresponds to a single VPLS instance. Thus, all C-VLANs for a that >> >customer share the same MAC address domain and broadcast domain. >> > >> >2) Qualified learning: each C-VLAN is represented by a P-VLAN. Thus a given >> >C-VLAN (e.g., VLAN-10) over different ACs maps into a unique P-VLAN (e.g., >> >VLAN-100) and that P-VLAN corresponds to a single VPLS instance. >> > >> >Therefore, in both cases, a single P-VLAN correspond to a single VPLS >> >instance and vise versa - e.g., one-to-one mapping. >> > >> >>No. You misunderstand my point. I'm not talking about learning, I'm >>talking about value-add service, such as rate-limited, access list control. >>For learning,I agree with you, one P-VLAN to one VPLS-instance is enough. >>But for value-add service, it is not enough, require many P-VLANs to one >>VPLS-instance. > >For unqualified learning, customer's VLANs are transparent to the SP. And >as the matter of fact there is single MAC address domain and broadcast >domain for all the VLAN of that customer. So what that means is the >customer's MAC addresses need to be unique across all the VLANs or else >unqualified learning would not work for that customer. So, given that all >MAC addresses of a given customer are unique, then you can run ACL based on >customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified >learning, then you simply copy the CoS bits of the inner tag to he outer >tag and perform QoS on the P-VLAN tag. > >The situation for qualified learning, should be clear since there is no >outer-tag and P-VLAN is just a mapping of the C-VLAN. > >If this is yet not clear to you, please clearly state the issue with an >example. > Ok, I give an example. Two customers A and B are connected a MTU via different physcal ports, the MTU is connected to a PE-rs via one physical port.The PE-rs aplly rate-limit of 5Mbps to customer A, and apply rate-limit of 10Mbps to customer B. How can the PE-rs distinguish the two customer? (1)Your answer is run ACL on customer's MAC. But, Customer MAC is untrusted, because the provider do not know customer MAC, and the MAC will change frequently so need to change ACL frequently. So,it is difficult to use ACL based on customer MAC. (2)My unswer is to run ACL based on P-VLAN, customer A and customer B have different P-VLAN. P-VLAN is trusted, P-VLAN would not change frequently, provider known P-VLAN. It is better than run ACL based on customer MAC. >-Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 13:14: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 NAA08748 for ; Wed, 16 Apr 2003 13:14:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GHGmn01630 for ; Wed, 16 Apr 2003 13:16:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GHGi316932 for ; Wed, 16 Apr 2003 13:16:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416092231.0161b738@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 10:11:53 -0700 To: Du Wenhua , Ali Sajassi , "Vasile Radoaca" , Rick Wilder From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDE00I13YZ73I@mta0.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: > >For unqualified learning, customer's VLANs are transparent to the SP. And > >as the matter of fact there is single MAC address domain and broadcast > >domain for all the VLAN of that customer. So what that means is the > >customer's MAC addresses need to be unique across all the VLANs or else > >unqualified learning would not work for that customer. So, given that all > >MAC addresses of a given customer are unique, then you can run ACL based on > >customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified > >learning, then you simply copy the CoS bits of the inner tag to he outer > >tag and perform QoS on the P-VLAN tag. > > > >The situation for qualified learning, should be clear since there is no > >outer-tag and P-VLAN is just a mapping of the C-VLAN. > > > >If this is yet not clear to you, please clearly state the issue with an > >example. > > >Ok, I give an example. >Two customers A and B are connected a MTU via different physcal ports, >the MTU is connected to a PE-rs via one physical port.The PE-rs aplly >rate-limit of 5Mbps to customer A, and apply rate-limit of 10Mbps to >customer B. >How can the PE-rs distinguish the two customer? >(1)Your answer is run ACL on customer's MAC. >But, Customer MAC is untrusted, because the provider do not know customer >MAC, >and the MAC will change frequently so need to change ACL frequently. >So,it is difficult to use ACL based on customer MAC. >(2)My unswer is to run ACL based on P-VLAN, customer A and customer B have >different P-VLAN. >P-VLAN is trusted, P-VLAN would not change frequently, provider known >P-VLAN. It is better than >run ACL based on customer MAC. No, there is still confusion and your confusion may be about VPLS instance First, are these two customers part of the same VPLS instance or not ? If they are then they are using the same FIB and they need to coordinate their MAC addresses with each other in order not to have overlapping MAC addresses (refer to sec. 8.1.1). Because both customers are part of the same VPLS instance, then they will be identified by the same P-VLAN. However, if each customer has its own VPLS instance, then they have their own FIB (and MAC address space) and each will be identified by its own VPLS-instance id and P-VLAN id. Second, regarding the rate limiting and traffic policing. Policing and shaping functionality should be done as close to the edge as possible (before congestion point) and they are done at the MTU-s (not PE-rs) and they are performed on a per AC basis (AC can be either customer port for unqualified learning and customer VLAN for qualified learning). Some of these stuff is described in MEF white paper and you may want to take a look at it. So for a given customer that has multiple sites connected to the same MTU-s, the QoS (rate limiting, shaping, policing) is performed on per customer site (e.g., per AC) basis. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 15:04: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 PAA12167 for ; Wed, 16 Apr 2003 15:04:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GJ6On04041 for ; Wed, 16 Apr 2003 15:06:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GJ6J303446 for ; Wed, 16 Apr 2003 15:06:19 -0400 (EDT) Message-ID: From: "O'Connor, Don" To: "'ppvpn@nortelnetworks.com'" Subject: Experimental Versus Standards Track Date: Wed, 16 Apr 2003 14:02:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: fncimr02.fnc.fujitsu.com X-SMTP-MAIL-FROM: Don.OConnor@fnc.fujitsu.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: fncimr02.fnc.fujitsu.com [168.127.0.4] X-LYRIS-Message-Id: For the drafts that have been proposed for working group status are there any opinions with respect to the experimental versus standards track question? Regards, Don From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 15:10: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 PAA12844 for ; Wed, 16 Apr 2003 15:10:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GJCBn08816 for ; Wed, 16 Apr 2003 15:12:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GJC5318043 for ; Wed, 16 Apr 2003 15:12:05 -0400 (EDT) Date: Thu, 17 Apr 2003 03:05:03 +0800 From: Du Wenhua Subject: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft To: Ali Sajassi , Ali Sajassi , "Vasile Radoaca" , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDG00HRCA598L@mta1.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta1 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12844 Hi, Ali Sajassi Thanks. Pls see my comments in line ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-17 At 10:11:00 2003-04-16, Ali Sajassi wrote: >>> >For unqualified learning, customer's VLANs are transparent to the SP. And >> >as the matter of fact there is single MAC address domain and broadcast >> >domain for all the VLAN of that customer. So what that means is the >> >customer's MAC addresses need to be unique across all the VLANs or else >> >unqualified learning would not work for that customer. So, given that all >> >MAC addresses of a given customer are unique, then you can run ACL based on >> >customer's MAC for that P-VLAN. If multi SLAs are needed for unqualified >> >learning, then you simply copy the CoS bits of the inner tag to he outer >> >tag and perform QoS on the P-VLAN tag. >> > >> >The situation for qualified learning, should be clear since there is no >> >outer-tag and P-VLAN is just a mapping of the C-VLAN. >> > >> >If this is yet not clear to you, please clearly state the issue with an >> >example. >> > >>Ok, I give an example. >>Two customers A and B are connected a MTU via different physcal ports, >>the MTU is connected to a PE-rs via one physical port.The PE-rs aplly >>rate-limit of 5Mbps to customer A, and apply rate-limit of 10Mbps to >>customer B. >>How can the PE-rs distinguish the two customer? >>(1)Your answer is run ACL on customer's MAC. >>But, Customer MAC is untrusted, because the provider do not know customer >>MAC, >>and the MAC will change frequently so need to change ACL frequently. >>So,it is difficult to use ACL based on customer MAC. >>(2)My unswer is to run ACL based on P-VLAN, customer A and customer B have >>different P-VLAN. >>P-VLAN is trusted, P-VLAN would not change frequently, provider known >>P-VLAN. It is better than >>run ACL based on customer MAC. > >No, there is still confusion and your confusion may be about VPLS instance >First, are these two customers part of the same VPLS instance or not ? If >they are then they are using the same FIB and they need to coordinate their >MAC addresses with each other in order not to have overlapping MAC >addresses (refer to sec. 8.1.1). >Because both customers are part of the >same VPLS instance, then they will be identified by the same P-VLAN. Yes, I'm talking about two customers belong to the same VPLS instance. True, the two customers can be identified by the same P-VLAN. But how to distinguish the two customers in PE-rs??? Your answer is -customer MAC-. I do agree with you that customer MAC is unique in the VPLS intstance. But it is a bad way to run ACL based on -customer MAC-, and it is a better way to run ACL based one different P-VLANs. Pls see my explain above for why it is a bad way. In the other side, would you tell me why we can not use different P-VLANs for different customers in the same VPLS instance? Is this hard to implement? Is this break any rules in the draft-ietf-ppvpn-l2-framework-03.txt? >However, if each customer has its own VPLS instance, then they have their >own FIB (and MAC address space) and each will be identified by its own >VPLS-instance id and P-VLAN id. No, I'm not talking about this. I'm talking about two customers belong to the same VPLS instance. >Second, regarding the rate limiting and traffic policing. Policing and >shaping functionality should be done as close to the edge as possible >(before congestion point) and they are done at the MTU-s (not PE-rs) and >they are performed on a per AC basis (AC can be either customer port for >unqualified learning and customer VLAN for qualified learning). Some of >these stuff is described in MEF white paper and you may want to take a look >at it. So for a given customer that has multiple sites connected to the >same MTU-s, the QoS (rate limiting, shaping, policing) is performed on per >customer site (e.g., per AC) basis. > >-Ali Rate-limit is just only an example, there are many other value-add services which need to apply in PE-rs based on per customer. If you think that MTU can do all the value-add services and the PE-rs do not need to apply any value-add services based on per customer, I have nothing to say. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 15:15: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 PAA13376 for ; Wed, 16 Apr 2003 15:15:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GJHUn11951 for ; Wed, 16 Apr 2003 15:17:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GJHQ326449 for ; Wed, 16 Apr 2003 15:17:27 -0400 (EDT) Date: Wed, 16 Apr 2003 15:13:23 -0400 (EDT) From: schultz@io.iol.unh.edu To: Cheng-Yin Lee cc: Rick Wilder , "Marco Carugi" , ppvpn@nortelnetworks.com, Gerard Goubert , nfinn@cisco.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft In-Reply-To: <3E9C8C96.1FF565D8@alcatel.com> Message-ID: References: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> <3E9C8C96.1FF565D8@alcatel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: io.iol.unh.edu X-SMTP-MAIL-FROM: schultz@io.iol.unh.edu X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: io.iol.unh.edu [132.177.123.82] X-LYRIS-Message-Id: Cheng-Yin, I see #1 as being a serious issue. Many people in the VPLS community believe that the CE device will always be a router running an IGP. But as we all know, customers may want to simplify the solution and cut their costs by using a bridge or repeater. This discussion is focused on looping, but filtering database scalability is also an issue. A problem with using spanning tree or rapid spanning tree is that some service providers would not want an injection of BPDUs into their network from customer sites. The 802.1 working group is solving these problems with their new draft, 802.1ad, Provider Bridges. Does this vpls internet draft plan to reference that document? My concern is that ppvpn will come up with one solution and 802.1 will solve this in a different manner. The problem is that these 2 solutions are not mutually exclusive and will both be implemented on many devices. Thanks, -Ben ---------------------- > 1) Traffic Looping > > +---------------- > | > +------+ > +---------| PE | > | |device| > | +------+ > +------+ | > | CE | | > |device| | SP network > +------+ | > | +------+ > | | PE | > +---------|device| > +------+ > | > +---------------- > (a) > > If CE is a hub, does lasserre-vkompella support this valid configuration > requirement (to make the service more resilient to PE or MTU-S > failure)? How to prevent traffic from looping in the e.g. above taken > from the requirements document? > I think loop issues were first brought up in 2001, but it has not been > addressed. > (I don't think the answer is rate-limiting of customer traffic ;-)). From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 15:27: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 PAA13701 for ; Wed, 16 Apr 2003 15:27:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GJTWn17149 for ; Wed, 16 Apr 2003 15:29:33 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GJTQ305880 for ; Wed, 16 Apr 2003 15:29:27 -0400 (EDT) From: "Jim Guichard" To: "Sylvia Sugar" , Subject: RE: RD in 2547 bis Date: Wed, 16 Apr 2003 15:20:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Sylvia, > >-----Original Message----- > >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com] > >Sent: Wednesday, April 16, 2003 6:23 AM > >To: ppvpn@lyris.nortelnetworks.com > >Subject: Re: RD in 2547 bis > > > > > >Hello, > > > >We were involved in an MPLS design for a service provider here. > > > >I would like to know the following: > > > > > >> > > > Also, with RT, we can simply check for one RT attribute > >and decide > >>whether > >> > > > we want 100s of MP_NLRI or not (the way BGP update is > >packed). If we > >>had > >> > >to > >> > > > do this based on RD, then we really would have to go > >through each > >>VPNv4 > >> > > > prefix to find out whether it was a candidate for the > >import or not. > >> > > > >> > >>Agree with this point of yours. > > > >This is what is confusing me. > >>From what my book says authored by cisco press, use route > >targets to assign > >routes to put routes into a VRF. So we anyways use the "Route Target > >attribute" for this. This is correct - the RT controls the import/export policies - the RD has nothing to do with this, period. > > > >> > >> > > > >RD is local to the router /used to distinguish VPNv4 routes > >>locally, is my > >> > >understanding. > >> > > RD becomes crucial with the presence of RRs. > >> > >>How come? Can you please give me some pointers as to how RD becomes > >>"crucial" in presence > >>of RRs. the RD is not really local to the router in the sense that it can affect route selection at the RRs. If you use the same RD on say PE1 and PE2 (lets call it RD 100:2) and then export route 1.1.1.1 from both PEs, the RR will see two identical routes e.g. 100:2:1.1.1.1. It will select one as best path and therefore one of the routes is lost from downstream PEs. > >> > >> > > > > I think it comes down to what gives us more granularity and > >>control over > >> > > > what we want to do. > >> > >>I think this is it. And nothing else. We can also work out with > >having just > >>one RT but > >>then having both gives us some greater control over what we want to do! > >> > > > > > >Yes Mr Smith, but how does not having Route Distinguisher affect things. see above RR discussion. > > > >I have no example in this book which shows me how to use "Route > >Distinguisher" can help. It doesnt get used to filter routes either. It > >seems to be nothing but local. it is not in the book as it has nothing to do with import/export policies. Jim > > > >Maybe its not in this book. Can someone please suggest some good book to > >read to clarify this? > > > >Can you please explain the "what we want to do" bit? > > > >-SylviaXO > > > >_________________________________________________________________ > >MSN 8 with e-mail virus protection service: 2 months FREE* > >http://join.msn.com/?page=features/virus > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 15:44: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 PAA14270 for ; Wed, 16 Apr 2003 15:44:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GJkrn21441 for ; Wed, 16 Apr 2003 15:46:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GJkn313972 for ; Wed, 16 Apr 2003 15:46:49 -0400 (EDT) Message-ID: <20030416194312.31296.qmail@web12806.mail.yahoo.com> Date: Wed, 16 Apr 2003 12:43:12 -0700 (PDT) From: vrishab sikand Subject: RE: RD in 2547 bis To: Jim Guichard , Sylvia Sugar , ppvpn@lyris.nortelnetworks.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1801775087-1050522192=:30217" X-SMTP-HELO: web12806.mail.yahoo.com X-SMTP-MAIL-FROM: v_sikand@yahoo.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web12806.mail.yahoo.com [216.136.174.41] X-LYRIS-Message-Id: --0-1801775087-1050522192=:30217 Content-Type: text/plain; charset=us-ascii [snip]... > >This is what is confusing me. > >>From what my book says authored by cisco press, use route > >targets to assign > >routes to put routes into a VRF. So we anyways use the "Route Target > >attribute" for this. >This is correct - the RT controls the import/export policies - the RD has >nothing to do with this, period. What about the case: Where routes are being injected into the back bone via a connection at a PE from the CE. At that point (unless BGP is being used between PE - CE and its a provider of provider case) there is no RT or RD coming with route. The association with the VRF and the interface is done on basis of configured RD. So in a way the import policy there is based on RD. Jim Guichard wrote:Sylvia, > >-----Original Message----- > >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com] > >Sent: Wednesday, April 16, 2003 6:23 AM > >To: ppvpn@lyris.nortelnetworks.com > >Subject: Re: RD in 2547 bis > > > > > >Hello, > > > >We were involved in an MPLS design for a service provider here. > > > >I would like to know the following: > > > > > >> > > > Also, with RT, we can simply check for one RT attribute > >and decide > >>whether > >> > > > we want 100s of MP_NLRI or not (the way BGP update is > >packed). If we > >>had > >> > >to > >> > > > do this based on RD, then we really would have to go > >through each > >>VPNv4 > >> > > > prefix to find out whether it was a candidate for the > >import or not. > >> > > > >> > >>Agree with this point of yours. > > > >This is what is confusing me. > >>From what my book says authored by cisco press, use route > >targets to assign > >routes to put routes into a VRF. So we anyways use the "Route Target > >attribute" for this. This is correct - the RT controls the import/export policies - the RD has nothing to do with this, period. > > > >> > >> > > > >RD is local to the router /used to distinguish VPNv4 routes > >>locally, is my > >> > >understanding. > >> > > RD becomes crucial with the presence of RRs. > >> > >>How come? Can you please give me some pointers as to how RD becomes > >>"crucial" in presence > >>of RRs. the RD is not really local to the router in the sense that it can affect route selection at the RRs. If you use the same RD on say PE1 and PE2 (lets call it RD 100:2) and then export route 1.1.1.1 from both PEs, the RR will see two identical routes e.g. 100:2:1.1.1.1. It will select one as best path and therefore one of the routes is lost from downstream PEs. > >> > >> > > > > I think it comes down to what gives us more granularity and > >>control over > >> > > > what we want to do. > >> > >>I think this is it. And nothing else. We can also work out with > >having just > >>one RT but > >>then having both gives us some greater control over what we want to do! > >> > > > > > >Yes Mr Smith, but how does not having Route Distinguisher affect things. see above RR discussion. > > > >I have no example in this book which shows me how to use "Route > >Distinguisher" can help. It doesnt get used to filter routes either. It > >seems to be nothing but local. it is not in the book as it has nothing to do with import/export policies. Jim > > > >Maybe its not in this book. Can someone please suggest some good book to > >read to clarify this? > > > >Can you please explain the "what we want to do" bit? > > > >-SylviaXO > > > >_________________________________________________________________ > >MSN 8 with e-mail virus protection service: 2 months FREE* > >http://join.msn.com/?page=features/virus > > > > --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. --0-1801775087-1050522192=:30217 Content-Type: text/html; charset=us-ascii
[snip]...
 
> >This is what is confusing me.
> >>From what my book says authored by cisco press, use route
> >targets to assign
> >routes to put routes into a VRF. So we anyways use the "Route Target
> >attribute" for this.

>This is correct - the RT controls the import/export policies - the RD has
>nothing to do with this, period.
What about the case: Where routes are being injected into the back bone via a connection at a PE from the CE. At that point (unless BGP is being used between PE - CE and its a provider of provider case) there is no RT or RD coming with route. The association with the VRF and the interface is done on basis of configured RD. So in a way the import policy there is based on RD.


Jim Guichard <jguichar@cisco.com> wrote:
Sylvia,

> >-----Original Message-----
> >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com]
> >Sent: Wednesday, April 16, 2003 6:23 AM
> >To: ppvpn@lyris.nortelnetworks.com
> >Subject: Re: RD in 2547 bis
> >
> >
> >Hello,
> >
> >We were involved in an MPLS design for a service provider here.
> >
> >I would like to know the following:
> >
> >
> >> > > > Also, with RT, we can simply check for one RT attribute
> >and decide
> >>whether
> >> > > > we want 100s of MP_NLRI or not (the way BGP update is
> >packed). If we
> >>had
> >> > >to
> >> > > > do this based on RD, then we really would have to go
> >through each
> >>VP! Nv4
> >> > > > prefix to find out whether it was a candidate for the
> >import or not.
> >> > >
> >>
> >>Agree with this point of yours.
> >
> >This is what is confusing me.
> >>From what my book says authored by cisco press, use route
> >targets to assign
> >routes to put routes into a VRF. So we anyways use the "Route Target
> >attribute" for this.

This is correct - the RT controls the import/export policies - the RD has
nothing to do with this, period.

> >
> >>
> >> > > > >RD is local to the router /used to distinguish VPNv4 routes
> >>locally, is my
> >> > >understanding.
> >> > > RD becomes crucial with the presence of RRs.
> >>
> >>How come? Can you please give me some pointers as to how RD becomes
> >&g! t;"crucial" in presence
> >>of RRs.

the RD is not r eally local to the router in the sense that it can affect
route selection at the RRs. If you use the same RD on say PE1 and PE2 (lets
call it RD 100:2) and then export route 1.1.1.1 from both PEs, the RR will
see two identical routes e.g. 100:2:1.1.1.1. It will select one as best path
and therefore one of the routes is lost from downstream PEs.

> >>
> >> > > > > I think it comes down to what gives us more granularity and
> >>control over
> >> > > > what we want to do.
> >>
> >>I think this is it. And nothing else. We can also work out with
> >having just
> >>one RT but
> >>then having both gives us some greater control over what we want to do!
> >>
> >
> >
> >Yes Mr Smith, but how does not having Route Distinguisher affect things.

see above RR discussion.

> >
> >I have! no example in this book which shows me how to use "Route
> >Distinguisher" can help. It doesnt get used to filter routes either. It
> >seems to be nothing but local.

it is not in the book as it has nothing to do with import/export policies.

Jim

> >
> >Maybe its not in this book. Can someone please suggest some good book to
> >read to clarify this?
> >
> >Can you please explain the "what we want to do" bit?
> >
> >-SylviaXO
> >
> >_________________________________________________________________
> >MSN 8 with e-mail virus protection service: 2 months FREE*
> >http://join.msn.com/?page=features/virus
> >
> >


Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. --0-1801775087-1050522192=:30217-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 15:52:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14504 for ; Wed, 16 Apr 2003 15:52:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GJsMn25442 for ; Wed, 16 Apr 2003 15:54:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GJsJ319758 for ; Wed, 16 Apr 2003 15:54:19 -0400 (EDT) From: "Jim Guichard" To: "vrishab sikand" , "Sylvia Sugar" , Subject: RE: RD in 2547 bis Date: Wed, 16 Apr 2003 15:45:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C3042F.40AB2D80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <20030416194312.31296.qmail@web12806.mail.yahoo.com> X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C3042F.40AB2D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: vrishab sikand [mailto:v_sikand@yahoo.com] Sent: Wednesday, April 16, 2003 3:43 PM To: Jim Guichard; Sylvia Sugar; ppvpn@lyris.nortelnetworks.com Subject: RE: RD in 2547 bis [snip]... > >This is what is confusing me. > >>From what my book says authored by cisco press, use route > >targets to assign > >routes to put routes into a VRF. So we anyways use the "Route Target > >attribute" for this. >This is correct - the RT controls the import/export policies - the RD has >nothing to do with this, period. What about the case: Where routes are being injected into the back bone via a connection at a PE from the CE. At that point (unless BGP is being used between PE - CE and its a provider of provider case) there is no RT or RD coming with route. The association with the VRF and the interface is done on basis of configured RD. So in a way the import policy there is based on RD. I think you are confused with the RT - the RT provides the association with an importing VRF from the backbone. For routes coming from the CE e.g. there is no RD or RT association, the association with the VRF is based on the routing protocol context and/or interface. Jim Jim Guichard wrote: Sylvia, > >-----Original Message----- > >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com] > >Sent: Wednesday, April 16, 2003 6:23 AM > >To: ppvpn@lyris.nortelnetworks.com > >Subject: Re: RD in 2547 bis > > > > > >Hello, > > > >We were involved in an MPLS design for a service provider here. > > > >I would like to know the following: > > > > > >> > > > Also, with RT, we can simply check for one RT attribute > >and decide > >>whether > >> > > > we want 100s of MP_NLRI or not (the way BGP update is > >packed). If we > >>had > >> > >to > >> > > > do this based on RD, then we really would have to go > >through each > >>VP! Nv4 > >> > > > prefix to find out whether it was a candidate for the > >import or not. > >> > > > >> > >>Agree with this point of yours. > > > >This is what is confusing me. > >>From what my book says authored by cisco press, use route > >targets to assign > >routes to put routes into a VRF. So we anyways use the "Route Target > >attribute" for this. This is correct - the RT controls the import/export policies - the RD has nothing to do with this, period. > > > >> > >> > > > >RD is local to the router /used to distinguish VPNv4 routes > >>locally, is my > >> > >understanding. > >> > > RD becomes crucial with the presence of RRs. > >> > >>How come? Can you please give me some pointers as to how RD becomes > >>! ;"crucial" in presence > >>of RRs. the RD ! is not r eally local to the router in the sense that it can affect route selection at the RRs. If you use the same RD on say PE1 and PE2 (lets call it RD 100:2) and then export route 1.1.1.1 from both PEs, the RR will see two identical routes e.g. 100:2:1.1.1.1. It will select one as best path and therefore one of the routes is lost from downstream PEs. > >> > >> > > > > I think it comes down to what gives us more granularity and > >>control over > >> > > > what we want to do. > >> > >>I think this is it. And nothing else. We can also work out with > >having just > >>one RT but > >>then having both gives us some greater control over what we want to do! > >> > > > > > >Yes Mr Smith, but how does not having Route Distinguisher affect things. see above RR discussion. > > > >I have! no example in this book which shows me how to use "Route > >Distinguisher" can help. It doesnt get used to filter routes either. It > >seems to be nothing but local. it is not in the book as it has nothing to do with import/export policies. Jim > > > >Maybe its not in this book. Can someone please suggest some good book to > >read to clarify this? > > > >Can you please explain the "what we want to do" bit? > > > >-SylviaXO > > > >_________________________________________________________________ > >MSN 8 with e-mail virus protection service: 2 months FREE* > >http://join.msn.com/?page=features/virus > > > > ---------------------------------------------------------------------------- -- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. ------=_NextPart_000_0037_01C3042F.40AB2D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: vrishab sikand=20 [mailto:v_sikand@yahoo.com]
Sent: Wednesday, April 16, 2003 = 3:43=20 PM
To: Jim Guichard; Sylvia Sugar;=20 ppvpn@lyris.nortelnetworks.com
Subject: RE: RD in 2547=20 bis

[snip]...
 
> >This is what is confusing me.
> >>From what = my book=20 says authored by cisco press, use route
> >targets to = assign
>=20 >routes to put routes into a VRF. So we anyways use the "Route=20 Target
> >attribute" for this.

>This is correct - = the RT=20 controls the import/export policies - the RD has
>nothing to do = with=20 this, period.
What about the case: Where routes are being injected into the = back bone=20 via a connection at a PE from the CE. At that point (unless BGP = is being=20 used between PE - CE and its a provider of provider case) there = is no RT=20 or RD coming with route. The association with the VRF and the = interface is=20 done on basis of configured RD. So in a way the import policy there is = based=20 on RD. 
 
I=20 think you are confused with the RT - the RT provides the association = with an=20 importing VRF from the backbone. For routes coming from the CE e.g. = there is=20 no RD or RT association, the association with the VRF is based on the = routing=20 protocol context and/or interface. Jim
 


Jim=20 Guichard <jguichar@cisco.com> wrote:
Sylvia,

>=20 >-----Original Message-----
> >From: Sylvia Sugar=20 [mailto:sylvia_sugar@hotmail.com]
> >Sent: Wednesday, April = 16,=20 2003 6:23 AM
> >To: ppvpn@lyris.nortelnetworks.com
>=20 >Subject: Re: RD in 2547 bis
> >
> >
>=20 >Hello,
> >
> >We were involved in an MPLS = design for a=20 service provider here.
> >
> >I would like to know = the=20 following:
> >
> >
> >> > > > = Also,=20 with RT, we can simply check for one RT attribute
> >and=20 decide
> >>whether
> >> > > > we = want 100s=20 of MP_NLRI or not (the way BGP update is
> >packed). If = we
>=20 >>had
> >> > >to
> >> > > = > do=20 this based on RD, then we really would have to go
> = >through=20 each
> >>VP! Nv4
> >> > > > prefix = to find=20 out whether it was a candidate for the
> >import or = not.
>=20 >> > >
> >>
> >>Agree with this = point of=20 yours.
> >
> >This is what is confusing = me.
>=20 >>From what my book says authored by cisco press, use = route
>=20 >targets to assign
> >routes to put routes into a VRF. = So we=20 anyways use the "Route Target
> >attribute" for = this.

This=20 is correct - the RT controls the import/export policies - the RD=20 has
nothing to do with this, period.

> >
>=20 >>
> >> > > > >RD is local to the = router /used=20 to distinguish VPNv4 routes
> >>locally, is my
> = >>=20 > >understanding.
> >> > > RD becomes = crucial with=20 the presence of RRs.
> >>
> >>How come? Can = you=20 please give me some pointers as to how RD becomes
> >>!=20 ;"crucial" in presence
> >>of RRs.

the RD ! is = not r=20 eally local to the router in the sense that it can affect
route = selection=20 at the RRs. If you use the same RD on say PE1 and PE2 (lets
call = it RD=20 100:2) and then export route 1.1.1.1 from both PEs, the RR = will
see two=20 identical routes e.g. 100:2:1.1.1.1. It will select one as best = path
and=20 therefore one of the routes is lost from downstream PEs.

> = >>
> >> > > > > I think it comes down = to what=20 gives us more granularity and
> >>control over
> = >>=20 > > > what we want to do.
> >>
> = >>I think=20 this is it. And nothing else. We can also work out with
> = >having=20 just
> >>one RT but
> >>then having both = gives us=20 some greater control over what we want to do!
> = >>
>=20 >
> >
> >Yes Mr Smith, but how does not having = Route=20 Distinguisher affect things.

see above RR = discussion.

>=20 >
> >I have! no example in this book which shows me how = to use=20 "Route
> >Distinguisher" can help. It doesnt get used to = filter=20 routes either. It
> >seems to be nothing but = local.

it is=20 not in the book as it has nothing to do with import/export=20 policies.

Jim

> >
> >Maybe its not in = this=20 book. Can someone please suggest some good book to
> >read = to=20 clarify this?
> >
> >Can you please explain the = "what we=20 want to do" bit?
> >
> >-SylviaXO
> = >
>=20 = >_________________________________________________________________
= >=20 >MSN 8 with e-mail virus protection service: 2 months = FREE*
>=20 >http://join.msn.com/?page=3Dfeatures/virus
> >
>=20 >


Do you Yahoo!?
T= he New=20 Yahoo! Search - Faster. Easier. Bingo. ------=_NextPart_000_0037_01C3042F.40AB2D80-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 17:19:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17245 for ; Wed, 16 Apr 2003 17:19:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GLLSn01835 for ; Wed, 16 Apr 2003 17:21:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GLLP322596 for ; Wed, 16 Apr 2003 17:21:25 -0400 (EDT) Message-ID: <3E9DC8B4.D34CF125@alcatel.com> Date: Wed, 16 Apr 2003 17:18:44 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: schultz@io.iol.unh.edu CC: Rick Wilder , "Marco Carugi" , ppvpn@nortelnetworks.com, Gerard Goubert , nfinn@cisco.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft References: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> <3E9C8C96.1FF565D8@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ben, schultz@io.iol.unh.edu wrote: > I see #1 as being a serious issue. The repercussion of #2 could be varied and may affect CE bridges too. See Muneyoshi Suzuki's email on "Comments on the L2 VPN framework and solutions documents", point #2. If the LAN is not properly emulated (connectivity/reachability do fail, and not just from link failures alone) and BPDUs are not received by some CEs bridges, are loops not a possibility as well? > Many people in the VPLS community > believe that the CE device will always be a router running an IGP. But as > we all know, customers may want to simplify the solution and cut their > costs by using a bridge or repeater. This discussion is focused on > looping, but filtering database scalability is also an issue. I agree filtering database scalability is also an issue, and the L2VPN requirements doc do state that the L2VPN solution should be scalable (some example numbers given) in this respect. > A problem with using spanning tree or rapid spanning tree is that some > service providers would not want an injection of BPDUs into their network > from customer sites. The BPDUs may not necessarily be injected into the provider's central office network, but could be limited to (provider owned) customer premises equipment, for lack of a better term. OTOH, trying to prevent loops over multiple trees (independent customer, providers forwarding paths, concatenated) may be more challenging. > The 802.1 working group is solving these problems with their new draft, > 802.1ad, Provider Bridges. Does this vpls internet draft plan to > reference that document? My concern is that ppvpn will come up with one > solution and 802.1 will solve this in a different manner. Well, there is IEEE bridging and there is PPVPN full-meshed split-horizon forwarding. > The problem is > that these 2 solutions are not mutually exclusive and will both be > implemented on many devices. I'll let you argue this one :-). Perhaps you could also point to sections in 802.1ad which addresses the issues being discussed here? Thanks Cheng-Yin > > ---------------------- > > 1) Traffic Looping > > > > +---------------- > > | > > +------+ > > +---------| PE | > > | |device| > > | +------+ > > +------+ | > > | CE | | > > |device| | SP network > > +------+ | > > | +------+ > > | | PE | > > +---------|device| > > +------+ > > | > > +---------------- > > (a) > > > > If CE is a hub, does lasserre-vkompella support this valid configuration > > requirement (to make the service more resilient to PE or MTU-S > > failure)? How to prevent traffic from looping in the e.g. above taken > > from the requirements document? > > I think loop issues were first brought up in 2001, but it has not been > > addressed. > > (I don't think the answer is rate-limiting of customer traffic ;-)). From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 17:24:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17361 for ; Wed, 16 Apr 2003 17:24:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GLQkn05426 for ; Wed, 16 Apr 2003 17:26:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GLQg327517 for ; Wed, 16 Apr 2003 17:26:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416133530.01c9b620@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 14:24:07 -0700 To: Du Wenhua , Ali Sajassi , "Vasile Radoaca" , Rick Wilder From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDG00HRCA598L@mta1.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: > >No, there is still confusion and your confusion may be about VPLS instance > >First, are these two customers part of the same VPLS instance or not ? If > >they are then they are using the same FIB and they need to coordinate their > >MAC addresses with each other in order not to have overlapping MAC > >addresses (refer to sec. 8.1.1). > >Because both customers are part of the > >same VPLS instance, then they will be identified by the same P-VLAN. >Yes, I'm talking about two customers belong to the same VPLS instance. >True, the two customers can be identified by the same P-VLAN. >But how to distinguish the two customers in PE-rs??? Your answer is >-customer MAC-. >I do agree with you that customer MAC is unique in the VPLS intstance. But >it is >a bad way to run ACL based on -customer MAC-, and it is a better way to >run ACL based one >different P-VLANs. Pls see my explain above for why it is a bad way. > >In the other side, would you tell me why we can not use different >P-VLANs for different >customers in the same VPLS instance? Is this hard to implement? Is this >break any rules >in the draft-ietf-ppvpn-l2-framework-03.txt? The reason you cannot combine two customers in the same VPLS instance or at least is not recommended is because you only have a single MAC address domain and broadcast domain per VPLS instance which means the same FIB table is shared by VLANs from both customer (VLANs from both customers point to the same FIB table) as well as the same broadcast domain is used for both (customers see each other MAC addresses). Then, how do you coordinate the MAC addressed across different customers. It is tough enough to coordinate within a single customer for unqualified learning. If the MAC addresses are not coordinated (both within the domain of a single customer as well as across them), then their traffic gets blackholed !!!! How do you address that ? or are you going to restrict their MAC address sapce ? And how do you enforce how much of that FIB to be used by one customer versus the other ? Or how do you block one customer traffic from reaching the other one ? Because of these issues, sharing a VPLS instance is not viable. Also I am definitely not recommending to use MAC ACL for such cases. The recommendation is that each customer has (at least) its own VPLS instance so that the SP can properly enforce the SLA and proper delivery of customer frames. > >Second, regarding the rate limiting and traffic policing. Policing and > >shaping functionality should be done as close to the edge as possible > >(before congestion point) and they are done at the MTU-s (not PE-rs) and > >they are performed on a per AC basis (AC can be either customer port for > >unqualified learning and customer VLAN for qualified learning). Some of > >these stuff is described in MEF white paper and you may want to take a look > >at it. So for a given customer that has multiple sites connected to the > >same MTU-s, the QoS (rate limiting, shaping, policing) is performed on per > >customer site (e.g., per AC) basis. > >Rate-limit is just only an example, there are many other value-add >services which >need to apply in PE-rs based on per customer. If you think that MTU can >do all the >value-add services and the PE-rs do not need to apply any value-add >services based on per customer, I have nothing to say. PE-rs can offer whatever value-add service that you have in mind on a per customer basis by having one VPLS instance per customer. What benefits can you get by sharing the same VPLS instance by multiple customers which violates the principle of isolation and privacy between customers. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 18:29: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 SAA20007 for ; Wed, 16 Apr 2003 18:29:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GMVqn21584 for ; Wed, 16 Apr 2003 18:31:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GMVn301244 for ; Wed, 16 Apr 2003 18:31:49 -0400 (EDT) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5DC8@trimail2> From: "Serbest, Yetik" To: "'mattsquire@acm.org'" , "'Rick Wilder'" Cc: ppvpn@nortelnetworks.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Wed, 16 Apr 2003 17:29:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: serbest@tri.sbc.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: I would like to second that. Thanks, yetik -----Original Message----- From: Matt Squire [mailto:mattsquire@acm.org] Sent: Tuesday, April 15, 2003 7:08 AM To: 'Rick Wilder' Cc: ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft The Laserre/VKompella draft should definitely progress as a working group draft. Its a solid technical contribution with a lot of support behind it. - Matt Olen Stokes wrote: > I would also like to support making this a working group draft. > > Cheers, > Olen > > -----Original Message----- > *From:* Rick Wilder [mailto:rwilder@masergy.com] > *Sent:* Thursday, April 10, 2003 11:20 AM > *To:* ppvpn@nortelnetworks.com > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > draft > > As noted in the minutes, at the San Francisco meeting strong > interest was expressed in pursuing the > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > agreed to finalize that decision only after the WG participants who > weren't there could have a say. > > > > So, if there are opinions that have not been heard, now is the time, > and this list is the place. Let's set a one-week limit to conclude > this issue. > > > > Rick > > > > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ------- > > From the minutes: > > > > 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. > > > [snipped] > > Marco: asked for show of hands to make this a wG draft. > Strong interest was shown in room. Further discussion on the list. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 18:38:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20240 for ; Wed, 16 Apr 2003 18:38:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GMf1n24995 for ; Wed, 16 Apr 2003 18:41:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3GMev310664 for ; Wed, 16 Apr 2003 18:40:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Wed, 16 Apr 2003 17:38:32 -0500 Message-ID: Thread-Topic: draft-lasserre-vkompella-ppvpn-vpls as working group draft Thread-Index: AcMEZ96qlVt7Wx/gSY+Eb0Fc/A7t2QAAHwFw From: "Fang, Luyuan, ALABS" To: "Serbest, Yetik" , , "Rick Wilder" Cc: X-SMTP-HELO: kcmso2.proxy.att.com X-SMTP-MAIL-FROM: luyuanfang@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kcmso2.att.com [192.128.134.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20240 Me too. Thanks, Luyuan -----Original Message----- From: Serbest, Yetik [mailto:serbest@tri.sbc.com] Sent: Wednesday, April 16, 2003 6:29 PM To: 'mattsquire@acm.org'; 'Rick Wilder' Cc: ppvpn@nortelnetworks.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft I would like to second that. Thanks, yetik -----Original Message----- From: Matt Squire [mailto:mattsquire@acm.org] Sent: Tuesday, April 15, 2003 7:08 AM To: 'Rick Wilder' Cc: ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft The Laserre/VKompella draft should definitely progress as a working group draft. Its a solid technical contribution with a lot of support behind it. - Matt Olen Stokes wrote: > I would also like to support making this a working group draft. > > Cheers, > Olen > > -----Original Message----- > *From:* Rick Wilder [mailto:rwilder@masergy.com] > *Sent:* Thursday, April 10, 2003 11:20 AM > *To:* ppvpn@nortelnetworks.com > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > draft > > As noted in the minutes, at the San Francisco meeting strong > interest was expressed in pursuing the > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > agreed to finalize that decision only after the WG participants who > weren't there could have a say. > > > > So, if there are opinions that have not been heard, now is the time, > and this list is the place. Let's set a one-week limit to conclude > this issue. > > > > Rick > > > > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ------- > > From the minutes: > > > > 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. > > > [snipped] > > Marco: asked for show of hands to make this a wG draft. > Strong interest was shown in room. Further discussion on the list. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 22:10: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 WAA24105 for ; Wed, 16 Apr 2003 22:10:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3H2Ckn16581 for ; Wed, 16 Apr 2003 22:12:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3H2Cg301996 for ; Wed, 16 Apr 2003 22:12:43 -0400 (EDT) Date: Thu, 17 Apr 2003 10:09:28 +0800 From: Du Wenhua Subject: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft To: Ali Sajassi , Ali Sajassi , "Vasile Radoaca" , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDG00HNGTSQ8L@mta1.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta1 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA24105 Hi, Ali Sajassi Thanks for your comments again. But your comments is out of the scope of my topic. I'm talking about: one P-VLAN or many P-LAN? Many P-VLAN is better. Your comments is: one VPLS instance or many VPLS instance? Many VPLS instance is better. The two topic has nothing to do with each other. They do not conflict with each other. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-17 At 14:24:00 2003-04-16, Ali Sajassi wrote: >>> >No, there is still confusion and your confusion may be about VPLS instance >> >First, are these two customers part of the same VPLS instance or not ? If >> >they are then they are using the same FIB and they need to coordinate their >> >MAC addresses with each other in order not to have overlapping MAC >> >addresses (refer to sec. 8.1.1). >> >Because both customers are part of the >> >same VPLS instance, then they will be identified by the same P-VLAN. >>Yes, I'm talking about two customers belong to the same VPLS instance. >>True, the two customers can be identified by the same P-VLAN. >>But how to distinguish the two customers in PE-rs??? Your answer is >>-customer MAC-. >>I do agree with you that customer MAC is unique in the VPLS intstance. But >>it is >>a bad way to run ACL based on -customer MAC-, and it is a better way to >>run ACL based one >>different P-VLANs. Pls see my explain above for why it is a bad way. >> >>In the other side, would you tell me why we can not use different >>P-VLANs for different >>customers in the same VPLS instance? Is this hard to implement? Is this >>break any rules >>in the draft-ietf-ppvpn-l2-framework-03.txt? > >The reason you cannot combine two customers in the same VPLS instance or at >least is not recommended is because you only have a single MAC address Once more, your answer is out of the scope of the my topic. I'm talking about: one P-VLAN or many P-LAN? Your comment is: one VPLS instance or many VPLS instance? >domain and broadcast domain per VPLS instance which means the same FIB >table is shared by VLANs from both customer (VLANs from both customers >point to the same FIB table) as well as the same broadcast domain is used >for both (customers see each other MAC addresses). Then, how do you >coordinate the MAC addressed across different customers. It is tough enough >to coordinate within a single customer for unqualified learning. If the MAC >addresses are not coordinated (both within the domain of a single customer >as well as across them), then their traffic gets blackholed !!!! What is the issue with MAC coordinated? I'm sorry I don't known what you mean. Please a example of the issue. >How do you address that ? or are you going to restrict their MAC address sapce ? And >how do you enforce how much of that FIB to be used by one customer versus >the other ? This has nothing to do with P-VLAN. It has something to do with number of VPLS instances. > Or how do you block one customer traffic from reaching the >other one ? By P-VLAN. > Because of these issues, sharing a VPLS instance is not viable. Once more, your answer is out of the scope of the my topic. I'm talking about: one P-VLAN or many P-LAN? Your comment is: one VPLS instance or many VPLS instance? >Also I am definitely not recommending to use MAC ACL for such >cases. The recommendation is that each customer has (at least) its own VPLS >instance so that the SP can properly enforce the SLA and proper delivery of >customer frames. Once more, your answer is out of the scope of the my topic. (1)My topic: it is better to use many P-VLANs than one P-VLAN when all customer share one VPLS instance. (2)Your answer: it is better to use many VPLS instances rather than one VPLS instance. I think (1) and (2) is two different topic. They do not conflict with each other. ********************************************************************** I beleive many P-VLAN have no issue. Let us look into the draft again. (1)Between PE-rs and PE-r, we use VC label. (2)Between PE-rs and MTU-s, we can use VC label. (3)Between PE-rs and MTU-s, we can also use P-VLAN tag. As list above, to PE-rs a P-VLAN tag is just have the same function as a VC lable. The different is P-VLAN tag is 12bit and the VC label is 20bit. Now we can use different VC label for different customer, so we can use different P-VLAN tag for different customer. Just replace a VC label with a P-VLAN tag. In other words, P-VLAN tag == VC label of spoke pseudowire, as follow (1)Thus, the spoke pseudowire from the PE-r is treated as a virtual port and the PE-rs device will switch traffic between the spoke pseudowire, hub pseudowires, and access ports once it has learned the MAC addresses. (2)Thus, the P-VLAN from the MTU is treated as a virtual port and the PE-rs device will switch traffic between the PVLANs, hub pseudowires, and access ports once it has learned the MAC addresses. There is no issue in (1), so there is no issue in (2). follow words are copied from the draft: 10.1.1.2. PE-rs Operation The PE-rs device is a device that supports all the bridging functions for VPLS service and supports the routing and MPLS encapsulation, i.e. it supports all the functions described in [VPLS]. The operation of PE-rs is independent of the type of device at the other end of the spoke pseudowire. Thus, the spoke pseudowire from the PE-r is treated as a virtual port and the PE-rs device will switch traffic between the spoke pseudowire, hub pseudowires, and access ports once it has learned the MAC addresses. > >> >Second, regarding the rate limiting and traffic policing. Policing and >> >shaping functionality should be done as close to the edge as possible >> >(before congestion point) and they are done at the MTU-s (not PE-rs) and >> >they are performed on a per AC basis (AC can be either customer port for >> >unqualified learning and customer VLAN for qualified learning). Some of >> >these stuff is described in MEF white paper and you may want to take a look >> >at it. So for a given customer that has multiple sites connected to the >> >same MTU-s, the QoS (rate limiting, shaping, policing) is performed on per >> >customer site (e.g., per AC) basis. >> >>Rate-limit is just only an example, there are many other value-add >>services which >>need to apply in PE-rs based on per customer. If you think that MTU can >>do all the >>value-add services and the PE-rs do not need to apply any value-add >>services based on per customer, I have nothing to say. > >PE-rs can offer whatever value-add service that you have in mind on a per >customer basis by having one VPLS instance per customer. What benefits can >you get by sharing the same VPLS instance by multiple customers which >violates the principle of isolation and privacy between customers. Once more, your answer is out of the scope of the my topic. I'm talking about: one P-VLAN or many P-LAN? Your comment is: one VPLS instance or many VPLS instance? > >-Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 16 23:37:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25434 for ; Wed, 16 Apr 2003 23:37:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3H3dFn26089 for ; Wed, 16 Apr 2003 23:39:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3H3dB325509 for ; Wed, 16 Apr 2003 23:39:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416192928.01d12a98@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 20:35:56 -0700 To: Du Wenhua , Ali Sajassi , "Vasile Radoaca" , Rick Wilder From: Ali Sajassi Subject: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft Cc: "ppvpn@nortelnetworks.com" In-Reply-To: <0HDG00HNGTSQ8L@mta1.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 10:09 AM 4/17/2003 +0800, Du Wenhua wrote: >Hi, Ali Sajassi > Thanks for your comments again. But your comments is out of the scope > of my topic. > I'm talking about: one P-VLAN or many P-LAN? Many P-VLAN is better. > Your comments is: one VPLS instance or many VPLS instance? Many VPLS > instance is better. > The two topic has nothing to do with each other. They do not conflict > with each other. They do if you try to understand the relationship between VPLS instance, MAC address domain, and broadcast domain. It seems like you still haven't grasped what a VPLS instance really means. In IEEE language, MAC address domain correspond to the filtering database (e.g., IVL versus SVL mode) and broadcast domain correspond to the filtering action (e.g., GVRP). In IEEE, you can have either SVL or IVL mode in parallel with running GVRP - e.g., a group of VLANs can share the same filtering database (SVL mode) and still have different broadcast groups per VLAN. To simplify thing for VPLS and to avoid running GVRP over the core, we have decided long time ago to have one broadcast domain per filtering database (per MAC address domain). In VPLS, the broadcast domain is identified by a group of PWs and MAC address domain by filtering database (e.g. one filtering database per MAC address domain). Now, if you understand these fundamentals, then you understand the rest of the comments that I made. > >The reason you cannot combine two customers in the same VPLS instance or at > >least is not recommended is because you only have a single MAC address >Once more, your answer is out of the scope of the my topic. >I'm talking about: one P-VLAN or many P-LAN? >Your comment is: one VPLS instance or many VPLS instance? Think about in term of MAC address domain and broadcast domain. When you talk about two customers sharing one VPLS instance. Based on our definition of VPLS instance, it means both of them use the same MAC address domain and broadcast domain. > >domain and broadcast domain per VPLS instance which means the same FIB > >table is shared by VLANs from both customer (VLANs from both customers > >point to the same FIB table) as well as the same broadcast domain is used > >for both (customers see each other MAC addresses). Then, how do you > >coordinate the MAC addressed across different customers. It is tough enough > >to coordinate within a single customer for unqualified learning. If the MAC > >addresses are not coordinated (both within the domain of a single customer > >as well as across them), then their traffic gets blackholed !!!! >What is the issue with MAC coordinated? I'm sorry I don't known what you mean. >Please a example of the issue. Please refer to Annex B of 802.1Q standards. It gives a good description of why you have to use IVL mode when you have duplicate MAC addresses - e.g., why you have to use different filtering databases - e.g., if you don't, then MAC address entries get over-written and traffic goes to wrong places. > >How do you address that ? >or are you going to restrict their MAC address sapce ? And > >how do you enforce how much of that FIB to be used by one customer versus > >the other ? >This has nothing to do with P-VLAN. It has something to do with number of VPLS >instances. > > Or how do you block one customer traffic from reaching the > >other one ? >By P-VLAN. > > Because of these issues, sharing a VPLS instance is not viable. >Once more, your answer is out of the scope of the my topic. >I'm talking about: one P-VLAN or many P-LAN? >Your comment is: one VPLS instance or many VPLS instance? > >Also I am definitely not recommending to use MAC ACL for such > >cases. The recommendation is that each customer has (at least) its own VPLS > >instance so that the SP can properly enforce the SLA and proper delivery of > >customer frames. >Once more, your answer is out of the scope of the my topic. >(1)My topic: it is better to use many P-VLANs than one P-VLAN when all >customer >share one VPLS instance. >(2)Your answer: it is better to use many VPLS instances rather than one >VPLS instance. >I think (1) and (2) is two different topic. They do not conflict with each >other. I hope by now, it is clear why we cannot map two P-VLANs into the same VPLS instance. If not, then I give up :-) >********************************************************************** >I beleive many P-VLAN have no issue. Let us look into the draft again. > >(1)Between PE-rs and PE-r, we use VC label. >(2)Between PE-rs and MTU-s, we can use VC label. >(3)Between PE-rs and MTU-s, we can also use P-VLAN tag. A single VC label correspond to a single PW; whereas, a group of PWs correspond to a single LAN - that's why we sometimes refer to it as V-LAN emulation. You can refer to the L2-framework draft and it explain it some more. PW is different than VLAN !!! I hope by now, the whole thing is clear and this will be my last email on this thread. Cheers, Ali >As list above, to PE-rs a P-VLAN tag is just have the same function as a >VC lable. >The different is P-VLAN tag is 12bit and the VC label is 20bit. >Now we can use different VC label for different customer, so we can use >different >P-VLAN tag for different customer. Just replace a VC label with a P-VLAN tag. > >In other words, P-VLAN tag == VC label of spoke pseudowire, as follow >(1)Thus, the spoke pseudowire from the PE-r is treated as a virtual >port and the PE-rs device will switch traffic between the spoke pseudowire, >hub pseudowires, and access ports once it has learned the MAC addresses. >(2)Thus, the P-VLAN from the MTU is treated as a virtual >port and the PE-rs device will switch traffic between the PVLANs, >hub pseudowires, and access ports once it has learned the MAC addresses. > >There is no issue in (1), so there is no issue in (2). > >follow words are copied from the draft: > 10.1.1.2. PE-rs Operation > > The PE-rs device is a device that supports all the bridging > functions for VPLS service and supports the routing and MPLS > encapsulation, i.e. it supports all the functions described in > [VPLS]. > > The operation of PE-rs is independent of the type of device at the > other end of the spoke pseudowire. Thus, the spoke pseudowire from > the PE-r is treated as a virtual port and the PE-rs device will > switch traffic between the spoke pseudowire, hub pseudowires, and > access ports once it has learned the MAC addresses. > > > > >> >Second, regarding the rate limiting and traffic policing. Policing and > >> >shaping functionality should be done as close to the edge as possible > >> >(before congestion point) and they are done at the MTU-s (not PE-rs) and > >> >they are performed on a per AC basis (AC can be either customer port for > >> >unqualified learning and customer VLAN for qualified learning). Some of > >> >these stuff is described in MEF white paper and you may want to take > a look > >> >at it. So for a given customer that has multiple sites connected to the > >> >same MTU-s, the QoS (rate limiting, shaping, policing) is performed > on per > >> >customer site (e.g., per AC) basis. > >> > >>Rate-limit is just only an example, there are many other value-add > >>services which > >>need to apply in PE-rs based on per customer. If you think that MTU can > >>do all the > >>value-add services and the PE-rs do not need to apply any value-add > >>services based on per customer, I have nothing to say. > > > >PE-rs can offer whatever value-add service that you have in mind on a per > >customer basis by having one VPLS instance per customer. What benefits can > >you get by sharing the same VPLS instance by multiple customers which > >violates the principle of isolation and privacy between customers. >Once more, your answer is out of the scope of the my topic. >I'm talking about: one P-VLAN or many P-LAN? >Your comment is: one VPLS instance or many VPLS instance? > > > >-Ali > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 03:22: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 DAA11240 for ; Thu, 17 Apr 2003 03:22:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3H7OOW15286 for ; Thu, 17 Apr 2003 03:24:25 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3H7OLR17427 for ; Thu, 17 Apr 2003 03:24:22 -0400 (EDT) Date: Thu, 17 Apr 2003 00:21:30 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4390137370.20030417002130@psg.com> To: ppvpn@nortelnetworks.com Subject: Subject lines [was: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- May I suggest that we use different subject lines for e-mails expressing opinions on whether a given draft should be a WG document and those for a more elaborate technical discussion? Thank you. -- Alex http://www.psg.com/~zinin/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 03:54:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11748 for ; Thu, 17 Apr 2003 03:54:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3H7uLW19164 for ; Thu, 17 Apr 2003 03:56:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3H7uIR25929 for ; Thu, 17 Apr 2003 03:56:18 -0400 (EDT) X-Originating-IP: [203.124.140.97] X-Originating-Email: [sylvia_sugar@hotmail.com] From: "Sylvia Sugar" To: jguichar@cisco.com, ppvpn@lyris.nortelnetworks.com Subject: RE: RD in 2547 bis Date: Thu, 17 Apr 2003 07:53:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2003 07:53:49.0356 (UTC) FILETIME=[7B2C36C0:01C304B6] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: sylvia_sugar@hotmail.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: bay1-f31.bay1.hotmail.com [65.54.245.31] X-LYRIS-Message-Id: Hello Mr. Jim, I must thank you for taking time to mail back on my query. It really feels nice to have the author of a book on MPLS, answer me my queries. I am really thankful to you for your time and patience. I still have a few more things to clarify. > > >> > > >> > > > >RD is local to the router /used to distinguish VPNv4 routes > > >>locally, is my > > >> > >understanding. > > >> > > RD becomes crucial with the presence of RRs. > > >> > > >>How come? Can you please give me some pointers as to how RD becomes > > >>"crucial" in presence > > >>of RRs. > >the RD is not really local to the router in the sense that it can affect >route selection at the RRs. If you use the same RD on say PE1 and PE2 (lets >call it RD 100:2) and then export route 1.1.1.1 from both PEs, the RR will >see two identical routes e.g. 100:2:1.1.1.1. It will select one as best >path >and therefore one of the routes is lost from downstream PEs. But Mr Jim, how could one use different Route Distiguisher for the same prefix? In the book it seems to say its unique to the customer. On the other had, when one passes routes across VPNs, it seems to say that the Route Target is used to identify the "VRF" of customer. There is something about multiple service providers, who each would have control of RD which would be local to them, but Route Target would be unique to a customer across all service providers. The reason cited for the same is the size of the Route Distinguisher is very small. This is my understanding from 2547 and 2547bis. I am not too sure where this was mentioned in your book. However, it seems to make Route Distinguisher redundant. One could simply replace Route Distinguisher with Route Target and it seems to achieve the same functionality Please correct me if I am wrong. This is all sooo confusing. :-(( -SylviaXO _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 07:37: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 HAA16402 for ; Thu, 17 Apr 2003 07:37:52 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HBVmW16659 for ; Thu, 17 Apr 2003 07:31:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HBViR15284 for ; Thu, 17 Apr 2003 07:31:44 -0400 (EDT) Message-Id: <200304171126.HAA15889@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-requirements-06.txt Date: Thu, 17 Apr 2003 07:26:36 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Service requirements for Layer 3 Provider Provisioned Virtual Private Networks: Author(s) : M. Carugi, D. McDysan Filename : draft-ietf-ppvpn-requirements-06.txt Pages : 48 Date : 2003-4-16 This document provides requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use for the provisioning of a VPN service. This document expresses a service provider perspective, based upon past experience of IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer as well as a service provider perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-requirements-06.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-requirements-06.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-requirements-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16143013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-requirements-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16143013.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 08:39:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19286 for ; Thu, 17 Apr 2003 08:39:09 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HCfHW28666 for ; Thu, 17 Apr 2003 08:41:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HCfER20158 for ; Thu, 17 Apr 2003 08:41:15 -0400 (EDT) Date: Thu, 17 Apr 2003 14:38:47 +0200 Message-Id: Subject: =?iso-8859-1?Q?draft-kompella-ppvpn-vpls-01.txt?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?fpalozza@blu.it?=" To: "=?iso-8859-1?Q?ppvpn?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 193.110.48.4 X-SMTP-HELO: smtp3.libero.it X-SMTP-MAIL-FROM: fpalozza@blu.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp3.libero.it [193.70.192.127] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19286 We as a customer (BT subsidiary in Italy) would like to support draft-kompella-ppvpn-vpls-01.txt, making this a working group draft. We like the MP-BGP approach for discovery and signalling, much better then manage another protocol (LDP, DNS, ...). We like the scalability (RR) and the re-using of the IP VPN stuff. Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 10:30:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23444 for ; Thu, 17 Apr 2003 10:30:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HEX1W00263 for ; Thu, 17 Apr 2003 10:33:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HEWwR10963 for ; Thu, 17 Apr 2003 10:32:59 -0400 (EDT) From: "Antonio Palozza" To: Subject: draft-kompella-ppvpn-vpls-01.txt Date: Thu, 17 Apr 2003 16:26:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-SMTP-HELO: telecomitalia.it X-SMTP-MAIL-FROM: antonio.palozza@telecomitalia.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpout.telecomitalia.it [156.54.232.100] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit We are the incumbent in Italy,International Branch.We wuold like to support draft-kompella-ppvpn-vpls-01.txt. The MP-BGP approach,the scalability with Route Reflector and the maintaining of current IP VPN control are very important added values. Thank you -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 11:10:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24845 for ; Thu, 17 Apr 2003 11:10:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HFCfW20422 for ; Thu, 17 Apr 2003 11:12:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HFCbR15277 for ; Thu, 17 Apr 2003 11:12:38 -0400 (EDT) Date: Thu, 17 Apr 2003 17:04:08 +0200 From: Nardello Elisabetta Subject: draft-kompella-ppvpn-vpls-01.txt To: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Importance: normal Priority: normal Thread-Topic: draft-kompella-ppvpn-vpls-01.txt thread-index: AcME8pfA/6+N/yx9RJOMQRZxw1Innw== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 17 Apr 2003 15:04:09.0302 (UTC) FILETIME=[990F4F60:01C304F2] X-SMTP-HELO: dns1.tilab.com X-SMTP-MAIL-FROM: Elisabetta.Nardello@TILAB.COM X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dns1.tilab.com [163.162.42.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24845 Telecom Italia Lab is the Research institute for the whole TI group. We would like to support draft-kompella-ppvpn-vpls-01.txt. We like the scalability (RR) and BGP control plane. We like the possibility to maintain the current IP VPN control infrastructure, it allows semplicity and flexibility. Thank you, Elisabetta Nardello ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 11:46:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25800 for ; Thu, 17 Apr 2003 11:46:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HFmwW28764 for ; Thu, 17 Apr 2003 11:48:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HFmsR08193 for ; Thu, 17 Apr 2003 11:48:54 -0400 (EDT) From: "Jim Guichard" To: "Sylvia Sugar" , Subject: RE: RD in 2547 bis Date: Thu, 17 Apr 2003 11:36:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-msg-core-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: ams-msg-core-1.cisco.com [144.254.74.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Sylvia, > >-----Original Message----- > >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com] > >Sent: Thursday, April 17, 2003 3:54 AM > >To: jguichar@cisco.com; ppvpn@lyris.nortelnetworks.com > >Subject: RE: RD in 2547 bis > > > > > >Hello Mr. Jim, > > > >I must thank you for taking time to mail back on my query. It > >really feels > >nice to have the author of a book on MPLS, answer me my queries. > >I am really > >thankful to you for your time and patience. > > > > > >I still have a few more things to clarify. > > > > > >> > >> > >> > >> > > > >RD is local to the router /used to distinguish VPNv4 routes > >> > >>locally, is my > >> > >> > >understanding. > >> > >> > > RD becomes crucial with the presence of RRs. > >> > >> > >> > >>How come? Can you please give me some pointers as to how RD becomes > >> > >>"crucial" in presence > >> > >>of RRs. > >> > >>the RD is not really local to the router in the sense that it can affect > >>route selection at the RRs. If you use the same RD on say PE1 > >and PE2 (lets > >>call it RD 100:2) and then export route 1.1.1.1 from both PEs, > >the RR will > >>see two identical routes e.g. 100:2:1.1.1.1. It will select one as best > >>path > >>and therefore one of the routes is lost from downstream PEs. > > > > > >But Mr Jim, how could one use different Route Distiguisher for the same > >prefix? In the book it seems to say its unique to the customer. this can happen if you export the same route from two different PEs - note that this will happen if you have a dual-attached site advertising the same set of prefixes. > > > >On the other had, when one passes routes across VPNs, it seems > >to say that > >the Route Target is used to identify the "VRF" of customer. There is > >something about multiple service providers, who each would have > >control of > >RD which would be local to them, but Route Target would be unique to a > >customer across all service providers. not necessarily - you can rewrite the RT values at the ASBR routers or you can carry them unchanged between AS's - this is a deployment choice. > > > >The reason cited for the same is the size of the Route > >Distinguisher is very > >small. the RD is 64 bits = 8 bytes > > > >This is my understanding from 2547 and 2547bis. > > > >I am not too sure where this was mentioned in your book. > > > >However, it seems to make Route Distinguisher redundant. > >One could simply replace Route Distinguisher with Route Target > >and it seems > >to achieve the same functionality no, it does not. The RT is used for import/export policy. The RD is used to make the IPv4 address unique. An update can carry multiple RT values but a single RD for each NLRI within the update. Jim > > > >Please correct me if I am wrong. This is all sooo confusing. :-(( > > > >-SylviaXO > > > >_________________________________________________________________ > >MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > >http://join.msn.com/?page=features/virus From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 12:55:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28366 for ; Thu, 17 Apr 2003 12:55:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HGw0W22211 for ; Thu, 17 Apr 2003 12:58:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HGvuR01487 for ; Thu, 17 Apr 2003 12:57:57 -0400 (EDT) Date: Fri, 18 Apr 2003 00:50:38 +0800 From: Du Wenhua Subject: Re: Re: Re: draft-lasserre-vkompella-ppvpn-vpls as working groupdraft To: Ali Sajassi , Ali Sajassi , "Vasile Radoaca" , Rick Wilder Cc: "ppvpn@nortelnetworks.com" Message-id: <0HDH00L41YQ2SW@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,vasile@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28366 Hi, Ali Sajassi Thank for your comments. I agree with you that it is better to end the thread now. So I don't write comments in line, just give a summarization. (1)My topic: It is better to use many P-VLANs than one P-VLAN in one VPLS intance mode(a.k.a Unqualified learning). (2)Your comment: It is better to use many VPLS instances(a.k.a Qualified learning) than one VPLS instance(a.k.a Qualified learning) in VPLS. (3)Another guy say: It is better to use L3 VPN than VPLS in PPVPN. All of above maybe true. Their relationship is as follow tree: PPVPN---+-----L3 VPN | | +-----VPLS---+-----Qualified learning | | +----Unqualified learning--+----One P-VLAN | | +----Many P-VLANs ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-18 At 20:35:00 2003-04-16, Ali Sajassi wrote: >>At 10:09 AM 4/17/2003 +0800, Du Wenhua wrote: >>Hi, Ali Sajassi >> Thanks for your comments again. But your comments is out of the scope >> of my topic. >> I'm talking about: one P-VLAN or many P-LAN? Many P-VLAN is better. >> Your comments is: one VPLS instance or many VPLS instance? Many VPLS >> instance is better. >> The two topic has nothing to do with each other. They do not conflict >> with each other. > >They do if you try to understand the relationship between VPLS instance, >MAC address domain, and broadcast domain. It seems like you still haven't >grasped what a VPLS instance really means. In IEEE language, MAC address >domain correspond to the filtering database (e.g., IVL versus SVL mode) and >broadcast domain correspond to the filtering action (e.g., GVRP). In IEEE, >you can have either SVL or IVL mode in parallel with running GVRP - e.g., a >group of VLANs can share the same filtering database (SVL mode) and still >have different broadcast groups per VLAN. To simplify thing for VPLS and to >avoid running GVRP over the core, we have decided long time ago to have one >broadcast domain per filtering database (per MAC address domain). In VPLS, >the broadcast domain is identified by a group of PWs and MAC address domain >by filtering database (e.g. one filtering database per MAC address domain). > >Now, if you understand these fundamentals, then you understand the rest of >the comments that I made. > >> >The reason you cannot combine two customers in the same VPLS instance or at >> >least is not recommended is because you only have a single MAC address >>Once more, your answer is out of the scope of the my topic. >>I'm talking about: one P-VLAN or many P-LAN? >>Your comment is: one VPLS instance or many VPLS instance? > >Think about in term of MAC address domain and broadcast domain. When you >talk about two customers sharing one VPLS instance. Based on our definition >of VPLS instance, it means both of them use the same MAC address domain and >broadcast domain. > > > >> >domain and broadcast domain per VPLS instance which means the same FIB >> >table is shared by VLANs from both customer (VLANs from both customers >> >point to the same FIB table) as well as the same broadcast domain is used >> >for both (customers see each other MAC addresses). Then, how do you >> >coordinate the MAC addressed across different customers. It is tough enough >> >to coordinate within a single customer for unqualified learning. If the MAC >> >addresses are not coordinated (both within the domain of a single customer >> >as well as across them), then their traffic gets blackholed !!!! >>What is the issue with MAC coordinated? I'm sorry I don't known what you mean. >>Please a example of the issue. > >Please refer to Annex B of 802.1Q standards. It gives a good description of >why you have to use IVL mode when you have duplicate MAC addresses - e.g., >why you have to use different filtering databases - e.g., if you don't, >then MAC address entries get over-written and traffic goes to wrong places. > > >> >How do you address that ? >>or are you going to restrict their MAC address sapce ? And >> >how do you enforce how much of that FIB to be used by one customer versus >> >the other ? >>This has nothing to do with P-VLAN. It has something to do with number of VPLS >>instances. >> > Or how do you block one customer traffic from reaching the >> >other one ? >>By P-VLAN. >> > Because of these issues, sharing a VPLS instance is not viable. >>Once more, your answer is out of the scope of the my topic. >>I'm talking about: one P-VLAN or many P-LAN? >>Your comment is: one VPLS instance or many VPLS instance? >> >Also I am definitely not recommending to use MAC ACL for such >> >cases. The recommendation is that each customer has (at least) its own VPLS >> >instance so that the SP can properly enforce the SLA and proper delivery of >> >customer frames. >>Once more, your answer is out of the scope of the my topic. >>(1)My topic: it is better to use many P-VLANs than one P-VLAN when all >>customer >>share one VPLS instance. >>(2)Your answer: it is better to use many VPLS instances rather than one >>VPLS instance. >>I think (1) and (2) is two different topic. They do not conflict with each >>other. > >I hope by now, it is clear why we cannot map two P-VLANs into the same VPLS >instance. If not, then I give up :-) > > >>********************************************************************** >>I beleive many P-VLAN have no issue. Let us look into the draft again. >> >>(1)Between PE-rs and PE-r, we use VC label. >>(2)Between PE-rs and MTU-s, we can use VC label. >>(3)Between PE-rs and MTU-s, we can also use P-VLAN tag. > >A single VC label correspond to a single PW; whereas, a group of PWs >correspond to a single LAN - that's why we sometimes refer to it as V-LAN >emulation. You can refer to the L2-framework draft and it explain it some >more. PW is different than VLAN !!! > >I hope by now, the whole thing is clear and this will be my last email on >this thread. > >Cheers, >Ali > > >>As list above, to PE-rs a P-VLAN tag is just have the same function as a >>VC lable. >>The different is P-VLAN tag is 12bit and the VC label is 20bit. >>Now we can use different VC label for different customer, so we can use >>different >>P-VLAN tag for different customer. Just replace a VC label with a P-VLAN tag. >> >>In other words, P-VLAN tag == VC label of spoke pseudowire, as follow >>(1)Thus, the spoke pseudowire from the PE-r is treated as a virtual >>port and the PE-rs device will switch traffic between the spoke pseudowire, >>hub pseudowires, and access ports once it has learned the MAC addresses. >>(2)Thus, the P-VLAN from the MTU is treated as a virtual >>port and the PE-rs device will switch traffic between the PVLANs, >>hub pseudowires, and access ports once it has learned the MAC addresses. >> >>There is no issue in (1), so there is no issue in (2). >> >>follow words are copied from the draft: >> 10.1.1.2. PE-rs Operation >> >> The PE-rs device is a device that supports all the bridging >> functions for VPLS service and supports the routing and MPLS >> encapsulation, i.e. it supports all the functions described in >> [VPLS]. >> >> The operation of PE-rs is independent of the type of device at the >> other end of the spoke pseudowire. Thus, the spoke pseudowire from >> the PE-r is treated as a virtual port and the PE-rs device will >> switch traffic between the spoke pseudowire, hub pseudowires, and >> access ports once it has learned the MAC addresses. >> >> > >> >> >Second, regarding the rate limiting and traffic policing. Policing and >> >> >shaping functionality should be done as close to the edge as possible >> >> >(before congestion point) and they are done at the MTU-s (not PE-rs) and >> >> >they are performed on a per AC basis (AC can be either customer port for >> >> >unqualified learning and customer VLAN for qualified learning). Some of >> >> >these stuff is described in MEF white paper and you may want to take >> a look >> >> >at it. So for a given customer that has multiple sites connected to the >> >> >same MTU-s, the QoS (rate limiting, shaping, policing) is performed >> on per >> >> >customer site (e.g., per AC) basis. >> >> >> >>Rate-limit is just only an example, there are many other value-add >> >>services which >> >>need to apply in PE-rs based on per customer. If you think that MTU can >> >>do all the >> >>value-add services and the PE-rs do not need to apply any value-add >> >>services based on per customer, I have nothing to say. >> > >> >PE-rs can offer whatever value-add service that you have in mind on a per >> >customer basis by having one VPLS instance per customer. What benefits can >> >you get by sharing the same VPLS instance by multiple customers which >> >violates the principle of isolation and privacy between customers. >>Once more, your answer is out of the scope of the my topic. >>I'm talking about: one P-VLAN or many P-LAN? >>Your comment is: one VPLS instance or many VPLS instance? >> > >> >-Ali >> >> >> From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 13:30:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29500 for ; Thu, 17 Apr 2003 13:30:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HHWKW07765 for ; Thu, 17 Apr 2003 13:32:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HHWIR25713 for ; Thu, 17 Apr 2003 13:32:18 -0400 (EDT) Message-Id: <200304171729.h3HHTMB0019721@rtp-core-1.cisco.com> To: Mourad BERKANE cc: ppvpn@nortelnetworks.com Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Tue, 15 Apr 2003 11:03:38 +0200. <8D91FF5277472A45A0A8F9654A14649701494945@frlnparexcha03.lambdanet.fr> 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: Thu, 17 Apr 2003 13:29:21 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Mourad> If a vendor could explain me how using 2 differents protocols for Mourad> Control Plane (signaling and auto-discovery) will be more efficient Mourad> (technical argumentations please and not philosophical ones) than Mourad> when using only one protocol (MP-BGP). I don't know why the one who explains this needs to be a vendor ;-), but there are a large number of inefficiences in using BGP for the signaling. Suppose that 100 PEs participate in a particular VPLS, and suppose that PE17 has some information to signal to PE43. With point-to-point signaling, PE17 sends a message to PE43, PE43 replies (if necessary), and we're done. With BGP-based signaling, PE17 sends a message to the route reflector, which then resends it to PEs 1-16, and PEs 18-99. So instead of sending one message, you send 100. Ninety-eight of the PEs that receive the message will parse it and find it irrelevant. Efficient? Now let's look at the individual messages. When some PE, say PE92, joins the VPLS instance, it needs to allocate 99 labels, one for each of the other PEs. With point-to-point signaling, PE92 must engage each of the other 99 PEs in one short transaction. PE92 can assign the labels in a way which best suits its implementation, and labels are not assigned unless they are to be used. With BGP-based signaling, we could have PE92 assign 99 individual labels. Then PE92 would send a rather long message to the RR, containing the 99 assignments. The RR would forward these to the 99 other PEs, each of which would then have to find the one label that it cares about. Efficient? To avoid the inefficiency here, we have the "label block hack", in which PE92 reduces the size of its message by assigning a contiguous block of 99 labels, specifying only the beginning and the end of the block. But now if PE92 needs to signal something to PE27, how does it do it? I think all it can do is create a message with 99 signals, 98 of which are "null". It sends it to the RR, which forwards it to the other 99 PEs. All of them parse the message, 98 of them throw it away, and PE27 finally gets its signal. Efficient? (And if this sort of efficiency were not considered important, we wouldn't have the label block hack to begin with.) The requirement to allocate labels in contiguous blocks like this imposes constraints on the way in which implementations may assign labels to particular functions. This is the only place in all of MPLS where constraints like this are imposed. How labels are allocated should really be a local implementation matter, not constrained by protocols. (Perhaps you consider this to be a "philosophical" argument, but I think it can have a real impact on future implementations.) To get the best use out of the label block hack, it is advisable to overprovision, so that all the PEs which are on-line allocate in advance label space for PEs that are not yet on-line. Now you're wasting labels; each wasted label corresponds to a real piece of high speed memory in your forwarding engine, i.e., this is real resources being wasted, not just "numbers". E.g., each wasted label is one less L3VPN route that can be supported. Efficient? In general, providing two functions by using a single protocol instead of two is only more efficient if the single protocol does a good job of providing both functions. Did you ever have both a telnet connection and an ftp connection open to the same destination at the same time? Would it be more efficient to use telnet to do your file transfers, since that would be "one protocol"? What really needs to be discussed in the present context is whether BGP is a good signaling protocol for setting up point-to-point circuits. It's true VPLS provides, much like L3VPN, a multipoint service. However, VPLS is built on top of a mesh of point-to-point circuits, whereas L3VPN is not. That difference needs to be taken into account before concluding that the same set of mechanisms should be used in both cases. I think that some people have presumed that in VPLS, there really is no PE-to-PE signaling that needs to be done. You just piggyback a bunch of labels on the auto-discovery mechanism, and you're all done. If that's the case, then the inefficiencies I discussed above don't come into play. But I haven't seen any justification for this presumption. Certainly in PWE3 there's quite a few things that can be signaled on a point-to-point basis with respect to an ethernet pseudowire. And in VPLS itself, there are quite a number of issues (many still unresolved) about when and where sequencing is needed, about how to transmit control messages, etc., which seem to require some sort of signaling after the circuit has been set up. So it seems to me that there are quite a few technical disadvantages to using BGP-with-RRs (which is inherently a point-to-multipoint signaling substrate) as the basis for doing point-to-point signaling. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 13:51: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 NAA00101 for ; Thu, 17 Apr 2003 13:51:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HHruW12990 for ; Thu, 17 Apr 2003 13:53:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HHrrR08455 for ; Thu, 17 Apr 2003 13:53:54 -0400 (EDT) Message-Id: <200304171750.h3HHoxB0025571@rtp-core-1.cisco.com> To: "DECRAENE Bruno FTRD/DAC/ISS" cc: ppvpn@lyris.nortelnetworks.com, "FONDEVIOLE Benoit FTRD/DAC/ISS" , "JACQUET David FTRD/DAC/ISS" Subject: Re: issues with draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Tue, 15 Apr 2003 18:50:31 +0200. 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: Thu, 17 Apr 2003 13:50:58 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: A few short comments: > - Using one -well known- protocol (MP-BGP) for discovery and signalling is > easier to manage than two protocols (LDP + MP-BGP/RADIUS/DNS/?) Well, that's exactly what was said in favor of CR-LDP ;-) In fact, the overwhelming majority of 2547 networks have LDP already, so the comparison really is BGP+LDP vs. BGP+LDP, with the difference being over whether certain functions go in one place or the other. >- BGP RR greatly reduces the number of sessions to monitor: o(N) vs o(N*N) Indeed, this is its main advantage. (Well, every proposal has advantages and disadvantages ;-)) However, you still have O(N*N) pseudowires to monitor, (not to mention that learning and multicast replication must be applied to each pseudowire) so the overall scalability of the scheme is not improved. (Note also that in routing, RRs improve scalability by digesting the routing information and applying the decision process, thereby reducing the amount of information that needs to be passed along. This sort of scalability improvement is not possible in L2VPN.) > Regarding management, the less work, the better. Typically, maintaining a point-to-point circuit requires maintaining state at both its endpoints. If the control information that sets up and maintains the circuit must lay down state in a third party (RR), a fourth party (two RRs), or more (hierarchical RRs), the management work would seem to be more rather than less. >- With the large scale deployment of 2547 VPN, we gained valuable > experience with MP-BGP (managing, scaling,...). Seems fine to re-use it. I'd be the first to agree that 2547 VPNs are really a great piece of technology ;-) But even I wouldn't say that it is the solution to every problem. Some SPs expect to have lots more PEs supporting VPLS than they have supporting L3VPN, perhaps hundreds or even thousands more. I don't know if this applies to you, but if it does you will certainly need to be putting your experience to good use as you add all these additional clients to your RRs ;-) From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 14:28:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01190 for ; Thu, 17 Apr 2003 14:28:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HIUuW11378 for ; Thu, 17 Apr 2003 14:30:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HIUqR16392 for ; Thu, 17 Apr 2003 14:30:52 -0400 (EDT) Message-ID: <3E9EF208.6090202@isi.edu> Date: Thu, 17 Apr 2003 11:27:20 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030407 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec-vpn@puck.nether.net, ipsec@lists.tislabs.com, ppvpn@lyris.nortelnetworks.com Subject: ID update: draft-touch-ipsec-vpn-05.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030305020806060603010903" X-SMTP-HELO: boreas.isi.edu X-SMTP-MAIL-FROM: larse@ISI.EDU X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: boreas.isi.edu [128.9.160.161] X-LYRIS-Message-Id: This is a cryptographically signed message in MIME format. --------------ms030305020806060603010903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, we've updated our ID on "Use of IPsec Transport Mode for Dynamic Routing", and would appreciate comments. ftp://ftp.isi.edu/internet-drafts/draft-touch-ipsec-vpn-05.txt While the basic contents are identical, the latest update has been restructured for better readability and adds an extended discussion of alternative approaches. Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms030305020806060603010903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQxNzE4MjcyMFowIwYJKoZIhvcNAQkEMRYEFP2wBK/GXuBjRvcf2Ewa HxKLj75gMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAIs8OD4xqGN0EVe59peEEen8Tv//6srFRUReq kEZZPnyNa+Ho4wmxaSJY7xq1SM5FFNQNLUNUp2Kq7Y3R3GwAALw6qDudBe0mMj/F8P53TP3Z Da4fwJGSSbOQ3RPCpFgGtXz1s9Lsw2LedTi29W95oJIbY65EVgxsp/vtvO7I9dyoNbfa6YOS lFPLSu1+6xBsXbV7HrToKx5FhUJ71D5gf5AMUHUk5NGfIpJvEKu4A/AL+Uz3gdsh8y8tIO3/ WpyC33WWqGX63yAuom+/83m6vhx2lYzgiAGql8isvCxPiguoCzB7jTdFjV60aZpp9hVNM08z EcUWSOU+ZicxEaY4vwAAAAAAAA== --------------ms030305020806060603010903-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 15:06:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02907 for ; Thu, 17 Apr 2003 15:06:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HJ8KW06521 for ; Thu, 17 Apr 2003 15:08:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HJ8HR03491 for ; Thu, 17 Apr 2003 15:08:17 -0400 (EDT) Message-ID: <3E9EFA1E.D297B515@alcatel.com> Date: Thu, 17 Apr 2003 15:01:50 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Serbest Yetik" CC: "'mattsquire@acm.org'" , "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5DC8@trimail2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yetik, As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I assume you care about the requirements in that draft. From the requirements draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that loops be prevented." I agree that it is a fundamental requirement that bridging loops be handled in a VPLS solution. As we know loops can have a devastating effect on a bridged network. So, has this point been carefully considered for the VPLS drafts being proposed to be progressed? I think the VPLS drafts being considered here (using full-meshed with split-horizon) are not able to handle common scenarios/requirements leading to loops and causing network meltdowns. This point has been raised before by several people but it still has not been addressed. If this mandatory requirement (not a minor detail or rare scenario) is not addressed and we still progress these drafts what is the message to the industry? That it's ok to continue pushing solutions that don't meet fundamental requirements? Thanks, Cheng-Yin "Serbest, Yetik" wrote: > > I would like to second that. > > Thanks, > yetik > > -----Original Message----- > From: Matt Squire [mailto:mattsquire@acm.org] > Sent: Tuesday, April 15, 2003 7:08 AM > To: 'Rick Wilder' > Cc: ppvpn@nortelnetworks.com > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > The Laserre/VKompella draft should definitely progress as a working > group draft. Its a solid technical contribution with a lot of support > behind it. > > - Matt > > Olen Stokes wrote: > > I would also like to support making this a working group draft. > > > > Cheers, > > Olen > > > > -----Original Message----- > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > *Sent:* Thursday, April 10, 2003 11:20 AM > > *To:* ppvpn@nortelnetworks.com > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > draft > > > > As noted in the minutes, at the San Francisco meeting strong > > interest was expressed in pursuing the > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > agreed to finalize that decision only after the WG participants who > > weren't there could have a say. > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > and this list is the place. Let's set a one-week limit to conclude > > this issue. > > > > > > > > Rick > > > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ------- > > > > From the minutes: > > > > > > > > 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. > > > > > > [snipped] > > > > Marco: asked for show of hands to make this a wG draft. > > Strong interest was shown in room. Further discussion on the list. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 15:16:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03991 for ; Thu, 17 Apr 2003 15:16:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HJIsW10094 for ; Thu, 17 Apr 2003 15:18:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HJIoR25831 for ; Thu, 17 Apr 2003 15:18:51 -0400 (EDT) X-Originating-IP: [219.65.149.27] X-Originating-Email: [sylvia_sugar@hotmail.com] From: "Sylvia Sugar" To: ppvpn@lyris.nortelnetworks.com Subject: RE: RD in 2547 bis Date: Thu, 17 Apr 2003 19:15:31 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2003 19:15:33.0358 (UTC) FILETIME=[B7DB98E0:01C30515] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: sylvia_sugar@hotmail.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: bay1-f53.bay1.hotmail.com [65.54.245.53] X-LYRIS-Message-Id: Hello Mr. Jim, Thank you so much Mr Jim. I believe I have made my point clear and you have given me the necessary answers. only 2 remain: >not necessarily - you can rewrite the RT values at the ASBR routers or you >can carry them unchanged between AS's - this is a deployment choice. 1st let me put on my glasses: @_@ 1. From 2457bis: 4.3.1. The Route Target Attribute Every VRF is associated with one or more "Route Target" attributes. When a VPN-IPv4 route is created (from an IPv4 route which the PE has learned from a CE) by a PE router, it is associated with one or more "Route Target" attributes. These are carried in BGP as attributes of the route. Any route associated with Route Target T must be distributed to every PE router that has a VRF associated with Route Target T. When such a route is received by a PE router, it is eligible to be installed those of the PE's VRFs which are associated with Route Target T. *(Whether it actually gets installed depends upon the outcome of the BGP decision process, and upon the outcome of the decision process of the PE-CE IGP.)* Is this mean that even if one "overwrites" the route target, the route target still identifies the VRF "across the globe" where the routes get distributed? So if even one was to modify the routes, it would not be a problem as the defination of Route Target would remain the same throughout across all Service Providers? Also, does this mean that the BGP decision process now works after filtering on Route Target? also from RFC 2547: 4.2.4. Building VPNs using Target and Origin Attributes By setting up the Target VPN and VPN of Origin attributes properly, one can construct different kinds of VPNs. Suppose it is desired to create a Closed User Group (CUG) which contains a particular set of sites. This can be done by creating a particular Target VPN attribute value to represent the CUG. This value then needs to be associated with the per-site forwarding tables for each site in the CUG, and it needs to be associated with every route learned from a site in the CUG. Any route which has this Target VPN attribute will need to be redistributed so that it reaches every PE router attached to one of the sites in the CUG. Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Target Attribute values, one meaning "Hub" and one meaning "Spoke". Then routes from the spokes could be distributed to the hub, without causing routes from the hub to be distributed to the spokes. Suppose one has a number of sites which are in an intranet and an extranet, as well as a number of sites which are in the intranet only. Then there may be both intranet and extranet routes which have a Target VPN identifying the entire set of sites. The sites which are to have intranet routes only can filter out all routes with the "wrong" *VPN of Origin*. (@_@) These two attributes allow great flexibility in allowing one to control the distribution of routing information among various sets of sites, which in turn provides great flexibility in constructing VPNs. There doesnt seem to be any mention of Route Distinguisher here :-(( oooooohhhhhh! this is all so confusing now :-(( Could you please clarify? 2. >the RD is 64 bits = 8 bytes from 2547bis: The RDs are structured so that every service provider can administer its own "numbering space" (i.e., can make its own assignments of RDs), without conflicting with the RD assignments made by any other service provider. so Mr. Jim, incase one goes across service providers, RD may overlap? ohh now its all so confusing again :-(( The RT seems to be longer than RD too :-(( Thank you so much for your help and patience. I am sure now I can confidently look into MPBGP based on 2547 and 2547bis and hence give a good solution to my customers. Thanks all, -SylviaXO >From: "Jim Guichard" >To: "Sylvia Sugar" , > >Subject: RE: RD in 2547 bis >Date: Thu, 17 Apr 2003 11:36:24 -0400 > >Hi Sylvia, > > > >-----Original Message----- > > >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com] > > >Sent: Thursday, April 17, 2003 3:54 AM > > >To: jguichar@cisco.com; ppvpn@lyris.nortelnetworks.com > > >Subject: RE: RD in 2547 bis > > > > > > > > >Hello Mr. Jim, > > > > > >I must thank you for taking time to mail back on my query. It > > >really feels > > >nice to have the author of a book on MPLS, answer me my queries. > > >I am really > > >thankful to you for your time and patience. > > > > > > > > >I still have a few more things to clarify. > > > > > > > > >> > >> > > >> > >> > > > >RD is local to the router /used to distinguish VPNv4 >routes > > >> > >>locally, is my > > >> > >> > >understanding. > > >> > >> > > RD becomes crucial with the presence of RRs. > > >> > >> > > >> > >>How come? Can you please give me some pointers as to how RD >becomes > > >> > >>"crucial" in presence > > >> > >>of RRs. > > >> > > >>the RD is not really local to the router in the sense that it can >affect > > >>route selection at the RRs. If you use the same RD on say PE1 > > >and PE2 (lets > > >>call it RD 100:2) and then export route 1.1.1.1 from both PEs, > > >the RR will > > >>see two identical routes e.g. 100:2:1.1.1.1. It will select one as >best > > >>path > > >>and therefore one of the routes is lost from downstream PEs. > > > > > > > > >But Mr Jim, how could one use different Route Distiguisher for the same > > >prefix? In the book it seems to say its unique to the customer. > >this can happen if you export the same route from two different PEs - note >that this will happen if you have a dual-attached site advertising the same >set of prefixes. > > > > > > >On the other had, when one passes routes across VPNs, it seems > > >to say that > > >the Route Target is used to identify the "VRF" of customer. There is > > >something about multiple service providers, who each would have > > >control of > > >RD which would be local to them, but Route Target would be unique to a > > >customer across all service providers. > >not necessarily - you can rewrite the RT values at the ASBR routers or you >can carry them unchanged between AS's - this is a deployment choice. > > > > > > >The reason cited for the same is the size of the Route > > >Distinguisher is very > > >small. > >the RD is 64 bits = 8 bytes > > > > > > >This is my understanding from 2547 and 2547bis. > > > > > >I am not too sure where this was mentioned in your book. > > > > > >However, it seems to make Route Distinguisher redundant. > > >One could simply replace Route Distinguisher with Route Target > > >and it seems > > >to achieve the same functionality > >no, it does not. The RT is used for import/export policy. The RD is used to >make the IPv4 address unique. An update can carry multiple RT values but a >single RD for each NLRI within the update. Jim > > > > > > >Please correct me if I am wrong. This is all sooo confusing. :-(( > > > > > >-SylviaXO > > > > > >_________________________________________________________________ > > >MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > > >http://join.msn.com/?page=features/virus > > > _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 16:11:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05942 for ; Thu, 17 Apr 2003 16:11:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HKDbW12071 for ; Thu, 17 Apr 2003 16:13:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HKDYR03955 for ; Thu, 17 Apr 2003 16:13:35 -0400 (EDT) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5DCF@trimail2> From: "Serbest, Yetik" To: "'Cheng-Yin.Lee@alcatel.com'" Cc: "'mattsquire@acm.org'" , "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Thu, 17 Apr 2003 14:57:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: serbest@tri.sbc.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Cheng-Yin, When a draft becomes a working group document, that does not mean we stop working on it. Your point is good, and we will work on the issue. There was some preliminary discussion among the authors; and when we have some conclusions, we will share them with the group. There are some other issues as well. In DT, as you see from the mail (dated 2/6/2003) below I raised that issue. ".....Anyway, as long as we move on and reach the time when we discuss how to support dual-homed CEs or customers with backdoor links, and how to troubleshoot the service when q or qinq spokes are present etc... I am fine with it." Thanks, yetik -----Original Message----- From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] Sent: Thursday, April 17, 2003 2:02 PM To: Serbest, Yetik Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Yetik, As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I assume you care about the requirements in that draft. From the requirements draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that loops be prevented." I agree that it is a fundamental requirement that bridging loops be handled in a VPLS solution. As we know loops can have a devastating effect on a bridged network. So, has this point been carefully considered for the VPLS drafts being proposed to be progressed? I think the VPLS drafts being considered here (using full-meshed with split-horizon) are not able to handle common scenarios/requirements leading to loops and causing network meltdowns. This point has been raised before by several people but it still has not been addressed. If this mandatory requirement (not a minor detail or rare scenario) is not addressed and we still progress these drafts what is the message to the industry? That it's ok to continue pushing solutions that don't meet fundamental requirements? Thanks, Cheng-Yin "Serbest, Yetik" wrote: > > I would like to second that. > > Thanks, > yetik > > -----Original Message----- > From: Matt Squire [mailto:mattsquire@acm.org] > Sent: Tuesday, April 15, 2003 7:08 AM > To: 'Rick Wilder' > Cc: ppvpn@nortelnetworks.com > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > draft > > The Laserre/VKompella draft should definitely progress as a working > group draft. Its a solid technical contribution with a lot of support > behind it. > > - Matt > > Olen Stokes wrote: > > I would also like to support making this a working group draft. > > > > Cheers, > > Olen > > > > -----Original Message----- > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > *Sent:* Thursday, April 10, 2003 11:20 AM > > *To:* ppvpn@nortelnetworks.com > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > draft > > > > As noted in the minutes, at the San Francisco meeting strong > > interest was expressed in pursuing the > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > agreed to finalize that decision only after the WG participants who > > weren't there could have a say. > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > and this list is the place. Let's set a one-week limit to conclude > > this issue. > > > > > > > > Rick > > > > > > > > > > -------------------------------------------------------------------- > > -- > > ---------------------------------------------------------------------- > > ------- > > > > From the minutes: > > > > > > > > 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. > > > > > > [snipped] > > > > Marco: asked for show of hands to make this a wG draft. > > Strong interest was shown in room. Further discussion on the > > list. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 16:31: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 QAA06723 for ; Thu, 17 Apr 2003 16:31:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HKXXW20954 for ; Thu, 17 Apr 2003 16:33:33 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HKXTR26436 for ; Thu, 17 Apr 2003 16:33:29 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Amit Singh" Cc: "Ppvpn" Subject: RE: L2vpn draft that is accepted by most vendors ? Date: Thu, 17 Apr 2003 13:17:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-OriginalArrivalTime: 17 Apr 2003 20:17:15.0596 (UTC) FILETIME=[569048C0:01C3051E] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Amit, I suggest you subscribe to the ppvpn mailing list where those questions are better addressed. VPLS (lasserre-vkompella - khandekar is a co-author, too) is one draft that is being considered for working group status. -Vach > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Amit > Singh > Sent: Thursday, April 17, 2003 12:45 PM > To: MPLS WG > Cc: mpls@UU.NET > Subject: L2vpn draft that is accepted by most vendors ? > Importance: Low > > > Is there a Draft that is gonna be standardized for Point to multipoint l2vpn > ??? khandekar or koempella ??? Just like martini > > Regards > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 16:35:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06829 for ; Thu, 17 Apr 2003 16:35:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HKbqW21784 for ; Thu, 17 Apr 2003 16:37:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HKblR01427 for ; Thu, 17 Apr 2003 16:37:48 -0400 (EDT) From: "Jim Guichard" To: "Sylvia Sugar" , Subject: RE: RD in 2547 bis Date: Thu, 17 Apr 2003 15:55:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-msg-core-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: ams-msg-core-1.cisco.com [144.254.74.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Sylvia, > >-----Original Message----- > >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com] > >Sent: Thursday, April 17, 2003 3:16 PM > >To: ppvpn@lyris.nortelnetworks.com > >Subject: RE: RD in 2547 bis > > > > > >Hello Mr. Jim, > > > >Thank you so much Mr Jim. > > > >I believe I have made my point clear and you have given me the necessary > >answers. > > > >only 2 remain: > > > >>not necessarily - you can rewrite the RT values at the ASBR > >routers or you > >>can carry them unchanged between AS's - this is a deployment choice. > > > >1st let me put on my glasses: > > > >@_@ > > > >1. > > > >>From 2457bis: > >4.3.1. The Route Target Attribute > > > > Every VRF is associated with one or more "Route Target" attributes. > > > > When a VPN-IPv4 route is created (from an IPv4 route which the PE has > > learned from a CE) by a PE router, it is associated with one or more > > "Route Target" attributes. These are carried in BGP as attributes of > > the route. > > > > Any route associated with Route Target T must be distributed to every > > PE router that has a VRF associated with Route Target T. When such a > > route is received by a PE router, it is eligible to be installed > > those of the PE's VRFs which are associated with Route Target T. > > *(Whether it actually gets installed depends upon the outcome of the > > BGP decision process, and upon the outcome of the decision process of > > the PE-CE IGP.)* > > > > > > > >Is this mean that even if one "overwrites" the route target, the route > >target still identifies the VRF "across the globe" where the routes get > >distributed? a PE may import any route that contains an RT value that has been configured as eligible for import locally. So, if PE1 has VRF1 that has an import statement saying "import any routes with RT value 1" then, if an update arrives with route X and RT value 1, it will import it. This particular route X might have been exported from PE2 in another AS using RT value 2 but at the ASBR a rewrite occurred where RT value 2 got changed to RT value 1. This is perfectly valid. > > > >So if even one was to modify the routes, it would not be a > >problem as the > >defination of Route Target would remain the same throughout across all > >Service Providers? > > > >Also, does this mean that the BGP decision process now works > >after filtering > >on Route Target? not exactly. I cannot speak for other implementations but in the Cisco case, BGP best path is run against all routes within the BGP table and then a further best path selection occurs during the import processing. So, if you had RD1:1.1.1.1, and RD2:1.1.1.1 in the BGP table, they would be considered as unique routes and therefore not comparable. However, if they both had RT value 1 and VRF1 imports RT value 1, they will be compared during the import and only 1 will be chosen as the best path. > > > > > > > >also from RFC 2547: > > > >4.2.4. Building VPNs using Target and Origin Attributes > > > > By setting up the Target VPN and VPN of Origin attributes properly, > > one can construct different kinds of VPNs. > > > > Suppose it is desired to create a Closed User Group (CUG) which > > contains a particular set of sites. This can be done by creating a > > particular Target VPN attribute value to represent the CUG. This > > value then needs to be associated with the per-site forwarding tables > > for each site in the CUG, and it needs to be associated with every > > route learned from a site in the CUG. Any route which has this > > Target VPN attribute will need to be redistributed so that it reaches > > every PE router attached to one of the sites in the CUG. > > > > Alternatively, suppose one desired, for whatever reason, to create a > > "hub and spoke" kind of VPN. This could be done by the use of two > > Target Attribute values, one meaning "Hub" and one meaning "Spoke". > > Then routes from the spokes could be distributed to the hub, without > > causing routes from the hub to be distributed to the spokes. > > > > Suppose one has a number of sites which are in an intranet and an > > extranet, as well as a number of sites which are in the intranet > > only. Then there may be both intranet and extranet routes which have > > a Target VPN identifying the entire set of sites. The sites which > > are to have intranet routes only can filter out all routes with the > > "wrong" *VPN of Origin*. (@_@) > > > > These two attributes allow great flexibility in allowing one to > > control the distribution of routing information among various sets of > > sites, which in turn provides great flexibility in constructing VPNs. > > > >There doesnt seem to be any mention of Route Distinguisher here :-(( and neither should there be 8^) the RT is what controls import/export - RD has nothing to do with it. > > > >oooooohhhhhh! this is all so confusing now :-(( Could you please clarify? > > > > > >2. > >>the RD is 64 bits = 8 bytes > >from 2547bis: > > > >The RDs are structured so that every service provider can administer > > its own "numbering space" (i.e., can make its own assignments of > > RDs), without conflicting with the RD assignments made by any other > > service provider. > > > >so Mr. Jim, incase one goes across service providers, RD may > >overlap? ohh > >now its all so confusing again :-(( no, it is actually the opposite. Because the normal structure of the RD is ASN:value it should be unique between providers as they have their own ASN#. They have to be unique otherwise you could get conflicting VPNv4 prefixes e.g if SPa uses RD1:100 and so does SPb then how can they both export route 1.1.1.1 ? it would be exported as 1:100:1.1.1.1 within both AS's. Jim > > > >The RT seems to be longer than RD too :-(( > > > >Thank you so much for your help and patience. > > > >I am sure now I can confidently look into MPBGP based on 2547 > >and 2547bis > >and hence give a good solution to my customers. > > > >Thanks all, > > > >-SylviaXO > > > > > > > > > >>From: "Jim Guichard" > >>To: "Sylvia Sugar" , > >> > >>Subject: RE: RD in 2547 bis > >>Date: Thu, 17 Apr 2003 11:36:24 -0400 > >> > >>Hi Sylvia, > >> > >> > >-----Original Message----- > >> > >From: Sylvia Sugar [mailto:sylvia_sugar@hotmail.com] > >> > >Sent: Thursday, April 17, 2003 3:54 AM > >> > >To: jguichar@cisco.com; ppvpn@lyris.nortelnetworks.com > >> > >Subject: RE: RD in 2547 bis > >> > > > >> > > > >> > >Hello Mr. Jim, > >> > > > >> > >I must thank you for taking time to mail back on my query. It > >> > >really feels > >> > >nice to have the author of a book on MPLS, answer me my queries. > >> > >I am really > >> > >thankful to you for your time and patience. > >> > > > >> > > > >> > >I still have a few more things to clarify. > >> > > > >> > > > >> > >> > >> > >> > >> > >> > > > >RD is local to the router /used to distinguish VPNv4 > >>routes > >> > >> > >>locally, is my > >> > >> > >> > >understanding. > >> > >> > >> > > RD becomes crucial with the presence of RRs. > >> > >> > >> > >> > >> > >>How come? Can you please give me some pointers as to how RD > >>becomes > >> > >> > >>"crucial" in presence > >> > >> > >>of RRs. > >> > >> > >> > >>the RD is not really local to the router in the sense that it can > >>affect > >> > >>route selection at the RRs. If you use the same RD on say PE1 > >> > >and PE2 (lets > >> > >>call it RD 100:2) and then export route 1.1.1.1 from both PEs, > >> > >the RR will > >> > >>see two identical routes e.g. 100:2:1.1.1.1. It will select one as > >>best > >> > >>path > >> > >>and therefore one of the routes is lost from downstream PEs. > >> > > > >> > > > >> > >But Mr Jim, how could one use different Route Distiguisher > >for the same > >> > >prefix? In the book it seems to say its unique to the customer. > >> > >>this can happen if you export the same route from two different > >PEs - note > >>that this will happen if you have a dual-attached site > >advertising the same > >>set of prefixes. > >> > >> > > > >> > >On the other had, when one passes routes across VPNs, it seems > >> > >to say that > >> > >the Route Target is used to identify the "VRF" of customer. There is > >> > >something about multiple service providers, who each would have > >> > >control of > >> > >RD which would be local to them, but Route Target would be > >unique to a > >> > >customer across all service providers. > >> > >>not necessarily - you can rewrite the RT values at the ASBR > >routers or you > >>can carry them unchanged between AS's - this is a deployment choice. > >> > >> > > > >> > >The reason cited for the same is the size of the Route > >> > >Distinguisher is very > >> > >small. > >> > >>the RD is 64 bits = 8 bytes > >> > >> > > > >> > >This is my understanding from 2547 and 2547bis. > >> > > > >> > >I am not too sure where this was mentioned in your book. > >> > > > >> > >However, it seems to make Route Distinguisher redundant. > >> > >One could simply replace Route Distinguisher with Route Target > >> > >and it seems > >> > >to achieve the same functionality > >> > >>no, it does not. The RT is used for import/export policy. The > >RD is used to > >>make the IPv4 address unique. An update can carry multiple RT > >values but a > >>single RD for each NLRI within the update. Jim > >> > >> > > > >> > >Please correct me if I am wrong. This is all sooo confusing. :-(( > >> > > > >> > >-SylviaXO > >> > > > >> > >_________________________________________________________________ > >> > >MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > >> > >http://join.msn.com/?page=features/virus > >> > >> > >> > > > > > >_________________________________________________________________ > >Help STOP SPAM with the new MSN 8 and get 2 months FREE* > >http://join.msn.com/?page=features/junkmail > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 16:35:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06855 for ; Thu, 17 Apr 2003 16:35:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HKc5W22022 for ; Thu, 17 Apr 2003 16:38:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HKc1R01749 for ; Thu, 17 Apr 2003 16:38:02 -0400 (EDT) Message-ID: From: "Moranganti, Ashwin" To: "'ppvpn@nortelnetworks.com'" Subject: Support for draft-shah-ppvpn-ipls-01.txt Date: Thu, 17 Apr 2003 14:59:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: smtp2.adc.com X-SMTP-MAIL-FROM: Ashwin.Moranganti@adc.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp2.adc.com [155.226.10.211] X-LYRIS-Message-Id: I would like to support "draft-shah-ppvpn-ipls-01.txt" to become a working group document. VPLS is becoming a prominent solution offering in the MSO market place. Almost all of the MSO's have an IP backbone . The CMTS's in the MSOs are being pushed to take up the role of the PE device. And most of the deployed CMTS devices are routers. Given that, if a CMTS router vendor were to choose from the widely popular choices, they are limited to lassare_vkompella or kompella_vpls drafts. Apart from the signaling differences. the kompella_vpls requires for an external L2 switch to complete the solution. And the Lassare_vkompella switch requires the CMTS router to incorporate MAC based learning ...etc in the data path. This has adverse development/performance and scalability implications. (I understand that most next gen routers/switches that incorporate switching and routing do not have these issues) draft-shah-ppvpn-ipls-01.txt is the only draft that provides an implementable and deployable solution for most routers out in the field (By making it possible for MAC learning in the control plane) Ashwin Moranganti From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 16:49:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07262 for ; Thu, 17 Apr 2003 16:49:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HKq3W29078 for ; Thu, 17 Apr 2003 16:52:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HKpxR15261 for ; Thu, 17 Apr 2003 16:52:00 -0400 (EDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 17 Apr 2003 13:48:20 -0700 (PDT) From: Kireeti Kompella To: Eric Rosen cc: Mourad BERKANE , "" Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-Reply-To: <200304171729.h3HHTMB0019721@rtp-core-1.cisco.com> Message-ID: <20030417123347.M55269@kummer.juniper.net> References: <200304171729.h3HHTMB0019721@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: On Thu, 17 Apr 2003, Eric Rosen wrote: > Mourad> If a vendor could explain me how using 2 differents protocols for > Mourad> Control Plane (signaling and auto-discovery) will be more efficient > Mourad> (technical argumentations please and not philosophical ones) than > Mourad> when using only one protocol (MP-BGP). > > I don't know why the one who explains this needs to be a vendor ;-), but > there are a large number of inefficiences in using BGP for the signaling. > > Suppose that 100 PEs participate in a particular VPLS, and suppose that PE17 > has some information to signal to PE43. > > With point-to-point signaling, PE17 sends a message to PE43, PE43 replies > (if necessary), and we're done. Sure. N*(N-1) is small when N = 2. > With BGP-based signaling, PE17 sends a message to the route reflector, which > then resends it to PEs 1-16, and PEs 18-99. So instead of sending one > message, you send 100. Ninety-eight of the PEs that receive the message > will parse it and find it irrelevant. Efficient? Excuse me, but are you not an author of rfc2547bis and draft-ietf-ppvpn-bgpvpn-auto-03.txt? In both of the above, you send 100 messages to all the PEs, even if the only other member of the VPN is PE43. So, for a more accurate picture (since BGP is *not* only for signaling), PE17 sends a message to the route reflector, saying essentially, "I'm in VPN foo, and btw, these are the labels to use". The RR then sends 100 messages to all other PEs. Most of these PEs ignore the message (they are not part of VPLS foo); the ones who are find out, with one message, that PE17 is part of VPLS foo, and which labels to use. Summary: one NLRI per PE per VPLS. Efficient? With BGP+LDP, the flow would be: PE17 sends a message to the route reflector, saying essentially, "I'm in VPN foo" (no labels). The RR then sends 100 messages to all other PEs. Most of these PEs ignore the message (they are not part of VPLS foo); the ones who are find out that PE17 is part of VPLS foo. So far, not much difference -- except: no labels. Now, the PEs who are in VPLS foo must kick off a separate interaction -- a new LDP session if needed, and new messages for the exchange of labels. And each PE in VPLS foo must do this independently. Summary: one NLRI per PE per VPLS plus N*(N-1) LDP label exchanges per VPLS with N members. Efficient? Certainly when N = 2. As for the "label block hack", sure, call it a hack, that should scare people away -- argumentum ad hominem always works. Efficient block allocation is a solved problem. Ask anyone who does memory management, or any number of allocation problems. > To get the best use out of the label block hack, it is advisable to > overprovision, so that all the PEs which are on-line allocate in advance > label space for PEs that are not yet on-line. Now you're wasting labels; > each wasted label corresponds to a real piece of high speed memory in your > forwarding engine, i.e., this is real resources being wasted, not just > "numbers". E.g., each wasted label is one less L3VPN route that can be > supported. Efficient? You certainly can do it this way. We don't. As for "wasting" labels, it amazes me that a vendor that allocates individual labels for each IP VPN prefix from the same PE keeps harping on this. To give credit where credit is due, the idea of using BGP for both auto-discovery and signaling came from RFC 2547. I thought this was clear; but I'll state it for the record. The one issue was that for IP VPNs, a single label per site suffices; for VPLS, you need several. Hence label blocks. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 16:55: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 QAA07691 for ; Thu, 17 Apr 2003 16:55:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HKvoW02943 for ; Thu, 17 Apr 2003 16:57:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HKvkR23178 for ; Thu, 17 Apr 2003 16:57:47 -0400 (EDT) Message-ID: From: "O'Connor, Don" To: "'Serbest, Yetik'" , "'Cheng-Yin.Lee@alcatel.com'" Cc: "'mattsquire@acm.org'" , "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Thu, 17 Apr 2003 15:53:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: fncimr02.fnc.fujitsu.com X-SMTP-MAIL-FROM: Don.OConnor@fnc.fujitsu.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: fncimr02.fnc.fujitsu.com [168.127.0.4] X-LYRIS-Message-Id: Yetik & Cheng-Yin, Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge Group to define solutions for these issues. Regards, Don -----Original Message----- From: Serbest, Yetik [mailto:serbest@tri.sbc.com] Sent: Thursday, April 17, 2003 2:58 PM To: 'Cheng-Yin.Lee@alcatel.com' Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cheng-Yin, When a draft becomes a working group document, that does not mean we stop working on it. Your point is good, and we will work on the issue. There was some preliminary discussion among the authors; and when we have some conclusions, we will share them with the group. There are some other issues as well. In DT, as you see from the mail (dated 2/6/2003) below I raised that issue. ".....Anyway, as long as we move on and reach the time when we discuss how to support dual-homed CEs or customers with backdoor links, and how to troubleshoot the service when q or qinq spokes are present etc... I am fine with it." Thanks, yetik -----Original Message----- From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] Sent: Thursday, April 17, 2003 2:02 PM To: Serbest, Yetik Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Yetik, As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I assume you care about the requirements in that draft. From the requirements draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that loops be prevented." I agree that it is a fundamental requirement that bridging loops be handled in a VPLS solution. As we know loops can have a devastating effect on a bridged network. So, has this point been carefully considered for the VPLS drafts being proposed to be progressed? I think the VPLS drafts being considered here (using full-meshed with split-horizon) are not able to handle common scenarios/requirements leading to loops and causing network meltdowns. This point has been raised before by several people but it still has not been addressed. If this mandatory requirement (not a minor detail or rare scenario) is not addressed and we still progress these drafts what is the message to the industry? That it's ok to continue pushing solutions that don't meet fundamental requirements? Thanks, Cheng-Yin "Serbest, Yetik" wrote: > > I would like to second that. > > Thanks, > yetik > > -----Original Message----- > From: Matt Squire [mailto:mattsquire@acm.org] > Sent: Tuesday, April 15, 2003 7:08 AM > To: 'Rick Wilder' > Cc: ppvpn@nortelnetworks.com > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > draft > > The Laserre/VKompella draft should definitely progress as a working > group draft. Its a solid technical contribution with a lot of support > behind it. > > - Matt > > Olen Stokes wrote: > > I would also like to support making this a working group draft. > > > > Cheers, > > Olen > > > > -----Original Message----- > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > *Sent:* Thursday, April 10, 2003 11:20 AM > > *To:* ppvpn@nortelnetworks.com > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > draft > > > > As noted in the minutes, at the San Francisco meeting strong > > interest was expressed in pursuing the > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > agreed to finalize that decision only after the WG participants who > > weren't there could have a say. > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > and this list is the place. Let's set a one-week limit to conclude > > this issue. > > > > > > > > Rick > > > > > > > > > > -------------------------------------------------------------------- > > -- > > ---------------------------------------------------------------------- > > ------- > > > > From the minutes: > > > > > > > > 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. > > > > > > [snipped] > > > > Marco: asked for show of hands to make this a wG draft. > > Strong interest was shown in room. Further discussion on the > > list. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 16:57:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07765 for ; Thu, 17 Apr 2003 16:57:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HKxaW07198 for ; Thu, 17 Apr 2003 16:59:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HKxUR26625 for ; Thu, 17 Apr 2003 16:59:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Thu, 17 Apr 2003 22:43:24 +0200 Message-ID: Thread-Topic: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMFB1kiNX/bngA1Q0GzHMy2RZOE6QAFggHQ From: "Hector Avalos" To: , "Mourad BERKANE" Cc: X-OriginalArrivalTime: 17 Apr 2003 20:43:25.0314 (UTC) FILETIME=[FE303E20:01C30521] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA07765 >>Mourad> If a vendor could explain me how using 2 differents protocols for >>Mourad> Control Plane (signaling and auto-discovery) will be more efficient >>Mourad> (technical argumentations please and not philosophical ones) than >>Mourad> when using only one protocol (MP-BGP). >>I don't know why the one who explains this needs to be a vendor ;-), but >>there are a large number of inefficiences in using BGP for the signaling. >>Suppose that 100 PEs participate in a particular VPLS, and suppose that PE17 >>has some information to signal to PE43. >>With point-to-point signaling, PE17 sends a message to PE43, PE43 replies >>(if necessary), and we're done. Hector> What would be the type of signaling message a PE17 will send to a PE43 Hector> that any other PE should be aware if the VPLS is a full mesh ? Hector> >>With BGP-based signaling, PE17 sends a message to the route reflector, which >>then resends it to PEs 1-16, and PEs 18-99. So instead of sending one >>message, you send 100. Ninety-eight of the PEs that receive the message >>will parse it and find it irrelevant. Efficient? Hector> This is the same behavior than 2547bis and it works very well. Hector> PE will need to handle one single message, so there is no issue here. Hector> There are RR which can handle this with no issues. And if there is Hector> an scaling issues we can partition the network with several RR Hector> like in 2547bis. So there is no scaling issues here. >>Now let's look at the individual messages. When some PE, say PE92, joins >>the VPLS instance, it needs to allocate 99 labels, one for each of the other >>PEs. With point-to-point signaling, PE92 must engage each of the other 99 >>PEs in one short transaction. PE92 can assign the labels in a way which best >>suits its implementation, and labels are not assigned unless they are to be >>used. >>With BGP-based signaling, we could have PE92 assign 99 individual labels. >>Then PE92 would send a rather long message to the RR, containing the 99 >>assignments. The RR would forward these to the 99 other PEs, each of which >>would then have to find the one label that it cares about. Efficient? Hector> With BGP the NLRI is the same for a VPLS with 2 PEs or 1000 PEs Hector> With BGP only the label base and offset is send on the NLRI Hector> he label block hack as you called it...So no issues again. >>To avoid the inefficiency here, we have the "label block hack", in which >>PE92 reduces the size of its message by assigning a contiguous block of 99 >>labels, specifying only the beginning and the end of the block. But now if >>PE92 needs to signal something to PE27, how does it do it? I think all it >>can do is create a message with 99 signals, 98 of which are "null". It >>sends it to the RR, which forwards it to the other 99 PEs. All of them >>parse the message, 98 of them throw it away, and PE27 finally gets its >>signal. Efficient? (And if this sort of efficiency were not considered >>important, we wouldn't have the label block hack to begin with.) Hector> for mesh VPLS I don't see the PE to PE message requirement. Hector> If it is to announce that the local port is down, it should announce it Hector> to all other PEs in the domain. >>The requirement to allocate labels in contiguous blocks like this imposes >>constraints on the way in which implementations may assign labels to >>particular functions. This is the only place in all of MPLS where >>constraints like this are imposed. How labels are allocated should really >>be a local implementation matter, not constrained by protocols. (Perhaps >>you consider this to be a "philosophical" argument, but I think it can have >>a real impact on future implementations.) Hector> what is the issue with this regarding its benefits ? >>To get the best use out of the label block hack, it is advisable to >>overprovision, so that all the PEs which are on-line allocate in advance >>label space for PEs that are not yet on-line. Now you're wasting labels; >>each wasted label corresponds to a real piece of high speed memory in your >>forwarding engine, i.e., this is real resources being wasted, not just >>"numbers". E.g., each wasted label is one less L3VPN route that can be >>supported. Efficient? Hector> I wonder what is the conception of a VPLS domain size. Hector> I guess that VPLS will not be applicable to +100 sites VPNs Hector> For a VPLS domain of 100 sites, a PE needs to reserve 100 labels Hector> If a PE supports 1000 VPNS of this size, then we end-up with 100,000 labels. Hector> I don't see any issue. Hector> I know some 2547bis applications which signals one label per prefix. Hector> If we do the math using VPNs with 100 routes each, we will see Hector> the label block uses quite less labels. So there should be no issues Hector> on PEs using label blocks. >>In general, providing two functions by using a single protocol instead of >>two is only more efficient if the single protocol does a good job of >>providing both functions. Did you ever have both a telnet connection and an >>ftp connection open to the same destination at the same time? Would it be >>more efficient to use telnet to do your file transfers, since that would be >>"one protocol"? What really needs to be discussed in the present context is >>whether BGP is a good signaling protocol for setting up point-to-point >>circuits. It's true VPLS provides, much like L3VPN, a multipoint service. >>However, VPLS is built on top of a mesh of point-to-point circuits, whereas >>L3VPN is not. That difference needs to be taken into account before >>concluding that the same set of mechanisms should be used in both cases. >>I think that some people have presumed that in VPLS, there really is no >>PE-to-PE signaling that needs to be done. You just piggyback a bunch of >>labels on the auto-discovery mechanism, and you're all done. If that's the >>case, then the inefficiencies I discussed above don't come into play. But I >>haven't seen any justification for this presumption. Certainly in PWE3 >>there's quite a few things that can be signaled on a point-to-point basis >>with respect to an ethernet pseudowire. And in VPLS itself, there are quite >>a number of issues (many still unresolved) about when and where sequencing >>is needed, about how to transmit control messages, etc., which seem to >>require some sort of signaling after the circuit has been set up. Hector> please share with us which PE-to-PE signaling needs to be done Hector> on a multi-point environment >>So it seems to me that there are quite a few technical disadvantages to >>using BGP-with-RRs (which is inherently a point-to-multipoint signaling >>substrate) as the basis for doing point-to-point signaling. Hector> I think that comparing BGP vs LDP for signaling is a wrong comparison Hector> BGP also does auto-discovery, which LDP doesn't. Hector> So I guess that Mourad's question remains open. How two protocols will be more efficient Hector> for signaling and auto-discovery ? From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 18:11:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11210 for ; Thu, 17 Apr 2003 18:11:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HM9dW14049 for ; Thu, 17 Apr 2003 18:09:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HM9YR22834 for ; Thu, 17 Apr 2003 18:09:34 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "O'Connor, Don" , "'Serbest, Yetik'" , Cc: , "'Rick Wilder'" , Subject: IEEE 802.1ad and VPLS Date: Thu, 17 Apr 2003 15:06:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-OriginalArrivalTime: 17 Apr 2003 22:06:36.0011 (UTC) FILETIME=[9CE02BB0:01C3052D] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Dan, Yes it is. One of the items in the ppvpn-wg minutes (note the date pre-dates the official PAR date which is Dec. 31, 2002, so we (as IETF participants) have been keeping in touch with the IEEE, albeit informally) for the Atlanta meeting shows: === clipped from minutes === Norm Finn - IEEE 802.1 unofficial liaison ----------------------------------------- Project authorization request (amendment to 802.1q VLANs) - enable a SP to offer the equivalent of separate LAN segments, bridged or virtual bridged LANs (network of bridges doing l2vpn type services). Name of project - 802.1AD. MAC-in-MAC not possible with this amendment. Confident that IETF L2vpn and 802.1AD will be interoperable, compatible etc if mailing discussions are carried through. === end of clip === -Vach > -----Original Message----- > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > Sent: Thursday, April 17, 2003 1:54 PM > To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > Yetik & Cheng-Yin, > > Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge > Group to define solutions for these issues. > > Regards, > > Don > > -----Original Message----- > From: Serbest, Yetik [mailto:serbest@tri.sbc.com] > Sent: Thursday, April 17, 2003 2:58 PM > To: 'Cheng-Yin.Lee@alcatel.com' > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > Cheng-Yin, > > When a draft becomes a working group document, that does not mean we stop > working on it. Your point is good, and we will work on the issue. There was > some preliminary discussion among the authors; and when we have some > conclusions, we will share them with the group. There are some other issues > as well. > > In DT, as you see from the mail (dated 2/6/2003) below I raised that issue. > > ".....Anyway, as long as we move on and reach the time when we discuss how > to support dual-homed CEs or customers with backdoor links, and how to > troubleshoot the service when q or qinq spokes are present etc... I am fine > with it." > > Thanks, > yetik > > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: Thursday, April 17, 2003 2:02 PM > To: Serbest, Yetik > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > Yetik, > As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I > assume you care about the requirements in that draft. From the requirements > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that > loops be prevented." > > I agree that it is a fundamental requirement that bridging loops be handled > in a VPLS solution. As we know loops can have a devastating effect on a > bridged network. > > So, has this point been carefully considered for the VPLS drafts being > proposed to be progressed? > > I think the VPLS drafts being considered here (using full-meshed with > split-horizon) are not able to handle common scenarios/requirements leading > to loops and causing network meltdowns. > > This point has been raised before by several people but it still has not > been addressed. If this mandatory requirement (not a minor detail or rare > scenario) is not addressed and we still progress these drafts what is the > message to the industry? That it's ok to continue pushing solutions that > don't meet fundamental requirements? > > Thanks, > Cheng-Yin > > "Serbest, Yetik" wrote: > > > > I would like to second that. > > > > Thanks, > > yetik > > > > -----Original Message----- > > From: Matt Squire [mailto:mattsquire@acm.org] > > Sent: Tuesday, April 15, 2003 7:08 AM > > To: 'Rick Wilder' > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > draft > > > > The Laserre/VKompella draft should definitely progress as a working > > group draft. Its a solid technical contribution with a lot of support > > behind it. > > > > - Matt > > > > Olen Stokes wrote: > > > I would also like to support making this a working group draft. > > > > > > Cheers, > > > Olen > > > > > > -----Original Message----- > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > *To:* ppvpn@nortelnetworks.com > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > draft > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > interest was expressed in pursuing the > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > > agreed to finalize that decision only after the WG participants who > > > weren't there could have a say. > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > > and this list is the place. Let's set a one-week limit to conclude > > > this issue. > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > ---------------------------------------------------------------------- > > > ------- > > > > > > From the minutes: > > > > > > > > > > > > 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. > > > > > > > > > [snipped] > > > > > > Marco: asked for show of hands to make this a wG draft. > > > Strong interest was shown in room. Further discussion on the > > > list. > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 18:53:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13272 for ; Thu, 17 Apr 2003 18:53:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HMtvW18461 for ; Thu, 17 Apr 2003 18:55:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HMtrR07948 for ; Thu, 17 Apr 2003 18:55:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20030417152351.01bf51a8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 15:40:14 -0700 To: Cheng-Yin.Lee@alcatel.com, Rick Wilder , "Marco Carugi" From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: ppvpn@nortelnetworks.com In-Reply-To: <3E9C8C96.1FF565D8@alcatel.com> References: <6B25E083A064374CA3D2FAB305CFAF7A03C42E@m-va-bsod03.add0.masergy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Cheng-Yin, The issues that you are bringing up in here are not just specific to our draft but also applies to other drafts (e.g., draft-kompella-vpls, draft-gvpls, ). If you have attended the IEEE 802.1 meeting, you should know that the first issue has been discussed there (both in the meeting as well as the mailing list) and there are two parts to it (and you only mention one of them): a) how does SP deal with customer loops b) how does SP react to customer TCN This issue is being addressed in within the 802.1ad and it is pertinent to bridging aspect of VPLS which is being handled by IEEE. So lets not confuse the issue in here. There are many things regarding VPLS that are not addressed by any of the drafts. VPLS is an end-to-end service (from customer uni to customer uni), IETF only deals with the provisioning of this service over MPLS/IP network. This service consists of bridging portion that is being dealt with IEEE. If you look at the l2vpn framework, the PE device consists of bridging module and "LAN emulation" module. What you are talking about will be taken care by bridging module by IEEE. Also what you are suggesting (e.g., SP participating in customer's STP) is not the answer !!! and this is not the right forum to discuss it either. It should be discussed in IEEE. Regarding the second point, of a PW failure without restoration, I find it very interesting that we can rely on failure recovery mechanism in bridges but not in routers !!! One thing that routers are good at, is to find alternate routes in case of link or node failure !!! -Ali At 06:49 PM 4/15/2003 -0400, Cheng-Yin Lee wrote: >Rick, Marco, >Before considering progressing VPLS solutions as WG drafts, I think it >is useful to understand how the different solutions meet the >requirements in >http://www.ietf.org/internet-drafts/draft-augustyn-ppvpn-l2vpn-requirements-02.txt >(at least for some of the basic LAN emulation service requirements, if >not all). > >Ignoring some of these requirements may render a solution not useful to >end customers. >For e.g. if the following requirements are not met, an operator may not >be able to provide a functional service and as a result, some end >customers may choose to setup their own virtual private LAN instead, and >provider provisioned VPLS may not become as successful as hoped. > >1) Traffic Looping > > +---------------- > | > +------+ > +---------| PE | > | |device| > | +------+ > +------+ | > | CE | | > |device| | SP network > +------+ | > | +------+ > | | PE | > +---------|device| > +------+ > | > +---------------- > (a) > >If CE is a hub, does lasserre-vkompella support this valid configuration >requirement (to make the service more resilient to PE or MTU-S >failure)? How to prevent traffic from looping in the e.g. above taken >from the requirements document? >I think loop issues were first brought up in 2001, but it has not been >addressed. >(I don't think the answer is rate-limiting of customer traffic ;-)). > >In the case of Hierarchical VPLS, the above configuration cannot be >supported either. >If this configuration cannot be supported, then if a PE-rs is down, all >CEs & MTU-S connected to the PE-rs are partitioned from the VPLS >network. > > +---------------- > | > +------+ > +---------| MTU-S|------------------PE-rs > | |device| | > | +------+ | > +------+ | > | CE | | > |device| SP network | > +------+ | > | +------+ | > | | MTU-S| | > +---------|device|------------------PE-rs > +------+ > | > +--------------------- > >For e.g. (if one were to attempt to use the above configuration >requirement for Hierarchical VPLS) : >Traffic will loop as well (for different customers connected to MTU-S >devices in this fashion) and VPLS cannot be enabled for these customers. >If however, the MTU-S are connected directly and the PE-rs removed, the >MTU-S (if they are IEEE 802.1d/q bridges) can form a spanning tree and >loops are avoided, i.e. the VPLS service can be enabled then. >I think the fundamental problem here is PE bridges customer traffic but >have no means to prevent loops in the forwarding path. > >2) Improper LAN Emulation >If a VC in a full-mesh failed and cannot be restored, CE routers in the >VPLS do not have a consistent view of all CE routers. > > CEA---PEA--------PEB---CEB > \ / > \ / > \ / > \/ > PEC > | > CEC > >E.g. if the link between PEA and PEB fails: >If there are routers using the emulated LAN or if CEs are routers, then >I don't see how customer routing protocol like OSPF will work. CEA will >not see CEB, but CEC sees CEA & CEB, and vice-versa. >The consequence is that, I don't think CEC can route to CEA or CEB at >all if PEA-PEB link is down. >If STP is used instead of full-meshed reverse split horizon forwarding, >at least CEC can still route to CEB (and CEA, if PEA-PEC link becomes >active), i.e. at least some sites can still reach each other. > >In the case of solutions using full-meshed including Hierarchical VPLS, >while a link/VC between two PEs is down or cannot be recovered, >customers VPLS services for all sites will become dysfunctional. >This will affect CE routers, CE bridges as well as MTU-S devices >operation. When it affects MTU-S devices, all customers VPLS with >connectivity to the MTU-S devices will be affected as well. > >In the above cases, full-meshed reverse split horizon forwarding is not >functional and the related solutions cannot be used. >I hope these issues will not be disregarded or trivialized because it is >unlikely end customers will. There are other important issues that need >to be addressed as well, but it's useful to understand how these >problems are handled to start with. > >Thanks >Cheng-Yin From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 18:58:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13444 for ; Thu, 17 Apr 2003 18:58:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HN0jW00171 for ; Thu, 17 Apr 2003 19:00:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HN0gR16672 for ; Thu, 17 Apr 2003 19:00:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030417154536.01ca5b88@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 15:58:02 -0700 To: Cheng-Yin.Lee@alcatel.com, "Serbest Yetik" From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: "'mattsquire@acm.org'" , "'Rick Wilder'" , ppvpn@nortelnetworks.com In-Reply-To: <3E9EFA1E.D297B515@alcatel.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5DC8@trimail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Cheng-Yin, As I mentioned before, the issue of customer dual-homing (either inter-provider or intra-provider) is one of the many bridging issues being discussed in 802.1ad and it is outside of the scope of IETF. The confusion in here is that you think IETF needs to be responsible for the entire end-to-end VPLS service. Whereas, IETF is only responsible for portion of it - e.g., LAN emulation part (refer to figure 3 l2vpn framework). The bridging portion is the responsibility of IEEE group as has been coordinated with them. So the requirements can be for an end-to-end service, but the end-to-end solution needs participation from MEF, IEEE, and IETF. -Ali At 03:01 PM 4/17/2003 -0400, Cheng-Yin Lee wrote: >Yetik, >As an one of the editor of >draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I assume you care about >the requirements in that draft. > From the requirements draft, Section 5.8: >"In case of VPLS, the L2VPN service MUST ensure that loops be >prevented." > >I agree that it is a fundamental requirement that bridging loops be >handled in a VPLS solution. As we know loops can have a devastating >effect on a bridged network. > >So, has this point been carefully considered for the VPLS drafts being >proposed to be progressed? > >I think the VPLS drafts being considered here (using full-meshed with >split-horizon) are not able to handle common scenarios/requirements >leading to loops and causing network meltdowns. > >This point has been raised before by several people but it still has not >been addressed. If this mandatory requirement (not a minor detail or >rare scenario) is not addressed and we still progress these drafts what >is the message to the industry? That it's ok to continue pushing >solutions that don't meet fundamental requirements? > >Thanks, >Cheng-Yin > >"Serbest, Yetik" wrote: > > > > I would like to second that. > > > > Thanks, > > yetik > > > > -----Original Message----- > > From: Matt Squire [mailto:mattsquire@acm.org] > > Sent: Tuesday, April 15, 2003 7:08 AM > > To: 'Rick Wilder' > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > The Laserre/VKompella draft should definitely progress as a working > > group draft. Its a solid technical contribution with a lot of support > > behind it. > > > > - Matt > > > > Olen Stokes wrote: > > > I would also like to support making this a working group draft. > > > > > > Cheers, > > > Olen > > > > > > -----Original Message----- > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > *To:* ppvpn@nortelnetworks.com > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > draft > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > interest was expressed in pursuing the > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > > agreed to finalize that decision only after the WG participants who > > > weren't there could have a say. > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > > and this list is the place. Let's set a one-week limit to conclude > > > this issue. > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > ---------------------------------------------------------------------- > > > ------- > > > > > > From the minutes: > > > > > > > > > > > > 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. > > > > > > > > > [snipped] > > > > > > Marco: asked for show of hands to make this a wG draft. > > > Strong interest was shown in room. Further discussion on the list. > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 19:04:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13575 for ; Thu, 17 Apr 2003 19:04:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HN6SW06297 for ; Thu, 17 Apr 2003 19:06:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HN6NR05783 for ; Thu, 17 Apr 2003 19:06:23 -0400 (EDT) Message-ID: From: "O'Connor, Don" To: "'vkompella@timetra.com'" , "O'Connor, Don" , "'Serbest, Yetik'" , Cheng-Yin.Lee@alcatel.com Cc: mattsquire@acm.org, "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: RE: IEEE 802.1ad and VPLS Date: Thu, 17 Apr 2003 17:54:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: fncimr02.fnc.fujitsu.com X-SMTP-MAIL-FROM: Don.OConnor@fnc.fujitsu.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: fncimr02.fnc.fujitsu.com [168.127.0.4] X-LYRIS-Message-Id: Vach, To confirm the relationship with draft-lasserre - when 802.1AD defines solutions for issues such as Provider Bridge customer BPDU snooping / unlearn signaling (for customer STP reconfiguration with backdoors, etc) - then this will be incorporated in draft-lasserre by reference. Is this an accurate perception? One issue I have been wondering about with respect to 802.1AD & PPVPN / draft-lasserre is for single ended L2 VPN provisioning, where will the interface between the L2 Control Plane (defined by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be defined. Don -----Original Message----- From: Vach Kompella [mailto:vkompella@timetra.com] Sent: Thursday, April 17, 2003 5:06 PM To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com Subject: IEEE 802.1ad and VPLS Dan, Yes it is. One of the items in the ppvpn-wg minutes (note the date pre-dates the official PAR date which is Dec. 31, 2002, so we (as IETF participants) have been keeping in touch with the IEEE, albeit informally) for the Atlanta meeting shows: === clipped from minutes === Norm Finn - IEEE 802.1 unofficial liaison ----------------------------------------- Project authorization request (amendment to 802.1q VLANs) - enable a SP to offer the equivalent of separate LAN segments, bridged or virtual bridged LANs (network of bridges doing l2vpn type services). Name of project - 802.1AD. MAC-in-MAC not possible with this amendment. Confident that IETF L2vpn and 802.1AD will be interoperable, compatible etc if mailing discussions are carried through. === end of clip === -Vach > -----Original Message----- > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > Sent: Thursday, April 17, 2003 1:54 PM > To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > Yetik & Cheng-Yin, > > Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge > Group to define solutions for these issues. > > Regards, > > Don > > -----Original Message----- > From: Serbest, Yetik [mailto:serbest@tri.sbc.com] > Sent: Thursday, April 17, 2003 2:58 PM > To: 'Cheng-Yin.Lee@alcatel.com' > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > Cheng-Yin, > > When a draft becomes a working group document, that does not mean we stop > working on it. Your point is good, and we will work on the issue. There was > some preliminary discussion among the authors; and when we have some > conclusions, we will share them with the group. There are some other issues > as well. > > In DT, as you see from the mail (dated 2/6/2003) below I raised that issue. > > ".....Anyway, as long as we move on and reach the time when we discuss how > to support dual-homed CEs or customers with backdoor links, and how to > troubleshoot the service when q or qinq spokes are present etc... I am fine > with it." > > Thanks, > yetik > > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: Thursday, April 17, 2003 2:02 PM > To: Serbest, Yetik > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > Yetik, > As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I > assume you care about the requirements in that draft. From the requirements > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that > loops be prevented." > > I agree that it is a fundamental requirement that bridging loops be handled > in a VPLS solution. As we know loops can have a devastating effect on a > bridged network. > > So, has this point been carefully considered for the VPLS drafts being > proposed to be progressed? > > I think the VPLS drafts being considered here (using full-meshed with > split-horizon) are not able to handle common scenarios/requirements leading > to loops and causing network meltdowns. > > This point has been raised before by several people but it still has not > been addressed. If this mandatory requirement (not a minor detail or rare > scenario) is not addressed and we still progress these drafts what is the > message to the industry? That it's ok to continue pushing solutions that > don't meet fundamental requirements? > > Thanks, > Cheng-Yin > > "Serbest, Yetik" wrote: > > > > I would like to second that. > > > > Thanks, > > yetik > > > > -----Original Message----- > > From: Matt Squire [mailto:mattsquire@acm.org] > > Sent: Tuesday, April 15, 2003 7:08 AM > > To: 'Rick Wilder' > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > draft > > > > The Laserre/VKompella draft should definitely progress as a working > > group draft. Its a solid technical contribution with a lot of support > > behind it. > > > > - Matt > > > > Olen Stokes wrote: > > > I would also like to support making this a working group draft. > > > > > > Cheers, > > > Olen > > > > > > -----Original Message----- > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > *To:* ppvpn@nortelnetworks.com > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > draft > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > interest was expressed in pursuing the > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > > agreed to finalize that decision only after the WG participants who > > > weren't there could have a say. > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > > and this list is the place. Let's set a one-week limit to conclude > > > this issue. > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > ---------------------------------------------------------------------- > > > ------- > > > > > > From the minutes: > > > > > > > > > > > > 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. > > > > > > > > > [snipped] > > > > > > Marco: asked for show of hands to make this a wG draft. > > > Strong interest was shown in room. Further discussion on the > > > list. > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 19:05: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 TAA13610 for ; Thu, 17 Apr 2003 19:05:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HN7QW07319 for ; Thu, 17 Apr 2003 19:07:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HN7NR09480 for ; Thu, 17 Apr 2003 19:07:23 -0400 (EDT) Message-ID: <3E9F3201.871146DD@alcatel.com> Date: Thu, 17 Apr 2003 19:00:17 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Serbest Yetik" CC: "'mattsquire@acm.org'" , "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5DCF@trimail2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yetik, Thanks for your response. > When a draft becomes a working group document, that does not mean we stop > working on it. I don't mean work should stop once a draft becomes a WG draft. On the contrary I think before progressing a draft, the fundamental mandatory requirements should be considered first. It's ok to progress a draft that does not fully meet all requirements, but if the WG sanctions a draft that does not meet fundamental requirements, that is not "a good start" and does not sound promising. > Your point is good, and we will work on the issue. There was > some preliminary discussion among the authors; and when we have some > conclusions, we will share them with the group. There are some other issues > as well. Looping problem in these drafts is not just with dual-home CEs or backdoor link, but may happen anytime (e.g. due to improper LAN emulation). This may happen anytime due to VC/tunnel down, traffic congestion, a node going down. These are not not special, rare scenarios, that can be fixed or optimized later. It can affect the service offered anytime, and not a 802.1ad problem. I think there are fundamental issues here with full-meshed split-horizon that I hope the WG would consider first before progressing any VPLS drafts. Since these are fundamental requirements in a VPLS solution that should be addressed first, I think it makes sense to hear how these issues will be resolved before rushing to sanction these drafts as WG drafts. Thanks Cheng-Yin > > In DT, as you see from the mail (dated 2/6/2003) below I raised that issue. > > ".....Anyway, as long as we move on and reach the time when we discuss how > to support dual-homed CEs or customers with backdoor links, and how to > troubleshoot the service when q or qinq spokes are present etc... I am fine > with it." > > Thanks, > yetik > > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: Thursday, April 17, 2003 2:02 PM > To: Serbest, Yetik > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > Yetik, > As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I > assume you care about the requirements in that draft. From the requirements > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that > loops be prevented." > > I agree that it is a fundamental requirement that bridging loops be handled > in a VPLS solution. As we know loops can have a devastating effect on a > bridged network. > > So, has this point been carefully considered for the VPLS drafts being > proposed to be progressed? > > I think the VPLS drafts being considered here (using full-meshed with > split-horizon) are not able to handle common scenarios/requirements leading > to loops and causing network meltdowns. > > This point has been raised before by several people but it still has not > been addressed. If this mandatory requirement (not a minor detail or rare > scenario) is not addressed and we still progress these drafts what is the > message to the industry? That it's ok to continue pushing solutions that > don't meet fundamental requirements? > > Thanks, > Cheng-Yin > > "Serbest, Yetik" wrote: > > > > I would like to second that. > > > > Thanks, > > yetik > > > > -----Original Message----- > > From: Matt Squire [mailto:mattsquire@acm.org] > > Sent: Tuesday, April 15, 2003 7:08 AM > > To: 'Rick Wilder' > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > draft > > > > The Laserre/VKompella draft should definitely progress as a working > > group draft. Its a solid technical contribution with a lot of support > > behind it. > > > > - Matt > > > > Olen Stokes wrote: > > > I would also like to support making this a working group draft. > > > > > > Cheers, > > > Olen > > > > > > -----Original Message----- > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > *To:* ppvpn@nortelnetworks.com > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > draft > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > interest was expressed in pursuing the > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > > agreed to finalize that decision only after the WG participants who > > > weren't there could have a say. > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > > and this list is the place. Let's set a one-week limit to conclude > > > this issue. > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > ---------------------------------------------------------------------- > > > ------- > > > > > > From the minutes: > > > > > > > > > > > > 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. > > > > > > > > > [snipped] > > > > > > Marco: asked for show of hands to make this a wG draft. > > > Strong interest was shown in room. Further discussion on the > > > list. > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 19:09:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13720 for ; Thu, 17 Apr 2003 19:09:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HNAlW10647 for ; Thu, 17 Apr 2003 19:10:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HNAhR16634 for ; Thu, 17 Apr 2003 19:10:44 -0400 (EDT) Message-ID: <3E9F336B.304F45AC@alcatel.com> Date: Thu, 17 Apr 2003 19:06:19 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ali Sajassi CC: Serbest Yetik , "'mattsquire@acm.org'" , "'Rick Wilder'" , ppvpn@nortelnetworks.com Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5DC8@trimail2> <4.3.2.7.2.20030417154536.01ca5b88@airborne.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, Pls see my response to Yetik Serbest and Ben Schultz. The looping issues may not all be addressed by 802.1ad. Regards Cheng-Yin Ali Sajassi wrote: > > Cheng-Yin, > > As I mentioned before, the issue of customer dual-homing (either > inter-provider or intra-provider) is one of the many bridging issues being > discussed in 802.1ad and it is outside of the scope of IETF. The confusion > in here is that you think IETF needs to be responsible for the entire > end-to-end VPLS service. Whereas, IETF is only responsible for portion of > it - e.g., LAN emulation part (refer to figure 3 l2vpn framework). The > bridging portion is the responsibility of IEEE group as has been > coordinated with them. So the requirements can be for an end-to-end > service, but the end-to-end solution needs participation from MEF, IEEE, > and IETF. > > -Ali > > At 03:01 PM 4/17/2003 -0400, Cheng-Yin Lee wrote: > >Yetik, > >As an one of the editor of > >draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I assume you care about > >the requirements in that draft. > > From the requirements draft, Section 5.8: > >"In case of VPLS, the L2VPN service MUST ensure that loops be > >prevented." > > > >I agree that it is a fundamental requirement that bridging loops be > >handled in a VPLS solution. As we know loops can have a devastating > >effect on a bridged network. > > > >So, has this point been carefully considered for the VPLS drafts being > >proposed to be progressed? > > > >I think the VPLS drafts being considered here (using full-meshed with > >split-horizon) are not able to handle common scenarios/requirements > >leading to loops and causing network meltdowns. > > > >This point has been raised before by several people but it still has not > >been addressed. If this mandatory requirement (not a minor detail or > >rare scenario) is not addressed and we still progress these drafts what > >is the message to the industry? That it's ok to continue pushing > >solutions that don't meet fundamental requirements? > > > >Thanks, > >Cheng-Yin > > > >"Serbest, Yetik" wrote: > > > > > > I would like to second that. > > > > > > Thanks, > > > yetik > > > > > > -----Original Message----- > > > From: Matt Squire [mailto:mattsquire@acm.org] > > > Sent: Tuesday, April 15, 2003 7:08 AM > > > To: 'Rick Wilder' > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > The Laserre/VKompella draft should definitely progress as a working > > > group draft. Its a solid technical contribution with a lot of support > > > behind it. > > > > > > - Matt > > > > > > Olen Stokes wrote: > > > > I would also like to support making this a working group draft. > > > > > > > > Cheers, > > > > Olen > > > > > > > > -----Original Message----- > > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > > *To:* ppvpn@nortelnetworks.com > > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > > draft > > > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > > interest was expressed in pursuing the > > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > > > agreed to finalize that decision only after the WG participants who > > > > weren't there could have a say. > > > > > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the time, > > > > and this list is the place. Let's set a one-week limit to conclude > > > > this issue. > > > > > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > ---------------------------------------------------------------------- > > > > ------- > > > > > > > > From the minutes: > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > [snipped] > > > > > > > > Marco: asked for show of hands to make this a wG draft. > > > > Strong interest was shown in room. Further discussion on the list. > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 19:16:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13854 for ; Thu, 17 Apr 2003 19:16:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HNIcW16162 for ; Thu, 17 Apr 2003 19:18:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HNIYR23746 for ; Thu, 17 Apr 2003 19:18:34 -0400 (EDT) Message-ID: <39469E08BD83D411A3D900204840EC55D7BB79@vie-msgusr-01.dc.fore.com> From: "Ju, Yu" To: "'Kireeti Kompella'" , Eric Rosen Cc: Mourad BERKANE , ppvpn@nortelnetworks.com Subject: RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Thu, 17 Apr 2003 18:53:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: Yu.Ju@marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Kireeti/Eric, I understand that the pupose of label block is to determine from which PE (or more precisely CE-id) the packet come from for MAC learning purpose. If for some reason a label our of a label block is not available any more, a label, say 1001, used by CE-id 5 may be used by CE-id 9 according to the algorithm in the draft. As a result, this may trigger some changes. What do you think about the following? BGP advertises a single label for a L2VPN NRLI to all PEs along with the CE-id. When a PE tunnels a L2 packet through MPLS, it push three labels instead of two. The top is the LSP label, the second is the label advertised by BGP, and the bottom label is the CE-id. This way, the receiving PE can infer from the label it advertised that there is going to be another bottom label which is the CE-id. From the CE-id, the PE knows which PE the packet come from. Thanks, Yu -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, April 17, 2003 4:48 PM To: Eric Rosen Cc: Mourad BERKANE; ppvpn@nortelnetworks.com Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt On Thu, 17 Apr 2003, Eric Rosen wrote: > Mourad> If a vendor could explain me how using 2 differents protocols for > Mourad> Control Plane (signaling and auto-discovery) will be more efficient > Mourad> (technical argumentations please and not philosophical ones) than > Mourad> when using only one protocol (MP-BGP). > > I don't know why the one who explains this needs to be a vendor ;-), but > there are a large number of inefficiences in using BGP for the signaling. > > Suppose that 100 PEs participate in a particular VPLS, and suppose that PE17 > has some information to signal to PE43. > > With point-to-point signaling, PE17 sends a message to PE43, PE43 replies > (if necessary), and we're done. Sure. N*(N-1) is small when N = 2. > With BGP-based signaling, PE17 sends a message to the route reflector, which > then resends it to PEs 1-16, and PEs 18-99. So instead of sending one > message, you send 100. Ninety-eight of the PEs that receive the message > will parse it and find it irrelevant. Efficient? Excuse me, but are you not an author of rfc2547bis and draft-ietf-ppvpn-bgpvpn-auto-03.txt? In both of the above, you send 100 messages to all the PEs, even if the only other member of the VPN is PE43. So, for a more accurate picture (since BGP is *not* only for signaling), PE17 sends a message to the route reflector, saying essentially, "I'm in VPN foo, and btw, these are the labels to use". The RR then sends 100 messages to all other PEs. Most of these PEs ignore the message (they are not part of VPLS foo); the ones who are find out, with one message, that PE17 is part of VPLS foo, and which labels to use. Summary: one NLRI per PE per VPLS. Efficient? With BGP+LDP, the flow would be: PE17 sends a message to the route reflector, saying essentially, "I'm in VPN foo" (no labels). The RR then sends 100 messages to all other PEs. Most of these PEs ignore the message (they are not part of VPLS foo); the ones who are find out that PE17 is part of VPLS foo. So far, not much difference -- except: no labels. Now, the PEs who are in VPLS foo must kick off a separate interaction -- a new LDP session if needed, and new messages for the exchange of labels. And each PE in VPLS foo must do this independently. Summary: one NLRI per PE per VPLS plus N*(N-1) LDP label exchanges per VPLS with N members. Efficient? Certainly when N = 2. As for the "label block hack", sure, call it a hack, that should scare people away -- argumentum ad hominem always works. Efficient block allocation is a solved problem. Ask anyone who does memory management, or any number of allocation problems. > To get the best use out of the label block hack, it is advisable to > overprovision, so that all the PEs which are on-line allocate in advance > label space for PEs that are not yet on-line. Now you're wasting labels; > each wasted label corresponds to a real piece of high speed memory in your > forwarding engine, i.e., this is real resources being wasted, not just > "numbers". E.g., each wasted label is one less L3VPN route that can be > supported. Efficient? You certainly can do it this way. We don't. As for "wasting" labels, it amazes me that a vendor that allocates individual labels for each IP VPN prefix from the same PE keeps harping on this. To give credit where credit is due, the idea of using BGP for both auto-discovery and signaling came from RFC 2547. I thought this was clear; but I'll state it for the record. The one issue was that for IP VPNs, a single label per site suffices; for VPLS, you need several. Hence label blocks. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 19:22: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 TAA14010 for ; Thu, 17 Apr 2003 19:22:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HNOQW18681 for ; Thu, 17 Apr 2003 19:24:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HNOHR27095 for ; Thu, 17 Apr 2003 19:24:18 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "O'Connor, Don" , "'Serbest, Yetik'" , Cc: , "'Rick Wilder'" , Subject: RE: IEEE 802.1ad and VPLS Date: Thu, 17 Apr 2003 16:20:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-OriginalArrivalTime: 17 Apr 2003 23:20:28.0291 (UTC) FILETIME=[EEB86D30:01C30537] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Dan, It isn't clear to me yet that the only reliable way to deal with L2 control protocol packets such as BPDUs is to pass them through the data plane of the VPLS. It is possible that one of the ways to deal with unlearns, e.g., is to use LDP messages, such as the MAC TLVs for specific or scoped unlearns. So, if "by reference" means that we don't assist the L2 solution with extensions to the VPLS signaling draft, then I disagree. If it means cooperative use of the L3 control plane with the IEEE work, I agree. Basically, we don't want to re-invent what is already there, but when we have L3 control plane methods available, it makes sense to figure out a division of work that makes the service work the best. From Clause 16 of the 802.1ad-d0 document: ... (stuff dealing with a potential topology with loops) ... requires an IETF connection (see also suggested Clause 6.6 Support of the Internal Sublayer Service by IETF foo) and to deal with some of the ‘loop through a customer’ questions and the partial answers that we have to those. -Vach > -----Original Message----- > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > Sent: Thursday, April 17, 2003 3:55 PM > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > Cheng-Yin.Lee@alcatel.com > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: RE: IEEE 802.1ad and VPLS > > > Vach, > > To confirm the relationship with draft-lasserre - when 802.1AD defines > solutions for issues such as Provider Bridge customer BPDU snooping / > unlearn signaling (for customer STP reconfiguration with backdoors, etc) - > then this will be incorporated in draft-lasserre by reference. Is this an > accurate perception? > > One issue I have been wondering about with respect to 802.1AD & PPVPN / > draft-lasserre is for single ended L2 VPN > provisioning, where will the interface between the L2 Control Plane (defined > by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be > defined. > > Don > > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Thursday, April 17, 2003 5:06 PM > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: IEEE 802.1ad and VPLS > > > Dan, > > Yes it is. One of the items in the ppvpn-wg minutes (note the date > pre-dates > the official PAR date which is Dec. 31, 2002, so we (as IETF participants) > have > been keeping in touch with the IEEE, albeit informally) for the Atlanta > meeting > shows: > > === clipped from minutes === > Norm Finn - IEEE 802.1 unofficial liaison > ----------------------------------------- > > Project authorization request (amendment to 802.1q VLANs) - enable a SP to > offer the equivalent of separate LAN segments, bridged or virtual bridged > LANs (network of bridges doing l2vpn type services). > > Name of project - 802.1AD. > MAC-in-MAC not possible with this amendment. > > Confident that IETF L2vpn and 802.1AD will be interoperable, compatible etc > if mailing discussions are carried through. > === end of clip === > > -Vach > > > -----Original Message----- > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > Sent: Thursday, April 17, 2003 1:54 PM > > To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > Yetik & Cheng-Yin, > > > > Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge > > Group to define solutions for these issues. > > > > Regards, > > > > Don > > > > -----Original Message----- > > From: Serbest, Yetik [mailto:serbest@tri.sbc.com] > > Sent: Thursday, April 17, 2003 2:58 PM > > To: 'Cheng-Yin.Lee@alcatel.com' > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > Cheng-Yin, > > > > When a draft becomes a working group document, that does not mean we stop > > working on it. Your point is good, and we will work on the issue. There > was > > some preliminary discussion among the authors; and when we have some > > conclusions, we will share them with the group. There are some other > issues > > as well. > > > > In DT, as you see from the mail (dated 2/6/2003) below I raised that > issue. > > > > ".....Anyway, as long as we move on and reach the time when we discuss how > > to support dual-homed CEs or customers with backdoor links, and how to > > troubleshoot the service when q or qinq spokes are present etc... I am > fine > > with it." > > > > Thanks, > > yetik > > > > -----Original Message----- > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > Sent: Thursday, April 17, 2003 2:02 PM > > To: Serbest, Yetik > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > Yetik, > > As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, > I > > assume you care about the requirements in that draft. From the > requirements > > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that > > loops be prevented." > > > > I agree that it is a fundamental requirement that bridging loops be > handled > > in a VPLS solution. As we know loops can have a devastating effect on a > > bridged network. > > > > So, has this point been carefully considered for the VPLS drafts being > > proposed to be progressed? > > > > I think the VPLS drafts being considered here (using full-meshed with > > split-horizon) are not able to handle common scenarios/requirements > leading > > to loops and causing network meltdowns. > > > > This point has been raised before by several people but it still has not > > been addressed. If this mandatory requirement (not a minor detail or rare > > scenario) is not addressed and we still progress these drafts what is the > > message to the industry? That it's ok to continue pushing solutions that > > don't meet fundamental requirements? > > > > Thanks, > > Cheng-Yin > > > > "Serbest, Yetik" wrote: > > > > > > I would like to second that. > > > > > > Thanks, > > > yetik > > > > > > -----Original Message----- > > > From: Matt Squire [mailto:mattsquire@acm.org] > > > Sent: Tuesday, April 15, 2003 7:08 AM > > > To: 'Rick Wilder' > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > > draft > > > > > > The Laserre/VKompella draft should definitely progress as a working > > > group draft. Its a solid technical contribution with a lot of support > > > behind it. > > > > > > - Matt > > > > > > Olen Stokes wrote: > > > > I would also like to support making this a working group draft. > > > > > > > > Cheers, > > > > Olen > > > > > > > > -----Original Message----- > > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > > *To:* ppvpn@nortelnetworks.com > > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > > draft > > > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > > interest was expressed in pursuing the > > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > > > agreed to finalize that decision only after the WG participants > who > > > > weren't there could have a say. > > > > > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the > time, > > > > and this list is the place. Let's set a one-week limit to conclude > > > > this issue. > > > > > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > ---------------------------------------------------------------------- > > > > ------- > > > > > > > > From the minutes: > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > [snipped] > > > > > > > > Marco: asked for show of hands to make this a wG draft. > > > > Strong interest was shown in room. Further discussion on the > > > > list. > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 19:28:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14080 for ; Thu, 17 Apr 2003 19:28:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HNUjW22186 for ; Thu, 17 Apr 2003 19:30:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HNUfR01310 for ; Thu, 17 Apr 2003 19:30:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20030417161618.01d0cdf0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 16:28:18 -0700 To: Cheng-Yin.Lee@alcatel.com, Ali Sajassi From: Ali Sajassi Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Cc: Serbest Yetik , "'mattsquire@acm.org'" , "'Rick Wilder'" , ppvpn@nortelnetworks.com In-Reply-To: <3E9F336B.304F45AC@alcatel.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5DC8@trimail2> <4.3.2.7.2.20030417154536.01ca5b88@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Cheng-Yin, I covered both of your points in details and if you still have concern, then reply directly to my email, tell me which portion of it is not clear and be specific please - saying split-horizon will not work due to congestion, will not cut it. If you have such a congestion that causes the traffic to get shut down (for several seconds - enough to cause dis-connectivity among endpoints) , then split-horizon is least of your problem !!! Let me repeat my email again ... ============================================== The issues that you are bringing up in here are not just specific to our draft but also applies to other drafts (e.g., draft-kompella-vpls, draft-gvpls, ). If you have attended the IEEE 802.1 meeting, you should know that the first issue has been discussed there (both in the meeting as well as the mailing list) and there are two parts to it (and you only mention one of them): a) how does SP deal with customer loops b) how does SP react to customer TCN This issue is being addressed in within the 802.1ad and it is pertinent to bridging aspect of VPLS which is being handled by IEEE. So lets not confuse the issue in here. There are many things regarding VPLS that are not addressed by any of the drafts. VPLS is an end-to-end service (from customer uni to customer uni), IETF only deals with the provisioning of this service over MPLS/IP network. This service consists of bridging portion that is being dealt with IEEE. If you look at the l2vpn framework, the PE device consists of bridging module and "LAN emulation" module. What you are talking about will be taken care by bridging module by IEEE. Also what you are suggesting (e.g., SP participating in customer's STP) is not the answer !!! and this is not the right forum to discuss it either. It should be discussed in IEEE. Regarding the second point, of a PW failure without restoration, I find it very interesting that we can rely on failure recovery mechanism in bridges but not in routers !!! One thing that routers are good at, is to find alternate routes in case of link or node failure !!! -Ali -Ali At 07:06 PM 4/17/2003 -0400, Cheng-Yin Lee wrote: >Ali, >Pls see my response to Yetik Serbest and Ben Schultz. >The looping issues may not all be addressed by 802.1ad. > >Regards >Cheng-Yin > >Ali Sajassi wrote: > > > > Cheng-Yin, > > > > As I mentioned before, the issue of customer dual-homing (either > > inter-provider or intra-provider) is one of the many bridging issues being > > discussed in 802.1ad and it is outside of the scope of IETF. The confusion > > in here is that you think IETF needs to be responsible for the entire > > end-to-end VPLS service. Whereas, IETF is only responsible for portion of > > it - e.g., LAN emulation part (refer to figure 3 l2vpn framework). The > > bridging portion is the responsibility of IEEE group as has been > > coordinated with them. So the requirements can be for an end-to-end > > service, but the end-to-end solution needs participation from MEF, IEEE, > > and IETF. > > > > -Ali > > > > At 03:01 PM 4/17/2003 -0400, Cheng-Yin Lee wrote: > > >Yetik, > > >As an one of the editor of > > >draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I assume you care about > > >the requirements in that draft. > > > From the requirements draft, Section 5.8: > > >"In case of VPLS, the L2VPN service MUST ensure that loops be > > >prevented." > > > > > >I agree that it is a fundamental requirement that bridging loops be > > >handled in a VPLS solution. As we know loops can have a devastating > > >effect on a bridged network. > > > > > >So, has this point been carefully considered for the VPLS drafts being > > >proposed to be progressed? > > > > > >I think the VPLS drafts being considered here (using full-meshed with > > >split-horizon) are not able to handle common scenarios/requirements > > >leading to loops and causing network meltdowns. > > > > > >This point has been raised before by several people but it still has not > > >been addressed. If this mandatory requirement (not a minor detail or > > >rare scenario) is not addressed and we still progress these drafts what > > >is the message to the industry? That it's ok to continue pushing > > >solutions that don't meet fundamental requirements? > > > > > >Thanks, > > >Cheng-Yin > > > > > >"Serbest, Yetik" wrote: > > > > > > > > I would like to second that. > > > > > > > > Thanks, > > > > yetik > > > > > > > > -----Original Message----- > > > > From: Matt Squire [mailto:mattsquire@acm.org] > > > > Sent: Tuesday, April 15, 2003 7:08 AM > > > > To: 'Rick Wilder' > > > > Cc: ppvpn@nortelnetworks.com > > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > > > The Laserre/VKompella draft should definitely progress as a working > > > > group draft. Its a solid technical contribution with a lot of support > > > > behind it. > > > > > > > > - Matt > > > > > > > > Olen Stokes wrote: > > > > > I would also like to support making this a working group draft. > > > > > > > > > > Cheers, > > > > > Olen > > > > > > > > > > -----Original Message----- > > > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > > > *To:* ppvpn@nortelnetworks.com > > > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > > > draft > > > > > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > > > interest was expressed in pursuing the > > > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group > draft. We > > > > > agreed to finalize that decision only after the WG > participants who > > > > > weren't there could have a say. > > > > > > > > > > > > > > > > > > > > So, if there are opinions that have not been heard, now is > the time, > > > > > and this list is the place. Let's set a one-week limit to > conclude > > > > > this issue. > > > > > > > > > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > ---------------------------------------------------------------------- > > > > > ------- > > > > > > > > > > From the minutes: > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > [snipped] > > > > > > > > > > Marco: asked for show of hands to make this a wG draft. > > > > > Strong interest was shown in room. Further discussion on the > list. > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 17 19:55:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14553 for ; Thu, 17 Apr 2003 19:55:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3HNvEW26215 for ; Thu, 17 Apr 2003 19:57:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3HNvBR09841 for ; Thu, 17 Apr 2003 19:57:12 -0400 (EDT) Message-ID: <3E9F3E72.117D5369@cisco.com> Date: Thu, 17 Apr 2003 16:53:22 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Muneyoshi Suzuki CC: ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <20030416.104110.71147346.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, The problems of running STP or RSTP over a "soft" connection such as an emulated LAN is a problem that has been well explored, for example in the context of ATM LAN emulation. The common critical item among these failure scenarios is that the users of the "soft" connection never have reliable knowledge of whether the connection is up or down. IEEE 802.1AD will certainly address these issues. In particular, 802.1AD is assuming, at this time, that the customers' spanning trees will be carried by a network of Provider Bridges which is, itself, running either Rapid Spanning Tree or Multiple Spanning Trees. In general, if one is running spanning tree over spanning tree in this manner, or if one is running spanning tree over any other connection that fails and heals itself over a period of a few seconds or longer, one runs into the kinds of problems you mention. If the Provider's network is composed solely of point-to-point physical links running RSTP or MSTP, and if certain other constraints such as the number of Provider's BPDUs allowed per second are chosen with this problem in mind, then one may expect the customers' spanning trees to work properly. In general, if the underlying soft connection technology heals itself in less than a second or so, there should be no significant problems with the customers' spanning trees. If connectivity can be fully or partially broken for more than a few seconds, then the customer must slow down his spanning tree failure detection timers correspondingly. There is a gray area between one second and a few seconds. One of the goals of the L2-VPN effort must be, in my opinion, to specify how full meshes can be guaranteed to meet the sub-second restoration requirement, or at the very least, to define what guarantees meshes can meet. Alternatively, a mechanism must be provided to signal failures of the full mesh in such a way that all of the connected Provider Bridges know that the link has failed, and avoid it until it can be re-established. In any event, but especially if a failure signaling mechanism is the best that IETF can do, then IEEE 802.1AD will have to consider very carefully whether and/or how a similar mechanism can be used to ensure that the customer, in turn, reliably detects any interruption or restoration of the service. At this time, interworking between the Provider and Customer networks has not received a lot of attention in 802.1, but it has not been ruled out, except for the obvious conclusion that they must not simply be peers. -- Norm Muneyoshi Suzuki wrote: > > I have a couple of comments on Emulated LAN which consists of VPLS > forwarders and full mesh pseudo wires with split-horizon forwarding > scheme, proposed in the L2 VPN framework as well as related solutions > documents, such as draft-lasserre-vkompella-ppvpn-vpls-04.txt and > draft-kompella-ppvpn-vpls-01.txt. > > (1) Protection racing > > This scheme does not terminate STP, so if a pseudo wire in the mesh > fails, it may be restored with a MPLS protection mechanism. In this case, > there is a possibility that the recovery time of the protection mechanism > may affect failure detection of user-STP. > > For example, if an LSP in the mesh fails, LSP protection mechanism may > recover it, however, if user-STP detects the failure simultaneously, > then it re-organize the L2 topology in a few minutes; but after the > re-organization, it also detects recovery of the failed LSP, then > user-STP restore the original L2 topology in a few minutes. > > Finally, this wastes twice time of STP topology change and spoils > fast MPLS protection mechanism. It is too unrealistic and dangerous to > prohibit user-STP, it may leads broadcast loop, thus, I think interworking > between user-STP and MPLS protection mechanism is needed. > > Note that, the above discussion assumes that the user-STP is working > properly in the above situation. However, this assumption is doubtful. > See the next comment. > > (2) Black hole > > >From a viewpoint user-STP, Emulated LAN, which consists of VPLS > forwarders and full mesh pseudo wires, is logically equivalent with a > hub-repeater. Assume that the single SP network consists of PE Bridges > and a single hub-repeater, and a PE Bridge port is connected to a port > in the hub-repeater. > > In this case, if the hub-repeater entirely fails (that is, *all* LSPs > fail at the same time), user-STP detects it and may re-organize user L2 > topology, if possible (e.g., the user has a back door link). If a single > port in the hub-repeater fails (that is, *all* LSPs connected to a single > PE fail at the same time), user-STP also detects it and may re-organize > the topology. > > However, failure of a single LSP in the mesh is logically equivalent > with the situation that the communications between two ports in the hub- > repeater fail, *but the remains are normal*. I'm not sure what happens > in this case, because I think this kind of failure is not assumed in STP > protocol design. I do not rigidly quantify what happens, but think there > will be a black hole. > > MPLS protection/FRR mechanism does not solve this issue, because it can > minimize probability of partial failure, but it does not eliminate the > possibility. If the LSP recovery is unsuccessful, the user will encounter > fatal situation. > > I believe the VPLS solution must be robust, that is, it must recover or > lead the network to a safe status automatically however the network > encounters a rare but fatal error. To enable large scale deployment, it must > not force the operators and users to reboot boxes even if the worst case. > > Thanks, > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 03:32:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05064 for ; Fri, 18 Apr 2003 03:32:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3I7WBW17712 for ; Fri, 18 Apr 2003 03:32:11 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3I7W7R18635 for ; Fri, 18 Apr 2003 03:32:08 -0400 (EDT) Date: Fri, 18 Apr 2003 16:27:12 +0900 (JST) Message-Id: <20030418.162712.41696376.suzuki.muneyoshi@lab.ntt.co.jp> To: nfinn@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <3E9F3E72.117D5369@cisco.com> References: <20030416.104110.71147346.suzuki.muneyoshi@lab.ntt.co.jp> <3E9F3E72.117D5369@cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Norm, Thanks for reply. > IEEE 802.1AD will certainly address these issues. In particular, > 802.1AD is assuming, at this time, that the customers' spanning trees > will be carried by a network of Provider Bridges which is, itself, > running either Rapid Spanning Tree or Multiple Spanning Trees. Good news. > In general, if one is running spanning tree over spanning tree in this > manner, or if one is running spanning tree over any other connection > that fails and heals itself over a period of a few seconds or longer, > one runs into the kinds of problems you mention. Yes. That is one of my points. > If the Provider's network is composed solely of point-to-point > physical links running RSTP or MSTP, and if certain other constraints > such as the number of Provider's BPDUs allowed per second are chosen > with this problem in mind, then one may expect the customers' spanning > trees to work properly. Agreed. If SP does *not* use full-mesh split-horizon scheme, it is true. > In general, if the underlying soft connection technology heals itself > in less than a second or so, there should be no significant problems > with the customers' spanning trees. If connectivity can be fully or > partially broken for more than a few seconds, then the customer must > slow down his spanning tree failure detection timers correspondingly. > There is a gray area between one second and a few seconds. In general situation, it is true. > One of the goals of the L2-VPN effort must be, in my opinion, to > specify how full meshes can be guaranteed to meet the sub-second > restoration requirement, or at the very least, to define what guarantees > meshes can meet. My point is the network behavior when the link protection is unsuccessful. If the SP network consists of Bridges and point-to-point links running STP, there is no significant issues. However, if the SP use full-mesh split-horizon scheme, customers may encounter loop or black hole. > Alternatively, a mechanism must be provided to signal > failures of the full mesh in such a way that all of the connected > Provider Bridges know that the link has failed, and avoid it until it > can be re-established. I'm not sure the above sachem. Do you mean if one of path in the mesh fails, the Provider Bridges blocks *all* the paths connected to the Bridge until the path recovery? I agree this is one of solutions, but don't think it is realistic. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 03:39: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 DAA05274 for ; Fri, 18 Apr 2003 03:39:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3I7fOW21096 for ; Fri, 18 Apr 2003 03:41:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3I7fLR23660 for ; Fri, 18 Apr 2003 03:41:21 -0400 (EDT) Message-ID: <2A0E0205053C8040BD1C471AB7C5901B3F57BC@wexrm1a.wind> From: Alviti Fabrizio To: "'ppvpn@nortelnetworks.com'" Subject: draft-kompella-ppvpn-vpls-01.txt Date: Fri, 18 Apr 2003 09:38:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-SMTP-HELO: mailrelay03.wind.it X-SMTP-MAIL-FROM: Fabrizio.Alviti@mail.wind.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailrelay03.wind.it [212.141.48.56] 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3057D.8405FE6E" ------_=_NextPart_001_01C3057D.8405FE6E Content-Type: text/plain; charset="iso-8859-1" Wind is the second operator in Italy. We would like to support draft-kompella-ppvpn-vpls-01.txt. The MP-BGP approach, the scalability with Route Reflector and the maintaining of current IP VPN control plan are very important added values. Thank you Fabrizio Alviti WIND Telecomunicazioni S.p.a. Information & Services Technologies Service Engineering & Control Via C.G. Viola, 48 - 00148 Roma Tel.: +39 06 8311 3501 Fax: +39 06 8311 5968 Cell: +39 (0) 329 6100572 E-Mail: fabrizio.alviti@mail.wind.it ------_=_NextPart_001_01C3057D.8405FE6E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-kompella-ppvpn-vpls-01.txt

Wind is the second operator in = Italy. We would like to support = draft-kompella-ppvpn-vpls-01.txt.

The MP-BGP approach, the = scalability with Route Reflector and the
maintaining of current IP VPN = control plan are very important added values.

Thank you


Fabrizio Alviti
WIND Telecomunicazioni = S.p.a.
Information & = Services Technologies
Service Engineering = & Control
Via C.G. Viola, 48 = - 00148 Roma
Tel.: +39 06 8311 = 3501
Fax: +39 06 8311 = 5968
Cell: +39 (0) 329 = 6100572
E-Mail: = fabrizio.alviti@mail.wind.it


------_=_NextPart_001_01C3057D.8405FE6E-- --------------InterScan_NT_MIME_Boundary-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 04:44:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06268 for ; Fri, 18 Apr 2003 04:44:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3I8kBW04537 for ; Fri, 18 Apr 2003 04:46:11 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3I8k7R24171 for ; Fri, 18 Apr 2003 04:46:08 -0400 (EDT) Date: Fri, 18 Apr 2003 17:41:08 +0900 (JST) Message-Id: <20030418.174108.71152937.suzuki.muneyoshi@lab.ntt.co.jp> To: "Marco Carugi" , rwilder@masergy.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: PPVPN L2 space : action plan (check for consensus expressed in SF meeting and other open points) From: Muneyoshi Suzuki In-Reply-To: References: 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,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Marco and Rick, As I pointed on the list, emulated LAN technology, which consists of VPLS forwarders and full mesh pseudo wires with split-horizon forwarding scheme and proposed in the L2 VPN framework, has architecture level issues such as protection racing, loop, and black hole. However, it is clear from the discussions on the list, these issues are difficult to solve by the PPVPN WG alone, but there is no official liaison between the IEEE 802.1 and PPVPN WGs. If we suppose that the issues are not problem because the issues will be solved by the 802.1 WG, it should be clearly addressed on the official liaison letter between 802.1 and PPVPN WGs. Otherwise, the VPLS architecture should be reconsidered. Again, architecture level error is usually fatal and beyond recall. Therefore, at this time, I opposite to select any L2 VPN solution document to WG item until architecture level issues are solved. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 06:07: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 GAA07399 for ; Fri, 18 Apr 2003 06:07:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IA9iW21133 for ; Fri, 18 Apr 2003 06:09:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IA9fR13487 for ; Fri, 18 Apr 2003 06:09:41 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A14649701494967@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'erosen@cisco.com'" Cc: ppvpn@nortelnetworks.com Subject: RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Date: Fri, 18 Apr 2003 12:07:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30592.4F2206E0" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30592.4F2206E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, Eric> Suppose that 100 PEs participate in a particular VPLS, and = suppose that Eric> PE17 has some information to PE43. Mourad> Assuming that VPLS is a broadcast domain, when a PE (PE17) need = to Mourad> seed an information to another PE only (PE43) and will not to sharing this control information Mourad> to other PEs registered in this VPLS domain (PE1-PE16,PE18-PE42,PE44-PE100)? Mourad> Your supposition is not applicable to VPLS applications, isn't = it? Mourad> A topology with 2 PEs routers only is not what i call a = broadcast domain, your reflexion may Mourad> refer to a Hub and Spoke architecture (different import/export = route target values) which i think Mourad> is not applicable to VPLS. Do you share this view? Mourad> Furthermore a CE site could be members of N differents VPLS = domain, he could share restricted infos Mourad> in VPLS A (PE17,PE43 only) and could be member of another less restricted VPLS domain B (PE1-PE100). Thanks & Best Regards, Mourad -----Message d'origine----- De : Eric Rosen [mailto:erosen@cisco.com] Envoy=E9 : jeudi 17 avril 2003 19:29 =C0 : Mourad BERKANE Cc : ppvpn@nortelnetworks.com Objet : Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt=20 Mourad> If a vendor could explain me how using 2 differents = protocols for Mourad> Control Plane (signaling and auto-discovery) will be more = efficient Mourad> (technical argumentations please and not philosophical ones) = than Mourad> when using only one protocol (MP-BGP).=20 I don't know why the one who explains this needs to be a vendor = ;-), but there are a large number of inefficiences in using BGP for the = signaling.=20 Suppose that 100 PEs participate in a particular VPLS, and suppose that = PE17 has some information to signal to PE43.=20 With point-to-point signaling, PE17 sends a message to PE43, PE43 = replies (if necessary), and we're done.=20 With BGP-based signaling, PE17 sends a message to the route reflector, = which then resends it to PEs 1-16, and PEs 18-99. So instead of = sending one message, you send 100. Ninety-eight of the PEs that receive the = message will parse it and find it irrelevant. Efficient? =20 ------_=_NextPart_001_01C30592.4F2206E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt =

Hi Eric,

Eric> Suppose that 100 PEs participate in a = particular VPLS, and suppose that
Eric> PE17 has some information to PE43.

Mourad> Assuming that VPLS is a broadcast domain, = when a PE (PE17) need to
Mourad> seed an information to another PE only = (PE43) and will not to sharing this control information
Mourad> to other PEs registered in this VPLS = domain (PE1-PE16,PE18-PE42,PE44-PE100)?

Mourad> Your supposition is not applicable to VPLS = applications, isn't it?
Mourad> A topology with 2 PEs routers only is not = what i call a broadcast domain, your reflexion may
Mourad> refer to a Hub and Spoke architecture = (different import/export route target values) which i think
Mourad> is not applicable to VPLS. Do you share = this view?
Mourad> Furthermore a CE site could be members of = N differents VPLS domain, he could share restricted infos
Mourad> in VPLS A (PE17,PE43 only) and could be = member of another less restricted VPLS domain B (PE1-PE100).

Thanks & Best Regards,
Mourad

-----Message d'origine-----
De : Eric Rosen [mailto:erosen@cisco.com]
Envoy=E9 : jeudi 17 avril 2003 19:29
=C0 : Mourad BERKANE
Cc : ppvpn@nortelnetworks.com
Objet : Re: [PWE3] Re: Issues with = draft-kompella-ppvpn-vpls-01.txt



Mourad> If a  vendor could explain me  = how using 2  differents protocols for
Mourad> Control Plane (signaling and  = auto-discovery) will be more efficient
Mourad> (technical  argumentations please = and  not philosophical  ones) than
Mourad> when using only one protocol (MP-BGP). =

I don't  know why the one  who explains = this needs  to be a  vendor ;-), but
there are a large number of inefficiences in using = BGP for the signaling.

Suppose that 100 PEs participate in a particular = VPLS, and suppose that PE17
has some information to signal to PE43.

With point-to-point  signaling, PE17 sends  = a message to PE43,  PE43 replies
(if necessary), and we're done.

With BGP-based signaling, PE17 sends a message to the = route reflector, which
then  resends it to  PEs 1-16,  and = PEs  18-99.  So  instead of  sending one
message, you  send 100.   = Ninety-eight of the  PEs that receive  the message
will parse it and find it irrelevant. = Efficient?






   

------_=_NextPart_001_01C30592.4F2206E0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 10:18: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 KAA15366 for ; Fri, 18 Apr 2003 10:18:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IEKCi28941 for ; Fri, 18 Apr 2003 10:20:12 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IEK8520052 for ; Fri, 18 Apr 2003 10:20:08 -0400 (EDT) Date: Fri, 18 Apr 2003 16:17:47 +0200 Message-ID: <3E9BA3F7000082EC@mail-5.tiscali.it> From: vmilitano@tiscali.it Subject: draft-kompella-ppvpn-vpls-01.txt To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: mail-5.tiscali.it X-SMTP-MAIL-FROM: vmilitano@tiscali.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail-5.tiscali.it [195.130.225.151] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15366 Good Morning, Support for: draft-kompella-ppvpn-vpls-01.txt Thank you Veronica Militano __________________________________________________________________ Tiscali ADSL, fino a 9 MESI GRATIS sull'offerta Tiscali ADSL Light Mega! Tiscali ADSL non teme confronti! Abbonati subito. http://point.tiscali.it/adsl/index.shtml From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 10:42:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15974 for ; Fri, 18 Apr 2003 10:42:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IEiei04167 for ; Fri, 18 Apr 2003 10:44:40 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IEia507207 for ; Fri, 18 Apr 2003 10:44:37 -0400 (EDT) Message-ID: From: "O'Connor, Don" To: "'vkompella@timetra.com'" , "O'Connor, Don" , "'Serbest, Yetik'" , Cheng-Yin.Lee@alcatel.com Cc: mattsquire@acm.org, "'Rick Wilder'" , ppvpn@nortelnetworks.com, "'tony@jeffree.co.uk'" , "'mick_seaman@ieee.org'" Subject: RE: IEEE 802.1ad and VPLS Date: Fri, 18 Apr 2003 09:41:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: fncimr01.fnc.fujitsu.com X-SMTP-MAIL-FROM: Don.OConnor@fnc.fujitsu.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: fncimr01.fnc.fujitsu.com [168.127.0.3] X-LYRIS-Message-Id: Vach, Are you suggesting that customer BPDUs should not be tunneled through the provider VPLS network? If this is the case it would not be possible for customers to run STP across multiple sites interconnected by the VPLS network. I agree with your point that it may also be possible to use L3 signaling for MAC unlearn signaling especially for the case where bridging and MPLS are supported in the same NE. This is relevant to my question pertaining to how the L2 control plane interacts with the L3 control plane. I think it would be good to have a more formalized liaison structure between ppvpn and 802.1AD - maybe some common email list. Don -----Original Message----- From: Vach Kompella [mailto:vkompella@timetra.com] Sent: Thursday, April 17, 2003 6:20 PM To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com Subject: RE: IEEE 802.1ad and VPLS Dan, It isn't clear to me yet that the only reliable way to deal with L2 control protocol packets such as BPDUs is to pass them through the data plane of the VPLS. It is possible that one of the ways to deal with unlearns, e.g., is to use LDP messages, such as the MAC TLVs for specific or scoped unlearns. So, if "by reference" means that we don't assist the L2 solution with extensions to the VPLS signaling draft, then I disagree. If it means cooperative use of the L3 control plane with the IEEE work, I agree. Basically, we don't want to re-invent what is already there, but when we have L3 control plane methods available, it makes sense to figure out a division of work that makes the service work the best. From Clause 16 of the 802.1ad-d0 document: ... (stuff dealing with a potential topology with loops) ... requires an IETF connection (see also suggested Clause 6.6 Support of the Internal Sublayer Service by IETF foo) and to deal with some of the 'loop through a customer' questions and the partial answers that we have to those. -Vach > -----Original Message----- > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > Sent: Thursday, April 17, 2003 3:55 PM > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > Cheng-Yin.Lee@alcatel.com > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: RE: IEEE 802.1ad and VPLS > > > Vach, > > To confirm the relationship with draft-lasserre - when 802.1AD defines > solutions for issues such as Provider Bridge customer BPDU snooping / > unlearn signaling (for customer STP reconfiguration with backdoors, etc) - > then this will be incorporated in draft-lasserre by reference. Is this an > accurate perception? > > One issue I have been wondering about with respect to 802.1AD & PPVPN / > draft-lasserre is for single ended L2 VPN > provisioning, where will the interface between the L2 Control Plane (defined > by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be > defined. > > Don > > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Thursday, April 17, 2003 5:06 PM > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: IEEE 802.1ad and VPLS > > > Dan, > > Yes it is. One of the items in the ppvpn-wg minutes (note the date > pre-dates > the official PAR date which is Dec. 31, 2002, so we (as IETF participants) > have > been keeping in touch with the IEEE, albeit informally) for the Atlanta > meeting > shows: > > === clipped from minutes === > Norm Finn - IEEE 802.1 unofficial liaison > ----------------------------------------- > > Project authorization request (amendment to 802.1q VLANs) - enable a SP to > offer the equivalent of separate LAN segments, bridged or virtual bridged > LANs (network of bridges doing l2vpn type services). > > Name of project - 802.1AD. > MAC-in-MAC not possible with this amendment. > > Confident that IETF L2vpn and 802.1AD will be interoperable, compatible etc > if mailing discussions are carried through. > === end of clip === > > -Vach > > > -----Original Message----- > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > Sent: Thursday, April 17, 2003 1:54 PM > > To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > Yetik & Cheng-Yin, > > > > Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge > > Group to define solutions for these issues. > > > > Regards, > > > > Don > > > > -----Original Message----- > > From: Serbest, Yetik [mailto:serbest@tri.sbc.com] > > Sent: Thursday, April 17, 2003 2:58 PM > > To: 'Cheng-Yin.Lee@alcatel.com' > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > Cheng-Yin, > > > > When a draft becomes a working group document, that does not mean we stop > > working on it. Your point is good, and we will work on the issue. There > was > > some preliminary discussion among the authors; and when we have some > > conclusions, we will share them with the group. There are some other > issues > > as well. > > > > In DT, as you see from the mail (dated 2/6/2003) below I raised that > issue. > > > > ".....Anyway, as long as we move on and reach the time when we discuss how > > to support dual-homed CEs or customers with backdoor links, and how to > > troubleshoot the service when q or qinq spokes are present etc... I am > fine > > with it." > > > > Thanks, > > yetik > > > > -----Original Message----- > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > Sent: Thursday, April 17, 2003 2:02 PM > > To: Serbest, Yetik > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > Yetik, > > As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt, > I > > assume you care about the requirements in that draft. From the > requirements > > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that > > loops be prevented." > > > > I agree that it is a fundamental requirement that bridging loops be > handled > > in a VPLS solution. As we know loops can have a devastating effect on a > > bridged network. > > > > So, has this point been carefully considered for the VPLS drafts being > > proposed to be progressed? > > > > I think the VPLS drafts being considered here (using full-meshed with > > split-horizon) are not able to handle common scenarios/requirements > leading > > to loops and causing network meltdowns. > > > > This point has been raised before by several people but it still has not > > been addressed. If this mandatory requirement (not a minor detail or rare > > scenario) is not addressed and we still progress these drafts what is the > > message to the industry? That it's ok to continue pushing solutions that > > don't meet fundamental requirements? > > > > Thanks, > > Cheng-Yin > > > > "Serbest, Yetik" wrote: > > > > > > I would like to second that. > > > > > > Thanks, > > > yetik > > > > > > -----Original Message----- > > > From: Matt Squire [mailto:mattsquire@acm.org] > > > Sent: Tuesday, April 15, 2003 7:08 AM > > > To: 'Rick Wilder' > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > > draft > > > > > > The Laserre/VKompella draft should definitely progress as a working > > > group draft. Its a solid technical contribution with a lot of support > > > behind it. > > > > > > - Matt > > > > > > Olen Stokes wrote: > > > > I would also like to support making this a working group draft. > > > > > > > > Cheers, > > > > Olen > > > > > > > > -----Original Message----- > > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > > *To:* ppvpn@nortelnetworks.com > > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > > draft > > > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > > interest was expressed in pursuing the > > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We > > > > agreed to finalize that decision only after the WG participants > who > > > > weren't there could have a say. > > > > > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the > time, > > > > and this list is the place. Let's set a one-week limit to conclude > > > > this issue. > > > > > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > ---------------------------------------------------------------------- > > > > ------- > > > > > > > > From the minutes: > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > [snipped] > > > > > > > > Marco: asked for show of hands to make this a wG draft. > > > > Strong interest was shown in room. Further discussion on the > > > > list. > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 11:28:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17160 for ; Fri, 18 Apr 2003 11:28:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IFV4i24077 for ; Fri, 18 Apr 2003 11:31:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IFUx527106 for ; Fri, 18 Apr 2003 11:31:00 -0400 (EDT) Organization: Centro di Servizi per la rete di Ateneo (Se.R.A.) - Universita' di Pisa - Italy Date: Fri, 18 Apr 2003 17:27:23 +0200 Subject: draft-kompella-ppvpn-vpls-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: stefano@unipi.it To: ppvpn@nortelnetworks.com Content-Transfer-Encoding: 7bit Message-Id: <408FAFA2-71B2-11D7-8CD4-0003938300C0@unipi.it> X-Mailer: Apple Mail (2.551) X-SMTP-HELO: sun-paolo.unipi.it X-SMTP-MAIL-FROM: stefano@unipi.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sun-paolo.unipi.it [131.114.20.24] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit We support draft-kompella-ppvpn-vpls-01.txt. We like the scalability (RR) and BGP control plane. We like the possibility to maintain the current IP VPN control infrastructure, it allows semplicity and flexibility. Thank you stefano suin From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 11:29: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 LAA17190 for ; Fri, 18 Apr 2003 11:29:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IFVPi24523 for ; Fri, 18 Apr 2003 11:31:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IFVM527643 for ; Fri, 18 Apr 2003 11:31:22 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "O'Connor, Don" , "'Serbest, Yetik'" , Cc: , "'Rick Wilder'" , , , Subject: RE: IEEE 802.1ad and VPLS Date: Fri, 18 Apr 2003 08:23:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-OriginalArrivalTime: 18 Apr 2003 15:24:11.0207 (UTC) FILETIME=[8FDD3570:01C305BE] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I think we have agreed that tunneling BPDUs is going to be done. I think that over and above that, it may be possible to use L3 control plane mechanisms to assist the convergence. I'm only saying that it is possible that as we develop some scenarios of customer and provider topologies, I don't want to assume that the only solution lies in L2 protocols. -Vach > -----Original Message----- > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > Sent: Friday, April 18, 2003 7:42 AM > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > Cheng-Yin.Lee@alcatel.com > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; > 'tony@jeffree.co.uk'; 'mick_seaman@ieee.org' > Subject: RE: IEEE 802.1ad and VPLS > > > Vach, > > Are you suggesting that customer BPDUs should not be tunneled through the > provider VPLS network? If this is the case it would not be possible for > customers to run STP across multiple sites interconnected by the VPLS > network. > > I agree with your point that it may also be possible to use L3 signaling for > MAC unlearn signaling especially for the case where bridging and MPLS are > supported in the same NE. This is relevant to my question pertaining to how > the L2 control plane interacts with the L3 control plane. > > I think it would be good to have a more formalized liaison structure between > ppvpn and 802.1AD - maybe some common email > list. > > Don > > > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Thursday, April 17, 2003 6:20 PM > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > Subject: RE: IEEE 802.1ad and VPLS > > > Dan, > > It isn't clear to me yet that the only reliable way to deal with L2 control > protocol packets such as BPDUs is to pass them through the data plane of the > VPLS. It is possible that one of the ways to deal with unlearns, e.g., is > to > use LDP messages, such as the MAC TLVs for specific or scoped unlearns. So, > if > "by reference" means that we don't assist the L2 solution with extensions to > the > VPLS signaling draft, then I disagree. If it means cooperative use of the > L3 > control plane with the IEEE work, I agree. Basically, we don't want to > re-invent what is already there, but when we have L3 control plane methods > available, it makes sense to figure out a division of work that makes the > service work the best. > > From Clause 16 of the 802.1ad-d0 document: > ... (stuff dealing with a potential topology with loops) ... requires an > IETF > connection (see also suggested Clause 6.6 Support of the Internal Sublayer > Service by IETF foo) and to deal with some of the 'loop through a customer' > questions and the partial answers that we have to those. > > -Vach > > > -----Original Message----- > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > Sent: Thursday, April 17, 2003 3:55 PM > > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > > Cheng-Yin.Lee@alcatel.com > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: RE: IEEE 802.1ad and VPLS > > > > > > Vach, > > > > To confirm the relationship with draft-lasserre - when 802.1AD defines > > solutions for issues such as Provider Bridge customer BPDU snooping / > > unlearn signaling (for customer STP reconfiguration with backdoors, etc) - > > then this will be incorporated in draft-lasserre by reference. Is this an > > accurate perception? > > > > One issue I have been wondering about with respect to 802.1AD & PPVPN / > > draft-lasserre is for single ended L2 VPN > > provisioning, where will the interface between the L2 Control Plane > (defined > > by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be > > defined. > > > > Don > > > > -----Original Message----- > > From: Vach Kompella [mailto:vkompella@timetra.com] > > Sent: Thursday, April 17, 2003 5:06 PM > > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: IEEE 802.1ad and VPLS > > > > > > Dan, > > > > Yes it is. One of the items in the ppvpn-wg minutes (note the date > > pre-dates > > the official PAR date which is Dec. 31, 2002, so we (as IETF participants) > > have > > been keeping in touch with the IEEE, albeit informally) for the Atlanta > > meeting > > shows: > > > > === clipped from minutes === > > Norm Finn - IEEE 802.1 unofficial liaison > > ----------------------------------------- > > > > Project authorization request (amendment to 802.1q VLANs) - enable a SP to > > offer the equivalent of separate LAN segments, bridged or virtual bridged > > LANs (network of bridges doing l2vpn type services). > > > > Name of project - 802.1AD. > > MAC-in-MAC not possible with this amendment. > > > > Confident that IETF L2vpn and 802.1AD will be interoperable, compatible > etc > > if mailing discussions are carried through. > > === end of clip === > > > > -Vach > > > > > -----Original Message----- > > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > > Sent: Thursday, April 17, 2003 1:54 PM > > > To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > > > > Yetik & Cheng-Yin, > > > > > > Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge > > > Group to define solutions for these issues. > > > > > > Regards, > > > > > > Don > > > > > > -----Original Message----- > > > From: Serbest, Yetik [mailto:serbest@tri.sbc.com] > > > Sent: Thursday, April 17, 2003 2:58 PM > > > To: 'Cheng-Yin.Lee@alcatel.com' > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > > > > Cheng-Yin, > > > > > > When a draft becomes a working group document, that does not mean we > stop > > > working on it. Your point is good, and we will work on the issue. There > > was > > > some preliminary discussion among the authors; and when we have some > > > conclusions, we will share them with the group. There are some other > > issues > > > as well. > > > > > > In DT, as you see from the mail (dated 2/6/2003) below I raised that > > issue. > > > > > > ".....Anyway, as long as we move on and reach the time when we discuss > how > > > to support dual-homed CEs or customers with backdoor links, and how to > > > troubleshoot the service when q or qinq spokes are present etc... I am > > fine > > > with it." > > > > > > Thanks, > > > yetik > > > > > > -----Original Message----- > > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > > Sent: Thursday, April 17, 2003 2:02 PM > > > To: Serbest, Yetik > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > > > > Yetik, > > > As an one of the editor of > draft-augustyn-ppvpn-l2vpn-requirements-02.txt, > > I > > > assume you care about the requirements in that draft. From the > > requirements > > > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that > > > loops be prevented." > > > > > > I agree that it is a fundamental requirement that bridging loops be > > handled > > > in a VPLS solution. As we know loops can have a devastating effect on a > > > bridged network. > > > > > > So, has this point been carefully considered for the VPLS drafts being > > > proposed to be progressed? > > > > > > I think the VPLS drafts being considered here (using full-meshed with > > > split-horizon) are not able to handle common scenarios/requirements > > leading > > > to loops and causing network meltdowns. > > > > > > This point has been raised before by several people but it still has not > > > been addressed. If this mandatory requirement (not a minor detail or > rare > > > scenario) is not addressed and we still progress these drafts what is > the > > > message to the industry? That it's ok to continue pushing solutions that > > > don't meet fundamental requirements? > > > > > > Thanks, > > > Cheng-Yin > > > > > > "Serbest, Yetik" wrote: > > > > > > > > I would like to second that. > > > > > > > > Thanks, > > > > yetik > > > > > > > > -----Original Message----- > > > > From: Matt Squire [mailto:mattsquire@acm.org] > > > > Sent: Tuesday, April 15, 2003 7:08 AM > > > > To: 'Rick Wilder' > > > > Cc: ppvpn@nortelnetworks.com > > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > > > draft > > > > > > > > The Laserre/VKompella draft should definitely progress as a working > > > > group draft. Its a solid technical contribution with a lot of support > > > > behind it. > > > > > > > > - Matt > > > > > > > > Olen Stokes wrote: > > > > > I would also like to support making this a working group draft. > > > > > > > > > > Cheers, > > > > > Olen > > > > > > > > > > -----Original Message----- > > > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > > > *To:* ppvpn@nortelnetworks.com > > > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > > > draft > > > > > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > > > interest was expressed in pursuing the > > > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. > We > > > > > agreed to finalize that decision only after the WG participants > > who > > > > > weren't there could have a say. > > > > > > > > > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the > > time, > > > > > and this list is the place. Let's set a one-week limit to > conclude > > > > > this issue. > > > > > > > > > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > -- > > > > > > ---------------------------------------------------------------------- > > > > > ------- > > > > > > > > > > From the minutes: > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > [snipped] > > > > > > > > > > Marco: asked for show of hands to make this a wG draft. > > > > > Strong interest was shown in room. Further discussion on the > > > > > list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 11:43:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17513 for ; Fri, 18 Apr 2003 11:43:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IFjJi27854 for ; Fri, 18 Apr 2003 11:45:19 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IFjF502948 for ; Fri, 18 Apr 2003 11:45:15 -0400 (EDT) Message-Id: <3EA01D90.348B5975@francetelecom.com> Date: Fri, 18 Apr 2003 11:45:20 -0400 From: "LIAN Franklin FTLD/IAP" Organization: France Telecom Long Distance X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: John Drake CC: "'Kireeti Kompella'" , ppvpn@nortelnetworks.com, rwilder@masergy.com Subject: Re: progressing docs ... References: <9D42C6E086250248810DCADA39CE7EFC972409@nimbus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: relais-inet-04.francetelecom.fr X-SMTP-MAIL-FROM: franklin.lian@francetelecom.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: relais-inet.francetelecom.com [212.234.67.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Sorry for the late jump in but I like the idea. John Drake wrote: > > I'd like to support making this a WG doc > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Thursday, April 10, 2003 10:27 AM > > To: ppvpn@nortelnetworks.com; rwilder@masergy.com > > Subject: progressing docs ... > > > > > > Hi Rick, > > > > If you are going down the path of progressing VPLS docs, could you > > also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a > > PPVPN WG doc? > > > > Thanks, > > Kireeti. > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 12:17: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 MAA18522 for ; Fri, 18 Apr 2003 12:17:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IGJPi14871 for ; Fri, 18 Apr 2003 12:19:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IGJM503698 for ; Fri, 18 Apr 2003 12:19:22 -0400 (EDT) Date: Fri, 18 Apr 2003 12:16:45 -0400 (EDT) From: schultz@io.iol.unh.edu To: Vach Kompella cc: "O'Connor, Don" , "'Serbest, Yetik'" , Cheng-Yin.Lee@alcatel.com, mattsquire@acm.org, "'Rick Wilder'" , ppvpn@nortelnetworks.com, tony@jeffree.co.uk, mick_seaman@ieee.org, Gerard Goubert Subject: RE: IEEE 802.1ad and VPLS In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: io.iol.unh.edu X-SMTP-MAIL-FROM: schultz@io.iol.unh.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: io.iol.unh.edu [132.177.123.82] X-LYRIS-Message-Id: Vach, So is the plan here to come up with a 802.1ad solution and a separate ppvpn (L3 control plane) solution? Or is this ppvpn committee going to work with 802.1 to design a specific interoperable solution? These options are not mutually exclusive. I am unclear as to how this effort is being organized beyond norm finn's unofficial liason. Thanks, -Ben On Fri, 18 Apr 2003, Vach Kompella wrote: > I think we have agreed that tunneling BPDUs is going to be done. I think that > over and above that, it may be possible to use L3 control plane mechanisms to > assist the convergence. I'm only saying that it is possible that as we develop > some scenarios of customer and provider topologies, I don't want to assume that > the only solution lies in L2 protocols. > > -Vach > > > -----Original Message----- > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > Sent: Friday, April 18, 2003 7:42 AM > > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > > Cheng-Yin.Lee@alcatel.com > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; > > 'tony@jeffree.co.uk'; 'mick_seaman@ieee.org' > > Subject: RE: IEEE 802.1ad and VPLS > > > > > > Vach, > > > > Are you suggesting that customer BPDUs should not be tunneled through the > > provider VPLS network? If this is the case it would not be possible for > > customers to run STP across multiple sites interconnected by the VPLS > > network. > > > > I agree with your point that it may also be possible to use L3 signaling for > > MAC unlearn signaling especially for the case where bridging and MPLS are > > supported in the same NE. This is relevant to my question pertaining to how > > the L2 control plane interacts with the L3 control plane. > > > > I think it would be good to have a more formalized liaison structure between > > ppvpn and 802.1AD - maybe some common email > > list. > > > > Don > > > > > > -----Original Message----- > > From: Vach Kompella [mailto:vkompella@timetra.com] > > Sent: Thursday, April 17, 2003 6:20 PM > > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > Subject: RE: IEEE 802.1ad and VPLS > > > > > > Dan, > > > > It isn't clear to me yet that the only reliable way to deal with L2 control > > protocol packets such as BPDUs is to pass them through the data plane of the > > VPLS. It is possible that one of the ways to deal with unlearns, e.g., is > > to > > use LDP messages, such as the MAC TLVs for specific or scoped unlearns. So, > > if > > "by reference" means that we don't assist the L2 solution with extensions to > > the > > VPLS signaling draft, then I disagree. If it means cooperative use of the > > L3 > > control plane with the IEEE work, I agree. Basically, we don't want to > > re-invent what is already there, but when we have L3 control plane methods > > available, it makes sense to figure out a division of work that makes the > > service work the best. > > > > From Clause 16 of the 802.1ad-d0 document: > > ... (stuff dealing with a potential topology with loops) ... requires an > > IETF > > connection (see also suggested Clause 6.6 Support of the Internal Sublayer > > Service by IETF foo) and to deal with some of the 'loop through a customer' > > questions and the partial answers that we have to those. > > > > -Vach > > > > > -----Original Message----- > > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > > Sent: Thursday, April 17, 2003 3:55 PM > > > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > > > Cheng-Yin.Lee@alcatel.com > > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > Subject: RE: IEEE 802.1ad and VPLS > > > > > > > > > Vach, > > > > > > To confirm the relationship with draft-lasserre - when 802.1AD defines > > > solutions for issues such as Provider Bridge customer BPDU snooping / > > > unlearn signaling (for customer STP reconfiguration with backdoors, etc) - > > > then this will be incorporated in draft-lasserre by reference. Is this an > > > accurate perception? > > > > > > One issue I have been wondering about with respect to 802.1AD & PPVPN / > > > draft-lasserre is for single ended L2 VPN > > > provisioning, where will the interface between the L2 Control Plane > > (defined > > > by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be > > > defined. > > > > > > Don > > > > > > -----Original Message----- > > > From: Vach Kompella [mailto:vkompella@timetra.com] > > > Sent: Thursday, April 17, 2003 5:06 PM > > > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > Subject: IEEE 802.1ad and VPLS > > > > > > > > > Dan, > > > > > > Yes it is. One of the items in the ppvpn-wg minutes (note the date > > > pre-dates > > > the official PAR date which is Dec. 31, 2002, so we (as IETF participants) > > > have > > > been keeping in touch with the IEEE, albeit informally) for the Atlanta > > > meeting > > > shows: > > > > > > === clipped from minutes === > > > Norm Finn - IEEE 802.1 unofficial liaison > > > ----------------------------------------- > > > > > > Project authorization request (amendment to 802.1q VLANs) - enable a SP to > > > offer the equivalent of separate LAN segments, bridged or virtual bridged > > > LANs (network of bridges doing l2vpn type services). > > > > > > Name of project - 802.1AD. > > > MAC-in-MAC not possible with this amendment. > > > > > > Confident that IETF L2vpn and 802.1AD will be interoperable, compatible > > etc > > > if mailing discussions are carried through. > > > === end of clip === > > > > > > -Vach > > > > > > > -----Original Message----- > > > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > > > Sent: Thursday, April 17, 2003 1:54 PM > > > > To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' > > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > > > > > > > Yetik & Cheng-Yin, > > > > > > > > Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge > > > > Group to define solutions for these issues. > > > > > > > > Regards, > > > > > > > > Don > > > > > > > > -----Original Message----- > > > > From: Serbest, Yetik [mailto:serbest@tri.sbc.com] > > > > Sent: Thursday, April 17, 2003 2:58 PM > > > > To: 'Cheng-Yin.Lee@alcatel.com' > > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > > > > > > > Cheng-Yin, > > > > > > > > When a draft becomes a working group document, that does not mean we > > stop > > > > working on it. Your point is good, and we will work on the issue. There > > > was > > > > some preliminary discussion among the authors; and when we have some > > > > conclusions, we will share them with the group. There are some other > > > issues > > > > as well. > > > > > > > > In DT, as you see from the mail (dated 2/6/2003) below I raised that > > > issue. > > > > > > > > ".....Anyway, as long as we move on and reach the time when we discuss > > how > > > > to support dual-homed CEs or customers with backdoor links, and how to > > > > troubleshoot the service when q or qinq spokes are present etc... I am > > > fine > > > > with it." > > > > > > > > Thanks, > > > > yetik > > > > > > > > -----Original Message----- > > > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > > > Sent: Thursday, April 17, 2003 2:02 PM > > > > To: Serbest, Yetik > > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft > > > > > > > > > > > > Yetik, > > > > As an one of the editor of > > draft-augustyn-ppvpn-l2vpn-requirements-02.txt, > > > I > > > > assume you care about the requirements in that draft. From the > > > requirements > > > > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that > > > > loops be prevented." > > > > > > > > I agree that it is a fundamental requirement that bridging loops be > > > handled > > > > in a VPLS solution. As we know loops can have a devastating effect on a > > > > bridged network. > > > > > > > > So, has this point been carefully considered for the VPLS drafts being > > > > proposed to be progressed? > > > > > > > > I think the VPLS drafts being considered here (using full-meshed with > > > > split-horizon) are not able to handle common scenarios/requirements > > > leading > > > > to loops and causing network meltdowns. > > > > > > > > This point has been raised before by several people but it still has not > > > > been addressed. If this mandatory requirement (not a minor detail or > > rare > > > > scenario) is not addressed and we still progress these drafts what is > > the > > > > message to the industry? That it's ok to continue pushing solutions that > > > > don't meet fundamental requirements? > > > > > > > > Thanks, > > > > Cheng-Yin > > > > > > > > "Serbest, Yetik" wrote: > > > > > > > > > > I would like to second that. > > > > > > > > > > Thanks, > > > > > yetik > > > > > > > > > > -----Original Message----- > > > > > From: Matt Squire [mailto:mattsquire@acm.org] > > > > > Sent: Tuesday, April 15, 2003 7:08 AM > > > > > To: 'Rick Wilder' > > > > > Cc: ppvpn@nortelnetworks.com > > > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > > > > draft > > > > > > > > > > The Laserre/VKompella draft should definitely progress as a working > > > > > group draft. Its a solid technical contribution with a lot of support > > > > > behind it. > > > > > > > > > > - Matt > > > > > > > > > > Olen Stokes wrote: > > > > > > I would also like to support making this a working group draft. > > > > > > > > > > > > Cheers, > > > > > > Olen > > > > > > > > > > > > -----Original Message----- > > > > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > > > > *To:* ppvpn@nortelnetworks.com > > > > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group > > > > > > draft > > > > > > > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > > > > interest was expressed in pursuing the > > > > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. > > We > > > > > > agreed to finalize that decision only after the WG participants > > > who > > > > > > weren't there could have a say. > > > > > > > > > > > > > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the > > > time, > > > > > > and this list is the place. Let's set a one-week limit to > > conclude > > > > > > this issue. > > > > > > > > > > > > > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > -- > > > > > > > > ---------------------------------------------------------------------- > > > > > > ------- > > > > > > > > > > > > From the minutes: > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > [snipped] > > > > > > > > > > > > Marco: asked for show of hands to make this a wG draft. > > > > > > Strong interest was shown in room. Further discussion on the > > > > > > list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 12:32: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 MAA18854 for ; Fri, 18 Apr 2003 12:32:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IGYAi18749 for ; Fri, 18 Apr 2003 12:34:11 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IGY6512254 for ; Fri, 18 Apr 2003 12:34:07 -0400 (EDT) Reply-To: From: "Vach Kompella" To: Cc: "O'Connor, Don" , "'Serbest, Yetik'" , , , "'Rick Wilder'" , , , , "Gerard Goubert" Subject: RE: IEEE 802.1ad and VPLS Date: Fri, 18 Apr 2003 09:31:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-OriginalArrivalTime: 18 Apr 2003 16:31:19.0375 (UTC) FILETIME=[F0D6DDF0:01C305C7] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit It's too early to say exactly how the pieces interact. Initial discussions with members in the IEEE (particularly Mick Seaman, Norm Finn, Tony Jeffree, Matt Squire) have shown that they think that draft-lasserre-vkompella can fit in the IEEE model. On our side, the design team discussions have confirmed that. The IEEE believes it takes some definition on their part, which is what 802.1ad is. Both 802.1ad and draft-lasserre-vkompella are "works in progress." The IEEE has clearly gotten far enough that they got a draft0. We are still deciding whether draft-lasserre-vkompella is a WG document or not. I'd say, when we get past that stage in the IETF, we can ask for formal liaisons. That's why I've been pushing for IETF recognition that what we are working on here in ppvpn is worth furthering. I don't think the process calls for everything to be nailed down before the IETF recognizes the work as its own rather than an individual contribution. As a final point, this has been a call to make draft-lasserre-vkompella a working group document, nothing more. I (fondly) think that phase has been achieved, but I'll wait for official confirmation from the chairs. -Vach > -----Original Message----- > From: schultz@io.iol.unh.edu [mailto:schultz@io.iol.unh.edu] > Sent: Friday, April 18, 2003 9:17 AM > To: Vach Kompella > Cc: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com; > mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; > tony@jeffree.co.uk; mick_seaman@ieee.org; Gerard Goubert > Subject: RE: IEEE 802.1ad and VPLS > > > > Vach, > > So is the plan here to come up with a 802.1ad solution and a separate > ppvpn (L3 control plane) solution? Or is this ppvpn committee going to > work with 802.1 to design a specific interoperable solution? These > options are not mutually exclusive. > > I am unclear as to how this effort is being organized beyond norm finn's > unofficial liason. > > Thanks, > -Ben > > On Fri, 18 Apr 2003, Vach Kompella wrote: > > > I think we have agreed that tunneling BPDUs is going to be done. I > think that > > over and above that, it may be possible to use L3 control plane > mechanisms to > > assist the convergence. I'm only saying that it is possible that > as we develop > > some scenarios of customer and provider topologies, I don't want to > assume that > > the only solution lies in L2 protocols. > > > > -Vach > > > > > -----Original Message----- > > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > > Sent: Friday, April 18, 2003 7:42 AM > > > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > > > Cheng-Yin.Lee@alcatel.com > > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; > > > 'tony@jeffree.co.uk'; 'mick_seaman@ieee.org' > > > Subject: RE: IEEE 802.1ad and VPLS > > > > > > > > > Vach, > > > > > > Are you suggesting that customer BPDUs should not be tunneled through the > > > provider VPLS network? If this is the case it would not be possible for > > > customers to run STP across multiple sites interconnected by the VPLS > > > network. > > > > > > I agree with your point that it may also be possible to use L3 > signaling for > > > MAC unlearn signaling especially for the case where bridging and MPLS are > > > supported in the same NE. This is relevant to my question > pertaining to how > > > the L2 control plane interacts with the L3 control plane. > > > > > > I think it would be good to have a more formalized liaison > structure between > > > ppvpn and 802.1AD - maybe some common email > > > list. > > > > > > Don > > > > > > > > > -----Original Message----- > > > From: Vach Kompella [mailto:vkompella@timetra.com] > > > Sent: Thursday, April 17, 2003 6:20 PM > > > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > Subject: RE: IEEE 802.1ad and VPLS > > > > > > > > > Dan, > > > > > > It isn't clear to me yet that the only reliable way to deal with > L2 control > > > protocol packets such as BPDUs is to pass them through the data > plane of the > > > VPLS. It is possible that one of the ways to deal with unlearns, e.g., is > > > to > > > use LDP messages, such as the MAC TLVs for specific or scoped > unlearns. So, > > > if > > > "by reference" means that we don't assist the L2 solution with > extensions to > > > the > > > VPLS signaling draft, then I disagree. If it means cooperative use of the > > > L3 > > > control plane with the IEEE work, I agree. Basically, we don't want to > > > re-invent what is already there, but when we have L3 control plane methods > > > available, it makes sense to figure out a division of work that makes the > > > service work the best. > > > > > > From Clause 16 of the 802.1ad-d0 document: > > > ... (stuff dealing with a potential topology with loops) ... requires an > > > IETF > > > connection (see also suggested Clause 6.6 Support of the Internal Sublayer > > > Service by IETF foo) and to deal with some of the 'loop through a > customer' > > > questions and the partial answers that we have to those. > > > > > > -Vach > > > > > > > -----Original Message----- > > > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > > > Sent: Thursday, April 17, 2003 3:55 PM > > > > To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; > > > > Cheng-Yin.Lee@alcatel.com > > > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > Subject: RE: IEEE 802.1ad and VPLS > > > > > > > > > > > > Vach, > > > > > > > > To confirm the relationship with draft-lasserre - when 802.1AD defines > > > > solutions for issues such as Provider Bridge customer BPDU snooping / > > > > unlearn signaling (for customer STP reconfiguration with > backdoors, etc) - > > > > then this will be incorporated in draft-lasserre by reference. > Is this an > > > > accurate perception? > > > > > > > > One issue I have been wondering about with respect to 802.1AD & PPVPN / > > > > draft-lasserre is for single ended L2 VPN > > > > provisioning, where will the interface between the L2 Control Plane > > > (defined > > > > by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be > > > > defined. > > > > > > > > Don > > > > > > > > -----Original Message----- > > > > From: Vach Kompella [mailto:vkompella@timetra.com] > > > > Sent: Thursday, April 17, 2003 5:06 PM > > > > To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com > > > > Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > Subject: IEEE 802.1ad and VPLS > > > > > > > > > > > > Dan, > > > > > > > > Yes it is. One of the items in the ppvpn-wg minutes (note the date > > > > pre-dates > > > > the official PAR date which is Dec. 31, 2002, so we (as IETF > participants) > > > > have > > > > been keeping in touch with the IEEE, albeit informally) for the Atlanta > > > > meeting > > > > shows: > > > > > > > > === clipped from minutes === > > > > Norm Finn - IEEE 802.1 unofficial liaison > > > > ----------------------------------------- > > > > > > > > Project authorization request (amendment to 802.1q VLANs) - > enable a SP to > > > > offer the equivalent of separate LAN segments, bridged or > virtual bridged > > > > LANs (network of bridges doing l2vpn type services). > > > > > > > > Name of project - 802.1AD. > > > > MAC-in-MAC not possible with this amendment. > > > > > > > > Confident that IETF L2vpn and 802.1AD will be interoperable, compatible > > > etc > > > > if mailing discussions are carried through. > > > > === end of clip === > > > > > > > > -Vach > > > > > > > > > -----Original Message----- > > > > > From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] > > > > > Sent: Thursday, April 17, 2003 1:54 PM > > > > > To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' > > > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working > group draft > > > > > > > > > > > > > > > Yetik & Cheng-Yin, > > > > > > > > > > Isn't the PPVPN group in theory working with the 802.1AD > Provider Bridge > > > > > Group to define solutions for these issues. > > > > > > > > > > Regards, > > > > > > > > > > Don > > > > > > > > > > -----Original Message----- > > > > > From: Serbest, Yetik [mailto:serbest@tri.sbc.com] > > > > > Sent: Thursday, April 17, 2003 2:58 PM > > > > > To: 'Cheng-Yin.Lee@alcatel.com' > > > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > > Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working > group draft > > > > > > > > > > > > > > > Cheng-Yin, > > > > > > > > > > When a draft becomes a working group document, that does not mean we > > > stop > > > > > working on it. Your point is good, and we will work on the > issue. There > > > > was > > > > > some preliminary discussion among the authors; and when we have some > > > > > conclusions, we will share them with the group. There are some other > > > > issues > > > > > as well. > > > > > > > > > > In DT, as you see from the mail (dated 2/6/2003) below I raised that > > > > issue. > > > > > > > > > > ".....Anyway, as long as we move on and reach the time when we discuss > > > how > > > > > to support dual-homed CEs or customers with backdoor links, and how to > > > > > troubleshoot the service when q or qinq spokes are present etc... I am > > > > fine > > > > > with it." > > > > > > > > > > Thanks, > > > > > yetik > > > > > > > > > > -----Original Message----- > > > > > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > > > > > Sent: Thursday, April 17, 2003 2:02 PM > > > > > To: Serbest, Yetik > > > > > Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com > > > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working > group draft > > > > > > > > > > > > > > > Yetik, > > > > > As an one of the editor of > > > draft-augustyn-ppvpn-l2vpn-requirements-02.txt, > > > > I > > > > > assume you care about the requirements in that draft. From the > > > > requirements > > > > > draft, Section 5.8: "In case of VPLS, the L2VPN service MUST > ensure that > > > > > loops be prevented." > > > > > > > > > > I agree that it is a fundamental requirement that bridging loops be > > > > handled > > > > > in a VPLS solution. As we know loops can have a devastating > effect on a > > > > > bridged network. > > > > > > > > > > So, has this point been carefully considered for the VPLS drafts being > > > > > proposed to be progressed? > > > > > > > > > > I think the VPLS drafts being considered here (using full-meshed with > > > > > split-horizon) are not able to handle common scenarios/requirements > > > > leading > > > > > to loops and causing network meltdowns. > > > > > > > > > > This point has been raised before by several people but it > still has not > > > > > been addressed. If this mandatory requirement (not a minor detail or > > > rare > > > > > scenario) is not addressed and we still progress these drafts what is > > > the > > > > > message to the industry? That it's ok to continue pushing > solutions that > > > > > don't meet fundamental requirements? > > > > > > > > > > Thanks, > > > > > Cheng-Yin > > > > > > > > > > "Serbest, Yetik" wrote: > > > > > > > > > > > > I would like to second that. > > > > > > > > > > > > Thanks, > > > > > > yetik > > > > > > > > > > > > -----Original Message----- > > > > > > From: Matt Squire [mailto:mattsquire@acm.org] > > > > > > Sent: Tuesday, April 15, 2003 7:08 AM > > > > > > To: 'Rick Wilder' > > > > > > Cc: ppvpn@nortelnetworks.com > > > > > > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group > > > > > > draft > > > > > > > > > > > > The Laserre/VKompella draft should definitely progress as a working > > > > > > group draft. Its a solid technical contribution with a lot > of support > > > > > > behind it. > > > > > > > > > > > > - Matt > > > > > > > > > > > > Olen Stokes wrote: > > > > > > > I would also like to support making this a working group draft. > > > > > > > > > > > > > > Cheers, > > > > > > > Olen > > > > > > > > > > > > > > -----Original Message----- > > > > > > > *From:* Rick Wilder [mailto:rwilder@masergy.com] > > > > > > > *Sent:* Thursday, April 10, 2003 11:20 AM > > > > > > > *To:* ppvpn@nortelnetworks.com > > > > > > > *Subject:* draft-lasserre-vkompella-ppvpn-vpls as > working group > > > > > > > draft > > > > > > > > > > > > > > As noted in the minutes, at the San Francisco meeting strong > > > > > > > interest was expressed in pursuing the > > > > > > > "draft-lasserre-vkompella-ppvpn-vpls" as a working > group draft. > > > We > > > > > > > agreed to finalize that decision only after the WG > participants > > > > who > > > > > > > weren't there could have a say. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if there are opinions that have not been heard, now is the > > > > time, > > > > > > > and this list is the place. Let's set a one-week limit to > > > conclude > > > > > > > this issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > -- > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > ------- > > > > > > > > > > > > > > From the minutes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > [snipped] > > > > > > > > > > > > > > Marco: asked for show of hands to make this a wG draft. > > > > > > > Strong interest was shown in room. Further discussion on the > > > > > > > list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 12:36:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19063 for ; Fri, 18 Apr 2003 12:36:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IGcoi22132 for ; Fri, 18 Apr 2003 12:38:50 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IGck516395 for ; Fri, 18 Apr 2003 12:38:47 -0400 (EDT) Message-Id: <200304181636.h3IGaPB0007701@rtp-core-1.cisco.com> To: "Hector Avalos" cc: "Mourad BERKANE" , ppvpn@nortelnetworks.com Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Thu, 17 Apr 2003 22:43:24 +0200. 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: Fri, 18 Apr 2003 12:36:25 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Hector> What would be the type of signaling message a PE17 will send to a Hector> PE43 that any other PE should be aware if the VPLS is a full mesh? I think you're asking whether PE17 might really ever need to send a control message to PE43 that the other 98 PEs don't need to know about. Some possible examples: sequence number synchronization, OAM functions that utilize the control plane, QoS. I'll admit though that using BGP for VPLS signaling is not quite as bad as using it for VPWS signaling. Surely no one would ever propose it for the latter, right ;-) Eric> So instead of sending one message, you send 100. Ninety-eight of the Eric> PEs that receive the message will parse it and find it irrelevant. Hector> This is the same behavior than 2547bis and it works very well. Well, I'm always delighted to hear folks say how well 2547bis works! But this is not the same behavior. In L3VPN, if a PE makes a routing change for some VPN, that change is meaningful to all the other PEs supporting that VPN. Thus it MUST be communicated to all the other PEs. What we're talking about with VPLS is information that is meaningful to only one remote PE in the VPLS, but gets sent to all the others anyway. Hector> I wonder what is the conception of a VPLS domain size. Hector> I guess that VPLS will not be applicable to +100 sites VPNs If one expected a VPLS to contain a relatively small number of sites, one wouldn't even bother with the label block hack. Hector> For a VPLS domain of 100 sites, a PE needs to reserve 100 labels Hector> If a PE supports 1000 VPNS of this size, then we end-up with Hector> 100,000 labels. If you really have 100 sites in a VPLS, each PE needs to use 100 labels, however you distribute them, and whether you are using label blocks or not. The wastage only comes if you overprovision the label block size to allow for future expansion. Then the issue isn't that you're using 100,000 labels, it's that 50,000 of them (assuming there are 50 sites now, with plans to possibly add 50 more, if business is good) aren't being used at all. Hector> I know some 2547bis applications which signals one label per Hector> prefix. And in such applications, if VPLS requires that a PE hold 50,000 labels in abeyance for possible future expansion, that's 50,000 fewer prefixes that that PE can support in L3VPN. There are also some advantages to being able to assign the in-use labels compactly. If a router reboots, it may be a good idea for it to remember where it left off assigning labels before, so that it can start assigning new labels from where it left off. This reduces the likelihood of confusion if some some system out there is still using the old labels. (Perhaps that other system hasn't gotten the latest BGP updates yet, or perhaps it is one of those newfangled "non-stop-forwarding" systems which is continuing to forward even if it is temporarily unable to process the BGP updates.) If you're using a scheme which wastes labels, it's more difficult to do this effectively. The notion of a label range being meaningful at the protocol level really departs from the MPLS architecture. If some hardware designer decides that even numbered labels should be used for 2547, odd numbered labels non-prime numbers for VPWS, and prime numbers for VPWS, he should be able to do that. Hector> I think that comparing BGP vs LDP for signaling is a wrong Hector> comparison BGP also does auto-discovery, which LDP doesn't. So I Hector> guess that Mourad's question remains open. How two protocols will be Hector> more efficient for signaling and auto-discovery ? I guess I thought I had addressed that. If you were to use Radius for auto-discovery, would you also be proposing to use it for signaling? From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 13:43:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20559 for ; Fri, 18 Apr 2003 13:43:54 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IHjvi10075 for ; Fri, 18 Apr 2003 13:45:58 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IHjr500585 for ; Fri, 18 Apr 2003 13:45:53 -0400 (EDT) Message-Id: <200304181743.h3IHhSB0024781@rtp-core-1.cisco.com> To: Kireeti Kompella cc: Mourad BERKANE , "" Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Thu, 17 Apr 2003 13:48:20 -0700. <20030417123347.M55269@kummer.juniper.net> 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: Fri, 18 Apr 2003 13:43:26 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Eric> Suppose that 100 PEs participate in a particular VPLS, and suppose Eric> that PE17 has some information to signal to PE43.x Eric> With point-to-point signaling, PE17 sends a message to PE43, PE43 Eric> replies (if necessary), and we're done. Kireeti> Sure. N*(N-1) is small when N = 2. I think you missed the first sentence above. Kireeti> Excuse me, but are you not an author of rfc2547bis and Kireeti> draft-ietf-ppvpn-bgpvpn-auto-03.txt? Yes, indeed. Kireeti> In both of the above, you send 100 messages to all the PEs, even if Kireeti> the only other member of the VPN is PE43. The case under discussion is where PE1, ..., PE100 are all members of the VPN. In L3VPN, and in auto-discovery, there just isn't any possible case in which PE17 has something to say only to PE43, because there are no point-to-point connections. In L2VPN, which is built on top of point-to-point connections, it becomes possible to use the control plane to talk about individual point-to-point connections. In VPWS, one has to do a fair amount of this, in VPLS less. The issue is whether BGP is a good way to do this, and whether there is enough of this to matter. It's not necessarily true that in either L3VPN or L2VPN, information is ever sent to all PEs; techniques like ORF can be used to limit the distribution to only those PEs which belong to the particular VPN or VPLS. What there is no way to do is to limit the distribution of information further. In L3VPN, there is no reason to do that, but in L2VPN there is. Kireeti> As for the "label block hack", sure, call it a hack, that should Kireeti> scare people away -- argumentum ad hominem always works. No, "ad hominem" would be if I called you a hacker; the worst you can accuse me of is "name calling" ;-) But I think it's fair to call it a hack because it imposes constraints on the label assignment methodology that depart from the MPLS architecture, and the reason for imposing those constraints is to make a particular sort of solution (BGP-based L2VPN signaling) possible. It's quite a clever hack, actually, but that's not the same as being a good idea. Kireeti> As for "wasting" labels, it amazes me that a vendor that allocates Kireeti> individual labels for each IP VPN prefix from the same PE keeps Kireeti> harping on this. Speaking of ad hominems ... It seems to me there are two cases: 1. If one thinks of labels as a scarce resource which must be carefully used, one certainly doesn't want to waste labels. 2. If one uses labels quite freely, one doesn't want to find out that one has run out of them because some have to be kept unused. So I don't see how wasting labels can be justified. Kireeti> Efficient block allocation is a solved problem. Ask anyone who Kireeti> does memory management, That must be why memory fragmentation is so rarely a problem ;-) If the label space becomes too fragmented, I guess one can always reorganize it, assuming one doesn't mind losing all one's connections in the meantime. Kireeti> With BGP+LDP, the flow would be ... We can cut this a bit short. If you assume that the only information that EVER needs to be communicated about a particular pseudowire is its label, then the protocol interactions at the startup transient are, as you indicate, well optimized in the all-BGP solution, which piggybacks the labels on the auto-discovery. But if there is any additional information about particular pseudowires that needs to be signaled, and if there is any signaling which needs to be done after auto-discovery has completed, the all-BGP solution is much less effective, particularly once the startup transient is over. (Note that in L3VPN, the discovery is really piggybacked on the route distribution, rather than vice versa.) We haven't even yet raised the issue of whether it is beneficial to have a single signaling protocol which can be used for VPLS, VPWS, individual P2P pseudowires, etc. IMHO, given the need to have LDP/L2TP solutions, a BGP solution would have to be extremely superior in order to be worth it. Kireeti> The one issue was that for IP VPNs, a single label per site Kireeti> suffices; for VPLS, you need several. Oh, the "one issue" again. The real difference with respect to the number of labels is that in IP VPNs, the labels are "per route", while in VPLS they are "per pair of PEs" (and in VPWS they are "per pair of attachment circuits"). Naturally, it makes sense to use a routing protocol to distribute per-route labels. To distribute "per pair of something" labels you'd tend to look to a "per pair of something" protocol. Kireeti> To give credit where credit is due, the idea of using BGP for both Kireeti> auto-discovery and signaling came from RFC 2547. Well, they say that imitation is the sincerest form of flattery, but in this case I'm not so sure ;-) From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 14:10:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21212 for ; Fri, 18 Apr 2003 14:10:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IICsi20103 for ; Fri, 18 Apr 2003 14:12:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IICp509605 for ; Fri, 18 Apr 2003 14:12:52 -0400 (EDT) Message-Id: <5.2.0.9.2.20030418140248.0498fc10@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 18 Apr 2003 14:09:19 -0400 To: erosen@cisco.com, Kireeti Kompella From: "Thomas D. Nadeau" Subject: Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt Cc: Mourad BERKANE , "" In-Reply-To: <200304181743.h3IHhSB0024781@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Just one thing to add inline. No ad hominems from me I assure you. 8) >Eric> Suppose that 100 PEs participate in a particular VPLS, and suppose >Eric> that PE17 has some information to signal to PE43.x > >Eric> With point-to-point signaling, PE17 sends a message to PE43, PE43 >Eric> replies (if necessary), and we're done. > >Kireeti> Sure. N*(N-1) is small when N = 2. > >I think you missed the first sentence above. > >Kireeti> Excuse me, but are you not an author of rfc2547bis and >Kireeti> draft-ietf-ppvpn-bgpvpn-auto-03.txt? > >Yes, indeed. > >Kireeti> In both of the above, you send 100 messages to all the PEs, even if >Kireeti> the only other member of the VPN is PE43. > >The case under discussion is where PE1, ..., PE100 are all members of the >VPN. In L3VPN, and in auto-discovery, there just isn't any possible case in >which PE17 has something to say only to PE43, because there are no >point-to-point connections. In L2VPN, which is built on top of >point-to-point connections, it becomes possible to use the control plane to >talk about individual point-to-point connections. In VPWS, one has to do a >fair amount of this, in VPLS less. The issue is whether BGP is a good way >to do this, and whether there is enough of this to matter. > >It's not necessarily true that in either L3VPN or L2VPN, information is ever >sent to all PEs; techniques like ORF can be used to limit the distribution >to only those PEs which belong to the particular VPN or VPLS. What there is >no way to do is to limit the distribution of information further. In L3VPN, >there is no reason to do that, but in L2VPN there is. > >Kireeti> As for the "label block hack", sure, call it a hack, that should >Kireeti> scare people away -- argumentum ad hominem always works. > >No, "ad hominem" would be if I called you a hacker; the worst you can accuse >me of is "name calling" ;-) But I think it's fair to call it a hack because >it imposes constraints on the label assignment methodology that depart from >the MPLS architecture, and the reason for imposing those constraints is to >make a particular sort of solution (BGP-based L2VPN signaling) possible. >It's quite a clever hack, actually, but that's not the same as being a good >idea. > >Kireeti> As for "wasting" labels, it amazes me that a vendor that allocates >Kireeti> individual labels for each IP VPN prefix from the same PE keeps >Kireeti> harping on this. > >Speaking of ad hominems ... > >It seems to me there are two cases: > >1. If one thinks of labels as a scarce resource which must be carefully > used, one certainly doesn't want to waste labels. > >2. If one uses labels quite freely, one doesn't want to find out that one > has run out of them because some have to be kept unused. > >So I don't see how wasting labels can be justified. > >Kireeti> Efficient block allocation is a solved problem. Ask anyone who >Kireeti> does memory management, > >That must be why memory fragmentation is so rarely a problem ;-) If the >label space becomes too fragmented, I guess one can always reorganize it, >assuming one doesn't mind losing all one's connections in the meantime. > >Kireeti> With BGP+LDP, the flow would be ... > >We can cut this a bit short. If you assume that the only information that >EVER needs to be communicated about a particular pseudowire is its label, >then the protocol interactions at the startup transient are, as you >indicate, well optimized in the all-BGP solution, which piggybacks the >labels on the auto-discovery. But if there is any additional information >about particular pseudowires that needs to be signaled, and if there is any >signaling which needs to be done after auto-discovery has completed, the >all-BGP solution is much less effective, particularly once the startup >transient is over. > >(Note that in L3VPN, the discovery is really piggybacked on the route >distribution, rather than vice versa.) Eric raises a good point. In the case of pseudo-wires, it is often important to send information related to the PW after it has been signaled. Take the case of periodic OAM information that must be passed between end points of the PW. It may be necessary depending on how this is configured, to pass this information often enough to make it interesting in terms of the number of messages send p2p. However, when multipled by the number of PE sites that a BGP-based solution would have to repeat these messages uselessly to, this seems like an issue. Even in the case of non-periodic OAM information as described in draft-shah-pwe3-control-protocol-extension, I don't see why the fact that the status of one PW changing should necessarily bother every other PE in the VPLS. --Tom http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 14:30: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 OAA21746 for ; Fri, 18 Apr 2003 14:30:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IIWmi24661 for ; Fri, 18 Apr 2003 14:32:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IIWj522063 for ; Fri, 18 Apr 2003 14:32:45 -0400 (EDT) Date: Fri, 18 Apr 2003 13:26:30 -0500 From: "Christopher N. \"Nick\" DelRegno" Subject: draft-kompella-ppvpn-vpls-01.txt To: ppvpn@nortelnetworks.com, "'Rick Wilder'" , "Marco Carugi" Message-id: <00af01c305d8$0b227bf0$2d7a32a6@maggot> Organization: WorldCom, Global Access Technology Development MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_cIGgRiumuZrnR8E4JTMQuQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: dgesmtp02.wcom.com X-SMTP-MAIL-FROM: Nick.DelRegno@mci.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dgesmtp02.wcom.com [199.249.16.17] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_cIGgRiumuZrnR8E4JTMQuQ) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Rick/Marco: I support "draft-kompella-ppvpn-vpls-01.txt" becoming a working group draft. As 2547 VPNs have been successful for many service providers, it seems unreasonable to dismiss a similar approach for L2 VPNs without further study because there is another way to do it. Draft-kompella would allow service providers to leverage existing RFC2547 networks to provide L2 VPNs as well. Both "draft-kompella-ppvpn-vpls-01.txt" and "draft-lasserre-vkompella-ppvpn-vpls-04.txt" have merit and should be brought into the working group and worked. Thanks, Nick DelRegno --Boundary_(ID_cIGgRiumuZrnR8E4JTMQuQ) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Rick/Marco:

 

I support “draft-kompella-ppvpn-vpls-01.txt” = becoming a working group draft.

 

As 2547 VPNs have been successful for many service providers, it = seems unreasonable to dismiss a similar approach for L2 VPNs without further = study because there is another way to do it.  Draft-kompella would allow = service providers to leverage existing RFC2547 networks to provide L2 VPNs as = well.  Both “draft-kompella-ppvpn-vpls-01.txt” and = “draft-lasserre-vkompella-ppvpn-vpls-04.txt” have merit and should be brought into the working group and = worked.

 

Thanks,

Nick DelRegno

--Boundary_(ID_cIGgRiumuZrnR8E4JTMQuQ)-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 15:35:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24671 for ; Fri, 18 Apr 2003 15:35:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IJNpi13113 for ; Fri, 18 Apr 2003 15:23:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IJNl516885 for ; Fri, 18 Apr 2003 15:23:47 -0400 (EDT) Message-Id: <5.2.0.9.2.20030418151119.0499a9b0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 18 Apr 2003 15:19:32 -0400 To: "Christopher N. \"Nick\" DelRegno" , ppvpn@nortelnetworks.com, "'Rick Wilder'" , "Marco Carugi" From: "Thomas D. Nadeau" Subject: Re: draft-kompella-ppvpn-vpls-01.txt In-Reply-To: <00af01c305d8$0b227bf0$2d7a32a6@maggot> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: At 01:26 PM 4/18/2003 -0500, Christopher N. \"Nick\" DelRegno wrote: >Rick/Marco: > > > >I support draft-kompella-ppvpn-vpls-01.txtbecoming a working group draft. > > > >As 2547 VPNs have been successful for many service providers, it seems >unreasonable to dismiss a similar approach for L2 VPNs without further >study because there is another way to do it. Draft-kompella would allow >service providers to leverage existing RFC2547 networks to provide L2 VPNs >as well. Both draft-kompella-ppvpn-vpls-01.txtand >draft-lasserre-vkompella-ppvpn-vpls-04.txthave merit and should be brought >into the working group and worked. Nick, there is a big difference between investigation and the WG actually agreeing to work on something. Individual drafts are appropriate containers for the former, but once the WG has adopted a draft it means that it is something that we endorse (and probably will eventually ask to move to proposed standard). Although I would agree with you that there seems to be evidence that people want to at least investigate the K.Kompella approach, there seem to be architectural issues related to this approach that merit more investigation before moving forward. --Tom http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 15:39:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24779 for ; Fri, 18 Apr 2003 15:39:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IJfqi17096 for ; Fri, 18 Apr 2003 15:41:52 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IJfm527762 for ; Fri, 18 Apr 2003 15:41:49 -0400 (EDT) Message-Id: <3EA054DC.AB14C762@francetelecom.com> Date: Fri, 18 Apr 2003 15:41:16 -0400 From: "LIAN Franklin FTLD/IAP" Organization: France Telecom Long Distance X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf To: DECRAENE Bruno FTR CC: ppvpn@lyris.nortelnetworks.com, "FONDEVIOLE Benoit FTRD/DAC" , "JACQUET David FTRD/DAC" Subject: Re: draft-kompella-ppvpn-vpls-01.txt References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-SMTP-HELO: relais-inet-04.francetelecom.fr X-SMTP-MAIL-FROM: franklin.lian@francetelecom.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: relais-inet.francetelecom.com [212.234.67.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ietf.org id PAA24779 FTRLD is the IP service division of France Telecom, we would like to echo our colleagues' support to draft-kompella-ppvpn-vpls-01.txt, making this a working group draft. Best regards, Zidan Lian DECRAENE Bruno FTR wrote: > > We would like to support draft-kompella-ppvpn-vpls-01.txt, making this a working group draft. > > Regarding management, the less work, the better. > - Using one -well known- protocol (MP-BGP) for discovery and signalling is easier to manage than two protocols (LDP + MP-BGP/RADIUS/DNS/?) > - BGP RR greatly reduces the number of sessions to monitor: o(N) vs o(N*N) > - With the large scale deployment of 2547 VPN, we gained valuable experience with MP-BGP (managing, scaling,...). Seems fine to re-use it. > > As Rahul said, both drafts are interesting for various SP/customers. It would be better if -at least- the data plane description were the same. > > Regards, > > Benoît, David, Bruno > > > -----Original Message----- > > From: Rahul Aggarwal [mailto:rahul@redback.com] > > Sent: Monday, April 14, 2003 4:35 PM > > To: ppvpn@nortelnetworks.com > > Subject: Regarding progressing VPLS docs > > > > > > > > Hi Marco and Rick, > > > > I would like to add my support for making both: > > > > draft-lasserre-vkompella-ppvpn-vpls-04.txt > > draft-kompella-ppvpn-vpls-01.txt > > > > as WG docs with the caveat that the common parts should not be > > repeated. draft-lasserre may be a good place to keep the common > > portion. In particular the data plane description that is > > common to these > > specs can be left in draft-lasserre and pulled out of draft-kompella. > > > > Its possible to have a never ending discussion on the pros and cons of > > each. The bottomline is that LDP signaling + protocol X > > auto-discovery or > > BGP signaling + BGP auto-discovery, both have their own > > applicability. If > > down the road we figure out that one of these solutions doesn't have > > deployment traction, the respective doc doesn't have to be > > moved to RFC > > status. > > > > Thanks, > > rahul > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 16:32: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 QAA26061 for ; Fri, 18 Apr 2003 16:32:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IKYUi05123 for ; Fri, 18 Apr 2003 16:34:30 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IKYR512563 for ; Fri, 18 Apr 2003 16:34:27 -0400 (EDT) Date: Fri, 18 Apr 2003 15:30:14 -0500 From: "Christopher N. \"Nick\" DelRegno" Subject: RE: draft-kompella-ppvpn-vpls-01.txt In-reply-to: <5.2.0.9.2.20030418151119.0499a9b0@bucket.cisco.com> To: "'Thomas D. Nadeau'" , "'Christopher N. \"Nick\" DelRegno'" , ppvpn@nortelnetworks.com, "'Rick Wilder'" , "Marco Carugi" Message-id: <00d201c305e9$51c2ddf0$2d7a32a6@maggot> Organization: WorldCom, Global Access Technology Development MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: dgesmtp02.wcom.com X-SMTP-MAIL-FROM: Nick.DelRegno@mci.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dgesmtp02.wcom.com [199.249.16.17] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Tom: While I am aware of the IETF standards process, it never hurts to reiterate it. I certainly hope that we can consider moving both toward an endorsement. I see merit in both VPLS approaches, especially in a phased approach where at one stage (or network size) one approach makes more sense than the other. I don't see these drafts competing as much as others seem to. We have tested implementations of both drafts and can see uses for them both. My concern is that if these drafts are seen as directly competing, once we take Lasserre-VKompella into the working group, the KKompella draft will be that much more difficult to take to proposed standard. It is important to me that we better understand the implications of BGP vs BGP+LDP, as has already been mentioned on the list. I believe that neither draft is error-free or done, and both have unanswered architectural questions. Regards, Nick Christopher N. "Nick" DelRegno, Advisory Engineer MCI, Global Access Technology Development 400 International Pkwy, 1010/041 Richardson, TX 75081-2886 Tel: 972-729-3411 Fax: 972-729-3249 Email: Nick.DelRegno@mci.com Pager: pagenick@delregno.com -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, April 18, 2003 2:20 PM To: Christopher N. "Nick" DelRegno; ppvpn@nortelnetworks.com; 'Rick Wilder'; Marco Carugi Subject: Re: draft-kompella-ppvpn-vpls-01.txt At 01:26 PM 4/18/2003 -0500, Christopher N. \"Nick\" DelRegno wrote: >Rick/Marco: > > > >I support draft-kompella-ppvpn-vpls-01.txtbecoming a working group draft. > > > >As 2547 VPNs have been successful for many service providers, it seems >unreasonable to dismiss a similar approach for L2 VPNs without further >study because there is another way to do it. Draft-kompella would allow >service providers to leverage existing RFC2547 networks to provide L2 VPNs >as well. Both draft-kompella-ppvpn-vpls-01.txtand >draft-lasserre-vkompella-ppvpn-vpls-04.txthave merit and should be brought >into the working group and worked. Nick, there is a big difference between investigation and the WG actually agreeing to work on something. Individual drafts are appropriate containers for the former, but once the WG has adopted a draft it means that it is something that we endorse (and probably will eventually ask to move to proposed standard). Although I would agree with you that there seems to be evidence that people want to at least investigate the K.Kompella approach, there seem to be architectural issues related to this approach that merit more investigation before moving forward. --Tom http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751 X From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 18:11:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29033 for ; Fri, 18 Apr 2003 18:11:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IMDIi16645 for ; Fri, 18 Apr 2003 18:13:18 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3IMDE502537 for ; Fri, 18 Apr 2003 18:13:14 -0400 (EDT) Date: Fri, 18 Apr 2003 15:10:21 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <162229867692.20030418151021@psg.com> To: "LIAN Franklin FTLD/IAP" CC: DECRAENE Bruno FTR , ppvpn@lyris.nortelnetworks.com, "FONDEVIOLE Benoit FTRD/DAC" , "JACQUET David FTRD/DAC" Subject: Re: draft-kompella-ppvpn-vpls-01.txt In-Reply-To: <3EA054DC.AB14C762@francetelecom.com> References: <3EA054DC.AB14C762@francetelecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Zidan- The IETF does not recognize companies, especially when consensus is being gauged within a WG. You should express your *personal* and *technical* opinion. Cheers. -- Alex http://www.psg.com/~zinin/ Friday, April 18, 2003, 12:41:16 PM, LIAN Franklin FTLD/IAP wrote: > FTRLD is the IP service division of France Telecom, we would like to > echo our colleagues' support to draft-kompella-ppvpn-vpls-01.txt, > making this a working group draft. > Best regards, > Zidan Lian From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 19:46:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01206 for ; Fri, 18 Apr 2003 19:46:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3INmvi26236 for ; Fri, 18 Apr 2003 19:48:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3INms501423 for ; Fri, 18 Apr 2003 19:48:54 -0400 (EDT) Message-ID: <3EA08E50.7011B94@cisco.com> Date: Fri, 18 Apr 2003 16:46:24 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Muneyoshi Suzuki CC: ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <20030416.104110.71147346.suzuki.muneyoshi@lab.ntt.co.jp> <3E9F3E72.117D5369@cisco.com> <20030418.162712.41696376.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, Thank you for bringing up the subject. It needs more attention. This (long) message is an attempt to give it some. :) The requirement that a full mesh must meet is that you never have partial connectivity for more than a brief period of time. Otherwise, the mesh is not suitable to server as part of a network that carries bridged traffic, including the various 802.1D Layer 2 control protocols such as spanning tree BPDUs. I will note, as an aside, that in general, a full mesh may be carrying Customers' BPDUs, a Provider's BPDUs, or both. The requirements are the same, in any case. Following the requirements terminology, let's call the full mesh an emulated LAN, and the module inside a box that passes the data between the pseudowires and the emulated port the Forwarding Function. The bridge sits above the emulated port. One additional concept is required. The emulated port which the FF provides the upper layers has certain characteristics, among them an ifOperState, which is either UP or DOWN. One would assume that, upon initialization, the FF would be ifOperState == DOWN to the upper layers until it had obtained (through discovery) its list of other FFs and had established its pseudowires. At that point, it would change its state to ifOperState == UP, which would trigger the bridge above it to start normal operations. This would typically involve transmitting BPDUs and waiting to see if any other bridges were also transmitting BPDUs, before it starts to send and receive data. This is all part of the standard way that bridges prevent loops; 802.1D specifies exactly what a bridge must do when a link's ifOperState goes UP or DOWN. Now, the rules: 1. Every Forwarding Function has a list of the other FFs it thinks belong to its emulated LAN. This list is obtained through the discovery process. 2. Similarly, every Forwarding Function has a list of the FFs with which it has established functional pseudowires. This may involve control-layer (not Ethernet data layer!) pings. 3. The Forwarding Function, of course, signals, accepts, and/or deletes pseudowires as needed to make the two lists match. 4. Unless or until an FF has a pseudowire up and running to every member of its list, it must present ifOperState == DOWN to its upper layers. That is, any time that an FF's list of established pseudowires does not match its list of emulated LAN participants, it must stay ifOperState == DOWN. When one or both of the lists has changed so that they match, again, the FF may present ifOperState == UP. (There may be other constraints on ifOperState as well, for example, the ifAdminState control.) Of course, data may flow through an emulated LAN port in either direction only when ifOperState == UP. The above rules mean, in in essence, that an FF doesn't pass data unless it thinks that it has a full mesh established. Furthermore, it signals the bridge via ifOperState whenever the state of the full mesh changes. This guarantees that the bridge running over the full mesh will work properly. It is particularly important to note that this "do not send or receive unless all links are up" rule is *not* imposed on the individual pseudowires, but on the emulated LAN port! The emulated ifOperState must not interfere with establishing a pseudowire and verifying that it works. Also, one FF does *not* know whether another FF to which it has established a pseudowire is or is not passing data up or down its stack. Without this decoupling, one gets into a horrible tangle of intention vs. reality and race conditions. With this set of rules, an emulated LAN matches the semantics of a fat yellow coax, or of a set of hubbed Ethernet segments. In fact, it works better than a physical medium! This set of rules fixes a problem of shared media: connecting a new device may cause a temporary loop, and consequent broadcast storm. Since all FFs do a down-then- up transition of ifOperState when a new FF joins or an old one leaves, the unsignaled joins and leaves which cause temporary loops cannot occur. In my earlier e-mail, I claimed that a full mesh must be able to guarantee that it will either heal itself within a specified period of time, or must notify the upper layers (bridges, in this case) of the failure. With the formulation above, we may restate this constraint in a manner that one may believe can be met: Whenever the set M of FFs belonging to a full mesh changes, all FFs belonging to M after the change must be reliably notified of the change within time T. (Where "reliably" means "often enough that I can put up with the consequences when it fails".) I'm sure I can optimize this further, so that most connectivity transitions may go unsignaled in most FFs. This would improve the connectivity of the network without compromising its integrity. In particular, when an FF dies or leaves, there is no requirement to immediately tell everyone, or to make them transition ifOperState. But the essential point is that I'm pretty sure that it is possible to make the full mesh compatible with bridging. The task for 802.1AD will be to ensure that a similar guarantee can be offered to the Customer whose spanning tree is running over a network of Provider Bridges, given that the full mesh at the core of the Provider Bridge network can notify the Provider Bridges of its state. -- Norm Muneyoshi Suzuki wrote: > > > One of the goals of the L2-VPN effort must be, in my opinion, to > > specify how full meshes can be guaranteed to meet the sub-second > > restoration requirement, or at the very least, to define what guarantees > > meshes can meet. > > My point is the network behavior when the link protection is unsuccessful. > If the SP network consists of Bridges and point-to-point links running > STP, there is no significant issues. However, if the SP use full-mesh > split-horizon scheme, customers may encounter loop or black hole. > > > Alternatively, a mechanism must be provided to signal > > failures of the full mesh in such a way that all of the connected > > Provider Bridges know that the link has failed, and avoid it until it > > can be re-established. > > I'm not sure the above sachem. Do you mean if one of path in the mesh > fails, the Provider Bridges blocks *all* the paths connected to the > Bridge until the path recovery? I agree this is one of solutions, but > don't think it is realistic. > > Thanks, > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 21:05:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03251 for ; Fri, 18 Apr 2003 21:05:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3J17ji05353 for ; Fri, 18 Apr 2003 21:07:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3J17g529397 for ; Fri, 18 Apr 2003 21:07:42 -0400 (EDT) Date: Sat, 19 Apr 2003 00:03:40 GMT From: customprintgoods@netscape.net X-Priority: 3 To: ppvpn@nortelnetworks.com Subject: Giant Posters made from YOUR images - just $7.00 a square foot Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-SMTP-HELO: southerneagle.com X-SMTP-MAIL-FROM: customprintgoods@netscape.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [63.91.121.73] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit GIANT SIZED POSTERS made from YOUR IMAGES!
GIANT SIZED POSTERS made from YOUR IMAGES!
Send us Any Picture or Drawing or Artwork - We'll make your Poster for $7.00 a square foot
22" x 28" poster for $30.00
Free Shipping for Orders Over $80.00
shipped in 2-3 days
(rolled in a protective mailing tube)

Minimum Order: $30.00
Shipping: $5.50
JUST EMAIL YOUR SCANNED IMAGES OR ART AND WE'LL MAIL YOUR POSTER IN 2-3 DAYS!

° Family Pictures Can Become Attention Getting Wall Art
° Large Sized Graphic Exhibits
° Upscale Signage
° Special Memories
° Memorable Humorous Moments

20" x 25" - $ 24.50 24" x 30" - $ 35.00
20" x 28" - $ 27.50 29" x 32" - $ 45.00
22" x 28" - $ 30.00 54" x 96" - $252.00
DISCOUNTS
(for min. size of 3 sq. ft.)
5 posters = $6.00 per square foot
10 posters = $5.50 per square foot
20 posters up = $5.00 per square foot

Convert your favorite:
*Action Pictures
*Team Picture
*Class Picture
*Any Picture
To a GIANT POSTER SIZED PRINT!
FROM THIS
IF IMAGE FAILS TO LOAD, PLEASE LET US KNOW		 TO THIS (or BIGGER!)
IF IMAGE FAILS TO LOAD, PLEASE LET US KNOW

WHAT TO DO:
We are a family owned business operating in Memphis, Tennessee for over 29 years.
Please contact us via email:
PersonalizedColors@excite.com
or call Toll Free: 1-877-503-7415
to place an order or get additional information.

SIGNATURES
GIANT SIZED POSTERS * CORPORATE APPAREL * SIGNS & BANNERS * PROMOTIONAL PRODUCTS * TROPHIES & AWARDS
559 S. Highland Street * Memphis, TN 38111
901-327-5456

Toll Free: 1-877-503-7415

We are a family owned business operating in Memphis, Tennessee for over 29 years.

 

 

We honor the removal requests that we receive.
To be removed from future mailings, please email us at: NoMailHere@excite.com with the email address you want removed in the Subject Line of your email. Our system checks the subject line for email addresses and will remove those addresses from our database.
We apologize for any inconvenience.

From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 18 22:30: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 WAA04668 for ; Fri, 18 Apr 2003 22:30:38 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3J2Wli13771 for ; Fri, 18 Apr 2003 22:32:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3J2Wi516014 for ; Fri, 18 Apr 2003 22:32:45 -0400 (EDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 18 Apr 2003 19:30:33 -0700 (PDT) From: Kireeti Kompella To: Alex Zinin cc: ppvpn@lyris.nortelnetworks.com Subject: Re: draft-kompella-ppvpn-vpls-01.txt In-Reply-To: <162229867692.20030418151021@psg.com> Message-ID: <20030418191910.Q60918@kummer.juniper.net> References: <3EA054DC.AB14C762@francetelecom.com> <162229867692.20030418151021@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hi Alex, On Fri, 18 Apr 2003, Alex Zinin wrote: > Zidan- > > The IETF does not recognize companies, especially when consensus is > being gauged within a WG. You should express your *personal* and > *technical* opinion. Is it okay to mention one's affiliation, so that others can see whether this opinion comes from a vendor or a provider? Also, as far as I can judge, a hum or a raised hand or an email that "we'd like to support this draft" are all equally technical. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 19 02:02:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09565 for ; Sat, 19 Apr 2003 02:02:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3J64Mi10872 for ; Sat, 19 Apr 2003 02:04:22 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3J64GM26187 for ; Sat, 19 Apr 2003 02:04:16 -0400 (EDT) Message-Id: <5.1.0.14.2.20030419075726.00ab0008@mail.nodalis.it> Date: Sat, 19 Apr 2003 07:59:44 +0200 To: ppvpn@nortelnetworks.com From: Luca Nannipieri Subject: draft-kompella-ppvpn-vpls-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sit2.nodalis.it X-SMTP-MAIL-FROM: lnannipieri@nodalis.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp2.nodalis.it [213.188.192.68] X-LYRIS-Message-Id: We would like to support draft-kompella-ppvpn-vpls-01.txt. Ing. Luca Nannipieri Nodalis Telecomunicazioni www.nodalis.it From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 00:52:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23279 for ; Mon, 21 Apr 2003 00:52:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3L4sm400021 for ; Mon, 21 Apr 2003 00:54:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3L4sj413037 for ; Mon, 21 Apr 2003 00:54:45 -0400 (EDT) Date: Mon, 21 Apr 2003 13:48:00 +0900 (JST) Message-Id: <20030421.134800.63057419.suzuki.muneyoshi@lab.ntt.co.jp> To: nfinn@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <3EA08E50.7011B94@cisco.com> References: <3E9F3E72.117D5369@cisco.com> <20030418.162712.41696376.suzuki.muneyoshi@lab.ntt.co.jp> <3EA08E50.7011B94@cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Norm, > One additional concept is required. The emulated port which the FF > provides the upper layers has certain characteristics, among > them an ifOperState, which is either UP or DOWN. This deeply depends on physical link characteristic such as full-duplex, half-duplex bi-directional, and uni-directional. Especially, in an uni-directional link such as LSP, it is difficult to timely notify a failure from receiver side to sender side, because reverse path may not available. > Of course, data may flow through an emulated LAN port in either > direction only when ifOperState == UP. The above rules mean, in > in essence, that an FF doesn't pass data unless it thinks that it > has a full mesh established. I understand your proposal is if an LSP between two PE fails, block all LSPs connecting to these PEs. Is it wise to use links as serial system? Here, we assume N as number of PEs, and R as reliability of a single LSP. In this case, reliability of a single PE in the proposal is: R ^ {2*(N -1)}. Obviously, it is ruinous under large N. I think there is a much simple and robust solution. Connect Provider Bridges with point-to-point LSPs and use STP/RSTP in the network, and don't use split-horizon scheme. Needless to say LSPs must be raw mode; tagged mode violates the standard. In this case, if PEs are connected with full mesh LSPs, reliability of a single PE is: 1- {(1- R^2) ^ (N -1)}. Obviously, this is a robust solution because it use LSPs as parallel system. Furthermore, this does not need to revise the existing standards, it only needs Q-in-Q or MAC-in-MAC specification in 802.1ad. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 03:55:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07326 for ; Mon, 21 Apr 2003 03:55:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3L7ve413584 for ; Mon, 21 Apr 2003 03:57:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3L7va403081 for ; Mon, 21 Apr 2003 03:57:37 -0400 (EDT) Message-ID: <020a01c307db$31c174a0$31726051@c2f4r3> Reply-To: "Brian Powell" From: "Brian Powell" To: "MVNO world" Subject: Laptop Nomads - New from MVNOinfo.com Date: Mon, 21 Apr 2003 08:54:03 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0206_01C307E3.8F446260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SMTP-HELO: mta03-svc.ntlworld.com X-SMTP-MAIL-FROM: bpowell@arran.prestel.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mta03-svc.ntlworld.com [62.253.162.43] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0206_01C307E3.8F446260 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0207_01C307E3.8F446260" ------=_NextPart_001_0207_01C307E3.8F446260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageNew From MVNOinfo.com =20 =20 NEWS: As well as the MVNO market, we are now also focussing on global = activity in the Wi-Fi arena - one of the 'hottest' new area's to hit the = world of communications since the emergence of MVNOs in 1999. As an = introduction, we have attached a 1-page article for you to read = entitled: "Laptop Nomads" (or - the search for seated mobile computing). = In this article you will also find out how to get a free copy of our new = monthly bulletin: "What's Going on in The World of Wi-Fi (April 2003)". NEW: MVNOinfo.com Community Section. Regular visitors to the site will = notice that we have now revamped it and added a new FREE Community = Section which includes a message board for you to pose questions to = Brian Powell (author of our MVNO reports) as well as the community press = releases, a new area to post your own articles and a free white paper = section. To access the community and its options, you will need to = register once by visiting www.mvnoinfo.com and clicking on "Community". = By becoming a member, you will also be able to post your own white = papers and press releases if they are MVNO or Wi-Fi related. We will be = adding more options to this section in due course to make this site a = truly useful MVNO resource for you all.=20 To start the community section off, we have posted two FREE white papers = and one new article for you to read and download.=20 If you would also like your banner on this site in front of an MVNO and = Wi-Fi specific audience, we are now ready to establish reciprocal links = with MVNO & Wi-Fi companies - so visit the banners page (click on "about = us") for all the relevant info and then get in touch through = www.mvnoinfo.com . Make sure you continue to visit us regularly as more = updates will be posted in the near future. COMING SOON: MVNO Global Association (MVNO-GA) You may be interested to = hear that MVNOinfo.com is laying the foundations for an MVNO Global = Association (MVNO-GA), which will be a 'membership-only', = 'not-for-profit' association focused on the opportunities and = developments in the MVNO and Wi-Fi markets. =20 We will seek to garner membership from a broad spectrum of companies and = individuals in the communications industry and from vendors that service = the communications industry too. Members will be able to gain industry = exposure through the MVNO-GA area of our web site and potentially = benefit from sales lead introductions through MVNO-GA. Please visit: = www.mvnoinfo.com regularly to get launch details (expected early May = 2003). =20 Best wishes MVNOinfo.com www.mvnoinfo.com=20 =20 -------------------------------------------------------------------------= -------------------------------------------------------------------------= ---------------------- 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. =20 ------=_NextPart_001_0207_01C307E3.8F446260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
New From=20 MVNOinfo.com
 
 
NEWS:  As well as=20 the MVNO market, we are now also focussing on global activity in the = Wi-Fi arena=20 - one of the 'hottest' new area's to = hit the=20 world of communications since the emergence of MVNOs in 1999. As an=20 introduction, we have attached a 1-page article for you to read=20 entitled: "Laptop Nomads"=20 (or=20 - the search for seated mobile computing). = In this=20 article you will also find out how to get a free copy of our new = monthly=20 bulletin: "What's Going on in The World of = Wi-Fi (April=20 2003)".
 
 
NEW:  MVNOinfo.com Community = Section. Regular visitors to the site will notice that we have = now revamped=20 it and added a new FREE Community Section which includes a message = board=20 for you to pose questions to Brian Powell (author of our MVNO = reports) as=20 well as the community press releases, a new area to post your own = articles=20 and a free white paper section. To access the community and its options, = you=20 will need to register once by visiting www.mvnoinfo.com and clicking=20 on "Community". By becoming a member, you will also be able to post your = own=20 white papers and press releases if they are MVNO or Wi-Fi = related. We will=20 be adding more options to this section in due course to make = this site=20 a truly useful MVNO resource for you all.=20

To start the community = section off, we=20 have posted two FREE white papers and one new article for you to read = and=20 download.

If you = would also like your=20 banner on this site in front of an MVNO and Wi-Fi specific audience, = we are=20 now ready to establish reciprocal links with MVNO & Wi-Fi=20 companies - so visit the banners page (click on "about us") for all = the=20 relevant info and then get in touch through www.mvnoinfo.com . Make = sure=20 you continue to visit us regularly as more updates will be = posted in=20 the near future.

 
COMING=20 SOON: MVNO=20 Global Association (MVNO-GA) You=20 may be interested to hear that MVNOinfo.com is=20 laying the foundations for an MVNO Global Association (MVNO-GA), which = will be a=20 'membership-only', 'not-for-profit' association focused on the=20 opportunities and developments in the MVNO and Wi-Fi = markets.
 
We will seek to garner=20 membership from a broad spectrum of companies and individuals in = the=20 communications industry and from vendors that service the communications = industry too. Members will be = able=20 to gain industry exposure through the MVNO-GA area of our = web=20 site and potentially benefit from sales = lead=20 introductions through MVNO-GA. Please visit: www.mvnoinfo.com regularly to = get launch=20 details (expected early May 2003).
 
 
Best=20 wishes
MVNOinfo.com
www.mvnoinfo.com=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_001_0207_01C307E3.8F446260-- ------=_NextPart_000_0206_01C307E3.8F446260 Content-Type: application/msword; name="Laptop Nomads_Article.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Laptop Nomads_Article.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMQAAAAAAAAAA EAAAMwAAAAEAAAD+////AAAAADAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWQAJCAAACBK/AAAAAAAAEAAAAAAABAAAghUAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA AAAJBBYALB4AAJE9AQCRPQEAghEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAIQBAAAAAAAAhAEAAIQB AAAAAAAAhAEAAAAAAACEAQAAAAAAAIQBAAAAAAAAhAEAABQAAAAAAAAAAAAAAJgBAAAAAAAAmAEA AAAAAACYAQAAAAAAAJgBAAAAAAAAmAEAAAwAAACkAQAAFAAAAJgBAAAAAAAAmAoAALYAAADEAQAA FgAAANoBAAAAAAAA2gEAAAAAAADaAQAAAAAAANoBAAAAAAAA2gEAAAAAAADaAQAAAAAAANoBAAAA AAAALAcAAAIAAAAuBwAAAAAAAC4HAAAAAAAALgcAAD0AAABrBwAAegEAAOUIAAB6AQAAXwoAACQA AABOCwAA9AEAAEINAABsAAAAgwoAABUAAAAAAAAAAAAAAAAAAAAAAAAAhAEAAAAAAADaAQAAAAAA AAAAAAAAAAAAAAAAAAAAAADaAQAAAAAAANoBAAAAAAAA2gEAAAAAAADaAQAAAAAAAIMKAAAAAAAA ZgIAAAAAAACEAQAAAAAAAIQBAAAAAAAA2gEAAAAAAAAAAAAAAAAAANoBAAAAAAAAxAEAAAAAAABm AgAAAAAAAGYCAAAAAAAAZgIAAAAAAADaAQAAUgAAAIQBAAAAAAAA2gEAAAAAAACEAQAAAAAAANoB AAAAAAAALAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmAEAAAAAAACYAQAAAAAAAIQBAAAAAAAAhAEA AAAAAACEAQAAAAAAAIQBAAAAAAAA2gEAAAAAAAAsBwAAAAAAAGYCAADGBAAAZgIAAAAAAAAAAAAA AAAAACwHAAAAAAAAhAEAAAAAAACEAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAcAAAAAAADaAQAAAAAAALgBAAAMAAAAgMGWFNkG wwGYAQAAAAAAAJgBAAAAAAAALAIAADoAAAAsBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ0N DUxhcHRvcCBOb21hZHMNKG9yIC0gInRoZSBzZWFyY2ggZm9yIHNlYXRlZCBtb2JpbGUgY29tcHV0 aW5nIikNDQ0NDUEgbmV3IGJyZWVkIG9mIGNvbW11bmljYXRpb25zIHVzZXIgbm93IHBlcnZhZGVz IHRoZSB0ZWxlY29tcyBsYW5kc2NhcGUgLSANVGhlICJMYXB0b3AgTm9tYWQiDQ0NRGlmZmVyZW50 aWF0ZWQgZnJvbSBhbGwgb3RoZXIgdHlwZXMgb2YgdXNlciwgdGhlIExhcHRvcCBOb21hZCBoYXMg YW4gaW5zYXRpYWJsZSBkZXNpcmUgdG8gc29hayB1cCBhcyBtdWNoIHJhZGlvIGZyZXF1ZW5jeSBh cyBwb3NzaWJsZSBpbiBsb2NhdGlvbnMga25vd24gYXMgJ0xBTiBIb3RzcG90cycgb3IgJ1dpLUZp IExvdW5nZXMnLiBUaGUgTGFwdG9wIE5vbWFkIGlzIG5ldmVyIChpZiBldmVyIHJhcmVseSkgc2Vl biBpbiBJbnRlcm5ldCBDYWbpcyBvciBzaXR0aW5nIGF0IGFuIG9mZmljZSBkZXNrLCB3aGV0aGVy IGluIGEgY29tcGFueSBwcmVtaXNlcyBvciBhIGhvbWUgdGVsZS1vZmZpY2UuIA0gDVllcyAtIHRo aXMgaXMgYSB2ZXJ5IGRpZmZlcmVudCB0eXBlIG9mIHVzZXIgLSBhbmQgb25lIHdoaWNoIGlzIGRl c3BlcmF0ZWx5IHN0YXJ2ZWQgb2YgcmlnaHQga2luZCBvZiBjb21tdW5pY2F0aW9ucyBmYWNpbGl0 aWVzIG5lZWRlZCB0byBmZWVkIGhpcyBvYnNlc3NpdmUgZGVzaXJlIHRvIHBhcmsgaGlzIGJ1dHQg aW4gcHVibGljIHBsYWNlcyBhbmQgc3VyZiB0aGUgbmV0IG9yIGFjY2VzcyBoaXMgSVNQICB2aWEg YSBMYXB0b3AgUEMgb3Igb3RoZXIgcG9ydGFibGUgY29tcHV0aW5nIGRldmljZS4gWWVzIC0gdGhl IExhcHRvcCBOb21hZCBhbHdheXMgc2VlbXMgdG8gYmUgb24gYSBkZXNwZXJhdGUgbWlzc2lvbiB0 byBsb2NhdGUgJ3NlYXRlZCBtb2JpbGUgY29tcHV0aW5nIHNwYWNlJyAtIGJldHRlciBrbm93IHRv IG5vbi1ub21hZHMgYXMgTEFOIEhvdHNwb3RzLg0NVGhlIGNvbW11bmljYXRpb25zIGluZHVzdHJ5 IGhhcyBnb3QgdXNlZCB0byBzZXJ2aW5nIHRoZSBuZWVkcyBvZiBvdGhlciB1c2VyIHR5cGVzIGxp a2U6IFJvYWQgV2FycmlvcnMoMSksIEdsb2JhbCBIb3BwZXJzKDIpLCBUZWxld29ya2VycywgKDMp IERlc2sgU29sZGllcnMoNCksIGFuZCBPbi1zaXRlIFJvdmVycyg1KS4gV2hpbGUgbW9iaWxlIHRl bGVwaG9ueSBwcm92aWRlcyBhIHNvbHV0aW9uIGZvciByZWFsLXRpbWUgdm9pY2UgY29tbXVuaWNh dGlvbiwgdGhlcmUgaXMgbm93IGFuIGVtZXJnaW5nIG5lZWQgZm9yIJNhbnl3aGVyZSwgYW55dGlt ZZQgZGF0YSBjb21tdW5pY2F0aW9uLg0NT25lIG9mIHRoZSBiaWdnZXN0IHByb2JsZW1zIHRoZSBM YXB0b3AgTm9tYWQgZmFjZXMgaXMgJ3NpZ25hZ2UnLiBZZXMsIGl0IGlzIGEgZmFjdCB0aGF0IG1h bnkgbWlsbGlvbnMgb2YgcGVvcGxlIHBhc3MgdGhyb3VnaCBXaS1GaS1lbmFibGVkIGFyZWFzIGV2 ZXJ5IGRheSBpbiBwbGFjZXMgbGlrZSBhaXJwb3J0cywgdHJhaW4gc3RhdGlvbnMsIGhvdGVscyBh bmQgb3RoZXIgcHVibGljIHBsYWNlcyBhbmQgbmV2ZXIgZXZlbiBrbm93IGl0LiBXaHk/IC0gc2lt cGx5IGJlY2F1c2UgdGhlcmUgaXMgbm8gc2lnbmFnZS4gSXQgc2VlbXMgcmF0aGVyIGlyb25pYywg Z2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBzbyBtdWNoIG90aGVyIHNpZ25hZ2UgYXJvdW5k LCBlLmcuIHNpZ25zIGZvciBubyBzbW9raW5nIGFyZWFzIGluIHJlc3RhdXJhbnRzLCBmb3IgcHVi bGljIHRvaWxldHMsIGZvciBwdWJsaWMgY2FyIHBhcmtzLCBldGMsIGV0Yywgd2hpY2ggY2xlYXJs eSBkZXNjcmliZSB0aGUgcHVycG9zZSBhbmQgdXNlIG9mIHRoYXQgcGFydGljdWxhciBwdWJsaWMg YXJlYSBvciBmYWNpbGl0eS4gQnV0LCBoYXMgYW55b25lIGV2ZXIgc2VlbiBhIHNpZ24gc2F5aW5n ICJMQU4gSG90LXNwb3QiIG9yICJXaS1GaSBMb3VuZ2UiIG9yICJMYXB0b3AgTm9tYWQgQXJlYSI/ IC0gcHJvYmFibHkgbm90Lg0NRlJFRSBPRkZFUjogUGxlYXNlIGhlbHAgdXMgdG8gbG9jYXRlIHRo ZXNlIHBsYWNlcy4gSWYgeW91IHNlZSBzaWduYWdlIGFkdmVydGlzaW5nIGEgTEFOIEhvdC1zcG90 IG9yIFdpLUZpIExvdW5nZSwgc2VuZCBkZXRhaWxzIG9mIHdoZXJlIGFuZCB3aGVuIGFuZCBob3cg b2J2aW91cyB0aGUgc2lnbmFnZSBpcyBieSBlbWFpbCB0bzogEyBIWVBFUkxJTksgbWFpbHRvOmJy aWFucEBtdm5vaW5mby5jb20gARRicmlhbnBAbXZub2luZm8uY29tFSBhbmQgd2Ugd2lsbCBzZW5k IHlvdSBmcmVlIG9mIGNoYXJnZSwgYSBjb3B5IG9mIG91ciByZWNlbnRseS1wdWJsaXNoZWQgV2hp dGUgUGFwZXIsIGVudGl0bGVkOiAiV2hhdCdzIEdvaW5nIG9uIGluIFRoZSBXb3JsZCBvZiBXaS1G aSAoQXByaWwgMjAwMykiLg0NDQ0NDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0oMSkgUm9hZCB3YXJyaW9ycyBhcmUg cGVvcGxlIHdobyBzcGVuZCBtb3N0IG9mIHRoZWlyIHRpbWUgb3V0c2lkZSB0aGUgY29tcGFueSAo ZS5nLiBzYWxlc3Blb3BsZSwgbWFpbnRlbmFuY2UgcGVyc29ubmVsLCBhbmQgY29uc3VsdGFudHMp LiBUaGVzZSB1c2VycyBuZWVkIG1lc3NhZ2luZyBhcHBsaWNhdGlvbnMsIHBlcnNvbmFsIGluZm9y bWF0aW9uIG1hbmFnZW1lbnQsIGFwcGxpY2F0aW9ucyBmb3IgZmlsdGVyaW5nIGluZm9ybWF0aW9u LCBtZXNzYWdlcyBhbmQgY2FsbHMsIGFuZCBub3RpZmljYXRpb24uIFRoZXkgbXVzdCBiZSBhYmxl IHRvIGFjY2VzcyB0aGVzZSBvbiBhbnkgY29tbXVuaWNhdGlvbnMgZGV2aWNlIGluIGFueSBwbGFj ZS4JCygyKSBHbG9iYWwgaG9wcGVycyBhcmUgcGVvcGxlIHdpdGggYSBtaXggb2YgcHJvZmlsZXMg YmVjYXVzZSB0aGV5IHNvbWV0aW1lcyB3b3JrIGluc2lkZSBhbmQgc29tZXRpbWVzIG91dHNpZGUg dGhlIGNvbXBhbnkuIFRoZXkgZnJlcXVlbnRseSBoYXZlIG1hbmFnZW1lbnQgcmVzcG9uc2liaWxp dGllcyAoZS5nLiBjb3Jwb3JhdGUgZXhlY3V0aXZlLCB0b3AgbWFuYWdlbWVudC4gSW4gYWRkaXRp b24sIGJlY2F1c2Ugb2YgdGhlaXIgcG9zaXRpb25zIHdpdGhpbiB0aGVpciBjb21wYW5pZXMsIHRo ZXkgaGF2ZSBzcGVjaWZpYyBuZWVkcywgc3VjaCBhcyBwZXJzb25hbGl6YXRpb24gb2YgdGhlaXIg d29ya2luZyBlbnZpcm9ubWVudHMuDSgzKSBUZWxld29ya2VycyAob3IgaG9tZSB3b3JrZXJzKSBh cmUgcGVvcGxlIHdob3NlIGRlc2sgaXMgYSB2aXJ0dWFsIG9mZmljZSBhdCB0aGVpciByZW1vdGUg bG9jYXRpb24uDSg0KSBEZXNrIHNvbGRpZXJzIGFyZSBwZW9wbGUgd2hvIHdvcmsgYWxtb3N0IGVu dGlyZWx5IGF0IHRoZWlyIGRlc2tzIChlLmcuIHRlbGVzYWxlcykuDSg1KSBPbi1zaXRlIHJvdmVy cyBhcmUgcGVvcGxlIHdobyBhcmUgc29tZXRpbWVzIGF0IHRoZWlyIGRlc2tzIGFuZCBzb21ldGlt ZXMgZWxzZXdoZXJlIGluIHRoZSBjb21wYW55IHByZW1pc2VzIGFuZCBuZWVkIGJvdGggZml4ZWQg YW5kIG1vYmlsZSBjb21tdW5pY2F0aW9ucyBzZXJ2aWNlcyAoZS5nLiBhc3Npc3RhbnRzKS4NLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDakgQWxsIHJpZ2h0cyByZXNlcnZlZC4gVGhpcyBkb2N1bWVudCBjb250YWlucyBp bmZvcm1hdGlvbiBwcm9wcmlldGFyeSB0byBNVk5PaW5mby5jb20sIHNvbWUgb3IgYWxsIG9mIHdo aWNoIG1heSBiZSBsZWdhbGx5IHByaXZpbGVnZWQuIEl0IGlzIGZvciB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IG9ubHkuIE5vIHBhcnQgb2YgdGhpcyBwdWJsaWNhdGlvbiBtYXkgYmUgcmVwcm9kdWNl ZCBpbiBhbnkgbWF0ZXJpYWwgZm9ybSAoaW5jbHVkaW5nIHBob3RvY29weWluZykgb3Igc3RvcmVk IGluIGFueSBtZWRpdW0gYnkgZWxlY3Ryb25pYyBtZWFucyBhbmQgd2hldGhlciBvciBub3QgdHJh bnNpZW50bHkgb3IgaW5jaWRlbnRhbGx5IHRvIHNvbWUgb3RoZXIgdXNlIG9mIHRoaXMgcHVibGlj YXRpb24gd2l0aG91dCB0aGUgd3JpdHRlbiBwcmlvciBwZXJtaXNzaW9uIG9mIHRoZSBjb3B5cmln aHQgb3duZXIuICBBcHBsaWNhdGlvbiBmb3IgdGhlIGNvcHlyaWdodCBvd25lcpJzIHBlcm1pc3Np b24gdG8gcmVwcm9kdWNlIGFueSBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGFkZHJl c3NlZCB0bzogTVZOT2luZm8uY29tLCBTdWl0ZSA1LjMsIDE0MCBUYWJlcm5hY2xlIFN0cmVldCwg TG9uZG9uIEVDMkEgNFNELCBVbml0ZWQgS2luZ2RvbS4NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAIEAAAEBAAA EgQAAEIEAABDBAAARgQAAKQEAAClBAAA+QUAAPoFAAAWCAAAGQgAACkIAAAsCAAAOggAAD4IAABM CAAATwgAAGMIAABmCAAApwsAALILAAApDAAALgwAADMMAAA3DAAAPAwAAFYMAABkDAAAZQwAAIsM AACMDAAAjQwAAKAMAAChDAAA/wwAADQNAAA1DQAAOg0AAPINAABAEgAA+BIAAEUTAABJEwAANRUA ADkVAACBFQAAghUAAPkA7+nf2una0wDTy9PL08vTy9PL08HTt9O307fTrNOerJus05Dp2vmJ+YaC hoKGAAAAAAAAAAAAAAAAAAAAAAAHNgiBQ0oQAARDShAAAAxDShAAT0oCAFFKAgAAFTUIgTYIgUIq CUNKFgBPSgIAUUoCAAQwShMAABsCCIEDagAAAAAGCAFDShYAT0oCAFFKAgBVCAEVA2oAAAAAQ0oW AE9KAgBRSgIAVQgBEjUIgTYIgUNKFgBPSgIAUUoCAAASNQiBQioJQ0oWAE9KAgBRSgIAAA9DShYA SCoBT0oCAFFKAgAMQ0oWAE9KAgBRSgIAAAhPSgIAUUoCAAASNQiBPioBQ0okAE9KAgBRSgIAAAs1 CIFPSgIAUUoCABI1CIE+KgFDSigAT0oCAFFKAgAADENKEgBPSgIAUUoCADAABAAAAQQAAAIEAAAD BAAABAQAABIEAABCBAAAQwQAAEQEAABFBAAARgQAAJAEAACjBAAApAQAAKUEAAD6BQAA/AUAALAH AACxBwAAAAkAAAEJAACmCwAApwsAADUNAAA2DQAANw0AADgNAAA5DQAAOg0AAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAAAAAAAAAAAAAAMAAAMkAQABAAAABQAADcYFAAH2GAAAHAAEAAABBAAAAgQAAAME AAAEBAAAEgQAAEIEAABDBAAARAQAAEUEAABGBAAAkAQAAKMEAACkBAAApQQAAPoFAAD8BQAAsAcA ALEHAAAACQAAAQkAAKYLAACnCwAANQ0AADYNAAA3DQAAOA0AADkNAAA6DQAA8g0AAMoQAAAwEQAA hxEAAEASAAD4EgAAghUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/f39/QAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwIRAAAjOg0AAPINAADKEAAAMBEA AIcRAABAEgAA+BIAAIIVAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAoRABJkI/8AAA3GCAACvQSmFwAAAAUAAA3GBQAB9hgAAAcqAAkwABIwABxQAQAfsIwu ILCgQSGwagEisO0BI5BqASSQVwQlsAAAF7DgAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANMAAABEAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5 us4RjIIAqgBLqQsCAAAAFwAAABQAAABiAHIAaQBhAG4AcABAAG0AdgBuAG8AaQBuAGYAbwAuAGMA bwBtAAAA4Mnqefm6zhGMggCqAEupCzYAAABtAGEAaQBsAHQAbwA6AGIAcgBpAGEAbgBwAEAAbQB2 AG4AbwBpAG4AZgBvAC4AYwBvAG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABQACgABAFsADwACAAAAAAAAACwAAEDx /wIALAAAAAYATgBvAHIAbQBhAGwAAAAFAAAAMSQAAAgAQ0oYAG1ICQQAAAAAAAAAAAAAAAAAAAAA AAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBu AHQAAAAAAAAAAAAAAAAANAD+DwEA8gA0AAAABwBUAHgAQgByAF8AcAAwAAAAEwAPAAMkAxJk8AAA AA3GBQABzAAAAAAAKAD+DwEAAgEoAAAABwBUAHgAQgByAF8AdAAxAAAACAAQABJk0QAAAAAAKAD+ TwEAEgEoAAAABwBUAHgAQgByAF8AdAAyAAAACAARABJk3QAAAAAANAD+DwEAIgE0AAAABwBUAHgA QgByAF8AcAAzAAAAFAASAA+E9hgSZPAAAAANxgUAAWAaAAAAKABVQKIAMQEoAAAACQBIAHkAcABl AHIAbABpAG4AawAAAAYAPioBQioCAAAAAIIRAAAEAAAeAAAAAP////8ABAAAghUAAAsAAAAABAAA Og0AAIIVAAAMAAAADgAAAAAEAACCFQAADQAAAGQIAACMCAAAoAgAAIIRAAATWBT/FYAAAAAAVAEA AFYBAADsAQAA8AEAAH4FAACABQAAcAcAAHIHAAALCAAADQgAACAJAAAiCQAAhBEAAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAAAAAABMAAAAVAAAA3wIAAOcCAAC6BwAAvgcAANoHAAA0CQAAhBEA AAcAGgAHABoABwAaAAcAGgAHAP//FAAAAAgAQgAgAFAAbwB3AGUAbABsAC4AQwA6AFwATQB5ACAA RABvAGMAdQBtAGUAbgB0AHMAXABNAFYATgBPAFwATABhAHAAdABvAHAAIABOAG8AbQBhAGQAcwBf AEEAcgB0AGkAYwBsAGUALgBkAG8AYwAIAEIAIABQAG8AdwBlAGwAbAA+AEMAOgBcAFcASQBOAEQA TwBXAFMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBm ACAATABhAHAAdABvAHAAIABOAG8AbQBhAGQAcwBfAEEAcgB0AGkAYwBsAGUALgBhAHMAZAAIAEIA IABQAG8AdwBlAGwAbAA+AEMAOgBcAFcASQBOAEQATwBXAFMAXABUAEUATQBQAFwAQQB1AHQAbwBS AGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAATABhAHAAdABvAHAAIABOAG8AbQBhAGQA cwBfAEEAcgB0AGkAYwBsAGUALgBhAHMAZAAIAEIAIABQAG8AdwBlAGwAbAAuAEMAOgBcAE0AeQAg AEQAbwBjAHUAbQBlAG4AdABzAFwATQBWAE4ATwBcAEwAYQBwAHQAbwBwACAATgBvAG0AYQBkAHMA XwBBAHIAdABpAGMAbABlAC4AZABvAGMACABCACAAUABvAHcAZQBsAGwALgBDADoAXABNAHkAIABE AG8AYwB1AG0AZQBuAHQAcwBcAE0AVgBOAE8AXABMAGEAcAB0AG8AcAAgAE4AbwBtAGEAZABzAF8A QQByAHQAaQBjAGwAZQAuAGQAbwBjAAgAQgAgAFAAbwB3AGUAbABsAD4AQwA6AFwAVwBJAE4ARABP AFcAUwBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYA IABMAGEAcAB0AG8AcAAgAE4AbwBtAGEAZABzAF8AQQByAHQAaQBjAGwAZQAuAGEAcwBkAAgAQgAg AFAAbwB3AGUAbABsAC4AQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABNAFYATgBPAFwA TABhAHAAdABvAHAAIABOAG8AbQBhAGQAcwBfAEEAcgB0AGkAYwBsAGUALgBkAG8AYwAIAEIAIABQ AG8AdwBlAGwAbAAuAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwATQBWAE4ATwBcAEwA YQBwAHQAbwBwACAATgBvAG0AYQBkAHMAXwBBAHIAdABpAGMAbABlAC4AZABvAGMACABCACAAUABv AHcAZQBsAGwALgBDADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAE0AVgBOAE8AXABMAGEA cAB0AG8AcAAgAE4AbwBtAGEAZABzAF8AQQByAHQAaQBjAGwAZQAuAGQAbwBjAAgAQgAgAFAAbwB3 AGUAbABsAC4AQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABNAFYATgBPAFwATABhAHAA dABvAHAAIABOAG8AbQBhAGQAcwBfAEEAcgB0AGkAYwBsAGUALgBkAG8AYwD/QEJyb3RoZXIgSEwt MTAzMCBzZXJpZXMATFBUMToAYnJvaGw5OWUAQnJvdGhlciBITC0xMDMwIHNlcmllcwBCcm90aGVy IEhMLTEwMzAgc2VyaWVzAAAAAAAAAAAAAAAERwKUAOYAAxcAAAEACQAAAAAAAAABAAEA/P8AAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAgAAAAAAyVMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG0GAgAA/3//f/8AAAADAQEB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAAAAMBAAAAAAAAAAC7AvYEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAEAAAAAAAAAAABCcm90aGVyIEhMLTEwMzAgc2VyaWVz AAAAAAAAAAAAAIEBQlJITDEwMzAuaW5pAAgAAABCcm90aGVyIEhMLTEwMzAgc2VyaWVzAAAAAAAA AAAAAAAERwKUAOYAAxcAAAEACQAAAAAAAAABAAEA/P8AAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABYAgAAAAAAyVMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAG0GAgAA/3//f/8AAAADAQEBAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAUAAAAAAAMBAAAAAAAAAAC7AvYEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AAAAAAEAAAAAAAAAAABCcm90aGVyIEhMLTEwMzAgc2VyaWVzAAAAAAAAAAAAAIEBQlJITDEwMzAu aW5pAAgAAAAAgAEAAAAAAAAAAAAgUAUBAQAAAAAAAAAAAAAAAAAAAAAAAAACEAAAAAAAAACCEQAA QAAACABAAAADAAAARxaQAQAAAgIGAwUEBQIDBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBt AGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAA AAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBAMAAAAAAAAAAAAAAAAAAAAB AAAAAAAAAEEAcgBpAGEAbAAAACIABABAAIoYAADQAgAAaAEAAAAAW6B0BoagdAYAAAAABAADAAAA jAIAALMOAAABABAAAAAEAIMAPAAAAIwCAACzDgAAAQAQAAAAPAAAAAAAAAC5IgAAAIQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAMjAAABAAGQBkAAAAGQAAADQRAAA0EQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AgAAAAAA//8SAAAAAAAAAA0ATABhAHAAdABvAHAAIABOAG8AbQBhAGQAcwAAAAAAAAAMAEIAcgBp AGEAbgAgAFAAbwB3AGUAbABsAAgAQgAgAFAAbwB3AGUAbABsAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5 T2gQq5EIACsns9kwAAAAfAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAALAAAAAEAAAAvAAAAAUA AADUAAAABgAAAOAAAAAHAAAA7AAAAAgAAAD8AAAACQAAABABAAASAAAAHAEAAAoAAAA4AQAADAAA AEQBAAANAAAAUAEAAA4AAABcAQAADwAAAGQBAAAQAAAAbAEAABMAAAB0AQAAAgAAAOQEAAAeAAAA DgAAAExhcHRvcCBOb21hZHMAbwAeAAAAAQAAAABhcHQeAAAADQAAAEJyaWFuIFBvd2VsbAAAbwAe AAAAAQAAAAByaWEeAAAAAQAAAAByaWEeAAAABwAAAE5vcm1hbABvHgAAAAkAAABCIFBvd2VsbABl bGweAAAAAgAAADQAUG8eAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAAAQAAAAADSSWsAAAAAQAAA AABiyo7TBsMBQAAAAAAMigHZBsMBAwAAAAEAAAADAAAAjAIAAAMAAACzDgAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAAr LPmuRAAAAAXVzdWcLhsQk5cIACss+a5MAQAACAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAJAA AAAGAAAAmAAAABEAAACgAAAAFwAAAKgAAAALAAAAsAAAABAAAAC4AAAAEwAAAMAAAAAWAAAAyAAA AA0AAADQAAAADAAAAOoAAAACAAAA5AQAAB4AAAAVAAAAQ2hhbWVsZW9uIENvbnN1bHRpbmcAAHYA AwAAADwAAAADAAAAEAAAAAMAAAA0EQAAAwAAAGoQCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAL AAAAAAAAAB4QAAABAAAADgAAAExhcHRvcCBOb21hZHMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMA AAABAAAALAEAAAQAAAAAAAAAKAAAAAEAAABSAAAAAgAAAFoAAAADAAAAsgAAAAIAAAACAAAACgAA AF9QSURfR1VJRAADAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAAQQAAAE4AAAB7AEUAQgBBAEQA MwA1AEUAMQAtADYAMgA5ADcALQAxADEARAA3AC0AQgBBADcANQAtADAAMABBADAAQwBDADcAQgBB ADIAMAAyAH0AAAAAAEEAAABwAAAABgAAAAMAAABkAFEAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAA HwAAABsAAABtAGEAaQBsAHQAbwA6AGIAcgBpAGEAbgBwAEAAbQB2AG4AbwBpAG4AZgBvAC4AYwBv AG0AAAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN AAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAAP7///8ZAAAAGgAAABsA AAAcAAAAHQAAAB4AAAAfAAAA/v///yEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAD+////KQAA ACoAAAArAAAALAAAAC0AAAAuAAAALwAAAP7////9////MgAAAP7////+/////v////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAA8AAAAAAAAAAAAAAAAAAAAADASIgBAAAAAAAA AAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAHXzknvbC AWCKpxTZBsMBNAAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAABkSIgBkQAAoGRIiAEsAEAA FEqIAehJiAEAAAAAAAAAAAAAAABQSYgB1Hh9AQoAAgH///////////////8AAAAAAAAAAAAAAAD/ /wIAFEqIAQAAAAAAAAAAAgAAAAEAAAAQAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABkSIgBWgAA8OiaAEh4mgBIIAUAALQAAAAAAAAADgACAAEAAAD///////// /////wA1AAAAGgAAADUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAEAAAAAAAAFcAbwByAGQA RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAlEuIAQAAAAAAAAAAAAAAAAAAAAAAAAAA7EuIAQAAAAAa AAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAgCDAawAYAAAIAAAAAACAAAAAAACwe AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAABAAAAAAAAAAAQAA AAAAAAAAAAAAAAAAACgAAgH////////////////sS4gBAAAAAAAAAABgAGAAAAAAAAAAAAAEAQAA /QAAAA8AAAAgAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////xQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAwAgTIgBFAAAACgAAAAAEAAAAQAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRIiAHVAACgGFiIASwAQAASAAIBAgAAAAcAAAD///// AAAAAOxLiAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAACwTIgBTwBiAGoAZQBj AHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYA AQD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAGCKpxTZBsMBYIqnFNkGwwH0TYgBEgAA 8A0ATAABAAAA/v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1l bnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA ------=_NextPart_000_0206_01C307E3.8F446260-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 10:18: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 KAA17731 for ; Mon, 21 Apr 2003 10:18:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3LELA401047 for ; Mon, 21 Apr 2003 10:21:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3LEL6415915 for ; Mon, 21 Apr 2003 10:21:06 -0400 (EDT) Message-ID: From: Joris wils To: "'Muneyoshi Suzuki'" , nfinn@cisco.com Cc: ppvpn@nortelnetworks.com Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Mon, 21 Apr 2003 10:16:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: CIMA.coriolisnet.com X-SMTP-MAIL-FROM: jwils@coriolisnet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.229.88.162] X-LYRIS-Message-Id: Muneyoshi, >I think there is a much simple and robust solution. Connect Provider Bridges >with point-to-point LSPs and use STP/RSTP in the network, and don't use >split-horizon scheme. Needless to say LSPs must be raw mode; tagged mode >violates the standard. >In this case, if PEs are connected with full mesh LSPs, reliability of a >single PE is: >1- {(1- R^2) ^ (N -1)}. >Obviously, this is a robust solution because it use LSPs as parallel system. >Furthermore, this does not need to revise the existing standards, it only >needs Q-in-Q or MAC-in-MAC specification in 802.1ad. Please verify my understanding: are you proposing that vendors add Bridging to their MPLS devices; Bridging over MPLS as it were, MPLS is the Transport. correct? If so, I have noticed, that vendors are quietly adding Bridging to their ATM, Frame and TDM devices as well. 802.1ad could interconnect all these devices, regardless of which media they use as the Transport. My question is: how do you deal with (portions of) the network, for which a spanning tree would be a very inefficient forwarding means, because the physical topology does not approximate a tree? Thank you, Joris Wils Consulting SW Engineer Coriolis Networks jwils@coriolisnet.com/978-264-1904x667 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 12:07:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21000 for ; Mon, 21 Apr 2003 12:07:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3LG9B401954 for ; Mon, 21 Apr 2003 12:09:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3LG98405168 for ; Mon, 21 Apr 2003 12:09:08 -0400 (EDT) Message-ID: From: Joris wils To: "'ppvpn@nortelnetworks.com'" Subject: Resend: Comments on the L2 VPN framework and solutions documents Date: Mon, 21 Apr 2003 12:00:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: CIMA.coriolisnet.com X-SMTP-MAIL-FROM: jwils@coriolisnet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.229.88.162] X-LYRIS-Message-Id: At the system manager's request because the note might have gotten stuck in the mail server. -----Original Message----- From: Joris wils Sent: Monday, April 21, 2003 10:17 AM To: 'Muneyoshi Suzuki'; nfinn@cisco.com Cc: ppvpn@nortelnetworks.com Subject: RE: Comments on the L2 VPN framework and solutions documents Muneyoshi, >I think there is a much simple and robust solution. Connect Provider Bridges >with point-to-point LSPs and use STP/RSTP in the network, and don't use >split-horizon scheme. Needless to say LSPs must be raw mode; tagged mode >violates the standard. >In this case, if PEs are connected with full mesh LSPs, reliability of a >single PE is: >1- {(1- R^2) ^ (N -1)}. >Obviously, this is a robust solution because it use LSPs as parallel system. >Furthermore, this does not need to revise the existing standards, it only >needs Q-in-Q or MAC-in-MAC specification in 802.1ad. Please verify my understanding: are you proposing that vendors add Bridging to their MPLS devices; Bridging over MPLS as it were, MPLS is the Transport. correct? If so, I have noticed, that vendors are quietly adding Bridging to their ATM, Frame and TDM devices as well. 802.1ad could interconnect all these devices, regardless of which media they use as the Transport. My question is: how do you deal with (portions of) the network, for which a spanning tree would be a very inefficient forwarding means, because the physical topology does not approximate a tree? Thank you, Joris Wils Consulting SW Engineer Coriolis Networks jwils@coriolisnet.com/978-264-1904x667 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 13:44:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23862 for ; Mon, 21 Apr 2003 13:44:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3LHkh419213 for ; Mon, 21 Apr 2003 13:46:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3LHkd425908 for ; Mon, 21 Apr 2003 13:46:39 -0400 (EDT) From: "Per Hansen" To: "'Joris wils'" , "'Muneyoshi Suzuki'" , Cc: Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Mon, 21 Apr 2003 19:43:48 +0200 Message-ID: <000001c3082d$91d34b00$0601a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SMTP-HELO: pfepc.post.tele.dk X-SMTP-MAIL-FROM: perflemming@hansen.mail.dk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pfepc.post.tele.dk [193.162.153.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Your comment seems valid - there are always good and bad. However on the other hand just using standard L2 bringing over LSPs is very simple and in some way straight forward because: * it just adapt to probably the most installed standard in the world. * The learning curve is simpler for everybody * Network Administration of Bridges are probably simpler * The development effort can be held on a minimum, known technology in combination with MPLS, * Silicon solutions can probably come faster to market and drive the cost down. * Virtual MAC switches can be provided with aggregation using MPLS labes via same links. * L2 Protocol software can faster be adapted. * Even LSPs can be setup by operator configuration, not signalling. -----Original Message----- From: Joris wils [mailto:jwils@coriolisnet.com] Sent: 21. april 2003 16:17 To: 'Muneyoshi Suzuki'; nfinn@cisco.com Cc: ppvpn@nortelnetworks.com Subject: RE: Comments on the L2 VPN framework and solutions documents Muneyoshi, >I think there is a much simple and robust solution. Connect Provider Bridges >with point-to-point LSPs and use STP/RSTP in the network, and don't use >split-horizon scheme. Needless to say LSPs must be raw mode; tagged mode >violates the standard. >In this case, if PEs are connected with full mesh LSPs, reliability of a >single PE is: >1- {(1- R^2) ^ (N -1)}. >Obviously, this is a robust solution because it use LSPs as parallel system. >Furthermore, this does not need to revise the existing standards, it only >needs Q-in-Q or MAC-in-MAC specification in 802.1ad. Please verify my understanding: are you proposing that vendors add Bridging to their MPLS devices; Bridging over MPLS as it were, MPLS is the Transport. correct? If so, I have noticed, that vendors are quietly adding Bridging to their ATM, Frame and TDM devices as well. 802.1ad could interconnect all these devices, regardless of which media they use as the Transport. My question is: how do you deal with (portions of) the network, for which a spanning tree would be a very inefficient forwarding means, because the physical topology does not approximate a tree? Thank you, Joris Wils Consulting SW Engineer Coriolis Networks jwils@coriolisnet.com/978-264-1904x667 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 16:41:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01355 for ; Mon, 21 Apr 2003 16:41:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3LKh9425819 for ; Mon, 21 Apr 2003 16:43:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3LKh4403790 for ; Mon, 21 Apr 2003 16:43:05 -0400 (EDT) Date: Mon, 21 Apr 2003 13:39:18 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14465423564.20030421133918@psg.com> To: Kireeti Kompella CC: ppvpn@lyris.nortelnetworks.com Subject: Company support vs personal support [was: Re: draft-kompella-ppvpn-vpls-01.txt] In-Reply-To: <20030418191910.Q60918@kummer.juniper.net> References: <3EA054DC.AB14C762@francetelecom.com> <162229867692.20030418151021@psg.com> <20030418191910.Q60918@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi, To all WG participants: BTW, my comment was not specific to Zidan's e-mail only. I've seen another 2 or 3 e-mails also stating a company's opinion. My recommendation to guys posted those is to state their personal opinion on the mailing list with their company's hat off. Kireeti, below, pls. Friday, April 18, 2003, 7:30:33 PM, Kireeti Kompella wrote: ... >> The IETF does not recognize companies, especially when consensus is >> being gauged within a WG. You should express your *personal* and >> *technical* opinion. > Is it okay to mention one's affiliation, so that others can see > whether this opinion comes from a vendor or a provider? > Also, as far as I can judge, a hum or a raised hand or an email that > "we'd like to support this draft" are all equally technical. As a co-chair of an IETF WG, you know, of course, that in the IETF, "Participation is by individual technical contributors, rather than by formal representatives of organizations". If operational nature of someone's personal feedback needs to be stressed, something like "I am from a Service Provider, and I believe that..." should work well. Something like "We think...", "I'm from and we believe...", or " believes...", is a wrong way of doing this, especially when the WG consensus is being gauged. IRET ; Return from AD interrupt Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 19:14: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 TAA08049 for ; Mon, 21 Apr 2003 19:14:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3LNGb415372 for ; Mon, 21 Apr 2003 19:16:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3LNGWI24084 for ; Mon, 21 Apr 2003 19:16:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20030421154706.01d44730@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Apr 2003 16:13:50 -0700 To: Muneyoshi Suzuki , nfinn@cisco.com From: Ali Sajassi Subject: Re: Comments on the L2 VPN framework and solutions documents Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp In-Reply-To: <20030421.134800.63057419.suzuki.muneyoshi@lab.ntt.co.jp> References: <3EA08E50.7011B94@cisco.com> <3E9F3E72.117D5369@cisco.com> <20030418.162712.41696376.suzuki.muneyoshi@lab.ntt.co.jp> <3EA08E50.7011B94@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Muneyoshi, >I think there is a much simple and robust solution. Connect Provider Bridges >with point-to-point LSPs and use STP/RSTP in the network, and don't use >split-horizon scheme. Needless to say LSPs must be raw mode; tagged mode >violates the standard. There are several issues w/ this appraoch: 1) Scalability aspect of the service - e.g., having tens or hundreds of thousands of customers which translate into 10Ks/100Ks PE-VLANs. It should be noted that 802.1ad in based on 802.1D/Q with 12-bit vlan field. Also it is not as simple as increasing the VLAN field, since it impacts the 802.1s/w and GMRP algorithms. 2) Impact to existing IEEE algorithms such as MSTP, RSTP, GMRP, GVRP, etc if need more than 4K vlan space. 3) Creating interdependency of different access domain - e.g., the same PE-VLAN needs to be used in different access domains 4) Inter-operability with MPLS access networks - how do you interoperate between a QinQ access network and an MPLS access network that doesn't run STP 5) Mandating the use of STP over MPLS/IP core - although some service providers don't mind running STP within an access network (e.g., QinQ island), they are concern running STP between islands because of its network mgmt aspect of it. -Ali >In this case, if PEs are connected with full mesh LSPs, reliability of a >single PE is: > >1- {(1- R^2) ^ (N -1)}. > >Obviously, this is a robust solution because it use LSPs as parallel system. >Furthermore, this does not need to revise the existing standards, it only >needs Q-in-Q or MAC-in-MAC specification in 802.1ad. > > >Thanks, > >Muneyoshi Suzuki >Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 21 21:01:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10837 for ; Mon, 21 Apr 2003 21:01:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3M13S426399 for ; Mon, 21 Apr 2003 21:03:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3M13LI14054 for ; Mon, 21 Apr 2003 21:03:21 -0400 (EDT) Date: Tue, 22 Apr 2003 09:57:28 +0900 (JST) Message-Id: <20030422.095728.07567803.suzuki.muneyoshi@lab.ntt.co.jp> To: jwils@coriolisnet.com Cc: nfinn@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: References: 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 Joris, > Please verify my understanding: are you proposing that vendors add Bridging > to their MPLS devices; Bridging over MPLS as it were, MPLS is the Transport. > correct? Correct. > If so, I have noticed, that vendors are quietly adding Bridging to > their ATM, Frame and TDM devices as well. 802.1ad could interconnect all > these devices, regardless of which media they use as the Transport. Exactly. > My question is: how do you deal with (portions of) the network, for which a > spanning tree would be a very inefficient forwarding means, because the > physical topology does not approximate a tree? Could you clarify this? What is spanning tree in the above context? 802.1D STP, or STP/RSTP/MSTP? If you are claiming STP topology change time is inefficient, the use of RSTP/MSTP should be considered. If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify the issues? Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 00:23:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14179 for ; Tue, 22 Apr 2003 00:23:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3M4Q5f10276 for ; Tue, 22 Apr 2003 00:26:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3M4Q1S22723 for ; Tue, 22 Apr 2003 00:26:02 -0400 (EDT) Date: Tue, 22 Apr 2003 13:20:15 +0900 (JST) Message-Id: <20030422.132015.104104846.suzuki.muneyoshi@lab.ntt.co.jp> To: perflemming@hansen.mail.dk Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <000001c3082d$91d34b00$0601a8c0@oemcomputer> References: <000001c3082d$91d34b00$0601a8c0@oemcomputer> 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 Per, > Your comment seems valid - there are always good and bad. > However on the other hand just using standard L2 bringing over > LSPs is very simple and in some way straight forward because: > > * it just adapt to probably the most installed standard > in the world. > * The learning curve is simpler for everybody > * Network Administration of Bridges are probably simpler > * The development effort can be held on a minimum, known > technology in combination with MPLS, > * Silicon solutions can probably come faster to market and > drive the cost down. > * Virtual MAC switches can be provided with aggregation > using MPLS labes via same links. > * L2 Protocol software can faster be adapted. > * Even LSPs can be setup by operator configuration, not > signalling. Agreed. Standard L2 bringing over LSPs is already proposed in draft-lee-ppvpn-hybrid-vpls-00.txt. And MAC-in-MAC described in draft-radoaca-ppvpn-gvpls-01.txt supports clear separation between the customers and provider address spaces. I think these documents need to update, but are a good start point to discuss robust architecture of virtual private bridged lan. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 04:05: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 EAA29641 for ; Tue, 22 Apr 2003 04:05:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3M87Of28712 for ; Tue, 22 Apr 2003 04:07:25 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3M87FS13989 for ; Tue, 22 Apr 2003 04:07:15 -0400 (EDT) From: "Stefano Bosio" To: Subject: draft-kompella-ppvpn-vpls-01.txt Date: Tue, 22 Apr 2003 10:06:40 +0200 Message-ID: <003c01c308a6$1aeed940$5f000e0a@thiscomp> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MIMETrack: Itemize by SMTP Server on itbre87a/Srv/Lutech(Release 5.0.9 |November 16, 2001) at 04/22/2003 10:04:54, Serialize by Router on itbre87a/Srv/Lutech(Release 5.0.9 |November 16, 2001) at 04/22/2003 10:04:54, Serialize complete at 04/22/2003 10:04:54 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: mail.lucchini.it X-SMTP-MAIL-FROM: s.bosio@lutech.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [62.94.104.100] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit We support draft-kompella-ppvpn-vpls-01 We like the scalability (RR) and BGP control plane. We like the possibility to maintain the current IP VPN control infrastructure, it allows semplicity and flexibility. Thank you Stefano Bosio From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 08:27: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 IAA05720 for ; Tue, 22 Apr 2003 08:27:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MCTTf26839 for ; Tue, 22 Apr 2003 08:29:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MCTQS22566 for ; Tue, 22 Apr 2003 08:29:26 -0400 (EDT) Message-ID: From: Joris wils To: "'Muneyoshi Suzuki'" , Joris wils Cc: nfinn@cisco.com, ppvpn@nortelnetworks.com Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Tue, 22 Apr 2003 08:26:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: CIMA.coriolisnet.com X-SMTP-MAIL-FROM: jwils@coriolisnet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.229.88.162] X-LYRIS-Message-Id: Muneyoshi, Thank you for your response. Answers below. >Joris, >> Please verify my understanding: are you proposing that vendors add Bridging >> to their MPLS devices; Bridging over MPLS as it were, MPLS is the Transport. >> correct? >Correct. >> If so, I have noticed, that vendors are quietly adding Bridging to >> their ATM, Frame and TDM devices as well. 802.1ad could interconnect all. >> these devices, regardless of which media they use as the Transport. >Exactly. >> My question is: how do you deal with (portions of) the network, for which a >> spanning tree would be a very inefficient forwarding means, because the >> physical topology does not approximate a tree? >Could you clarify this? What is spanning tree in the above context? >802.1D STP, or STP/RSTP/MSTP? >If you are claiming STP topology change time is inefficient, the use of >RSTP/MSTP should be considered. >If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify >the issues? Yes, at first approximation, they are efficient in the access & aggregation portion of a WAN, but inefficient in the core of a WAN. At first approximation: It is my understanding that a wide area network can be roughly divided into an access & aggregation portion on the one hand and a core on the other, each with a very different physical topology. The aggregation portion looks roughly like a tree with links or rings of increasing bandwidth heading towards the core. The core of the WAN, however, is an arbitrary interconnect of links, which usually bears no resemblance to a tree at all. So for any given vlan, it works well to rely on *STP in the aggregation portion, because the spanning tree will closely match the aggregation tree, so that no or few useful links have to go into blocking. In the core of the network, however, the spanning tree does not match the physical topology, so many possibly useful links to the vlan would have to be placed into blocking. So, you can say that *STP makes efficient use of the WAN bandwidth and links in the aggregation portion, but inefficient use in the core portion. MSTP is only a partial solution, because it does not provide efficient use of available bandwidth and links for any individual VLAN. VPLS, on the other hand, can provide efficient use of available bandwidth, as long as the number of split-horizon bridges is kept low enough to constrain broadcast, control plane and reliability inefficiences. So I have been an proponent of Norm Finn's approach in which a handful of Spanning Tree islands per vlan are interconnected by an Inter-Island Trunk provided by Ethernet Emulation using VPLS. I just think it is important to realize that these Spanning Tree islands will exist in the Aggregation portions of WAN and thus be largely constructed out of Provider Bridges, which are doing Bridging over Point-to-point media, such as MPLS, ATM, TDM, Frame or L2TP. At second approximation: Things may not be as bad as they seem above, if we consider the following: a) Many existing applications, which provide MAN/WAN based multipoint bridging (emulation) services are small and limited to the aggregation portions of the WAN cloud anyway. Thus, you could rely on *STP completely, because you can usually construct a spanning tree, which makes efficient use of the physical tree. b) Some applications, which do cross the core of the WAN, do so in such limited fashion, that a spanning tree can again be constructed, which makes efficient use of available interconnect and puts no or few useful links into blocking. >Thanks, >Muneyoshi Suzuki >Nippon Telegraph and Telephone Corp. Thanks, Joris Wils Consulting SW Engineer Coriolis Networks jwils@coriolisnet.com/978-264-1904x667 From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 10:46:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12243 for ; Tue, 22 Apr 2003 10:46:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MEmcf06991 for ; Tue, 22 Apr 2003 10:48:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MEmVS09795 for ; Tue, 22 Apr 2003 10:48:31 -0400 (EDT) Message-Id: <200304221442.h3MEgm4W000458@rtp-core-1.cisco.com> To: Norman Finn cc: Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Fri, 18 Apr 2003 16:46:24 -0700. <3EA08E50.7011B94@cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.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: Tue, 22 Apr 2003 10:42:47 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Norm> Unless or until an FF has a pseudowire up and running to every member Norm> of its [auto-discovered] list, it must present ifOperState == DOWN to Norm> its upper layers. Then a single flaky PE would bring down the entire emulated LAN, and the emulated LAN would stay down until either that PE comes back up, or the discovery procedure successfully removes that PE from the list and successfully informs all the other PEs. This doesn't seem that good. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 10:46: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 KAA12275 for ; Tue, 22 Apr 2003 10:46:52 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MEn3f07414 for ; Tue, 22 Apr 2003 10:49:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MEmwS10364 for ; Tue, 22 Apr 2003 10:48:59 -0400 (EDT) Message-Id: <200304221439.h3MEdV4W029413@rtp-core-1.cisco.com> To: Muneyoshi Suzuki cc: ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Wed, 16 Apr 2003 10:41:10 +0900. <20030416.104110.71147346.suzuki.muneyoshi@lab.ntt.co.jp> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.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: Tue, 22 Apr 2003 10:39:29 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: > there is a possibility that the recovery time of the protection mechanism > may affect failure detection of user-STP. I think the only feasible "solution" for this would be for the user-STP time constants to be appropriately adjusted to the recovery time frame of the PSN. It helps to use a PSN which has a shorter recovery time frame, but all we can really do is note the relationship. > However, failure of a single LSP in the mesh is logically equivalent with > the situation that the communications between two ports in the hub- > repeater fail, *but the remains are normal* ... I think this kind of > failure is not assumed in STP protocol design. Recovery from this should be at the PSN layer, I think, not at the VPLS layer. > I think there is a much simple and robust solution. Connect Provider > Bridges with point-to-point LSPs and use STP/RSTP in the network, and > don't use split-horizon scheme. You're proposing that all the VPLS traffic should be confined to a single spanning tree, (with the resulting sub-optimal routing), to compensate for the case in which the PSN's routing can't get traffic from A to B, but can get traffic from A to C and from C to B? That's a very large cost for an extraordinarily small benefit. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 11:40:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14098 for ; Tue, 22 Apr 2003 11:40:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MFgPf04960 for ; Tue, 22 Apr 2003 11:42:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MFgMS27050 for ; Tue, 22 Apr 2003 11:42:22 -0400 (EDT) Message-ID: <3EA56202.35A4EEEB@alcatel.com> Date: Tue, 22 Apr 2003 11:38:42 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Norman Finn , Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200304221442.h3MEgm4W000458@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, That's the point, a single flaky PE (in full-meshed with split-horizon) would cause improper LAN emulation, bringing down customer/access network bridging/routing (even if we don't do what Norm Finn is proposing here). Hopefully you would acknowledge the dilemma here. Thanks, Cheng-Yin Eric Rosen wrote: > > Norm> Unless or until an FF has a pseudowire up and running to every member > Norm> of its [auto-discovered] list, it must present ifOperState == DOWN to > Norm> its upper layers. > > Then a single flaky PE would bring down the entire emulated LAN, and the > emulated LAN would stay down until either that PE comes back up, or the > discovery procedure successfully removes that PE from the list and > successfully informs all the other PEs. This doesn't seem that good. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 11:48: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 LAA14317 for ; Tue, 22 Apr 2003 11:48:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MFp4f09204 for ; Tue, 22 Apr 2003 11:51:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MFp0S06929 for ; Tue, 22 Apr 2003 11:51:01 -0400 (EDT) From: Emmanuel.Desmet@alcatel.be Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft To: ppvpn@nortelnetworks.com Cc: emmanuel.desmet@alcatel.be X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Sender: Emmanuel.Desmet@alcatel.be Date: Tue, 22 Apr 2003 17:28:44 +0200 X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/22/2003 17:29:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-SMTP-HELO: relay4.alcatel.be X-SMTP-MAIL-FROM: Emmanuel.Desmet@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc245.alcatel.be [195.207.101.245] X-LYRIS-Message-Id: Though maybe too late, I'd anyway like to also back this I-D moving forward. Regards, emmanuel -------- Original Message -------- Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft Date: Mon, 14 Apr 2003 11:32:08 -0400 From: "Andrew G. Malis" To: "Rick Wilder" CC: Rick, I would like to support making this a WG draft. Thanks, Andy ------- At 4/10/2003 11:20 AM -0400, Rick Wilder wrote: > As noted in the minutes, at the San Francisco meeting strong interest > was expressed in pursuing the draft-lasserre-vkompella-ppvpn-vplsas a > working group draft. We agreed to finalize that decision only after > the WG participants who werent there could have a say. > > > > So, if there are opinions that have not been heard, now is the time, > and this list is the place. Lets set a one-week limit to conclude this > issue. > > > > Rick > > > > - > ------------------------------------------------------------------------------------------------------------------------------------------------- > > From the minutes: > > > > 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. > > > [snipped] > > Marco: asked for show of hands to make this a wG draft. > Strong interest was shown in room. Further discussion on the list. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 12:04:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14709 for ; Tue, 22 Apr 2003 12:04:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MG6kf04949 for ; Tue, 22 Apr 2003 12:06:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MG6aS10787 for ; Tue, 22 Apr 2003 12:06:37 -0400 (EDT) Subject: PE-CE addressing draft To: ppvpn@nortelnetworks.com, "Marco Carugi" , rwilder@masergy.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Vincent.Parfait@equant.com Date: Tue, 22 Apr 2003 17:38:14 +0200 X-MIMETrack: Serialize by Router on Nice1/Nice/SITA/WW(Release 5.0.9a |January 7, 2002) at 04/22/2003 05:38:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SMTP-HELO: mx1.sita.int X-SMTP-MAIL-FROM: Vincent.Parfait@equant.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mx1.sita.int [57.250.224.237] X-LYRIS-Message-Id: This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt I invite you to read through this new version and give your feedback to the list. The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space. Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document. Vincent Parfait Equant From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 12:18:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15147 for ; Tue, 22 Apr 2003 12:18:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MGL7f08544 for ; Tue, 22 Apr 2003 12:21:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MGL1S25681 for ; Tue, 22 Apr 2003 12:21:02 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 22 Apr 2003 18:15:29 +0200 From: "Andrea Ferrarese" To: Subject: Draft-kpmpella-ppvpn-vpls-01 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SMTP-HELO: vrn-inetsrv-01.agsm.it X-SMTP-MAIL-FROM: Andrea.Ferrarese@agsm.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [62.94.158.34] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit We support draft-kompella-ppvpn-vpls-01 We found that BGP control plane give scalability and flexibility. We like the possibility to maintain the actual config and VPN infrastructure for both l2 and l3 VPN. Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 12:44:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15842 for ; Tue, 22 Apr 2003 12:43:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MGkBf14586 for ; Tue, 22 Apr 2003 12:46:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MGk8S13310 for ; Tue, 22 Apr 2003 12:46:08 -0400 (EDT) Message-ID: From: "Schliesser, Benson" To: ppvpn@nortelnetworks.com, "Marco Carugi" , rwilder@masergy.com Cc: "'Vincent.Parfait@equant.com'" Subject: RE: PE-CE addressing draft Date: Tue, 22 Apr 2003 11:42:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-ECS-MailScanner: No virus is found X-SMTP-HELO: mailgate1b.savvis.net X-SMTP-MAIL-FROM: benson.schliesser@Savvis.net X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate1b.savvis.net [216.91.182.6] X-LYRIS-Message-Id: To say this in the politically correct fashion... I am from a Service Provider, and I believe that this draft should be made a working-group document. My only suggestion is that it be generalized to less-specific 'PPVPNs' instead of '2547bis VPNs', since it is useful also to the VR and CE-CE models. -Benson > -----Original Message----- > From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] > Sent: Tuesday, April 22, 2003 10:38 AM > To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com > Subject: PE-CE addressing draft > > > This is to inform you that the draft-guichard-pe-ce-addr has > been updated : > http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt > I invite you to read through this new version and give your > feedback to the > list. > > The main motivation for this proposal is to simplify the > Service Providers > operations in the scenario where they monitor CE-PE links, and/or CE > routers, while at the same time conserving IPV4 address space. > Large Service Providers such as Equant, ATT and Arcor are > supporting this > draft and are requesting that it becomes a working group document. > > Vincent Parfait > Equant > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 13:11: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 NAA16533 for ; Tue, 22 Apr 2003 13:11:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MHDGf02338 for ; Tue, 22 Apr 2003 13:13:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MHDBS05191 for ; Tue, 22 Apr 2003 13:13:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: PE-CE addressing draft Date: Tue, 22 Apr 2003 13:07:37 -0400 Message-ID: Thread-Topic: PE-CE addressing draft Thread-Index: AcMI58XPVheEovl1Qj6kckIdYJPCswACBIdA From: "Aleksey Tolchinskiy" To: , X-SMTP-HELO: ms3.us.didata.com X-SMTP-MAIL-FROM: Aleksey.Tolchinskiy@us.didata.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ms3.us.didata.com [204.56.122.90] X-LYRIS-Message-Id: I would like to support the "draft-guichard-pe-ce-addr-02.txt" becoming a WG document. This is a personal opinion and is not expressed on behalf of the company I work for. Aleksey -----Original Message----- From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] Sent: Tuesday, April 22, 2003 11:38 AM To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com Subject: PE-CE addressing draft This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt I invite you to read through this new version and give your feedback to the list. The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space. Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document. Vincent Parfait Equant From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 14:12:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19158 for ; Tue, 22 Apr 2003 14:12:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MIElf22380 for ; Tue, 22 Apr 2003 14:14:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MIEeS21254 for ; Tue, 22 Apr 2003 14:14:41 -0400 (EDT) Message-Id: <200304221757.h3MHvi4W001390@rtp-core-1.cisco.com> To: Cheng-Yin.Lee@alcatel.com cc: Norman Finn , Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Tue, 22 Apr 2003 11:38:42 -0400. <3EA56202.35A4EEEB@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: Tue, 22 Apr 2003 13:57:43 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Cheng-Yin> a single flaky PE (in full-meshed with split-horizon) would cause Cheng-Yin> improper LAN emulation, bringing down customer/access network Cheng-Yin> bridging/routing (even if we don't do what Norm Finn is proposing Cheng-Yin> here). I don't think that's been shown. If a particular PE is not behaving properly, then there are going to be issues communicating with the systems that are behind it. I don't understand why this brings the customer's whole network down. Cheng-Yin> Hopefully you would acknowledge the dilemma here. I agree that there are unresolved problems regarding the effect of PSN events on the customer's bridged network. I don't know whether these are solvable or not, just that more work needs to be done. (Of course, all these problems can be eliminated by making all the CE devices be routers, and using an IPLS service instead ;-)) From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 15:08:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21506 for ; Tue, 22 Apr 2003 15:08:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MJAOf10487 for ; Tue, 22 Apr 2003 15:10:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MJAIS10166 for ; Tue, 22 Apr 2003 15:10:18 -0400 (EDT) Reply-To: From: "himanshu shah" To: , Cc: "'Norman Finn'" , "'Muneyoshi Suzuki'" , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Tue, 22 Apr 2003 15:05:55 -0400 Message-ID: <000301c30902$34433470$021ea8c0@HSHAH700> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200304221757.h3MHvi4W001390@rtp-core-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-SMTP-HELO: smtp02.mrf.mail.rcn.net X-SMTP-MAIL-FROM: hshah@rcn.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp02.mrf.mail.rcn.net [207.172.4.61] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I agree with Eric on two points, 1) Verifying FF synchronization using low-grade, high-level loopbacks (such as ping), is difficult aspects of VPLS 2) Using IPLS instead and relying on CE router mechanisms to handle individual loss of connectivity /himanshu -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Tuesday, April 22, 2003 1:58 PM To: Cheng-Yin.Lee@alcatel.com Cc: Norman Finn; Muneyoshi Suzuki; ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents Cheng-Yin> a single flaky PE (in full-meshed with split-horizon) would cause Cheng-Yin> improper LAN emulation, bringing down customer/access network Cheng-Yin> bridging/routing (even if we don't do what Norm Finn is proposing Cheng-Yin> here). I don't think that's been shown. If a particular PE is not behaving properly, then there are going to be issues communicating with the systems that are behind it. I don't understand why this brings the customer's whole network down. Cheng-Yin> Hopefully you would acknowledge the dilemma here. I agree that there are unresolved problems regarding the effect of PSN events on the customer's bridged network. I don't know whether these are solvable or not, just that more work needs to be done. (Of course, all these problems can be eliminated by making all the CE devices be routers, and using an IPLS service instead ;-)) From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 15:19: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 PAA22485 for ; Tue, 22 Apr 2003 15:19:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MJMBf15285 for ; Tue, 22 Apr 2003 15:22:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3MJM7S17382 for ; Tue, 22 Apr 2003 15:22:08 -0400 (EDT) X-Originating-IP: [219.65.33.213] X-Originating-Email: [rtrfwdfrccie@hotmail.com] From: "Amit Singh" To: "Ppvpn" Subject: SUBSCRIBE ppvpn Date: Wed, 23 Apr 2003 01:16:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C30935.EC570B30" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 22 Apr 2003 19:17:50.0790 (UTC) FILETIME=[DDD6CE60:01C30903] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: rtrfwdfrccie@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: oe60.law11.hotmail.com [64.4.16.195] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C30935.EC570B30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SUBSCRIBE ppvpn ------=_NextPart_000_0081_01C30935.EC570B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SUBSCRIBE = ppvpn
------=_NextPart_000_0081_01C30935.EC570B30-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 20:45:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02771 for ; Tue, 22 Apr 2003 20:45:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3N0lDf01064 for ; Tue, 22 Apr 2003 20:47:13 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3N0lAS22860 for ; Tue, 22 Apr 2003 20:47:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20030422173117.01cb2e98@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Apr 2003 17:44:46 -0700 To: erosen@cisco.com, Norman Finn From: Ali Sajassi Subject: Re: Comments on the L2 VPN framework and solutions documents Cc: Muneyoshi Suzuki , ppvpn@nortelnetworks.com In-Reply-To: <200304221442.h3MEgm4W000458@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 10:42 AM 4/22/2003 -0400, Eric Rosen wrote: >Norm> Unless or until an FF has a pseudowire up and running to every member >Norm> of its [auto-discovered] list, it must present ifOperState == DOWN to >Norm> its upper layers. > >Then a single flaky PE would bring down the entire emulated LAN, and the >emulated LAN would stay down until either that PE comes back up, or the >discovery procedure successfully removes that PE from the list and >successfully informs all the other PEs. This doesn't seem that good. It also seems to me that taking the entire Emulated LAN (set of PWs) down and up as the result of a PW or node failure, might be too much (e.g., causing unnecessary service interruption). With respect to failures affecting the Emulated LAN, there can be two types: a) PW failure: PW failure should be taken care by PSN - if not, then there is something wrong with the node and it should be consider as node failure, right ? b) node failure: If there is a redundant PE, then redundancy mechanism takes care of it (e.g., intra-island STP) and if PE is not redundant, then it gets removed from the mesh but the remaining PEs still maintain the full-mesh with each other. It seems if the customer BPDU timer is adjusted to compensate for these two caeses (PW recovery by PSN and node recovery by SP STP), then it should be O.K. -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 20:58:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02961 for ; Tue, 22 Apr 2003 20:58:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3N10of04615 for ; Tue, 22 Apr 2003 21:00:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3N10mS28016 for ; Tue, 22 Apr 2003 21:00:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20030422174705.01c6b518@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Apr 2003 17:58:38 -0700 To: "Andrea Ferrarese" , From: Ali Sajassi Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: I'd like to know how many of the service providers who support this draft, only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to offer point-to-point Ethernet service? If a service provider plans to offer both types of services, then do they plan to use BGP for PW signaling of PtP Ethernet service ? Thanks, Ali At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: >We support draft-kompella-ppvpn-vpls-01 > >We found that BGP control plane give scalability and flexibility. We >like >the possibility to maintain the actual config and VPN infrastructure >for >both l2 and l3 VPN. > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 22 22:56:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04928 for ; Tue, 22 Apr 2003 22:56:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3N2wtf11602 for ; Tue, 22 Apr 2003 22:58:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3N2wqS22732 for ; Tue, 22 Apr 2003 22:58:52 -0400 (EDT) Date: Wed, 23 Apr 2003 11:53:29 +0900 (JST) Message-Id: <20030423.115329.07564874.suzuki.muneyoshi@lab.ntt.co.jp> To: erosen@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <200304221439.h3MEdV4W029413@rtp-core-1.cisco.com> References: <20030416.104110.71147346.suzuki.muneyoshi@lab.ntt.co.jp> <200304221439.h3MEdV4W029413@rtp-core-1.cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > > However, failure of a single LSP in the mesh is logically equivalent with > > the situation that the communications between two ports in the hub- > > repeater fail, *but the remains are normal* ... I think this kind of > > failure is not assumed in STP protocol design. > Recovery from this should be at the PSN layer, I think, not at the VPLS > layer. Neither PNS nor VPLS layer guarantee recovery. So, these are not solution. > You're proposing that all the VPLS traffic should be confined to a single > spanning tree, (with the resulting sub-optimal routing), to compensate for > the case in which the PSN's routing can't get traffic from A to B, but can > get traffic from A to C and from C to B? That's a very large cost for an > extraordinarily small benefit. It is much better than the fragility solution that has loop, blackhole or unreliable flaky PEs problems. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 11:36:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23611 for ; Wed, 23 Apr 2003 11:36:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NFcvG06702 for ; Wed, 23 Apr 2003 11:38:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NFcqS18453 for ; Wed, 23 Apr 2003 11:38:52 -0400 (EDT) Message-ID: <3EA6AC4C.6010702@cnaf.infn.it> Date: Wed, 23 Apr 2003 17:07:56 +0200 From: cristina vistoli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: ppvpn@nortelnetworks.com Subject: draft-kompella-ppvpn-vpls-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: iris.cnaf.infn.it X-SMTP-MAIL-FROM: cristina.vistoli@cnaf.infn.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: iris.cnaf.infn.it [131.154.3.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit We would like to support draft-kompella-ppvpn-vpls-01.txt. We like expecially the BGP Control Plane design. Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 11:40:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23742 for ; Wed, 23 Apr 2003 11:40:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NFgTG10320 for ; Wed, 23 Apr 2003 11:42:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NFgPS22966 for ; Wed, 23 Apr 2003 11:42:25 -0400 (EDT) Message-ID: From: Ives Dekoninck To: "'Vincent.Parfait@equant.com'" , "'ppvpn@nortelnetworks.com'" Cc: Ives Dekoninck Subject: RE: PE-CE addressing draft Date: Wed, 23 Apr 2003 10:11:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3096F.FB064DA0" 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_01C3096F.FB064DA0 Content-Type: text/plain; charset="iso-8859-1" Hi, I would also like to support the "draft-guichard-pe-ce-addr-02.txt" to become a workgroup document. An additional advantage of not having to coordinate addresses with the client is that we can summarise a block towards the management VPN which makes configuration more scalable and simpler. I am doing an implementation for a customer of ours and he also is in favour of this draft document. -Ives- -----Original Message----- From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchinskiy@us.didata.com] Sent: mardi 22 avril 2003 19:08 To: Vincent.Parfait@equant.com; ppvpn@nortelnetworks.com Subject: RE: PE-CE addressing draft I would like to support the "draft-guichard-pe-ce-addr-02.txt" becoming a WG document. This is a personal opinion and is not expressed on behalf of the company I work for. Aleksey -----Original Message----- From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] Sent: Tuesday, April 22, 2003 11:38 AM To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com Subject: PE-CE addressing draft This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt I invite you to read through this new version and give your feedback to the list. The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space. Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document. Vincent Parfait Equant ------_=_NextPart_001_01C3096F.FB064DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PE-CE addressing draft

Hi,

I would also like to support the = "draft-guichard-pe-ce-addr-02.txt" to become a workgroup = document.

An additional advantage of not having to coordinate = addresses with the client is that we can summarise a block towards the = management VPN which makes configuration more scalable and = simpler.

I am doing an implementation for a customer of ours = and he also is in favour of this draft document.

-Ives-



-----Original Message-----
From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchin= skiy@us.didata.com]
Sent: mardi 22 avril 2003 19:08
To: Vincent.Parfait@equant.com; = ppvpn@nortelnetworks.com
Subject: RE: PE-CE addressing draft


I would like to support the = "draft-guichard-pe-ce-addr-02.txt" becoming
a WG document.

This is a personal opinion and is not expressed on = behalf of the company
I work for.

Aleksey

-----Original Message-----
From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant= .com]
Sent: Tuesday, April 22, 2003 11:38 AM
To: ppvpn@nortelnetworks.com; Marco Carugi; = rwilder@masergy.com
Subject: PE-CE addressing draft


This is to inform you that the = draft-guichard-pe-ce-addr has been
updated :
http://www.ietf.org/internet-drafts/draft-guichard-pe-= ce-addr-02.txt
I invite you to read through this new version and = give your feedback to
the
list.

The main motivation for this proposal is to simplify = the Service
Providers
operations in the scenario where they monitor CE-PE = links, and/or CE
routers, while at the same time conserving IPV4 = address space.
Large Service Providers such as Equant, ATT and = Arcor are supporting
this
draft and are requesting that it becomes a working = group document.

Vincent Parfait
Equant





------_=_NextPart_001_01C3096F.FB064DA0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 11:51: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 LAA24130 for ; Wed, 23 Apr 2003 11:51:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NFrRG14989 for ; Wed, 23 Apr 2003 11:53:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NFrLS06870 for ; Wed, 23 Apr 2003 11:53:22 -0400 (EDT) Date: Wed, 23 Apr 2003 16:20:46 +0200 From: =?ISO-8859-1?Q?Jose_Luis_Pe=F1a_Sedano?= Subject: GVPLS To: ppvpn@nortelnetworks.com, "Nicolas Almendro" Message-id: <3EA6A13E.8000401@tid.es> Organization: Telefonica Investigacion y Desarrollo MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 X-Accept-Language: es-ES User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-SMTP-HELO: tid X-SMTP-MAIL-FROM: sedano@tid.es X-SMTP-RCPT-TO: nicolas.almendro@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tidos.tid.es [193.145.240.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id LAA24130 I support GVPLS work to be continued in the PPVNP group José Luis Peña Consultant Telefonica R&D, (Spain) From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 11:57:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24414 for ; Wed, 23 Apr 2003 11:57:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NFxYG21451 for ; Wed, 23 Apr 2003 11:59:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NFxSS15653 for ; Wed, 23 Apr 2003 11:59:30 -0400 (EDT) Message-ID: <3EA63B6D.D6542946@cisco.com> Date: Wed, 23 Apr 2003 09:06:21 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ali Sajassi CC: Andrea Ferrarese , ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 References: <4.3.2.7.2.20030422174705.01c6b518@airborne.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Ali, Very valid question ;) ... Even more valid would be to rephrase it to say: "Do all service providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and plan to offer some other forms of L2 p2p trasport would have objections to run both signalling menthods for setting them up (BGP for VPLS and targeted LDP for all other VPWS)" ? My personal _individual_ opinion is that vendors should support both signalling options as it seems quite common that a proper and fine tuned tool for any work produces better results :). Another spin on this thread is that if Juha's Radius propsal would be selected as an auto-discovery option clearly there should be no need to mess with BGP at all and signalling could be done with LDP in all cases. But if one selects to use BGP for VPLS autodiscovery adding few more bytes there with encoded very clever way of distributing label informations especially for VPLS services seems very reasonable. R. > Ali Sajassi wrote: > > I'd like to know how many of the service providers who support this draft, > only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to > offer point-to-point Ethernet service? > > If a service provider plans to offer both types of services, then do they > plan to use BGP for PW signaling of PtP Ethernet service ? > > Thanks, > Ali > > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > >We support draft-kompella-ppvpn-vpls-01 > > > >We found that BGP control plane give scalability and flexibility. We > >like > >the possibility to maintain the actual config and VPN infrastructure > >for > >both l2 and l3 VPN. > > > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 12:01: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 MAA24557 for ; Wed, 23 Apr 2003 12:01:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NG43G13825 for ; Wed, 23 Apr 2003 12:04:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NG3tS29832 for ; Wed, 23 Apr 2003 12:03:56 -0400 (EDT) X-Lotus-FromDomain: ARCOR From: Thomas.Kuehne@arcor.net To: ppvpn@nortelnetworks.com cc: Lars.Braeunig@arcor.net, Walter.Haeffner@arcor.net Message-ID: <41256D11.002A6461.00@slz-01-hub01.arcor.net> Date: Wed, 23 Apr 2003 08:42:54 +0100 Subject: Antwort: PE-CE addressing draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SMTP-HELO: mail.arcor.net X-SMTP-MAIL-FROM: Thomas.Kuehne@arcor.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.arcor.net [145.253.32.2] X-LYRIS-Message-Id: Hi all, As Vincent has already noted, Arcor is also requesting that this draft be adopted as a working group document. Regards, Thomas Kuehne Arcor Vincent.Parfait@equant.com 22.04.2003 16:38 An: ppvpn@nortelnetworks.com, "Marco Carugi" , rwilder@masergy.com Kopie: Thema: PE-CE addressing draft This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt I invite you to read through this new version and give your feedback to the list. The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space. Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document. Vincent Parfait Equant From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 12:07:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24766 for ; Wed, 23 Apr 2003 12:07:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NG9qG17614 for ; Wed, 23 Apr 2003 12:09:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NG9lS18121 for ; Wed, 23 Apr 2003 12:09:48 -0400 (EDT) Message-Id: <200304231336.h3NDaUlY013204@rtp-core-1.cisco.com> To: Muneyoshi Suzuki cc: ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-reply-to: Your message of Wed, 23 Apr 2003 11:53:29 +0900. <20030423.115329.07564874.suzuki.muneyoshi@lab.ntt.co.jp> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.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: Wed, 23 Apr 2003 09:36:30 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Eric> Recovery from this should be at the PSN layer, I think, not at the Eric> VPLS layer. Muneyoshi> Neither PNS nor VPLS layer guarantee recovery. So, these are not Muneyoshi> solution. There is no way to guarantee recovery against every possible failure. If you're sending the A-->C traffic on the path A-->B-->C, becuase that path is on the spanning tree, you might still have a problem in B where it drops the traffic that arrives from A and is destined to C. I'd say that this failure scenario is at least as likely as the other, probably more likely, because it involves more VPLS mechanisms. Eric> You're proposing that all the VPLS traffic should be confined to a Eric> single spanning tree, (with the resulting sub-optimal routing), to Eric> compensate for the case in which the PSN's routing can't get traffic Eric> from A to B, but can get traffic from A to C and from C to B? That's Eric> a very large cost for an extraordinarily small benefit. Muneyoshi> It is much better than the fragility solution that has loop, Muneyoshi> blackhole or unreliable flaky PEs problems. That's not much of a cost-benefit analysis. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 12:11: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 MAA24876 for ; Wed, 23 Apr 2003 12:11:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NGDgG20672 for ; Wed, 23 Apr 2003 12:13:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NGDYS29869 for ; Wed, 23 Apr 2003 12:13:35 -0400 (EDT) Message-Id: <3EA69F2B.808FB1E7@francetelecom.com> Date: Wed, 23 Apr 2003 10:11:55 -0400 From: "LIAN Franklin FTLD/IAP" Organization: France Telecom Long Distance X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vincent.Parfait@equant.com CC: ppvpn@nortelnetworks.com, "Marco Carugi" , rwilder@masergy.com Subject: Re: PE-CE addressing draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: relais-inet-02.francetelecom.fr X-SMTP-MAIL-FROM: franklin.lian@francetelecom.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: relais-inet.francetelecom.com [212.234.67.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit This message represents my personal opinions only. I agree that it makes sense to ask all SPs use the same IP pool for allocating addresses to PE-CE links and CE router loopback. In the draft, there is no detail information regarding which /8 IP block will be reserved, and I assume the /8 will come from an unassinged registered IP space. It will be great if IANA can approve such a /8 request because it makes the SP's life much easier. However, without the new /8 block approval, I think we may still get around the address problem with alternative solutions. In the current practice of allocating IP addresses from [RFC-1918] to the PE-CE link, the SP has to negoicate with the customer to see which private IP blocks from [RFC-1918] have been implemented in the customer's network and avoid those blocks by assinging IP from other private IP blocks. To do this, the SP has reserved several private IP blocks from [FRC-1918], and switch from one block to another when conflicts are found between the SP and customer. I think the same practice can be applied to the draft. Instead of allocating one /8 block, two /8 blocks can be recommended, and these /8 blocks do not have to be approved by IANA. For example, a SP can pickup 1.0.0.0/8 and 100.0.0.0/8 for the IP provisioning. If one customer does not fit in 1.0.0.0/8, the SP can use the IP from 100.0.0.0/8 for the customer. Well, I still like to have one dedicated /8 registered IP from IANA. I guess we can live without one. Zidan Vincent.Parfait@equant.com wrote: > > This is to inform you that the draft-guichard-pe-ce-addr has been updated : > http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt > I invite you to read through this new version and give your feedback to the > list. > > The main motivation for this proposal is to simplify the Service Providers > operations in the scenario where they monitor CE-PE links, and/or CE > routers, while at the same time conserving IPV4 address space. > Large Service Providers such as Equant, ATT and Arcor are supporting this > draft and are requesting that it becomes a working group document. > > Vincent Parfait > Equant From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 12:18:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25044 for ; Wed, 23 Apr 2003 12:18:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NGKnG24215 for ; Wed, 23 Apr 2003 12:20:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NGKiS21669 for ; Wed, 23 Apr 2003 12:20:44 -0400 (EDT) Date: Wed, 23 Apr 2003 14:12:32 +0900 (JST) Message-Id: <20030423.141232.41706744.suzuki.muneyoshi@lab.ntt.co.jp> To: jwils@coriolisnet.com Cc: nfinn@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: References: 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 Joris, Thanks for clarification. First, needless to say, I aware link block problem of STP/RSTP. We definitely need a solution. However, the solution must be robust. To enable large scale deployment, it must not force the operators and users to reboot boxes even if the worst case. The full mesh approach is a fragility solution that has loop, blackhole or unreliable flaky PEs problems, so we have no choice other than the conventional scheme. Second, if we regard xSTP as routing protocols, obviously there are less efficient than OSPF/BGP. However, if we regard xSTP as protocols for protection, these are not bad. If we reserve paths for fast protection for the mesh, there are active and standby meshes. I think this problem is not much different form xSTP link block problem. Finally, as far as I know, currently providers don't use STP due to long recovery time; instead manually configure a single tree topology. However, a single tree topology is not bad. Please image conventional telephone network architecture; it is a tree. A tree is one of fundamental network architecture. However, needless to say, topology free is much better than a tree. Therefore, I proposed OSPF or BGP-4 extension for MAC routing in Atlanta meeting (please see my slides in the last November). I think it is not easy to progress this work in the IETF, but I believe we need this kind of work in the near future. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 12:21: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 MAA25138 for ; Wed, 23 Apr 2003 12:21:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NGNrG26900 for ; Wed, 23 Apr 2003 12:23:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NGNmS00845 for ; Wed, 23 Apr 2003 12:23:48 -0400 (EDT) Message-ID: From: Ives Dekoninck To: "'Vincent.Parfait@equant.com'" , "'ppvpn@nortelnetworks.com'" Subject: RE: PE-CE addressing draft Date: Wed, 23 Apr 2003 09:06:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30966.E06622D0" 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_01C30966.E06622D0 Content-Type: text/plain; charset="iso-8859-1" Hi, I would also like to support the "draft-guichard-pe-ce-addr-02.txt" to become a workgroup document. An additional advantage of not having to coordinate addresses with the client is that we can summarise a block towards the management VPN which makes configuration more scalable and simpler. I am doing an implementation for a customer of ours and he also is in favour of this draft document. -Ives- -----Original Message----- From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchinskiy@us.didata.com] Sent: mardi 22 avril 2003 19:08 To: Vincent.Parfait@equant.com; ppvpn@nortelnetworks.com Subject: RE: PE-CE addressing draft I would like to support the "draft-guichard-pe-ce-addr-02.txt" becoming a WG document. This is a personal opinion and is not expressed on behalf of the company I work for. Aleksey -----Original Message----- From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] Sent: Tuesday, April 22, 2003 11:38 AM To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com Subject: PE-CE addressing draft This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt I invite you to read through this new version and give your feedback to the list. The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space. Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document. Vincent Parfait Equant ------_=_NextPart_001_01C30966.E06622D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PE-CE addressing draft

Hi,

I would also like to support the = "draft-guichard-pe-ce-addr-02.txt" to become a workgroup = document.

An additional advantage of not having to coordinate = addresses with the client is that we can summarise a block towards the = management VPN which makes configuration more scalable and = simpler.

I am doing an implementation for a customer of ours = and he also is in favour of this draft document.

-Ives-



-----Original Message-----
From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchin= skiy@us.didata.com]
Sent: mardi 22 avril 2003 19:08
To: Vincent.Parfait@equant.com; = ppvpn@nortelnetworks.com
Subject: RE: PE-CE addressing draft


I would like to support the = "draft-guichard-pe-ce-addr-02.txt" becoming
a WG document.

This is a personal opinion and is not expressed on = behalf of the company
I work for.

Aleksey

-----Original Message-----
From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant= .com]
Sent: Tuesday, April 22, 2003 11:38 AM
To: ppvpn@nortelnetworks.com; Marco Carugi; = rwilder@masergy.com
Subject: PE-CE addressing draft


This is to inform you that the = draft-guichard-pe-ce-addr has been
updated :
http://www.ietf.org/internet-drafts/draft-guichard-pe-= ce-addr-02.txt
I invite you to read through this new version and = give your feedback to
the
list.

The main motivation for this proposal is to simplify = the Service
Providers
operations in the scenario where they monitor CE-PE = links, and/or CE
routers, while at the same time conserving IPV4 = address space.
Large Service Providers such as Equant, ATT and = Arcor are supporting
this
draft and are requesting that it becomes a working = group document.

Vincent Parfait
Equant





------_=_NextPart_001_01C30966.E06622D0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 13:12: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 NAA26709 for ; Wed, 23 Apr 2003 13:12:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NHEhG26746 for ; Wed, 23 Apr 2003 13:14:43 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NHEah22943 for ; Wed, 23 Apr 2003 13:14:36 -0400 (EDT) Subject: Re: PE-CE addressing draft To: franklin.lian@francetelecom.com Cc: "Marco Carugi" , ppvpn@nortelnetworks.com, rwilder@masergy.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Vincent.Parfait@equant.com Date: Wed, 23 Apr 2003 17:58:45 +0200 X-MIMETrack: Serialize by Router on Nice1/Nice/SITA/WW(Release 5.0.9a |January 7, 2002) at 04/23/2003 05:58:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SMTP-HELO: mx1.sita.int X-SMTP-MAIL-FROM: Vincent.Parfait@equant.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: mx1.sita.int [57.250.224.237] X-LYRIS-Message-Id: Zidan, Thanks for your comments. Regarding the alternatives your propose : - use of RFC- 1918 addresses : As already explained in the draft (3.1), this approach is time consuming and intensive in terms of address management. With large customers this can even reveal impossible. As an example we have a customer with 20K VPN routing entries part of RFC-1918. Since these entries are very scattered the use of 2 alternate blocks would be far from being enough, in fact we would need hundreds of such blocks ! Then we would meet serious issues in term of management and performance : complexity of access lists, no possibility to summarize towards the management VPN ... - use of /8 blocks currently reserved like 1.0.0.0/8 or 100.0.0.0/8 To my knowledge these are public resources that we should not use. The purpose of this draft is exactly to get an official assigment of these resources by IANA to Service Providers. Vincent "LIAN Franklin FTLD/IAP" To: Vincent.Parfait@equant.com 23/04/2003 16:11 cc: ppvpn@nortelnetworks.com, Marco Carugi , rwilder@masergy.com bcc: Subject: Re: PE-CE addressing draft This message represents my personal opinions only. I agree that it makes sense to ask all SPs use the same IP pool for allocating addresses to PE-CE links and CE router loopback. In the draft, there is no detail information regarding which /8 IP block will be reserved, and I assume the /8 will come from an unassinged registered IP space. It will be great if IANA can approve such a /8 request because it makes the SP's life much easier. However, without the new /8 block approval, I think we may still get around the address problem with alternative solutions. In the current practice of allocating IP addresses from [RFC-1918] to the PE-CE link, the SP has to negoicate with the customer to see which private IP blocks from [RFC-1918] have been implemented in the customer's network and avoid those blocks by assinging IP from other private IP blocks. To do this, the SP has reserved several private IP blocks from [FRC-1918], and switch from one block to another when conflicts are found between the SP and customer. I think the same practice can be applied to the draft. Instead of allocating one /8 block, two /8 blocks can be recommended, and these /8 blocks do not have to be approved by IANA. For example, a SP can pickup 1.0.0.0/8 and 100.0.0.0/8 for the IP provisioning. If one customer does not fit in 1.0.0.0/8, the SP can use the IP from 100.0.0.0/8 for the customer. Well, I still like to have one dedicated /8 registered IP from IANA. I guess we can live without one. Zidan Vincent.Parfait@equant.com wrote: > > This is to inform you that the draft-guichard-pe-ce-addr has been updated : > http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt > I invite you to read through this new version and give your feedback to the > list. > > The main motivation for this proposal is to simplify the Service Providers > operations in the scenario where they monitor CE-PE links, and/or CE > routers, while at the same time conserving IPV4 address space. > Large Service Providers such as Equant, ATT and Arcor are supporting this > draft and are requesting that it becomes a working group document. > > Vincent Parfait > Equant From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 13:25:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27236 for ; Wed, 23 Apr 2003 13:25:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NHS7G01575 for ; Wed, 23 Apr 2003 13:28:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NHS2h01103 for ; Wed, 23 Apr 2003 13:28:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 19:07:53 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMJM9SYCHihuvjCRRySW69uXNobFQAhwweT From: "Hector Avalos" To: , X-OriginalArrivalTime: 23 Apr 2003 17:07:54.0488 (UTC) FILETIME=[E14B4780:01C309BA] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA27236 I think that this question should be asked to all SPs regadless of the draft they support. And if they plan to use vpls to deliver p2p eth services. Thanks Hector -------------------------- Sent from my Wireless Handheld -----Original Message----- From: Ali Sajassi To: Andrea Ferrarese ; ppvpn@nortelnetworks.com Sent: Wed Apr 23 01:58:38 2003 Subject: Re: Draft-kpmpella-ppvpn-vpls-01 I'd like to know how many of the service providers who support this draft, only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to offer point-to-point Ethernet service? If a service provider plans to offer both types of services, then do they plan to use BGP for PW signaling of PtP Ethernet service ? Thanks, Ali At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: >We support draft-kompella-ppvpn-vpls-01 > >We found that BGP control plane give scalability and flexibility. We >like >the possibility to maintain the actual config and VPN infrastructure >for >both l2 and l3 VPN. > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 13:43:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27731 for ; Wed, 23 Apr 2003 13:43:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NHjsG06935 for ; Wed, 23 Apr 2003 13:45:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NHjoh19905 for ; Wed, 23 Apr 2003 13:45:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20030423090700.01bb31e0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Apr 2003 09:30:28 -0700 To: raszuk@cisco.com, Ali Sajassi From: Ali Sajassi Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Cc: Andrea Ferrarese , ppvpn@nortelnetworks.com In-Reply-To: <3EA63B6D.D6542946@cisco.com> References: <4.3.2.7.2.20030422174705.01c6b518@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Hi Robert, That was not the conclusion that I was arriving at. The way I look at it is if a service provider needs to support both type of services (Multipoint and PtP), then we know that BGP is not suited well for PtP applications; therefore, the service provider needs to support directed LDP (as specified in PWE3). Now if the service provider insists in using BGP as signaling mechanism for Multipoint application (VPLS), then they end up supporting and maintaining both types of signaling mechanisms in their networks !! Also I don't like to tie up the signaling to the auto-discovery because they are independent. Therefore, a SP who wants to use BGP as auto-discovery, can do that and still use LDP as signaling and the SPs who want to use directory-based auto-discovery, can do that with the same LDP signaling. The argument between BGP and LDP signaling is that the BGP-camp assumes that there is nothing else to be distributed to VPLS members except labels; whereas, LDP camp doesn't want to impose such a big constraint as there are PW characteristics (such as QoS, sequencing, OOB OAM) that require additional info exchanges. LDP signaling offers a more flexible approach to carry PW specific info and with the state of VPLS and data-plane still being evolved, I would like to have a flexible signaling. Besides, as mentioned before, you have to use the same signaling for PtP application anyway. -Ali At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: >Hi Ali, > >Very valid question ;) ... > >Even more valid would be to rephrase it to say: "Do all service >providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and >plan to offer some other forms of L2 p2p trasport would have objections >to run both signalling menthods for setting them up (BGP for VPLS and >targeted LDP for all other VPWS)" ? > >My personal _individual_ opinion is that vendors should support both >signalling options as it seems quite common that a proper and fine tuned >tool for any work produces better results :). > >Another spin on this thread is that if Juha's Radius propsal would be >selected as an auto-discovery option clearly there should be no need to >mess with BGP at all and signalling could be done with LDP in all cases. >But if one selects to use BGP for VPLS autodiscovery adding few more >bytes there with encoded very clever way of distributing label >informations especially for VPLS services seems very reasonable. > >R. > > > > Ali Sajassi wrote: > > > > I'd like to know how many of the service providers who support this draft, > > only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to > > offer point-to-point Ethernet service? > > > > If a service provider plans to offer both types of services, then do they > > plan to use BGP for PW signaling of PtP Ethernet service ? > > > > Thanks, > > Ali > > > > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > >We support draft-kompella-ppvpn-vpls-01 > > > > > >We found that BGP control plane give scalability and flexibility. We > > >like > > >the possibility to maintain the actual config and VPN infrastructure > > >for > > >both l2 and l3 VPN. > > > > > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 13:50:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27935 for ; Wed, 23 Apr 2003 13:50:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NHqdG10960 for ; Wed, 23 Apr 2003 13:52:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NHqah26716 for ; Wed, 23 Apr 2003 13:52:36 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Cc: Subject: subscribe Date: Wed, 23 Apr 2003 12:47:23 -0400 Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C30996.7CFA7900" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp1g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,lyris@nortelnetworks.com X-SMTP-PEER-INFO: aismtp1g.bellsouth.com [139.76.165.196] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C30996.7CFA7900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit SUBSCRIBE ppvpn ------=_NextPart_000_0005_01C30996.7CFA7900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SUBSCRIBE=20 ppvpn
------=_NextPart_000_0005_01C30996.7CFA7900-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 14:04:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28349 for ; Wed, 23 Apr 2003 14:04:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NI6iG07932 for ; Wed, 23 Apr 2003 14:06:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NI6eh23673 for ; Wed, 23 Apr 2003 14:06:40 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Subject: ppvpn effort support Date: Wed, 23 Apr 2003 13:15:23 -0400 Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C3099A.66636770" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp3g.bls.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp3g.bellsouth.com [139.76.165.193] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C3099A.66636770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I regard the vpls effort as an important and significant development, both for the evolution of MPLS technology, but more importantly for solving various scaling issues in providing Ethernet related services. In order to progress that work there need to be several different types of documents developed as working group documents - - Service definition documents : to define the specific problem space in which a solution is sought e.g. draft-shah-ppvpn-arp-mediation draft-shah-ppvpn-ipls define specific protocol functionalities that are not well defined elsewhere and it would be commercially useful to have industry agreements in these areas. so I would like to support those as being working group documents. They are, however, only addressing specific corner cases of Ethernet service extensions and are somewhat peripheral to the main vpls discussion. perhaps I have missed it, but I do not think there is a good description of the problems that vpls is attempting to solve. draft-fin-ppvpn-bridging-vpls provides some insight into the bridging component, but this is incomplete as a description of a bridging service. there are Operations, administrating ad provisioning aspects that are also not addressed effectively. draft-vaccine-ppvpn-mgt-frwk is a framework only , but mechanized administration interfaces are required to scale beyond the limits of command line administration. QoS support will eventually be required in the service context. draft-chiussi-ppvpn-qos-framework attempts to address this. It is difficult to effectively address this topic however, without agreement on the service context and the implementation architecture. Solution space documents: draft-lasserre-vkompella-ppvpn-vpls provides a useful illustration of a number of interesting components of a potential vpls service. I am not sure that I understand all the design tradeoffs that are implied by this specific solution though. The range of discussion on this list implies that there are many viable solutions in this space. In looking at the constraints associated with our networks, there are at least two separate applications. (1) I believe there is a need for scaling the Ethernet service concept into smaller low density implementations - and draft-radoaca-ppvpn-gvpls seems to capture this. I would support this as a working group effort. (2) We have a need for scaling the Ethernet service concept beyond the metro and into regional scales. The major issue here is extending service across multiple administrative boundaries. while the hierarchical concepts of draft lasserre are important, I expect these notions of hierarchy will be associated with administrative boundaries. Administrative boundaries also imply administrative policy and BGP is the accepted tool for managing this. so I believe we need a solution along the lines of draft-kompella-ppvpn-vpls and I think this should be a working group document. Steven Wright Science & Technology BellSouth ------=_NextPart_000_0009_01C3099A.66636770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I = regard the vpls=20 effort as an important and significant development, both for the = evolution of=20 MPLS technology, but more importantly for solving various scaling issues = in=20 providing Ethernet related services. In order to progress that work = there need=20 to be several different types of documents  developed as working = group=20 documents  -
 
- = Service definition=20 documents :
to = define the=20 specific problem space in which a solution is sought
e.g. =20
draft-shah-ppvpn-arp-mediation =
draft-shah-ppvpn-ipls
 
define = specific=20 protocol functionalities that are not well defined elsewhere and  = it would=20 be commercially useful to have industry agreements  in these=20 areas.
so I = would like to=20 support those as being working group documents.
 
They = are, however,=20 only addressing specific corner cases of Ethernet service extensions and = are=20 somewhat peripheral to the main vpls = discussion. 
 
perhaps I have=20 missed it, but I do not think there is a good description of the = problems that=20 vpls is attempting to solve.
draft-fin-ppvpn-bridging-vpls  provides = some=20 insight into the bridging component, but this is incomplete as=20 a description of a bridging service.
there = are=20 Operations, administrating ad provisioning aspects that are also not = addressed=20 effectively.
 draft-vaccine-ppvpn-mgt-frwk is a = framework only=20 , but mechanized administration interfaces are required to scale beyond = the=20 limits of command line administration.
 
QoS = support will=20 eventually be required in the service context. =20 draft-chiussi-ppvpn-qos-framework  attempts to address this. It is=20 difficult to effectively address this topic  however, without = agreement on=20 the service context and the implementation architecture. =
 
 
 
Solution space=20 documents:
 
draft-lasserre-vkompella-ppvpn-vpls  = provides a=20 useful illustration of a number of interesting components of a potential = vpls=20 service. I am not sure that I understand all the design tradeoffs that = are=20 implied by this specific solution though. The range of discussion on = this list=20 implies that there are many viable solutions in this space. =
 
In = looking at the=20 constraints associated with our networks, there are at least = two=20 separate applications.
 
(1)  I believe=20 there is a need for scaling the Ethernet service concept  = into=20 smaller low density implementations - and  = draft-radoaca-ppvpn-gvpls seems=20 to capture this. I would support this as a working group=20 effort.
(2)  We have a=20 need for  scaling the Ethernet service concept beyond the = metro and=20 into regional scales. The major issue here is extending service = across=20 multiple  administrative boundaries.
while the=20 hierarchical concepts of draft lasserre are important, I expect these = notions of=20 hierarchy will be associated with administrative boundaries. = Administrative=20 boundaries also imply administrative policy  and BGP is the = accepted tool=20 for managing this. so I believe we need a solution along the lines of=20 draft-kompella-ppvpn-vpls and I think this should be a working group=20 document.
 
 
Steven = Wright
Science &=20 Technology
BellSouth
 
  
 
------=_NextPart_000_0009_01C3099A.66636770-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 14:21: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 OAA28988 for ; Wed, 23 Apr 2003 14:21:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NINHG12402 for ; Wed, 23 Apr 2003 14:23:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NINDh12446 for ; Wed, 23 Apr 2003 14:23:14 -0400 (EDT) Message-Id: <3EA6B1E8.F1C492EF@francetelecom.com> Date: Wed, 23 Apr 2003 11:31:52 -0400 From: "LIAN Franklin FTLD/IAP" Organization: France Telecom Long Distance X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vincent.Parfait@equant.com CC: ppvpn@nortelnetworks.com, "Marco Carugi" , rwilder@masergy.com Subject: Re: PE-CE addressing draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: relais-inet-04.francetelecom.fr X-SMTP-MAIL-FROM: franklin.lian@francetelecom.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: relais-inet.francetelecom.com [212.234.67.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Greetings, This message represents my personal opinions only. I agree that it makes sense to ask all SPs use the same IP pool for allocating addresses to PE-CE links and CE router loopback. In the draft, there is no detail information regarding which /8 IP block will be reserved, and I assume the /8 will come from an unassigned registered IP space. It will be great if IANA can approve such a /8 request because it makes the SP's life much easier. However, without the new /8 block approval, I think we may still get around the address problem with alternative solutions. In the current practice of allocating IP addresses from [RFC-1918] to the PE-CE link, the SP has to negociate with the customer to see which private IP blocks from [RFC-1918] have been implemented in the customer's network and avoid those blocks by assigning IP from other private IP blocks. To do this, the SP has reserved several private IP blocks from [RFC1918], and switch from one block to another when conflicts are found between the SP and customer. I think the same practice can be applied to the draft. Instead of allocating one /8 block, two /8 blocks can be recommended, and these /8 blocks do not have to be approved by IANA. For example, a SP can pickup 1.0.0.0/8 and 100.0.0.0/8 for the IP provisioning. If one customer does not fit in 1.0.0.0/8, the SP can use the IP from 100.0.0.0/8 for the customer. Well, I still like to have one dedicated /8 registered IP from IANA. I guess we can live without one. Zidan From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 14:33:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29559 for ; Wed, 23 Apr 2003 14:33:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NIZmG15285 for ; Wed, 23 Apr 2003 14:35:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NIZfh06964 for ; Wed, 23 Apr 2003 14:35:42 -0400 (EDT) Date: Wed, 23 Apr 2003 09:56:06 -0700 From: Peter Schoenmaker To: Robert Raszuk Cc: Ali Sajassi , Andrea Ferrarese , ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Message-ID: <20030423165606.GA82264@lugs.com> References: <4.3.2.7.2.20030422174705.01c6b518@airborne.cisco.com> <3EA63B6D.D6542946@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA63B6D.D6542946@cisco.com> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) X-SMTP-HELO: murdock.lugs.com X-SMTP-MAIL-FROM: pds@murdock.lugs.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: murdock.lugs.com [192.80.15.4] X-LYRIS-Message-Id: On Wed, Apr 23, 2003 at 09:06:21AM +0200, Robert Raszuk wrote: > Hi Ali, > > Very valid question ;) ... > > Even more valid would be to rephrase it to say: "Do all service > providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and > plan to offer some other forms of L2 p2p trasport would have objections > to run both signalling menthods for setting them up (BGP for VPLS and > targeted LDP for all other VPWS)" ? As a service provider, i am looking at deploying both P2P services and also P2MP services. The ideal solution would allow me to provide both types of services using the same toolset. I want to minimize the number of different ways we do things. This improves our ability to support the network. I want to make things easier on the Network operations people, and troubleshooting. > > My personal _individual_ opinion is that vendors should support both > signalling options as it seems quite common that a proper and fine tuned > tool for any work produces better results :). I would agree with this. Different people have different needs. VPLS with BGP appears at this time to be an attractive solution for me. I support draft-kompella-ppvpn-vpls-01 peter > > Another spin on this thread is that if Juha's Radius propsal would be > selected as an auto-discovery option clearly there should be no need to > mess with BGP at all and signalling could be done with LDP in all cases. > But if one selects to use BGP for VPLS autodiscovery adding few more > bytes there with encoded very clever way of distributing label > informations especially for VPLS services seems very reasonable. > > R. > > > > Ali Sajassi wrote: > > > > I'd like to know how many of the service providers who support this draft, > > only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to > > offer point-to-point Ethernet service? > > > > If a service provider plans to offer both types of services, then do they > > plan to use BGP for PW signaling of PtP Ethernet service ? > > > > Thanks, > > Ali > > > > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > >We support draft-kompella-ppvpn-vpls-01 > > > > > >We found that BGP control plane give scalability and flexibility. We > > >like > > >the possibility to maintain the actual config and VPN infrastructure > > >for > > >both l2 and l3 VPN. > > > > > >Thank you > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 14:41: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 OAA29987 for ; Wed, 23 Apr 2003 14:41:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NIhUG19364 for ; Wed, 23 Apr 2003 14:43:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NIhOh15588 for ; Wed, 23 Apr 2003 14:43:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 20:08:01 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMJwFFR2eVD05i8Ts6K1hxdnAPV9gAAvWXx From: "Hector Avalos" To: , Cc: , X-OriginalArrivalTime: 23 Apr 2003 18:08:01.0963 (UTC) FILETIME=[478447B0:01C309C3] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA29987 Ali If the sp provides 2547bis vpns they already use bgp for signaling. So if they use directed ldp for vpls they will also end with two signaling protocols. Using bgp for signaling in multipoint vpns simplifies sp work. Cheers Hector -------------------------- Sent from my Wireless Handheld -----Original Message----- From: Ali Sajassi To: raszuk@cisco.com ; Ali Sajassi CC: Andrea Ferrarese ; ppvpn@nortelnetworks.com Sent: Wed Apr 23 17:30:28 2003 Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Hi Robert, That was not the conclusion that I was arriving at. The way I look at it is if a service provider needs to support both type of services (Multipoint and PtP), then we know that BGP is not suited well for PtP applications; therefore, the service provider needs to support directed LDP (as specified in PWE3). Now if the service provider insists in using BGP as signaling mechanism for Multipoint application (VPLS), then they end up supporting and maintaining both types of signaling mechanisms in their networks !! Also I don't like to tie up the signaling to the auto-discovery because they are independent. Therefore, a SP who wants to use BGP as auto-discovery, can do that and still use LDP as signaling and the SPs who want to use directory-based auto-discovery, can do that with the same LDP signaling. The argument between BGP and LDP signaling is that the BGP-camp assumes that there is nothing else to be distributed to VPLS members except labels; whereas, LDP camp doesn't want to impose such a big constraint as there are PW characteristics (such as QoS, sequencing, OOB OAM) that require additional info exchanges. LDP signaling offers a more flexible approach to carry PW specific info and with the state of VPLS and data-plane still being evolved, I would like to have a flexible signaling. Besides, as mentioned before, you have to use the same signaling for PtP application anyway. -Ali At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: >Hi Ali, > >Very valid question ;) ... > >Even more valid would be to rephrase it to say: "Do all service >providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and >plan to offer some other forms of L2 p2p trasport would have objections >to run both signalling menthods for setting them up (BGP for VPLS and >targeted LDP for all other VPWS)" ? > >My personal _individual_ opinion is that vendors should support both >signalling options as it seems quite common that a proper and fine tuned >tool for any work produces better results :). > >Another spin on this thread is that if Juha's Radius propsal would be >selected as an auto-discovery option clearly there should be no need to >mess with BGP at all and signalling could be done with LDP in all cases. >But if one selects to use BGP for VPLS autodiscovery adding few more >bytes there with encoded very clever way of distributing label >informations especially for VPLS services seems very reasonable. > >R. > > > > Ali Sajassi wrote: > > > > I'd like to know how many of the service providers who support this draft, > > only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to > > offer point-to-point Ethernet service? > > > > If a service provider plans to offer both types of services, then do they > > plan to use BGP for PW signaling of PtP Ethernet service ? > > > > Thanks, > > Ali > > > > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > >We support draft-kompella-ppvpn-vpls-01 > > > > > >We found that BGP control plane give scalability and flexibility. We > > >like > > >the possibility to maintain the actual config and VPN infrastructure > > >for > > >both l2 and l3 VPN. > > > > > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 15:07:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01544 for ; Wed, 23 Apr 2003 15:07:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NJ9tG12797 for ; Wed, 23 Apr 2003 15:09:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NJ9qh14268 for ; Wed, 23 Apr 2003 15:09:52 -0400 (EDT) X-Lotus-FromDomain: TDE From: carlos.gbraschi@telefonica-data.com To: ppvpn@nortelnetworks.com Message-ID: Date: Wed, 23 Apr 2003 20:54:37 +0200 Subject: RE: PE-CE addressing draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Infomail-Id: 1051124297.4536020A81107C.44297 X-SMTP-HELO: infomail.es X-SMTP-MAIL-FROM: carlos.gbraschi@telefonica-data.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: nie2.infomail.es [195.235.39.19] X-LYRIS-Message-Id: Hi, I think this is something that will make administration of VPN networks much easier, so that being a workgroup document is something good for service providers. Knowing current policies of address assignment, is it foreseeable that IANA can grant so much address space (if any)? Clearly, the draft is missing some calculations that justify the amout of space needed. I don't know the size of the networks of Equant, France Telecom or ATT, but the request assumes VPNs with about 16 million management addresses. With high assignment efficiency, that could be enough for about 4-8 million connections. Having a real amount of points of presence (thousands), and assigning 256 address blocks, a 25-50% efficiency seems achievable (as there would be about 500-1000 connections per PoP), obviously with smaller networks efficiency could be much less... but that is not a problem. Current limits for scalability of VPNs stand at about 1 million, but I doubt management systems can handle that much load, so with partitioning of the management system in some independent VPNs, smaller addressing requirements (what about a /12?) could also work. Clearly a /16 would be inconvenient, but it's probably on the limit of the workable (needs management system partitioning for DSL-scale networks). Regards, Carlos. >From: Ives Dekoninck >To: "'Vincent.Parfait@equant.com'" , "'ppvpn@nortelnetworks.com'" >Subject: RE: PE-CE addressing draft >Date: Wed, 23 Apr 2003 09:06:35 +0200 > >Hi, > >I would also like to support the "draft-guichard-pe-ce-addr-02.txt" to >become a workgroup document. > >An additional advantage of not having to coordinate addresses with the >client is that we can summarise a block towards the management VPN which >makes configuration more scalable and simpler. > >I am doing an implementation for a customer of ours and he also is in favour >of this draft document. > >-Ives- > > > >-----Original Message----- >From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchinskiy@us.didata.com] >Sent: mardi 22 avril 2003 19:08 >To: Vincent.Parfait@equant.com; ppvpn@nortelnetworks.com >Subject: RE: PE-CE addressing draft > > >I would like to support the "draft-guichard-pe-ce-addr-02.txt" becoming >a WG document. > >This is a personal opinion and is not expressed on behalf of the company >I work for. > >Aleksey > >-----Original Message----- >From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] >Sent: Tuesday, April 22, 2003 11:38 AM >To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com >Subject: PE-CE addressing draft > > >This is to inform you that the draft-guichard-pe-ce-addr has been >updated : >http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt >I invite you to read through this new version and give your feedback to >the >list. > >The main motivation for this proposal is to simplify the Service >Providers >operations in the scenario where they monitor CE-PE links, and/or CE >routers, while at the same time conserving IPV4 address space. >Large Service Providers such as Equant, ATT and Arcor are supporting >this >draft and are requesting that it becomes a working group document. > >Vincent Parfait >Equant > > > > > Esperamos su visita en http://www.telefonica-data.es Este mensaje se dirige exclusivamente a su destinatario y puede contener informacion privilegiada o confidencial cuya divulgacion esta prohibida en virtud de la legislacion vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma via y proceda a su destruccion. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 15:21:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02802 for ; Wed, 23 Apr 2003 15:21:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NJO2G17798 for ; Wed, 23 Apr 2003 15:24:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NJNth00078 for ; Wed, 23 Apr 2003 15:23:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16038.50724.726705.916101@lohi.eng.song.fi> Date: Wed, 23 Apr 2003 19:58:12 +0300 To: raszuk@cisco.com Cc: Ali Sajassi , Andrea Ferrarese , ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-Reply-To: <3EA63B6D.D6542946@cisco.com> References: <4.3.2.7.2.20030422174705.01c6b518@airborne.cisco.com> <3EA63B6D.D6542946@cisco.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: rautu X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rautu.eng.song.fi [195.10.149.21] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Robert Raszuk writes: > Another spin on this thread is that if Juha's Radius propsal would be > selected as an auto-discovery option clearly there should be no need to > mess with BGP at all and signalling could be done with LDP in all cases. yes, there would be no need to mess with bgp, but actually no need to mess with ldp either. pure ip network is enough in my favorite combination, which is radius/l2tpv3. l2tpv3 has both signaling and data plane built in into a single protocol. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 15:35: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 PAA03734 for ; Wed, 23 Apr 2003 15:35:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NJblG23320 for ; Wed, 23 Apr 2003 15:37:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NJbhh17119 for ; Wed, 23 Apr 2003 15:37:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 21:20:51 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMJyzKDaRwH/RSlQsO6tslyCxpo1wAAkF10 From: "Hector Avalos" To: , Cc: , X-OriginalArrivalTime: 23 Apr 2003 19:20:54.0188 (UTC) FILETIME=[7590DEC0:01C309CD] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA03734 Jim 2547bis does not use directed ldp, but std ldp. And it is not used for signaling nor autodiscovery. 2547b and vpls requires autodiscovery, and bgp has already been sucessfuly implemented by SPs. PW does not need autodiscovery, so using directed ldp makes sense. Cheers Hector -------------------------- Sent from my Wireless Handheld -----Original Message----- From: Jim Guichard To: Hector Avalos ; sajassi@cisco.com CC: Andrea.Ferrarese@agsm.it ; ppvpn@nortelnetworks.com Sent: Wed Apr 23 19:59:16 2003 Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Hector - it is also fair to say that the chances are they are using LDP for their 2547 service. This means they already have two protocols in operation. I think it is also fair to say that anyone with experience of running a 2547 service will understand the complexity of controlling route distribution - extending this to also cover L2VPN service seems to me to be questionable considering the fact that a point-to-point protocol has already been deployed. Jim > >-----Original Message----- > >From: Hector Avalos [mailto:havalos@juniper.net] > >Sent: Wednesday, April 23, 2003 2:08 PM > >To: sajassi@cisco.com; sajassi@cisco.com > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Ali > > > >If the sp provides 2547bis vpns they already use bgp for signaling. So > >if they use directed ldp for vpls they will also end with two signaling > >protocols. > > > >Using bgp for signaling in multipoint vpns simplifies sp work. > > > >Cheers > >Hector > >-------------------------- > >Sent from my Wireless Handheld > > > > > >-----Original Message----- > >From: Ali Sajassi > >To: raszuk@cisco.com ; Ali Sajassi > >CC: Andrea Ferrarese ; > >ppvpn@nortelnetworks.com > >Sent: Wed Apr 23 17:30:28 2003 > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > >Hi Robert, > > > >That was not the conclusion that I was arriving at. The way I look at it > >is > >if a service provider needs to support both type of services (Multipoint > > > >and PtP), then we know that BGP is not suited well for PtP applications; > > > >therefore, the service provider needs to support directed LDP (as > >specified > >in PWE3). Now if the service provider insists in using BGP as signaling > >mechanism for Multipoint application (VPLS), then they end up supporting > > > >and maintaining both types of signaling mechanisms in their networks !! > > > >Also I don't like to tie up the signaling to the auto-discovery because > >they are independent. Therefore, a SP who wants to use BGP as > >auto-discovery, can do that and still use LDP as signaling and the SPs > >who > >want to use directory-based auto-discovery, can do that with the same > >LDP > >signaling. > > > >The argument between BGP and LDP signaling is that the BGP-camp assumes > >that there is nothing else to be distributed to VPLS members except > >labels; > >whereas, LDP camp doesn't want to impose such a big constraint as there > >are > >PW characteristics (such as QoS, sequencing, OOB OAM) that require > >additional info exchanges. LDP signaling offers a more flexible approach > >to > >carry PW specific info and with the state of VPLS and data-plane still > >being evolved, I would like to have a flexible signaling. Besides, as > >mentioned before, you have to use the same signaling for PtP application > > > >anyway. > > > >-Ali > > > > > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > >>Hi Ali, > >> > >>Very valid question ;) ... > >> > >>Even more valid would be to rephrase it to say: "Do all service > >>providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and > >>plan to offer some other forms of L2 p2p trasport would have objections > >>to run both signalling menthods for setting them up (BGP for VPLS and > >>targeted LDP for all other VPWS)" ? > >> > >>My personal _individual_ opinion is that vendors should support both > >>signalling options as it seems quite common that a proper and fine > >tuned > >>tool for any work produces better results :). > >> > >>Another spin on this thread is that if Juha's Radius propsal would be > >>selected as an auto-discovery option clearly there should be no need to > >>mess with BGP at all and signalling could be done with LDP in all > >cases. > >>But if one selects to use BGP for VPLS autodiscovery adding few more > >>bytes there with encoded very clever way of distributing label > >>informations especially for VPLS services seems very reasonable. > >> > >>R. > >> > >> > >> > Ali Sajassi wrote: > >> > > >> > I'd like to know how many of the service providers who support this > >draft, > >> > only plan to offer multi-point Ethernet service (VPLS) and do NOT > >plan to > >> > offer point-to-point Ethernet service? > >> > > >> > If a service provider plans to offer both types of services, then do > >they > >> > plan to use BGP for PW signaling of PtP Ethernet service ? > >> > > >> > Thanks, > >> > Ali > >> > > >> > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > >> > >We support draft-kompella-ppvpn-vpls-01 > >> > > > >> > >We found that BGP control plane give scalability and flexibility. > >We > >> > >like > >> > >the possibility to maintain the actual config and VPN > >infrastructure > >> > >for > >> > >both l2 and l3 VPN. > >> > > > >> > >Thank you > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 15:41: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 PAA03977 for ; Wed, 23 Apr 2003 15:41:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NJhVG27243 for ; Wed, 23 Apr 2003 15:43:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NJhQh24051 for ; Wed, 23 Apr 2003 15:43:27 -0400 (EDT) From: "Jim Guichard" To: , Subject: RE: PE-CE addressing draft Date: Wed, 23 Apr 2003 15:11:58 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Carlos, I think the size of the block is part of what the working group should evaluate. A /16 is already not enough for some networks. Jim > >-----Original Message----- > >From: carlos.gbraschi@telefonica-data.com > >[mailto:carlos.gbraschi@telefonica-data.com] > >Sent: Wednesday, April 23, 2003 2:55 PM > >To: ppvpn@nortelnetworks.com > >Subject: RE: PE-CE addressing draft > > > > > > > > > > > >Hi, > > > >I think this is something that will make administration of VPN > >networks much > >easier, so that being a workgroup document is something good for service > >providers. > > > >Knowing current policies of address assignment, is it > >foreseeable that IANA can > >grant so much address space (if any)? > > > >Clearly, the draft is missing some calculations that justify the > >amout of space > >needed. > > > >I don't know the size of the networks of Equant, France Telecom > >or ATT, but the > >request assumes VPNs with about 16 million management addresses. > >With high > >assignment efficiency, that could be enough for about 4-8 > >million connections. > >Having a real amount of points of presence (thousands), and assigning 256 > >address blocks, a 25-50% efficiency seems achievable (as there > >would be about > >500-1000 connections per PoP), obviously with smaller networks > >efficiency could > >be much less... but that is not a problem. > > > >Current limits for scalability of VPNs stand at about 1 million, > >but I doubt > >management systems can handle that much load, so with partitioning of the > >management system in some independent VPNs, smaller addressing > >requirements > >(what about a /12?) could also work. Clearly a /16 would be > >inconvenient, but > >it's probably on the limit of the workable (needs management > >system partitioning > >for DSL-scale networks). > > > >Regards, > > > > Carlos. > > > >>From: Ives Dekoninck > >>To: "'Vincent.Parfait@equant.com'" , > >"'ppvpn@nortelnetworks.com'" > >>Subject: RE: PE-CE addressing draft > >>Date: Wed, 23 Apr 2003 09:06:35 +0200 > >> > >>Hi, > >> > >>I would also like to support the "draft-guichard-pe-ce-addr-02.txt" to > >>become a workgroup document. > >> > >>An additional advantage of not having to coordinate addresses with the > >>client is that we can summarise a block towards the management VPN which > >>makes configuration more scalable and simpler. > >> > >>I am doing an implementation for a customer of ours and he also > >is in favour > >>of this draft document. > >> > >>-Ives- > >> > >> > >> > >>-----Original Message----- > >>From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchinskiy@us.didata.com] > >>Sent: mardi 22 avril 2003 19:08 > >>To: Vincent.Parfait@equant.com; ppvpn@nortelnetworks.com > >>Subject: RE: PE-CE addressing draft > >> > >> > >>I would like to support the "draft-guichard-pe-ce-addr-02.txt" becoming > >>a WG document. > >> > >>This is a personal opinion and is not expressed on behalf of the company > >>I work for. > >> > >>Aleksey > >> > >>-----Original Message----- > >>From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] > >>Sent: Tuesday, April 22, 2003 11:38 AM > >>To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com > >>Subject: PE-CE addressing draft > >> > >> > >>This is to inform you that the draft-guichard-pe-ce-addr has been > >>updated : > >>http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt > >>I invite you to read through this new version and give your feedback to > >>the > >>list. > >> > >>The main motivation for this proposal is to simplify the Service > >>Providers > >>operations in the scenario where they monitor CE-PE links, and/or CE > >>routers, while at the same time conserving IPV4 address space. > >>Large Service Providers such as Equant, ATT and Arcor are supporting > >>this > >>draft and are requesting that it becomes a working group document. > >> > >>Vincent Parfait > >>Equant > >> > >> > >> > >> > >> > > > > > >Esperamos su visita en http://www.telefonica-data.es > > > >Este mensaje se dirige exclusivamente a su destinatario y puede contener > >informacion privilegiada o confidencial cuya divulgacion esta > >prohibida en > >virtud de la legislacion vigente. Si ha recibido este mensaje > >por error, le > >rogamos que nos lo comunique inmediatamente por esta misma via y > >proceda a su > >destruccion. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 15:44: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 PAA04052 for ; Wed, 23 Apr 2003 15:44:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NJkcG00384 for ; Wed, 23 Apr 2003 15:46:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NJkZh27914 for ; Wed, 23 Apr 2003 15:46:35 -0400 (EDT) From: "Jim Guichard" To: "Hector Avalos" , Cc: , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 14:59:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hector - it is also fair to say that the chances are they are using LDP for their 2547 service. This means they already have two protocols in operation. I think it is also fair to say that anyone with experience of running a 2547 service will understand the complexity of controlling route distribution - extending this to also cover L2VPN service seems to me to be questionable considering the fact that a point-to-point protocol has already been deployed. Jim > >-----Original Message----- > >From: Hector Avalos [mailto:havalos@juniper.net] > >Sent: Wednesday, April 23, 2003 2:08 PM > >To: sajassi@cisco.com; sajassi@cisco.com > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Ali > > > >If the sp provides 2547bis vpns they already use bgp for signaling. So > >if they use directed ldp for vpls they will also end with two signaling > >protocols. > > > >Using bgp for signaling in multipoint vpns simplifies sp work. > > > >Cheers > >Hector > >-------------------------- > >Sent from my Wireless Handheld > > > > > >-----Original Message----- > >From: Ali Sajassi > >To: raszuk@cisco.com ; Ali Sajassi > >CC: Andrea Ferrarese ; > >ppvpn@nortelnetworks.com > >Sent: Wed Apr 23 17:30:28 2003 > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > >Hi Robert, > > > >That was not the conclusion that I was arriving at. The way I look at it > >is > >if a service provider needs to support both type of services (Multipoint > > > >and PtP), then we know that BGP is not suited well for PtP applications; > > > >therefore, the service provider needs to support directed LDP (as > >specified > >in PWE3). Now if the service provider insists in using BGP as signaling > >mechanism for Multipoint application (VPLS), then they end up supporting > > > >and maintaining both types of signaling mechanisms in their networks !! > > > >Also I don't like to tie up the signaling to the auto-discovery because > >they are independent. Therefore, a SP who wants to use BGP as > >auto-discovery, can do that and still use LDP as signaling and the SPs > >who > >want to use directory-based auto-discovery, can do that with the same > >LDP > >signaling. > > > >The argument between BGP and LDP signaling is that the BGP-camp assumes > >that there is nothing else to be distributed to VPLS members except > >labels; > >whereas, LDP camp doesn't want to impose such a big constraint as there > >are > >PW characteristics (such as QoS, sequencing, OOB OAM) that require > >additional info exchanges. LDP signaling offers a more flexible approach > >to > >carry PW specific info and with the state of VPLS and data-plane still > >being evolved, I would like to have a flexible signaling. Besides, as > >mentioned before, you have to use the same signaling for PtP application > > > >anyway. > > > >-Ali > > > > > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > >>Hi Ali, > >> > >>Very valid question ;) ... > >> > >>Even more valid would be to rephrase it to say: "Do all service > >>providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and > >>plan to offer some other forms of L2 p2p trasport would have objections > >>to run both signalling menthods for setting them up (BGP for VPLS and > >>targeted LDP for all other VPWS)" ? > >> > >>My personal _individual_ opinion is that vendors should support both > >>signalling options as it seems quite common that a proper and fine > >tuned > >>tool for any work produces better results :). > >> > >>Another spin on this thread is that if Juha's Radius propsal would be > >>selected as an auto-discovery option clearly there should be no need to > >>mess with BGP at all and signalling could be done with LDP in all > >cases. > >>But if one selects to use BGP for VPLS autodiscovery adding few more > >>bytes there with encoded very clever way of distributing label > >>informations especially for VPLS services seems very reasonable. > >> > >>R. > >> > >> > >> > Ali Sajassi wrote: > >> > > >> > I'd like to know how many of the service providers who support this > >draft, > >> > only plan to offer multi-point Ethernet service (VPLS) and do NOT > >plan to > >> > offer point-to-point Ethernet service? > >> > > >> > If a service provider plans to offer both types of services, then do > >they > >> > plan to use BGP for PW signaling of PtP Ethernet service ? > >> > > >> > Thanks, > >> > Ali > >> > > >> > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > >> > >We support draft-kompella-ppvpn-vpls-01 > >> > > > >> > >We found that BGP control plane give scalability and flexibility. > >We > >> > >like > >> > >the possibility to maintain the actual config and VPN > >infrastructure > >> > >for > >> > >both l2 and l3 VPN. > >> > > > >> > >Thank you > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 15:53: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 PAA04311 for ; Wed, 23 Apr 2003 15:53:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NJtYG04722 for ; Wed, 23 Apr 2003 15:55:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NJtVh09238 for ; Wed, 23 Apr 2003 15:55:31 -0400 (EDT) Message-ID: <20030423193258.93789.qmail@web12504.mail.yahoo.com> Date: Wed, 23 Apr 2003 12:32:58 -0700 (PDT) From: Sukanta ganguly Subject: Re: Comments on the L2 VPN framework and solutions documents To: Muneyoshi Suzuki , jwils@coriolisnet.com Cc: nfinn@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp In-Reply-To: <20030423.141232.41706744.suzuki.muneyoshi@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web12504.mail.yahoo.com X-SMTP-MAIL-FROM: sganguly@yahoo.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web12504.mail.yahoo.com [216.136.173.196] X-LYRIS-Message-Id: Hi, Just curious as to why you specified that "this kind of work can't be progressed in the IETF" ? Thanks SG --- Muneyoshi Suzuki wrote: > > Joris, > > Thanks for clarification. > > First, needless to say, I aware link block problem > of STP/RSTP. We > definitely need a solution. However, the solution > must be robust. > To enable large scale deployment, it must not force > the operators > and users to reboot boxes even if the worst case. > The full mesh > approach is a fragility solution that has loop, > blackhole or unreliable > flaky PEs problems, so we have no choice other than > the conventional scheme. > > Second, if we regard xSTP as routing protocols, > obviously there are less > efficient than OSPF/BGP. However, if we regard xSTP > as protocols for > protection, these are not bad. If we reserve paths > for fast protection > for the mesh, there are active and standby meshes. I > think this problem > is not much different form xSTP link block problem. > > Finally, as far as I know, currently providers don't > use STP due to long > recovery time; instead manually configure a single > tree topology. However, > a single tree topology is not bad. Please image > conventional telephone > network architecture; it is a tree. A tree is one of > fundamental network > architecture. However, needless to say, topology > free is much better than > a tree. Therefore, I proposed OSPF or BGP-4 > extension for MAC routing > in Atlanta meeting (please see my slides in the last > November). I think > it is not easy to progress this work in the IETF, > but I believe we need > this kind of work in the near future. > > > Thanks, > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. > > > > > > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 15:58:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04432 for ; Wed, 23 Apr 2003 15:58:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NK0KG15199 for ; Wed, 23 Apr 2003 16:00:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NK0Bh17626 for ; Wed, 23 Apr 2003 16:00:12 -0400 (EDT) Message-Id: <200304231934.h3NJXxlY020103@rtp-core-1.cisco.com> To: "Hector Avalos" cc: sajassi@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-reply-to: Your message of Wed, 23 Apr 2003 20:08:01 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Apr 2003 15:33:59 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Hector> If the sp provides 2547bis vpns they already use bgp for signaling. No they don't, as 2547bis does not use any signaling. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:03:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04756 for ; Wed, 23 Apr 2003 16:03:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NK5cG10390 for ; Wed, 23 Apr 2003 16:05:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NK5Yh02753 for ; Wed, 23 Apr 2003 16:05:34 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Hector Avalos" , , Cc: , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 12:40:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 23 Apr 2003 19:40:42.0007 (UTC) FILETIME=[398FAA70:01C309D0] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hector, If you want to qualify the LDP usage by saying that it is targeted LDP (which is different from regular LDP), then let's not pretend that BGP NLRIs for IPv4, 2547 and L2VPNs are similar at all. -Vach > -----Original Message----- > From: Hector Avalos [mailto:havalos@juniper.net] > Sent: Wednesday, April 23, 2003 12:21 PM > To: jguichar@cisco.com; sajassi@cisco.com > Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > Jim > > 2547bis does not use directed ldp, but std ldp. And it is not used for > signaling nor autodiscovery. > 2547b and vpls requires autodiscovery, and bgp has already been > sucessfuly implemented by SPs. > PW does not need autodiscovery, so using directed ldp makes sense. > > Cheers > Hector > > -------------------------- > Sent from my Wireless Handheld > > > -----Original Message----- > From: Jim Guichard > To: Hector Avalos ; sajassi@cisco.com > > CC: Andrea.Ferrarese@agsm.it ; > ppvpn@nortelnetworks.com > Sent: Wed Apr 23 19:59:16 2003 > Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > > Hector - it is also fair to say that the chances are they are using LDP > for > their 2547 service. This means they already have two protocols in > operation. > I think it is also fair to say that anyone with experience of running a > 2547 > service will understand the complexity of controlling route distribution > - > extending this to also cover L2VPN service seems to me to be > questionable > considering the fact that a point-to-point protocol has already been > deployed. Jim > > > >-----Original Message----- > > >From: Hector Avalos [mailto:havalos@juniper.net] > > >Sent: Wednesday, April 23, 2003 2:08 PM > > >To: sajassi@cisco.com; sajassi@cisco.com > > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > > > > >Ali > > > > > >If the sp provides 2547bis vpns they already use bgp for signaling. > So > > >if they use directed ldp for vpls they will also end with two > signaling > > >protocols. > > > > > >Using bgp for signaling in multipoint vpns simplifies sp work. > > > > > >Cheers > > >Hector > > >-------------------------- > > >Sent from my Wireless Handheld > > > > > > > > >-----Original Message----- > > >From: Ali Sajassi > > >To: raszuk@cisco.com ; Ali Sajassi > > > >CC: Andrea Ferrarese ; > > >ppvpn@nortelnetworks.com > > >Sent: Wed Apr 23 17:30:28 2003 > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Hi Robert, > > > > > >That was not the conclusion that I was arriving at. The way I look at > it > > >is > > >if a service provider needs to support both type of services > (Multipoint > > > > > >and PtP), then we know that BGP is not suited well for PtP > applications; > > > > > >therefore, the service provider needs to support directed LDP (as > > >specified > > >in PWE3). Now if the service provider insists in using BGP as > signaling > > >mechanism for Multipoint application (VPLS), then they end up > supporting > > > > > >and maintaining both types of signaling mechanisms in their networks > !! > > > > > >Also I don't like to tie up the signaling to the auto-discovery > because > > >they are independent. Therefore, a SP who wants to use BGP as > > >auto-discovery, can do that and still use LDP as signaling and the > SPs > > >who > > >want to use directory-based auto-discovery, can do that with the same > > >LDP > > >signaling. > > > > > >The argument between BGP and LDP signaling is that the BGP-camp > assumes > > >that there is nothing else to be distributed to VPLS members except > > >labels; > > >whereas, LDP camp doesn't want to impose such a big constraint as > there > > >are > > >PW characteristics (such as QoS, sequencing, OOB OAM) that require > > >additional info exchanges. LDP signaling offers a more flexible > approach > > >to > > >carry PW specific info and with the state of VPLS and data-plane > still > > >being evolved, I would like to have a flexible signaling. Besides, as > > >mentioned before, you have to use the same signaling for PtP > application > > > > > >anyway. > > > > > >-Ali > > > > > > > > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > > >>Hi Ali, > > >> > > >>Very valid question ;) ... > > >> > > >>Even more valid would be to rephrase it to say: "Do all service > > >>providers which support the draft-kompella-ppvpn-vpls-xx for VPLS > and > > >>plan to offer some other forms of L2 p2p trasport would have > objections > > >>to run both signalling menthods for setting them up (BGP for VPLS > and > > >>targeted LDP for all other VPWS)" ? > > >> > > >>My personal _individual_ opinion is that vendors should support both > > >>signalling options as it seems quite common that a proper and fine > > >tuned > > >>tool for any work produces better results :). > > >> > > >>Another spin on this thread is that if Juha's Radius propsal would > be > > >>selected as an auto-discovery option clearly there should be no need > to > > >>mess with BGP at all and signalling could be done with LDP in all > > >cases. > > >>But if one selects to use BGP for VPLS autodiscovery adding few more > > >>bytes there with encoded very clever way of distributing label > > >>informations especially for VPLS services seems very reasonable. > > >> > > >>R. > > >> > > >> > > >> > Ali Sajassi wrote: > > >> > > > >> > I'd like to know how many of the service providers who support > this > > >draft, > > >> > only plan to offer multi-point Ethernet service (VPLS) and do NOT > > >plan to > > >> > offer point-to-point Ethernet service? > > >> > > > >> > If a service provider plans to offer both types of services, then > do > > >they > > >> > plan to use BGP for PW signaling of PtP Ethernet service ? > > >> > > > >> > Thanks, > > >> > Ali > > >> > > > >> > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > >> > >We support draft-kompella-ppvpn-vpls-01 > > >> > > > > >> > >We found that BGP control plane give scalability and > flexibility. > > >We > > >> > >like > > >> > >the possibility to maintain the actual config and VPN > > >infrastructure > > >> > >for > > >> > >both l2 and l3 VPN. > > >> > > > > >> > >Thank you > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:12:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04952 for ; Wed, 23 Apr 2003 16:12:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKEeG16381 for ; Wed, 23 Apr 2003 16:14:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKEbh00525 for ; Wed, 23 Apr 2003 16:14:38 -0400 (EDT) From: "Jim Guichard" To: "Hector Avalos" , Cc: , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 16:00:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > >-----Original Message----- > >From: Hector Avalos [mailto:havalos@juniper.net] > >Sent: Wednesday, April 23, 2003 3:21 PM > >To: jguichar@cisco.com; sajassi@cisco.com > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Jim > > > >2547bis does not use directed ldp, but std ldp. And it is not used for > >signaling nor autodiscovery. well that depends on how you have deployed it but you are right that in general it is non-directed LDP. However, the point is that it is the same protocol. > >2547b and vpls requires autodiscovery, and bgp has already been > >sucessfuly implemented by SPs. no-one disputes that BGP is the right protocol for auto-discovery. > >PW does not need autodiscovery, so using directed ldp makes sense. exactly ! and what do we have between the VSI of PE routers running VPLS ? point-to-point PWs .. Jim > > > >Cheers > >Hector > > > >-------------------------- > >Sent from my Wireless Handheld > > > > > >-----Original Message----- > >From: Jim Guichard > >To: Hector Avalos ; sajassi@cisco.com > > > >CC: Andrea.Ferrarese@agsm.it ; > >ppvpn@nortelnetworks.com > >Sent: Wed Apr 23 19:59:16 2003 > >Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > > > >Hector - it is also fair to say that the chances are they are using LDP > >for > >their 2547 service. This means they already have two protocols in > >operation. > >I think it is also fair to say that anyone with experience of running a > >2547 > >service will understand the complexity of controlling route distribution > >- > >extending this to also cover L2VPN service seems to me to be > >questionable > >considering the fact that a point-to-point protocol has already been > >deployed. Jim > > > >> >-----Original Message----- > >> >From: Hector Avalos [mailto:havalos@juniper.net] > >> >Sent: Wednesday, April 23, 2003 2:08 PM > >> >To: sajassi@cisco.com; sajassi@cisco.com > >> >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >> >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >> > > >> > > >> >Ali > >> > > >> >If the sp provides 2547bis vpns they already use bgp for signaling. > >So > >> >if they use directed ldp for vpls they will also end with two > >signaling > >> >protocols. > >> > > >> >Using bgp for signaling in multipoint vpns simplifies sp work. > >> > > >> >Cheers > >> >Hector > >> >-------------------------- > >> >Sent from my Wireless Handheld > >> > > >> > > >> >-----Original Message----- > >> >From: Ali Sajassi > >> >To: raszuk@cisco.com ; Ali Sajassi > > > >> >CC: Andrea Ferrarese ; > >> >ppvpn@nortelnetworks.com > >> >Sent: Wed Apr 23 17:30:28 2003 > >> >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >> > > >> >Hi Robert, > >> > > >> >That was not the conclusion that I was arriving at. The way I look at > >it > >> >is > >> >if a service provider needs to support both type of services > >(Multipoint > >> > > >> >and PtP), then we know that BGP is not suited well for PtP > >applications; > >> > > >> >therefore, the service provider needs to support directed LDP (as > >> >specified > >> >in PWE3). Now if the service provider insists in using BGP as > >signaling > >> >mechanism for Multipoint application (VPLS), then they end up > >supporting > >> > > >> >and maintaining both types of signaling mechanisms in their networks > >!! > >> > > >> >Also I don't like to tie up the signaling to the auto-discovery > >because > >> >they are independent. Therefore, a SP who wants to use BGP as > >> >auto-discovery, can do that and still use LDP as signaling and the > >SPs > >> >who > >> >want to use directory-based auto-discovery, can do that with the same > >> >LDP > >> >signaling. > >> > > >> >The argument between BGP and LDP signaling is that the BGP-camp > >assumes > >> >that there is nothing else to be distributed to VPLS members except > >> >labels; > >> >whereas, LDP camp doesn't want to impose such a big constraint as > >there > >> >are > >> >PW characteristics (such as QoS, sequencing, OOB OAM) that require > >> >additional info exchanges. LDP signaling offers a more flexible > >approach > >> >to > >> >carry PW specific info and with the state of VPLS and data-plane > >still > >> >being evolved, I would like to have a flexible signaling. Besides, as > >> >mentioned before, you have to use the same signaling for PtP > >application > >> > > >> >anyway. > >> > > >> >-Ali > >> > > >> > > >> >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > >> >>Hi Ali, > >> >> > >> >>Very valid question ;) ... > >> >> > >> >>Even more valid would be to rephrase it to say: "Do all service > >> >>providers which support the draft-kompella-ppvpn-vpls-xx for VPLS > >and > >> >>plan to offer some other forms of L2 p2p trasport would have > >objections > >> >>to run both signalling menthods for setting them up (BGP for VPLS > >and > >> >>targeted LDP for all other VPWS)" ? > >> >> > >> >>My personal _individual_ opinion is that vendors should support both > >> >>signalling options as it seems quite common that a proper and fine > >> >tuned > >> >>tool for any work produces better results :). > >> >> > >> >>Another spin on this thread is that if Juha's Radius propsal would > >be > >> >>selected as an auto-discovery option clearly there should be no need > >to > >> >>mess with BGP at all and signalling could be done with LDP in all > >> >cases. > >> >>But if one selects to use BGP for VPLS autodiscovery adding few more > >> >>bytes there with encoded very clever way of distributing label > >> >>informations especially for VPLS services seems very reasonable. > >> >> > >> >>R. > >> >> > >> >> > >> >> > Ali Sajassi wrote: > >> >> > > >> >> > I'd like to know how many of the service providers who support > >this > >> >draft, > >> >> > only plan to offer multi-point Ethernet service (VPLS) and do NOT > >> >plan to > >> >> > offer point-to-point Ethernet service? > >> >> > > >> >> > If a service provider plans to offer both types of services, then > >do > >> >they > >> >> > plan to use BGP for PW signaling of PtP Ethernet service ? > >> >> > > >> >> > Thanks, > >> >> > Ali > >> >> > > >> >> > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > >> >> > >We support draft-kompella-ppvpn-vpls-01 > >> >> > > > >> >> > >We found that BGP control plane give scalability and > >flexibility. > >> >We > >> >> > >like > >> >> > >the possibility to maintain the actual config and VPN > >> >infrastructure > >> >> > >for > >> >> > >both l2 and l3 VPN. > >> >> > > > >> >> > >Thank you > >> > > >> > > >> > > >> > > >> > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:14:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04985 for ; Wed, 23 Apr 2003 16:14:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKGiG18113 for ; Wed, 23 Apr 2003 16:16:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKGeh06749 for ; Wed, 23 Apr 2003 16:16:41 -0400 (EDT) Message-ID: From: "Holmes, Daniel" To: ppvpn@nortelnetworks.com Subject: unsubscribe Date: Wed, 23 Apr 2003 15:26:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d588791e-977a-41b4-b5ab-649eb7059cc0" X-SMTP-HELO: peter.aprisma.com X-SMTP-MAIL-FROM: dholmes@aprisma.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [207.3.151.142] 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. ------=_NextPartTM-000-d588791e-977a-41b4-b5ab-649eb7059cc0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C309CE.30E1E750" ------_=_NextPart_001_01C309CE.30E1E750 Content-Type: text/plain UNSUBSCRIBE ppvpn ------_=_NextPart_001_01C309CE.30E1E750 Content-Type: text/html

 

UNSUBSCRIBE ppvpn

------_=_NextPart_001_01C309CE.30E1E750-- ------=_NextPartTM-000-d588791e-977a-41b4-b5ab-649eb7059cc0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:18: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 QAA05071 for ; Wed, 23 Apr 2003 16:18:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKKSG21801 for ; Wed, 23 Apr 2003 16:20:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKKOh18176 for ; Wed, 23 Apr 2003 16:20:24 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Hector Avalos" , , Cc: , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 12:28:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 23 Apr 2003 19:28:52.0842 (UTC) FILETIME=[92DDACA0:01C309CE] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Are you not also using LDP for your tunnel signaling protocol for 2547? -Vach > -----Original Message----- > From: Hector Avalos [mailto:havalos@juniper.net] > Sent: Wednesday, April 23, 2003 11:08 AM > To: sajassi@cisco.com; sajassi@cisco.com > Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > Ali > > If the sp provides 2547bis vpns they already use bgp for signaling. So > if they use directed ldp for vpls they will also end with two signaling > protocols. > > Using bgp for signaling in multipoint vpns simplifies sp work. > > Cheers > Hector > -------------------------- > Sent from my Wireless Handheld > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:32:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05625 for ; Wed, 23 Apr 2003 16:32:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKYnG26472 for ; Wed, 23 Apr 2003 16:34:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKYih01314 for ; Wed, 23 Apr 2003 16:34:44 -0400 (EDT) X-Lotus-FromDomain: ARCOR From: Thomas.Kuehne@arcor.net To: carlos.gbraschi@telefonica-data.com cc: ppvpn@nortelnetworks.com Message-ID: <41256D11.00721EF9.00@ffm-hq-gtw01.Arcor.net> Date: Wed, 23 Apr 2003 22:45:57 +0200 Subject: Antwort: RE: PE-CE addressing draft Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-SMTP-HELO: mail.arcor.net X-SMTP-MAIL-FROM: Thomas.Kuehne@arcor.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.arcor.net [145.253.32.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA05625 Hello Carlos! We at Arcor have performed some calculations, and we would be alright with /12. I can't speak for some of the bigger SPs, but I think the size of the address block will have to be determined from their needs. I don't think it's going to be a /8, though. Regards,   Thomas An:        ppvpn@nortelnetworks.com Kopie: Thema:        RE: PE-CE addressing draft Hi, I think this is something that will make administration of VPN networks much easier, so that being a workgroup document is something good for service providers. Knowing current policies of address assignment, is it foreseeable that IANA can grant so much address space (if any)? Clearly, the draft is missing some calculations that justify the amout of space needed. I don't know the size of the networks of Equant, France Telecom or ATT, but the request assumes VPNs with about 16 million management addresses. With high assignment efficiency, that could be enough for about 4-8 million connections. Having a real amount of points of presence (thousands), and assigning 256 address blocks, a 25-50% efficiency seems achievable (as there would be about 500-1000 connections per PoP), obviously with smaller networks efficiency could be much less... but that is not a problem. Current limits for scalability of VPNs stand at about 1 million, but I doubt management systems can handle that much load, so with partitioning of the management system in some independent VPNs, smaller addressing requirements (what about a /12?) could also work. Clearly a /16 would be inconvenient, but it's probably on the limit of the workable (needs management system partitioning for DSL-scale networks). Regards, Carlos. >From: Ives Dekoninck >To: "'Vincent.Parfait@equant.com'" , "'ppvpn@nortelnetworks.com'" >Subject: RE: PE-CE addressing draft >Date: Wed, 23 Apr 2003 09:06:35 +0200 > >Hi, > >I would also like to support the "draft-guichard-pe-ce-addr-02.txt" to >become a workgroup document. > >An additional advantage of not having to coordinate addresses with the >client is that we can summarise a block towards the management VPN which >makes configuration more scalable and simpler. > >I am doing an implementation for a customer of ours and he also is in favour >of this draft document. > >-Ives- > > > >-----Original Message----- >From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchinskiy@us.didata.com] >Sent: mardi 22 avril 2003 19:08 >To: Vincent.Parfait@equant.com; ppvpn@nortelnetworks.com >Subject: RE: PE-CE addressing draft > > >I would like to support the "draft-guichard-pe-ce-addr-02.txt" becoming >a WG document. > >This is a personal opinion and is not expressed on behalf of the company >I work for. > >Aleksey > >-----Original Message----- >From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] >Sent: Tuesday, April 22, 2003 11:38 AM >To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com >Subject: PE-CE addressing draft > > >This is to inform you that the draft-guichard-pe-ce-addr has been >updated : >http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt >I invite you to read through this new version and give your feedback to >the >list. > >The main motivation for this proposal is to simplify the Service >Providers >operations in the scenario where they monitor CE-PE links, and/or CE >routers, while at the same time conserving IPV4 address space. >Large Service Providers such as Equant, ATT and Arcor are supporting >this >draft and are requesting that it becomes a working group document. > >Vincent Parfait >Equant > > > > > Esperamos su visita en http://www.telefonica-data.es Este mensaje se dirige exclusivamente a su destinatario y puede contener informacion privilegiada o confidencial cuya divulgacion esta prohibida en virtud de la legislacion vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma via y proceda a su destruccion. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:36:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05807 for ; Wed, 23 Apr 2003 16:36:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKcrG00029 for ; Wed, 23 Apr 2003 16:38:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKcoh08916 for ; Wed, 23 Apr 2003 16:38:50 -0400 (EDT) Message-Id: <200304232007.h3NK7XlY002334@rtp-core-1.cisco.com> To: "Hector Avalos" cc: jguichar@cisco.com, sajassi@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-reply-to: Your message of Wed, 23 Apr 2003 21:20:51 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Apr 2003 16:07:33 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Hector> 2547bis does not use directed ldp, but std ldp. Oh, and "directed LDP" is a completely different protocol than "standard LDP", is it? In 2547bis, you don't use the PWE3/Martini extensions to LDP, that is true. Neither do you use the Kompella extensions to BGP. Obviously, adding an L2VPN service requires you to add some protocol machinery somewhere! I'm afraid that neither alternative provides something for nothing. Hector> Sent from my Wireless Handheld Apparently the service in Italy is first rate ;-) From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:40: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 QAA05910 for ; Wed, 23 Apr 2003 16:40:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKhCG03778 for ; Wed, 23 Apr 2003 16:43:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKh7h14234 for ; Wed, 23 Apr 2003 16:43:08 -0400 (EDT) Message-Id: <5.2.0.9.2.20030423161958.02ab1be0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Apr 2003 16:20:42 -0400 To: "Hector Avalos" , , From: "Thomas D. Nadeau" Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Hector, Why does it matter whether you are using directed LDP or the other modes? It is still all LDP distributing labels, right? --Tom >2547bis does not use directed ldp, but std ldp. And it is not used for >signaling nor autodiscovery. >2547b and vpls requires autodiscovery, and bgp has already been >sucessfuly implemented by SPs. >PW does not need autodiscovery, so using directed ldp makes sense. > >Cheers >Hector > >-------------------------- >Sent from my Wireless Handheld > > >-----Original Message----- >From: Jim Guichard >To: Hector Avalos ; sajassi@cisco.com > >CC: Andrea.Ferrarese@agsm.it ; >ppvpn@nortelnetworks.com >Sent: Wed Apr 23 19:59:16 2003 >Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > >Hector - it is also fair to say that the chances are they are using LDP >for >their 2547 service. This means they already have two protocols in >operation. >I think it is also fair to say that anyone with experience of running a >2547 >service will understand the complexity of controlling route distribution >- >extending this to also cover L2VPN service seems to me to be >questionable >considering the fact that a point-to-point protocol has already been >deployed. Jim > > > >-----Original Message----- > > >From: Hector Avalos [mailto:havalos@juniper.net] > > >Sent: Wednesday, April 23, 2003 2:08 PM > > >To: sajassi@cisco.com; sajassi@cisco.com > > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > > > > >Ali > > > > > >If the sp provides 2547bis vpns they already use bgp for signaling. >So > > >if they use directed ldp for vpls they will also end with two >signaling > > >protocols. > > > > > >Using bgp for signaling in multipoint vpns simplifies sp work. > > > > > >Cheers > > >Hector > > >-------------------------- > > >Sent from my Wireless Handheld > > > > > > > > >-----Original Message----- > > >From: Ali Sajassi > > >To: raszuk@cisco.com ; Ali Sajassi > > > >CC: Andrea Ferrarese ; > > >ppvpn@nortelnetworks.com > > >Sent: Wed Apr 23 17:30:28 2003 > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Hi Robert, > > > > > >That was not the conclusion that I was arriving at. The way I look at >it > > >is > > >if a service provider needs to support both type of services >(Multipoint > > > > > >and PtP), then we know that BGP is not suited well for PtP >applications; > > > > > >therefore, the service provider needs to support directed LDP (as > > >specified > > >in PWE3). Now if the service provider insists in using BGP as >signaling > > >mechanism for Multipoint application (VPLS), then they end up >supporting > > > > > >and maintaining both types of signaling mechanisms in their networks >!! > > > > > >Also I don't like to tie up the signaling to the auto-discovery >because > > >they are independent. Therefore, a SP who wants to use BGP as > > >auto-discovery, can do that and still use LDP as signaling and the >SPs > > >who > > >want to use directory-based auto-discovery, can do that with the same > > >LDP > > >signaling. > > > > > >The argument between BGP and LDP signaling is that the BGP-camp >assumes > > >that there is nothing else to be distributed to VPLS members except > > >labels; > > >whereas, LDP camp doesn't want to impose such a big constraint as >there > > >are > > >PW characteristics (such as QoS, sequencing, OOB OAM) that require > > >additional info exchanges. LDP signaling offers a more flexible >approach > > >to > > >carry PW specific info and with the state of VPLS and data-plane >still > > >being evolved, I would like to have a flexible signaling. Besides, as > > >mentioned before, you have to use the same signaling for PtP >application > > > > > >anyway. > > > > > >-Ali > > > > > > > > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > > >>Hi Ali, > > >> > > >>Very valid question ;) ... > > >> > > >>Even more valid would be to rephrase it to say: "Do all service > > >>providers which support the draft-kompella-ppvpn-vpls-xx for VPLS >and > > >>plan to offer some other forms of L2 p2p trasport would have >objections > > >>to run both signalling menthods for setting them up (BGP for VPLS >and > > >>targeted LDP for all other VPWS)" ? > > >> > > >>My personal _individual_ opinion is that vendors should support both > > >>signalling options as it seems quite common that a proper and fine > > >tuned > > >>tool for any work produces better results :). > > >> > > >>Another spin on this thread is that if Juha's Radius propsal would >be > > >>selected as an auto-discovery option clearly there should be no need >to > > >>mess with BGP at all and signalling could be done with LDP in all > > >cases. > > >>But if one selects to use BGP for VPLS autodiscovery adding few more > > >>bytes there with encoded very clever way of distributing label > > >>informations especially for VPLS services seems very reasonable. > > >> > > >>R. > > >> > > >> > > >> > Ali Sajassi wrote: > > >> > > > >> > I'd like to know how many of the service providers who support >this > > >draft, > > >> > only plan to offer multi-point Ethernet service (VPLS) and do NOT > > >plan to > > >> > offer point-to-point Ethernet service? > > >> > > > >> > If a service provider plans to offer both types of services, then >do > > >they > > >> > plan to use BGP for PW signaling of PtP Ethernet service ? > > >> > > > >> > Thanks, > > >> > Ali > > >> > > > >> > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > >> > >We support draft-kompella-ppvpn-vpls-01 > > >> > > > > >> > >We found that BGP control plane give scalability and >flexibility. > > >We > > >> > >like > > >> > >the possibility to maintain the actual config and VPN > > >infrastructure > > >> > >for > > >> > >both l2 and l3 VPN. > > >> > > > > >> > >Thank you > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:44: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 QAA06199 for ; Wed, 23 Apr 2003 16:44:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKkrG07420 for ; Wed, 23 Apr 2003 16:46:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKkoh18646 for ; Wed, 23 Apr 2003 16:46:50 -0400 (EDT) Date: Wed, 23 Apr 2003 13:34:31 -0700 (PDT) From: Kireeti Kompella Message-Id: <200304232034.h3NKYVE80568@kummer.juniper.net> To: raszuk@cisco.com, sajassi@cisco.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Cc: Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com In-Reply-To: <4.3.2.7.2.20030423090700.01bb31e0@airborne.cisco.com> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hi Ali, > The argument between BGP and LDP signaling is that the BGP-camp assumes > that there is nothing else to be distributed to VPLS members except labels; > whereas, LDP camp doesn't want to impose such a big constraint as there are > PW characteristics (such as QoS, sequencing, OOB OAM) that require > additional info exchanges. I've seen this argument repeated many times, so let me respond. Today, the PWs that make up a VPLS are point-to-point, i.e., each starts at some PE and ends up on some other PE. This is not a completely ideal situation, as one would really like to use point-to-multipoint tunnels for flooding -- but we don't (yet) have that technology in MPLS. But certainly for unicast, p2p PWs are fine. But let's not confuse the fact that VPLS PWs are point-to-point with the nature (p2p or p2mp) of signaling for those PWs. The most basic function of signaling is the exchange of labels. This is inherently point-to-multipoint -- all other PEs in a VPLS need to know what labels to use to send packets to the signaling PE. The next function of signaling is the withdrawal of labels, either because of administrative intervention or because the PE-CE link went down. Again, this is point-to-multipoint -- all other PEs in the VPLS need to be told. Another thing that needs to be communicated, be it during discovery or during signaling, is the MTU on the PE-CE interfaces. Again, this is point-to-multipoint -- the same value is sent to all peers. (BTW, to correct your statement above, BGP does signal MTU, not just labels.) Another signaling function described in draft-lasserre-vkompella-ppvpn-vpls is MAC Address Withdrawal. Again, this is point-to-multipoint -- a PE uses this to inform all other PEs in the VPLS to remove a certain set of MAC addresses from their filter tables. So, what aspect of signaling is inherently point-to-point? I.e., what information might one want to signal to some (but not all) members of a VPLS? Let's take your examples: > (such as QoS, sequencing, OOB OAM) 1. QoS is a nice, broad term. To some, it means bandwidth settings (CIR, burst, etc.); to others it means setting DSCPs or EXP bits. Let's take these in turn. a) bandwidth (CIR, burst, ...): For VPLS (as for IP, i.e., for any-to-any services), the most natural b/w expression is the "hose model", where the PE-CE connection is limited to (say) 2M CIR and 8M burst. Even if a detailed traffic matrix ("pipe model") were desirable (for VPLS and for IP), i.e., site 1 can send 2M to site 2, 6M to site 3, etc., is there a need to signal this info? This is simply implemented locally at each PE. If one goes down this path -- "we want a detailed traffic matrix, and we have to signal this" -- does one then abandon BGP signaling for IP VPNs and switch to LDP signaling? If on the other hand, one decides to go with the hose model, one could very well use the bandwidth community for VPLS as well as for RFC 2547 IP VPNs. b) DSCP/EXP setting -- this is again simply done locally, and in the fortunate case of VLANs, there could be a straightforward mapping of .1p bits to DSCP/EXP. Again, this mapping would be the same across the VPLS (otherwise, one would have a management nightmare). Thus, even if this was signaled, the signaling would be point-to-multipoint. 2. Sequencing. It seems to me that for a given VPLS, one either does sequencing among all the PEs for this VPLS, or not. The situation where one does sequencing among some but not others seems excessively complex. In any case, sequencing is done in the data plane -- a sequence number of 0 means no sequencing; non-zero means do sequencing. 3. OOB OAM. Not sure what this means: what is to be signalled, and what makes it point-to-point (i.e., PE1 wants to tell PE2 but not PE3)? Could you elaborate? My conclusion (so far; I will wait for your/Eric's responses) is that VPLS signaling is basically point-to-multipoint. That is bolstered by the fact that the LDP signaling defined in lasserre-vkompella doesn't actually have any parameters that are useful to signal to one PE in the VPLS but not any other. In the light of this conclusion, it seems much more natural to use a point-to-multipoint signaling mechanism (BGP) for VPLS rather than a point-to-point mechanism (LDP). Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:48:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06486 for ; Wed, 23 Apr 2003 16:48:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKojG11099 for ; Wed, 23 Apr 2003 16:50:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKofh23156 for ; Wed, 23 Apr 2003 16:50:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 22:25:31 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMJ0FqD0JsnJlJKTqmrkVYiKbmsmQABiGW2 From: "Hector Avalos" To: , , Cc: , X-OriginalArrivalTime: 23 Apr 2003 20:25:32.0075 (UTC) FILETIME=[7CF777B0:01C309D6] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA06486 Well, that's the nice thing of mp-bgp. Which in addition provide us support for inter-as an CoC, which several SPs would like to implement for vpls. But my point about ldp in 2547bis is that it is only used for tunneling, not for signaling or autodiscovery. That is the reason why 2547bis works over gre, ipsec,ldp and rsvp tunneling, even in 'parallel'. Yes, SPs may have several tunneling protocols, even for vpls. But they do not require 'complex' interaction with the autodiscovery and signaling protocols. Using bgp for these two fuctions for multipoint vpns simplifies SPs work. Cheers Hector -------------------------- Sent from my Wireless Handheld -----Original Message----- From: Vach Kompella To: Hector Avalos ; jguichar@cisco.com ; sajassi@cisco.com CC: Andrea.Ferrarese@agsm.it ; ppvpn@nortelnetworks.com Sent: Wed Apr 23 20:40:04 2003 Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Hector, If you want to qualify the LDP usage by saying that it is targeted LDP (which is different from regular LDP), then let's not pretend that BGP NLRIs for IPv4, 2547 and L2VPNs are similar at all. -Vach > -----Original Message----- > From: Hector Avalos [mailto:havalos@juniper.net] > Sent: Wednesday, April 23, 2003 12:21 PM > To: jguichar@cisco.com; sajassi@cisco.com > Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > Jim > > 2547bis does not use directed ldp, but std ldp. And it is not used for > signaling nor autodiscovery. > 2547b and vpls requires autodiscovery, and bgp has already been > sucessfuly implemented by SPs. > PW does not need autodiscovery, so using directed ldp makes sense. > > Cheers > Hector > > -------------------------- > Sent from my Wireless Handheld > > > -----Original Message----- > From: Jim Guichard > To: Hector Avalos ; sajassi@cisco.com > > CC: Andrea.Ferrarese@agsm.it ; > ppvpn@nortelnetworks.com > Sent: Wed Apr 23 19:59:16 2003 > Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > > Hector - it is also fair to say that the chances are they are using LDP > for > their 2547 service. This means they already have two protocols in > operation. > I think it is also fair to say that anyone with experience of running a > 2547 > service will understand the complexity of controlling route distribution > - > extending this to also cover L2VPN service seems to me to be > questionable > considering the fact that a point-to-point protocol has already been > deployed. Jim > > > >-----Original Message----- > > >From: Hector Avalos [mailto:havalos@juniper.net] > > >Sent: Wednesday, April 23, 2003 2:08 PM > > >To: sajassi@cisco.com; sajassi@cisco.com > > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > > > > >Ali > > > > > >If the sp provides 2547bis vpns they already use bgp for signaling. > So > > >if they use directed ldp for vpls they will also end with two > signaling > > >protocols. > > > > > >Using bgp for signaling in multipoint vpns simplifies sp work. > > > > > >Cheers > > >Hector > > >-------------------------- > > >Sent from my Wireless Handheld > > > > > > > > >-----Original Message----- > > >From: Ali Sajassi > > >To: raszuk@cisco.com ; Ali Sajassi > > > >CC: Andrea Ferrarese ; > > >ppvpn@nortelnetworks.com > > >Sent: Wed Apr 23 17:30:28 2003 > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Hi Robert, > > > > > >That was not the conclusion that I was arriving at. The way I look at > it > > >is > > >if a service provider needs to support both type of services > (Multipoint > > > > > >and PtP), then we know that BGP is not suited well for PtP > applications; > > > > > >therefore, the service provider needs to support directed LDP (as > > >specified > > >in PWE3). Now if the service provider insists in using BGP as > signaling > > >mechanism for Multipoint application (VPLS), then they end up > supporting > > > > > >and maintaining both types of signaling mechanisms in their networks > !! > > > > > >Also I don't like to tie up the signaling to the auto-discovery > because > > >they are independent. Therefore, a SP who wants to use BGP as > > >auto-discovery, can do that and still use LDP as signaling and the > SPs > > >who > > >want to use directory-based auto-discovery, can do that with the same > > >LDP > > >signaling. > > > > > >The argument between BGP and LDP signaling is that the BGP-camp > assumes > > >that there is nothing else to be distributed to VPLS members except > > >labels; > > >whereas, LDP camp doesn't want to impose such a big constraint as > there > > >are > > >PW characteristics (such as QoS, sequencing, OOB OAM) that require > > >additional info exchanges. LDP signaling offers a more flexible > approach > > >to > > >carry PW specific info and with the state of VPLS and data-plane > still > > >being evolved, I would like to have a flexible signaling. Besides, as > > >mentioned before, you have to use the same signaling for PtP > application > > > > > >anyway. > > > > > >-Ali > > > > > > > > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > > >>Hi Ali, > > >> > > >>Very valid question ;) ... > > >> > > >>Even more valid would be to rephrase it to say: "Do all service > > >>providers which support the draft-kompella-ppvpn-vpls-xx for VPLS > and > > >>plan to offer some other forms of L2 p2p trasport would have > objections > > >>to run both signalling menthods for setting them up (BGP for VPLS > and > > >>targeted LDP for all other VPWS)" ? > > >> > > >>My personal _individual_ opinion is that vendors should support both > > >>signalling options as it seems quite common that a proper and fine > > >tuned > > >>tool for any work produces better results :). > > >> > > >>Another spin on this thread is that if Juha's Radius propsal would > be > > >>selected as an auto-discovery option clearly there should be no need > to > > >>mess with BGP at all and signalling could be done with LDP in all > > >cases. > > >>But if one selects to use BGP for VPLS autodiscovery adding few more > > >>bytes there with encoded very clever way of distributing label > > >>informations especially for VPLS services seems very reasonable. > > >> > > >>R. > > >> > > >> > > >> > Ali Sajassi wrote: > > >> > > > >> > I'd like to know how many of the service providers who support > this > > >draft, > > >> > only plan to offer multi-point Ethernet service (VPLS) and do NOT > > >plan to > > >> > offer point-to-point Ethernet service? > > >> > > > >> > If a service provider plans to offer both types of services, then > do > > >they > > >> > plan to use BGP for PW signaling of PtP Ethernet service ? > > >> > > > >> > Thanks, > > >> > Ali > > >> > > > >> > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > >> > >We support draft-kompella-ppvpn-vpls-01 > > >> > > > > >> > >We found that BGP control plane give scalability and > flexibility. > > >We > > >> > >like > > >> > >the possibility to maintain the actual config and VPN > > >infrastructure > > >> > >for > > >> > >both l2 and l3 VPN. > > >> > > > > >> > >Thank you > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:54:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06822 for ; Wed, 23 Apr 2003 16:54:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NKv0G14948 for ; Wed, 23 Apr 2003 16:57:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NKuth00271 for ; Wed, 23 Apr 2003 16:56:56 -0400 (EDT) From: "Jim Guichard" To: "Hector Avalos" , , Cc: , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 16:28:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hector, > >-----Original Message----- > >From: Hector Avalos [mailto:havalos@juniper.net] > >Sent: Wednesday, April 23, 2003 4:26 PM > >To: vkompella@timetra.com; jguichar@cisco.com; sajassi@cisco.com > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Well, that's the nice thing of mp-bgp. > >Which in addition provide us support for inter-as an CoC, which several > >SPs would like to implement for vpls. good luck 8^) > >But my point about ldp in 2547bis is that it is only used for > >tunneling, not for signaling or autodiscovery. That is the reason why > >2547bis works over gre, ipsec,ldp and rsvp tunneling, even in > >'parallel'. > > > >Yes, SPs may have several tunneling protocols, even for vpls. But they > >do not require 'complex' interaction with the autodiscovery and > >signaling protocols. what exactly is complex about using the results of autodiscovery to automagically setup directed LDP sessions and exchange label space ? Jim > > > >Using bgp for these two fuctions for multipoint vpns simplifies SPs > >work. > > > >Cheers > >Hector > >-------------------------- > >Sent from my Wireless Handheld > > > > > >-----Original Message----- > >From: Vach Kompella > >To: Hector Avalos ; jguichar@cisco.com > >; sajassi@cisco.com > >CC: Andrea.Ferrarese@agsm.it ; > >ppvpn@nortelnetworks.com > >Sent: Wed Apr 23 20:40:04 2003 > >Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > > > >Hector, > > > >If you want to qualify the LDP usage by saying that it is targeted LDP > >(which is > >different from regular LDP), then let's not pretend that BGP NLRIs for > >IPv4, > >2547 and L2VPNs are similar at all. > > > >-Vach > > > >> -----Original Message----- > >> From: Hector Avalos [mailto:havalos@juniper.net] > >> Sent: Wednesday, April 23, 2003 12:21 PM > >> To: jguichar@cisco.com; sajassi@cisco.com > >> Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >> Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >> > >> > >> Jim > >> > >> 2547bis does not use directed ldp, but std ldp. And it is not used for > >> signaling nor autodiscovery. > >> 2547b and vpls requires autodiscovery, and bgp has already been > >> sucessfuly implemented by SPs. > >> PW does not need autodiscovery, so using directed ldp makes sense. > >> > >> Cheers > >> Hector > >> > >> -------------------------- > >> Sent from my Wireless Handheld > >> > >> > >> -----Original Message----- > >> From: Jim Guichard > >> To: Hector Avalos ; sajassi@cisco.com > >> > >> CC: Andrea.Ferrarese@agsm.it ; > >> ppvpn@nortelnetworks.com > >> Sent: Wed Apr 23 19:59:16 2003 > >> Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > >> > >> Hector - it is also fair to say that the chances are they are using > >LDP > >> for > >> their 2547 service. This means they already have two protocols in > >> operation. > >> I think it is also fair to say that anyone with experience of running > >a > >> 2547 > >> service will understand the complexity of controlling route > >distribution > >> - > >> extending this to also cover L2VPN service seems to me to be > >> questionable > >> considering the fact that a point-to-point protocol has already been > >> deployed. Jim > >> > >> > >-----Original Message----- > >> > >From: Hector Avalos [mailto:havalos@juniper.net] > >> > >Sent: Wednesday, April 23, 2003 2:08 PM > >> > >To: sajassi@cisco.com; sajassi@cisco.com > >> > >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >> > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >> > > > >> > > > >> > >Ali > >> > > > >> > >If the sp provides 2547bis vpns they already use bgp for signaling. > >> So > >> > >if they use directed ldp for vpls they will also end with two > >> signaling > >> > >protocols. > >> > > > >> > >Using bgp for signaling in multipoint vpns simplifies sp work. > >> > > > >> > >Cheers > >> > >Hector > >> > >-------------------------- > >> > >Sent from my Wireless Handheld > >> > > > >> > > > >> > >-----Original Message----- > >> > >From: Ali Sajassi > >> > >To: raszuk@cisco.com ; Ali Sajassi > >> > >> > >CC: Andrea Ferrarese ; > >> > >ppvpn@nortelnetworks.com > >> > >Sent: Wed Apr 23 17:30:28 2003 > >> > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >> > > > >> > >Hi Robert, > >> > > > >> > >That was not the conclusion that I was arriving at. The way I look > >at > >> it > >> > >is > >> > >if a service provider needs to support both type of services > >> (Multipoint > >> > > > >> > >and PtP), then we know that BGP is not suited well for PtP > >> applications; > >> > > > >> > >therefore, the service provider needs to support directed LDP (as > >> > >specified > >> > >in PWE3). Now if the service provider insists in using BGP as > >> signaling > >> > >mechanism for Multipoint application (VPLS), then they end up > >> supporting > >> > > > >> > >and maintaining both types of signaling mechanisms in their > >networks > >> !! > >> > > > >> > >Also I don't like to tie up the signaling to the auto-discovery > >> because > >> > >they are independent. Therefore, a SP who wants to use BGP as > >> > >auto-discovery, can do that and still use LDP as signaling and the > >> SPs > >> > >who > >> > >want to use directory-based auto-discovery, can do that with the > >same > >> > >LDP > >> > >signaling. > >> > > > >> > >The argument between BGP and LDP signaling is that the BGP-camp > >> assumes > >> > >that there is nothing else to be distributed to VPLS members except > >> > >labels; > >> > >whereas, LDP camp doesn't want to impose such a big constraint as > >> there > >> > >are > >> > >PW characteristics (such as QoS, sequencing, OOB OAM) that require > >> > >additional info exchanges. LDP signaling offers a more flexible > >> approach > >> > >to > >> > >carry PW specific info and with the state of VPLS and data-plane > >> still > >> > >being evolved, I would like to have a flexible signaling. Besides, > >as > >> > >mentioned before, you have to use the same signaling for PtP > >> application > >> > > > >> > >anyway. > >> > > > >> > >-Ali > >> > > > >> > > > >> > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > >> > >>Hi Ali, > >> > >> > >> > >>Very valid question ;) ... > >> > >> > >> > >>Even more valid would be to rephrase it to say: "Do all service > >> > >>providers which support the draft-kompella-ppvpn-vpls-xx for VPLS > >> and > >> > >>plan to offer some other forms of L2 p2p trasport would have > >> objections > >> > >>to run both signalling menthods for setting them up (BGP for VPLS > >> and > >> > >>targeted LDP for all other VPWS)" ? > >> > >> > >> > >>My personal _individual_ opinion is that vendors should support > >both > >> > >>signalling options as it seems quite common that a proper and fine > >> > >tuned > >> > >>tool for any work produces better results :). > >> > >> > >> > >>Another spin on this thread is that if Juha's Radius propsal would > >> be > >> > >>selected as an auto-discovery option clearly there should be no > >need > >> to > >> > >>mess with BGP at all and signalling could be done with LDP in all > >> > >cases. > >> > >>But if one selects to use BGP for VPLS autodiscovery adding few > >more > >> > >>bytes there with encoded very clever way of distributing label > >> > >>informations especially for VPLS services seems very reasonable. > >> > >> > >> > >>R. > >> > >> > >> > >> > >> > >> > Ali Sajassi wrote: > >> > >> > > >> > >> > I'd like to know how many of the service providers who support > >> this > >> > >draft, > >> > >> > only plan to offer multi-point Ethernet service (VPLS) and do > >NOT > >> > >plan to > >> > >> > offer point-to-point Ethernet service? > >> > >> > > >> > >> > If a service provider plans to offer both types of services, > >then > >> do > >> > >they > >> > >> > plan to use BGP for PW signaling of PtP Ethernet service ? > >> > >> > > >> > >> > Thanks, > >> > >> > Ali > >> > >> > > >> > >> > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > >> > >> > >We support draft-kompella-ppvpn-vpls-01 > >> > >> > > > >> > >> > >We found that BGP control plane give scalability and > >> flexibility. > >> > >We > >> > >> > >like > >> > >> > >the possibility to maintain the actual config and VPN > >> > >infrastructure > >> > >> > >for > >> > >> > >both l2 and l3 VPN. > >> > >> > > > >> > >> > >Thank you > >> > > > >> > > > >> > > > >> > > > >> > > > >> > >> > >> > >> > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 16:58:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07075 for ; Wed, 23 Apr 2003 16:58:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NL0oG27926 for ; Wed, 23 Apr 2003 17:00:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NL0hh04734 for ; Wed, 23 Apr 2003 17:00:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20030423131944.01f4cc68@mira-sjcm-3> X-Sender: jayk@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Apr 2003 13:25:56 -0700 To: "Hector Avalos" , , From: Jay Kumarasamy Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: jayk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 08:08 PM 4/23/2003 +0200, Hector Avalos wrote: >Ali > >If the sp provides 2547bis vpns they already use bgp for signaling. So BGP, only for carrying routes, no signalling. >if they use directed ldp for vpls they will also end with two signaling >protocols. How so ? If LDP is used for MPLS forwarding, then LDP is already in the core. - Jay >Using bgp for signaling in multipoint vpns simplifies sp work. > >Cheers >Hector >-------------------------- >Sent from my Wireless Handheld > > >-----Original Message----- >From: Ali Sajassi >To: raszuk@cisco.com ; Ali Sajassi >CC: Andrea Ferrarese ; >ppvpn@nortelnetworks.com >Sent: Wed Apr 23 17:30:28 2003 >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >Hi Robert, > >That was not the conclusion that I was arriving at. The way I look at it >is >if a service provider needs to support both type of services (Multipoint > >and PtP), then we know that BGP is not suited well for PtP applications; > >therefore, the service provider needs to support directed LDP (as >specified >in PWE3). Now if the service provider insists in using BGP as signaling >mechanism for Multipoint application (VPLS), then they end up supporting > >and maintaining both types of signaling mechanisms in their networks !! > >Also I don't like to tie up the signaling to the auto-discovery because >they are independent. Therefore, a SP who wants to use BGP as >auto-discovery, can do that and still use LDP as signaling and the SPs >who >want to use directory-based auto-discovery, can do that with the same >LDP >signaling. > >The argument between BGP and LDP signaling is that the BGP-camp assumes >that there is nothing else to be distributed to VPLS members except >labels; >whereas, LDP camp doesn't want to impose such a big constraint as there >are >PW characteristics (such as QoS, sequencing, OOB OAM) that require >additional info exchanges. LDP signaling offers a more flexible approach >to >carry PW specific info and with the state of VPLS and data-plane still >being evolved, I would like to have a flexible signaling. Besides, as >mentioned before, you have to use the same signaling for PtP application > >anyway. > >-Ali > > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > >Hi Ali, > > > >Very valid question ;) ... > > > >Even more valid would be to rephrase it to say: "Do all service > >providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and > >plan to offer some other forms of L2 p2p trasport would have objections > >to run both signalling menthods for setting them up (BGP for VPLS and > >targeted LDP for all other VPWS)" ? > > > >My personal _individual_ opinion is that vendors should support both > >signalling options as it seems quite common that a proper and fine >tuned > >tool for any work produces better results :). > > > >Another spin on this thread is that if Juha's Radius propsal would be > >selected as an auto-discovery option clearly there should be no need to > >mess with BGP at all and signalling could be done with LDP in all >cases. > >But if one selects to use BGP for VPLS autodiscovery adding few more > >bytes there with encoded very clever way of distributing label > >informations especially for VPLS services seems very reasonable. > > > >R. > > > > > > > Ali Sajassi wrote: > > > > > > I'd like to know how many of the service providers who support this >draft, > > > only plan to offer multi-point Ethernet service (VPLS) and do NOT >plan to > > > offer point-to-point Ethernet service? > > > > > > If a service provider plans to offer both types of services, then do >they > > > plan to use BGP for PW signaling of PtP Ethernet service ? > > > > > > Thanks, > > > Ali > > > > > > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > > >We support draft-kompella-ppvpn-vpls-01 > > > > > > > >We found that BGP control plane give scalability and flexibility. >We > > > >like > > > >the possibility to maintain the actual config and VPN >infrastructure > > > >for > > > >both l2 and l3 VPN. > > > > > > > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 17:10: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 RAA07808 for ; Wed, 23 Apr 2003 17:10:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NLCUG03601 for ; Wed, 23 Apr 2003 17:12:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NLCQh15199 for ; Wed, 23 Apr 2003 17:12:26 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Subject: vpls scaling question Date: Wed, 23 Apr 2003 17:03:40 -0400 Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C309BA.4AF76480" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: aismtp4g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp4g.bellsouth.com [139.76.165.194] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C309BA.4AF76480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit vpls is proposed as a mechanism to enable large-scale Ethernet networks. Can anyone quantify for me at what stage flat Ethernet networks break and vpls is required ? i.e what should the decision criteria be to convert an Ethernet network to a vpls network ? Steven Wright BellSouth ------=_NextPart_000_0011_01C309BA.4AF76480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
vpls = is proposed as=20 a mechanism to enable large-scale Ethernet networks.
Can = anyone quantify=20 for me at what stage flat Ethernet networks break and vpls is required=20 ?
i.e = what should the=20 decision criteria be to convert an Ethernet network to a vpls network=20 ?
Steven = Wright
BellSouth
------=_NextPart_000_0011_01C309BA.4AF76480-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 17:29: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 RAA08660 for ; Wed, 23 Apr 2003 17:29:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NLVtG07679 for ; Wed, 23 Apr 2003 17:31:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NLVoh29126 for ; Wed, 23 Apr 2003 17:31:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20030423135230.01cc3e38@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Apr 2003 14:18:38 -0700 To: "Hector Avalos" , From: Ali Sajassi Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: At 08:08 PM 4/23/2003 +0200, Hector Avalos wrote: >Ali > >If the sp provides 2547bis vpns they already use bgp for signaling. So >if they use directed ldp for vpls they will also end with two signaling >protocols. The point is Martini signaling has already been used/deployed for PtP application and the same signaling (without adding any new extensions) can be used for VPLS because VPLS uses PtP PWs. In other words, if a SP already supports PtP applications, then it can leverage the same signaling for VPLS. And the SP can still use BGP for auto-discovery part if they choose so. You cannot say the same thing with 2547bis because even the same protocol is used but different extensions are required for VPLS. -Ali >Using bgp for signaling in multipoint vpns simplifies sp work. > >Cheers >Hector >-------------------------- >Sent from my Wireless Handheld > > >-----Original Message----- >From: Ali Sajassi >To: raszuk@cisco.com ; Ali Sajassi >CC: Andrea Ferrarese ; >ppvpn@nortelnetworks.com >Sent: Wed Apr 23 17:30:28 2003 >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >Hi Robert, > >That was not the conclusion that I was arriving at. The way I look at it >is >if a service provider needs to support both type of services (Multipoint > >and PtP), then we know that BGP is not suited well for PtP applications; > >therefore, the service provider needs to support directed LDP (as >specified >in PWE3). Now if the service provider insists in using BGP as signaling >mechanism for Multipoint application (VPLS), then they end up supporting > >and maintaining both types of signaling mechanisms in their networks !! > >Also I don't like to tie up the signaling to the auto-discovery because >they are independent. Therefore, a SP who wants to use BGP as >auto-discovery, can do that and still use LDP as signaling and the SPs >who >want to use directory-based auto-discovery, can do that with the same >LDP >signaling. > >The argument between BGP and LDP signaling is that the BGP-camp assumes >that there is nothing else to be distributed to VPLS members except >labels; >whereas, LDP camp doesn't want to impose such a big constraint as there >are >PW characteristics (such as QoS, sequencing, OOB OAM) that require >additional info exchanges. LDP signaling offers a more flexible approach >to >carry PW specific info and with the state of VPLS and data-plane still >being evolved, I would like to have a flexible signaling. Besides, as >mentioned before, you have to use the same signaling for PtP application > >anyway. > >-Ali > > >At 09:06 AM 4/23/2003 +0200, Robert Raszuk wrote: > >Hi Ali, > > > >Very valid question ;) ... > > > >Even more valid would be to rephrase it to say: "Do all service > >providers which support the draft-kompella-ppvpn-vpls-xx for VPLS and > >plan to offer some other forms of L2 p2p trasport would have objections > >to run both signalling menthods for setting them up (BGP for VPLS and > >targeted LDP for all other VPWS)" ? > > > >My personal _individual_ opinion is that vendors should support both > >signalling options as it seems quite common that a proper and fine >tuned > >tool for any work produces better results :). > > > >Another spin on this thread is that if Juha's Radius propsal would be > >selected as an auto-discovery option clearly there should be no need to > >mess with BGP at all and signalling could be done with LDP in all >cases. > >But if one selects to use BGP for VPLS autodiscovery adding few more > >bytes there with encoded very clever way of distributing label > >informations especially for VPLS services seems very reasonable. > > > >R. > > > > > > > Ali Sajassi wrote: > > > > > > I'd like to know how many of the service providers who support this >draft, > > > only plan to offer multi-point Ethernet service (VPLS) and do NOT >plan to > > > offer point-to-point Ethernet service? > > > > > > If a service provider plans to offer both types of services, then do >they > > > plan to use BGP for PW signaling of PtP Ethernet service ? > > > > > > Thanks, > > > Ali > > > > > > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > > > >We support draft-kompella-ppvpn-vpls-01 > > > > > > > >We found that BGP control plane give scalability and flexibility. >We > > > >like > > > >the possibility to maintain the actual config and VPN >infrastructure > > > >for > > > >both l2 and l3 VPN. > > > > > > > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 18:22: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 SAA11825 for ; Wed, 23 Apr 2003 18:22:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NMOUG24497 for ; Wed, 23 Apr 2003 18:24:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NMOQh15182 for ; Wed, 23 Apr 2003 18:24:26 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Kireeti Kompella" , , Cc: , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 15:06:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: <200304232034.h3NKYVE80568@kummer.juniper.net> X-OriginalArrivalTime: 23 Apr 2003 22:06:47.0633 (UTC) FILETIME=[A2480C10:01C309E4] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Kireeti, See below. -Vach > > But let's not confuse the fact that VPLS PWs are point-to-point with > the nature (p2p or p2mp) of signaling for those PWs. > > The most basic function of signaling is the exchange of labels. This > is inherently point-to-multipoint -- all other PEs in a VPLS need to > know what labels to use to send packets to the signaling PE. Which is a pt-2-pt function. The fact that you are using a multi-point approach does not actually reflect that what you are doing is pt-2-pt (since the labels are signaled pt2pt, despite the label ranges). This is quite unlike the *true* pt-2-multipoint nature of, say, a route advertisement in IPv4, where everyone uses that route (modulo IGP costs, etc.), or VPN-IPv4 route advertisements, which all participating PEs use identically. Or, as you pointed out, the MTU, which it would be nice (but not essential) to send pt-2-multipoint to all PEs in a VPLS. > > In the light of this conclusion, it seems much more natural to use a > point-to-multipoint signaling mechanism (BGP) for VPLS rather than a > point-to-point mechanism (LDP). BGP, to be precise, is not a pt-2-multipoint; it is a broadcast mechanism. That is the issue. At what size VPN does a broadcast mechanism start becoming a useful tool? Just because you have a route reflector (one common answer given for this issue), you don't reduce the number of BGP messages being sent. BGP policies is another answer I saw: the filtering of messages at each PE doesn't reduce the number of messages sent. Tailoring the policy to cover the PEs in a VPN also doesn't quite cut it because you lose the auto-discovery since the membership is essentially encoded into the policy. So here's an example of an extension that would really work better with pt2pt signaling. Suppose we have a router that is not capable of tag manipulation. Martini extensions for signaling the desired tag value are described for the VLAN VC type. It would be possible to use that on a per-PW basis. Then we wouldn't require the VPLS tag manipulation capability. If you have that capability, as Ali pointed out in some other context, there are ways then to distribute the VPLS function across the PE and a bridge behind it. (Perhaps Ali will draw that picture; ascii art and multi-site VPNs don't go well together). > > Kireeti. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 18:52: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 SAA12557 for ; Wed, 23 Apr 2003 18:52:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NMsbG28755 for ; Wed, 23 Apr 2003 18:54:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NMsYh24428 for ; Wed, 23 Apr 2003 18:54:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030423142633.01d152a0@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Apr 2003 15:48:47 -0700 To: Kireeti Kompella , raszuk@cisco.com, sajassi@cisco.com From: Ali Sajassi Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Cc: Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com In-Reply-To: <200304232034.h3NKYVE80568@kummer.juniper.net> References: <4.3.2.7.2.20030423090700.01bb31e0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Hi Kireeti, Even though my original email was intended to find out what the SPs plan to do for P2P applications (e.g. VPWS) considering that it is based on Martini signaling and whether they want to have two types of signaling for L2VPN applications (e.g., one for VPWS and other for VPLS) considering that they say they want to leverage the same "tools" across different applications, you have focused in here on the applicability of BGP to VPLS application only. That's fine and lets go over it. At 01:34 PM 4/23/2003 -0700, Kireeti Kompella wrote: >Hi Ali, > > > The argument between BGP and LDP signaling is that the BGP-camp assumes > > that there is nothing else to be distributed to VPLS members except > labels; > > whereas, LDP camp doesn't want to impose such a big constraint as there > are > > PW characteristics (such as QoS, sequencing, OOB OAM) that require > > additional info exchanges. > >I've seen this argument repeated many times, so let me respond. > >Today, the PWs that make up a VPLS are point-to-point, i.e., each starts >at some PE and ends up on some other PE. This is not a completely ideal >situation, as one would really like to use point-to-multipoint tunnels >for flooding -- but we don't (yet) have that technology in MPLS. But >certainly for unicast, p2p PWs are fine. There are some VPLS proposal that use MP2P PWs for unicast but these proposals have some other issues. So P2P PWs for unicast is not the only approach but it is the one that got used in the original draft-lasserre and you are using it in your draft as well. >But let's not confuse the fact that VPLS PWs are point-to-point with >the nature (p2p or p2mp) of signaling for those PWs. > >The most basic function of signaling is the exchange of labels. This >is inherently point-to-multipoint -- all other PEs in a VPLS need to >know what labels to use to send packets to the signaling PE. > >The next function of signaling is the withdrawal of labels, either >because of administrative intervention or because the PE-CE link went >down. Again, this is point-to-multipoint -- all other PEs in the VPLS >need to be told. > >Another thing that needs to be communicated, be it during discovery or >during signaling, is the MTU on the PE-CE interfaces. Again, this is >point-to-multipoint -- the same value is sent to all peers. (BTW, to >correct your statement above, BGP does signal MTU, not just labels.) > >Another signaling function described in draft-lasserre-vkompella-ppvpn-vpls >is MAC Address Withdrawal. Again, this is point-to-multipoint -- a PE >uses this to inform all other PEs in the VPLS to remove a certain set >of MAC addresses from their filter tables. > >So, what aspect of signaling is inherently point-to-point? I.e., what >information might one want to signal to some (but not all) members of a >VPLS? Let's take your examples: Yes, we are having the same discussion as before and it comes down to whether there are PW specific info to be exchanged. So lets take a closer look. > > (such as QoS, sequencing, OOB OAM) > >1. QoS is a nice, broad term. To some, it means bandwidth settings > (CIR, burst, etc.); to others it means setting DSCPs or EXP bits. > Let's take these in turn. > >a) bandwidth (CIR, burst, ...): For VPLS (as for IP, i.e., for any-to-any > services), the most natural b/w expression is the "hose model", > where the PE-CE connection is limited to (say) 2M CIR and 8M burst. > > Even if a detailed traffic matrix ("pipe model") were desirable (for > VPLS and for IP), i.e., site 1 can send 2M to site 2, 6M to site 3, > etc., is there a need to signal this info? This is simply implemented > locally at each PE. > > If one goes down this path -- "we want a detailed traffic matrix, and > we have to signal this" -- does one then abandon BGP signaling for IP > VPNs and switch to LDP signaling? > > If on the other hand, one decides to go with the hose model, one > could very well use the bandwidth community for VPLS as well as for > RFC 2547 IP VPNs. > >b) DSCP/EXP setting -- this is again simply done locally, and in the > fortunate case of VLANs, there could be a straightforward mapping of > .1p bits to DSCP/EXP. Again, this mapping would be the same across > the VPLS (otherwise, one would have a management nightmare). Thus, > even if this was signaled, the signaling would be point-to-multipoint. When we talk about the QoS SLA, there are two aspects of it, one at the customer UNI and the other at the topology level (e.g., links among customer sites). With respect to the examples of QoS that you have provided, they are relevant to customer UNI and they don't address the topology side of it. To better understand what I mean by topology, let me give you an example. For the sake of this discussion, a VPLS instance for a given customer can be modeled by a set of Virtual switches connected with each other via PW links. Similar to the LAN network which is important for the customer to choose link BW and quality appropriately among different switches/bridges, it can be as important for the customer in doing the same thing for the PWs so that in case of congestion in the core, they are guaranteed with certain BW (either aggregate or on a per class basis). I have received such requirements from some customers although I don't think this would be the norm but nonetheless there will be some and we need to support it . So given that you want to setup BW and QoS on a per PW basis, then this is PW specific info that needs to be exchanged between two end-points and not everyone else. >2. Sequencing. It seems to me that for a given VPLS, one either does > sequencing among all the PEs for this VPLS, or not. The situation > where one does sequencing among some but not others seems excessively > complex. In any case, sequencing is done in the data plane -- a > sequence number of 0 means no sequencing; non-zero means do sequencing. Why not. Given that sequencing introduces additional overhead, the SP might want to be able to offer this at the lower granularity level (e.g., per pair of customer sites) rather than per VPLS instance. Also customer may want this service between two of its major hubs instead of among all the sites. >3. OOB OAM. Not sure what this means: what is to be signalled, and what > makes it point-to-point (i.e., PE1 wants to tell PE2 but not PE3)? > Could you elaborate? I meant OAM based on out-of-band - e.g., using signaling to check the PW status. As you have noticed there are some discussion on the list to control the status of the emulated VLAN (e.g., the set of PWs) based on the status of one of them. So one needs to be able to check the health of each PWs individually and having an out-of-band mechanism provides additional option. Also VCCV (which provides an OAM ping for PW) is based on LDP. >My conclusion (so far; I will wait for your/Eric's responses) is that >VPLS signaling is basically point-to-multipoint. That is bolstered by >the fact that the LDP signaling defined in lasserre-vkompella doesn't >actually have any parameters that are useful to signal to one PE in the >VPLS but not any other. Not everything has been addressed by the draft-lasserre-vkompella at this point but does it mean we should paints ourselves in the corner. -Ali >In the light of this conclusion, it seems much more natural to use a >point-to-multipoint signaling mechanism (BGP) for VPLS rather than a >point-to-point mechanism (LDP). > >Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 18:58:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13099 for ; Wed, 23 Apr 2003 18:58:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NN12G11597 for ; Wed, 23 Apr 2003 19:01:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NN0wh03140 for ; Wed, 23 Apr 2003 19:00:58 -0400 (EDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 23 Apr 2003 15:57:24 -0700 (PDT) From: Kireeti Kompella To: Vach Kompella cc: ppvpn@nortelnetworks.com Subject: RE: Draft-kompella-ppvpn-vpls-01 In-Reply-To: Message-ID: <20030423151047.D81032@kummer.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Hi Vach, On Wed, 23 Apr 2003, Vach Kompella wrote: > If you want to qualify the LDP usage by saying that it is targeted LDP > (which is different from regular LDP), then let's not pretend that BGP > NLRIs for IPv4, 2547 and L2VPNs are similar at all. No one is pretending that the BGP NLRIs for IPv4, 2547 and L2VPNs are the same, just as no one is pretending that the FECs for IPv4 and VPLS are the same. The protocol mechanisms for *distributing* and *processing* the NLRIs are the same, however. RDs and RTs have the same semantics and same processing. Resolution of NLRIs over tunnel LSPs works the same for 2547 NLRIs and L2VPNs. Similarly, the protocol mechanisms for *distributing* and *processing* the FECs are the same between 'hop-by-hop' LDP and targeted LDP. Some of the auxiliary stuff does change, though, like LDP neighbor discovery. Also with targeted LDP, you need a resolution mechanism (i.e., find an underlying tunnel) which you don't with 'hop-by-hop' LSPs. So, there are some differences between LDP and targetted LDP. I'll leave it to others to judge how significant these are. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 19:15:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13787 for ; Wed, 23 Apr 2003 19:15:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NNHtG15355 for ; Wed, 23 Apr 2003 19:17:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NNHph27065 for ; Wed, 23 Apr 2003 19:17:51 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Hector Avalos" , , Cc: , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Wed, 23 Apr 2003 16:13:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 23 Apr 2003 23:14:24.0628 (UTC) FILETIME=[14705B40:01C309EE] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Hector, > > Yes, SPs may have several tunneling protocols, even for vpls. But they > do not require 'complex' interaction with the autodiscovery and > signaling protocols. > Do you auto-discover the site IDs for each PE participating in an L2VPN (whether pt2pt or VPLS)? From what I understand, you don't. Then isn't configuring them, more or less sequentially to avoid unnecessary label waste, pretty much the same as identifying the PEs that are part of the VPN? You obviously don't want to accidentally make two PEs have the same site ID since they will end up using the same label in a label range. Do you think that configuring PE A to be site ID 1 in VPN 100 and site ID 5 in VPN 101 is confusing? You unfortunately cannot make the site ID unique to a PE, because it is an index into the label range. Would you prefer to use PE loopback or router ID as an ID, independently of the VPN, as is the case in the LDP signaling approach? > > Cheers > Hector > -------------------------- > Sent from my Wireless Handheld > -Vach From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 19:28:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14101 for ; Wed, 23 Apr 2003 19:28:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NNUoG19088 for ; Wed, 23 Apr 2003 19:30:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3NNUjh06123 for ; Wed, 23 Apr 2003 19:30:46 -0400 (EDT) Date: Wed, 23 Apr 2003 16:24:32 -0700 (PDT) Message-Id: <200304232324.h3NNOWu26345@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ali Sajassi Cc: ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-Reply-To: <4.3.2.7.2.20030423142633.01d152a0@airborne.cisco.com> References: <4.3.2.7.2.20030423090700.01bb31e0@airborne.cisco.com> <200304232034.h3NKYVE80568@kummer.juniper.net> <4.3.2.7.2.20030423142633.01d152a0@airborne.cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali Sajassi writes: > When we talk about the QoS SLA, there are two aspects of it, one at > the customer UNI and the other at the topology level (e.g., links > among customer sites). With respect to the examples of QoS that you > have provided, they are relevant to customer UNI and they don't > address the topology side of it. To better understand what I mean by > topology, let me give you an example. For the sake of this > discussion, a VPLS instance for a given customer can be modeled by a > set of Virtual switches connected with each other via PW > links. Similar to the LAN network which is important for the > customer to choose link BW and quality appropriately among different > switches/bridges, it can be as important for the customer in doing > the same thing for the PWs so that in case of congestion in the > core, they are guaranteed with certain BW (either aggregate or on a > per class basis). I have received such requirements from some > customers although I don't think this would be the norm but > nonetheless there will be some and we need to support it . So given > that you want to setup BW and QoS on a per PW basis, then this is PW > specific info that needs to be exchanged between two end-points and > not everyone else. I'm not sure i'm being able to parse your statement correctly... I'm assuming that you require the L2 service to be mapped to several different classes of service that the SP provides. The way this is implemented today (for 2547 or BGP-based L2VPN or VPLS) is: - You have "blue"/"red"/"green" RSVP LSPs between PEs. - Community tag on the corresponding BGP route selects which color LSP to use. This is deployed by more than one SP for 2547... it works AFAIK. Just another example why some people find it attractive to be able to use the same model L3VPNs and L2VPNs... a fair ammount of problems have been solved w/ L3VPNs that are also applicable to L2. IMHO, a deployable service has to include issues such as: inter-as operation, QoS mapping, auto-discovery, etc... Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 20:18: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 UAA15832 for ; Wed, 23 Apr 2003 20:18:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O0KVG03388 for ; Wed, 23 Apr 2003 20:20:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O0KSh21898 for ; Wed, 23 Apr 2003 20:20:28 -0400 (EDT) Date: Wed, 23 Apr 2003 17:16:56 -0700 (PDT) Message-Id: <200304240016.h3O0GuS69024@fuinar.juniper.net> From: Quaizar Vohra MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ali Sajassi Cc: Kireeti Kompella , raszuk@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-Reply-To: <4.3.2.7.2.20030423142633.01d152a0@airborne.cisco.com> References: <4.3.2.7.2.20030423090700.01bb31e0@airborne.cisco.com> <200304232034.h3NKYVE80568@kummer.juniper.net> <4.3.2.7.2.20030423142633.01d152a0@airborne.cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: qv@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, It seems that the argument for LDP signalling here is that it is flexible enough to allow for signalling of many a bells and whistles on a P2P basis. But if these bells and whistles are deduced from configuration then you end up loosing the benefits of autodiscovery. Autodiscovery followed by P2P signalling is beneficial if all the stuff signalled on a P2P basis is deduced interrnally within the protocol or if there is some inherent protocol behavior which is p2p in nature then I can see the usefulness of P2P signalling. Quaizar > > When we talk about the QoS SLA, there are two aspects of it, one at the > customer UNI and the other at the topology level (e.g., links among > customer sites). With respect to the examples of QoS that you have > provided, they are relevant to customer UNI and they don't address the > topology side of it. To better understand what I mean by topology, let me > give you an example. For the sake of this discussion, a VPLS instance for a > given customer can be modeled by a set of Virtual switches connected with > each other via PW links. Similar to the LAN network which is important for > the customer to choose link BW and quality appropriately among different > switches/bridges, it can be as important for the customer in doing the same > thing for the PWs so that in case of congestion in the core, they are > guaranteed with certain BW (either aggregate or on a per class basis). I > have received such requirements from some customers although I don't think > this would be the norm but nonetheless there will be some and we need to > support it . So given that you want to setup BW and QoS on a per PW basis, > then this is PW specific info that needs to be exchanged between two > end-points and not everyone else. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 22:24: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 WAA18892 for ; Wed, 23 Apr 2003 22:24:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O2QUG16959 for ; Wed, 23 Apr 2003 22:26:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O2QOh16202 for ; Wed, 23 Apr 2003 22:26:24 -0400 (EDT) Date: Thu, 24 Apr 2003 11:20:37 +0900 (JST) Message-Id: <20030424.112037.74674082.suzuki.muneyoshi@lab.ntt.co.jp> To: sganguly@yahoo.com Cc: jwils@coriolisnet.com, nfinn@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <20030423193258.93789.qmail@web12504.mail.yahoo.com> References: <20030423.141232.41706744.suzuki.muneyoshi@lab.ntt.co.jp> <20030423193258.93789.qmail@web12504.mail.yahoo.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Sukanta, > Just curious as to why you specified that "this kind > of work can't be progressed in the IETF" ? I did not say "can't" but think it is difficult, because, obviously it is out scope of the PPVPN WG charter. In my understanding, we need BOF to progress this kind of work. However, this proposal use IP routing protocol as technology but target is MAC frame routing. Is this in scope of the IETF? I think it is gray. From a technical view point, it is clear from the standard, MAC frame forwarding permits tentative out-sequence delivery, but loop is prohibited even if it is tentative. However, it is too difficult for current IP routing protocols to ensure loop free operation. So, a TTL field is indispensable in MAC frame, but it does not have the TTL. Therefore, this technology can't support current MAC frame; but it may be applicable Q-in-Q or MAC-in-MAC that have the TTL field. I think this is an allowable restriction, but this work can not be accomplished the IETF alone, co-operation with IEEE 801 is indispensable. If someone is interested in this work, please contact me. If there are sufficient interests, I will ask BOF to the IESG. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 23 22:42:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19331 for ; Wed, 23 Apr 2003 22:42:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O2imG20657 for ; Wed, 23 Apr 2003 22:44:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O2iir24318 for ; Wed, 23 Apr 2003 22:44:44 -0400 (EDT) Date: Thu, 24 Apr 2003 11:39:03 +0900 (JST) Message-Id: <20030424.113903.41710607.suzuki.muneyoshi@lab.ntt.co.jp> To: erosen@cisco.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <200304231336.h3NDaUlY013204@rtp-core-1.cisco.com> References: <20030423.115329.07564874.suzuki.muneyoshi@lab.ntt.co.jp> <200304231336.h3NDaUlY013204@rtp-core-1.cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > Muneyoshi> It is much better than the fragility solution that has loop, > Muneyoshi> blackhole or unreliable flaky PEs problems. > That's not much of a cost-benefit analysis. Good point. The most expensive is network maintenance labor costs. The worst case is the network is down due to corner-cutting implementation, then someone is awaken by midnight phone, and run around to reboot boxes. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 00:12:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21959 for ; Thu, 24 Apr 2003 00:12:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O4Efr04419 for ; Thu, 24 Apr 2003 00:14:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O4Ect11511 for ; Thu, 24 Apr 2003 00:14:38 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Muneyoshi Suzuki" , Cc: , , Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Wed, 23 Apr 2003 21:09:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: <20030424.112037.74674082.suzuki.muneyoshi@lab.ntt.co.jp> X-OriginalArrivalTime: 24 Apr 2003 04:10:36.0036 (UTC) FILETIME=[75060440:01C30A17] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Muneyoshi, > > From a technical view point, it is clear from the standard, MAC frame > forwarding permits tentative out-sequence delivery, but loop is prohibited > even if it is tentative. However, it is too difficult for current IP > routing protocols to ensure loop free operation. So, a TTL field is > indispensable in MAC frame, but it does not have the TTL. Therefore, > this technology can't support current MAC frame; but it may be applicable > Q-in-Q or MAC-in-MAC that have the TTL field. I think this is an allowable > restriction, but this work can not be accomplished the IETF alone, > co-operation with IEEE 801 is indispensable. Yes, defining a TTL in the MAC frame is out of scope for the IETF. If the IEEE is going to define something like this, and we want an L2 solution for the provider network, then we will work with the IEEE. Is something about the fact that we want to work with the IEEE 802.1ad wg bothering you? Is it insufficient? Do we need to work with some other group? > > If someone is interested in this work, please contact me. If there are > sufficient interests, I will ask BOF to the IESG. Why do we need a new working group? Why can't it be done here in the ppvpn WG? Or perhaps in the PWE3 WG? > > Thanks, > > Thanks. > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 03:31: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 DAA07182 for ; Thu, 24 Apr 2003 03:31:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O7Xir21791 for ; Thu, 24 Apr 2003 03:33:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O7Xep18292 for ; Thu, 24 Apr 2003 03:33:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Thu, 24 Apr 2003 09:30:56 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMJM9SYCHihuvjCRRySW69uXNobFQAgsmQg From: "Hector Avalos" To: "Ali Sajassi" Cc: X-OriginalArrivalTime: 24 Apr 2003 07:30:57.0638 (UTC) FILETIME=[7274E860:01C30A33] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA07182 I guess that your question should be addressed to all SPs planning to deploy VPLS regardless if they support kompella draft or lasserre-vkompella. Isn't it ? So we can have a better picture. cheers, Hector -----Original Message----- From: Ali Sajassi [mailto:sajassi@cisco.com] Sent: Wednesday, April 23, 2003 2:59 AM To: Andrea Ferrarese; ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 I'd like to know how many of the service providers who support this draft, only plan to offer multi-point Ethernet service (VPLS) and do NOT plan to offer point-to-point Ethernet service? If a service provider plans to offer both types of services, then do they plan to use BGP for PW signaling of PtP Ethernet service ? Thanks, Ali At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: >We support draft-kompella-ppvpn-vpls-01 > >We found that BGP control plane give scalability and flexibility. We >like >the possibility to maintain the actual config and VPN infrastructure >for >both l2 and l3 VPN. > >Thank you From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 03:59: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 DAA07542 for ; Thu, 24 Apr 2003 03:59:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O821r29793 for ; Thu, 24 Apr 2003 04:02:01 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O81vh02796 for ; Thu, 24 Apr 2003 04:01:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:recallmessage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Recall: Draft-kpmpella-ppvpn-vpls-01 Date: Thu, 24 Apr 2003 09:58:38 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMKN1AuB0vNS+HvSjuZI50IlnWiGw== Priority: Urgent Expiry-Date: Sat, 26 Apr 2003 09:58:14 +0200 From: "Hector Avalos" To: "Ali Sajassi" Cc: X-OriginalArrivalTime: 24 Apr 2003 07:58:39.0217 (UTC) FILETIME=[50D5BE10:01C30A37] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA07542 Hector Avalos would like to recall the message, "Draft-kpmpella-ppvpn-vpls-01". From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 04:24:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07929 for ; Thu, 24 Apr 2003 04:24:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O8QQr04634 for ; Thu, 24 Apr 2003 04:26:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O8QMM20635 for ; Thu, 24 Apr 2003 04:26:23 -0400 (EDT) Subject: Help on IEE802.1ad Date: Thu, 24 Apr 2003 16:24:42 +0800 Message-ID: <570B29DA89E90345B425CAF151BC0CFE022BDD@qqmail.qqtechnology.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30A3A.F48F1BCA" Thread-Topic: Help on IEE802.1ad Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 thread-index: AcMKOvSb/2iTS4XeQSetRE93qKuBoA== From: "Lu Xiao Min" To: X-SMTP-HELO: qqmail.qqtechnology.com X-SMTP-MAIL-FROM: xmlu@qqtechnology.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [211.144.14.125] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30A3A.F48F1BCA Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear all, I am working on VPLS. Could I possibly get the IEEE802.1ad draft ( I am not the IEEE802.1 member yet). Thanks for your assistance. Xiaomin Lu ------_=_NextPart_001_01C30A3A.F48F1BCA Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Help on IEE802.1ad

Dear = all,

I am working on = VPLS. Could I possibly get the IEEE802.1ad draft (
I am not the = IEEE802.1 member yet). Thanks for your assistance.


Xiaomin = Lu

------_=_NextPart_001_01C30A3A.F48F1BCA-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 05:53: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 FAA09777 for ; Thu, 24 Apr 2003 05:53:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3O9ttr22887 for ; Thu, 24 Apr 2003 05:55:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3O9tpo22022 for ; Thu, 24 Apr 2003 05:55:52 -0400 (EDT) Subject: RE: Draft-kpmpella-ppvpn-vpls-01 From: Giles Heron To: Hector Avalos Cc: Ali Sajassi , ppvpn@nortelnetworks.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Apr 2003 10:50:07 +0000 Message-Id: <1051181407.1934.25.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Well, we're planning to deploy both VPLS and PtoP (already have PtoP). We will be using LDP for both (we're using martini for PtoP and will use lasserre-vkompella for VPLS). Using BGP to distribute label ranges to all your peers so that each peer can pick out its own label, rather than using LDP to signal a label direct to each peer, feels like a bit of a kludge. If you're going to use BGP then I'd suggest using a source identifier on each packet so you can distribute the same label to all peers - perhaps go for UTI/L2TPv3 encaps rather than MPLS and rely on the source IP? Giles p.s. this is my own, unsolicited, opinion. No vendor asked me to state my position on the list or anything like that ;-) On Thu, 2003-04-24 at 07:30, Hector Avalos wrote: > I guess that your question should be addressed to all SPs planning to > deploy VPLS regardless if they support kompella draft or > lasserre-vkompella. Isn't it ? > > So we can have a better picture. > > cheers, > > Hector > > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Wednesday, April 23, 2003 2:59 AM > To: Andrea Ferrarese; ppvpn@nortelnetworks.com > Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > I'd like to know how many of the service providers who support this > draft, > only plan to offer multi-point Ethernet service (VPLS) and do NOT plan > to > offer point-to-point Ethernet service? > > If a service provider plans to offer both types of services, then do > they > plan to use BGP for PW signaling of PtP Ethernet service ? > > Thanks, > Ali > > At 06:15 PM 4/22/2003 +0200, Andrea Ferrarese wrote: > >We support draft-kompella-ppvpn-vpls-01 > > > >We found that BGP control plane give scalability and flexibility. We > >like > >the possibility to maintain the actual config and VPN infrastructure > >for > >both l2 and l3 VPN. > > > >Thank you > > > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 07:35:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11643 for ; Thu, 24 Apr 2003 07:35:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OBbSr06088 for ; Thu, 24 Apr 2003 07:37:28 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OBbPd00764 for ; Thu, 24 Apr 2003 07:37:25 -0400 (EDT) Message-Id: <200304241132.HAA11500@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-marques-ppvpn-ibgp-00.txt Date: Thu, 24 Apr 2003 07:32:13 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RFC2547bis networks using internal BGP as PE-CE protocol Author(s) : P. Marques et al. Filename : draft-marques-ppvpn-ibgp-00.txt Pages : 9 Date : 2003-4-23 This document defines protocol extensions and procedures for BGP PE- CE router iteration in RFC2547bis networks. These have the objective of making the usage of the RFC2547bis VPN transparent to the customer network, as far as routing information is concerned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-marques-ppvpn-ibgp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-marques-ppvpn-ibgp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-marques-ppvpn-ibgp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-23155448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-marques-ppvpn-ibgp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-marques-ppvpn-ibgp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-23155448.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 11:05:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19101 for ; Thu, 24 Apr 2003 11:05:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OF84r09859 for ; Thu, 24 Apr 2003 11:08:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OF80p20851 for ; Thu, 24 Apr 2003 11:08:00 -0400 (EDT) Message-Id: <5.2.0.9.2.20030424105011.028bffc0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 10:51:01 -0400 To: , "Kireeti Kompella" , , From: "Thomas D. Nadeau" Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Cc: , In-Reply-To: References: <200304232034.h3NKYVE80568@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: At 03:06 PM 4/23/2003 -0700, Vach Kompella wrote: >Kireeti, > >See below. > >-Vach > > > > > But let's not confuse the fact that VPLS PWs are point-to-point with > > the nature (p2p or p2mp) of signaling for those PWs. > > > > The most basic function of signaling is the exchange of labels. This > > is inherently point-to-multipoint -- all other PEs in a VPLS need to > > know what labels to use to send packets to the signaling PE. > >Which is a pt-2-pt function. The fact that you are using a multi-point >approach >does not actually reflect that what you are doing is pt-2-pt (since the labels >are signaled pt2pt, despite the label ranges). > >This is quite unlike the *true* pt-2-multipoint nature of, say, a route >advertisement in IPv4, where everyone uses that route (modulo IGP costs, >etc.), >or VPN-IPv4 route advertisements, which all participating PEs use identically. > >Or, as you pointed out, the MTU, which it would be nice (but not essential) to >send pt-2-multipoint to all PEs in a VPLS. > > > > > In the light of this conclusion, it seems much more natural to use a > > point-to-multipoint signaling mechanism (BGP) for VPLS rather than a > > point-to-point mechanism (LDP). > >BGP, to be precise, is not a pt-2-multipoint; it is a broadcast >mechanism. That >is the issue. At what size VPN does a broadcast mechanism start becoming a >useful tool? Just because you have a route reflector (one common answer given >for this issue), you don't reduce the number of BGP messages being sent. > >BGP policies is another answer I saw: the filtering of messages at each PE >doesn't reduce the number of messages sent. Tailoring the policy to cover the >PEs in a VPN also doesn't quite cut it because you lose the auto-discovery >since >the membership is essentially encoded into the policy. You also left out the fact that crafting these policies is not always such a trivial effort. --Tom >So here's an example of an extension that would really work better with pt2pt >signaling. Suppose we have a router that is not capable of tag manipulation. >Martini extensions for signaling the desired tag value are described for the >VLAN VC type. It would be possible to use that on a per-PW basis. Then we >wouldn't require the VPLS tag manipulation capability. If you have that >capability, as Ali pointed out in some other context, there are ways then to >distribute the VPLS function across the PE and a bridge behind >it. (Perhaps Ali >will draw that picture; ascii art and multi-site VPNs don't go well together). > > > > > Kireeti. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 11:15:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19525 for ; Thu, 24 Apr 2003 11:15:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OFI2r13711 for ; Thu, 24 Apr 2003 11:18:02 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OFHwK06181 for ; Thu, 24 Apr 2003 11:17:58 -0400 (EDT) Message-ID: <3EA7FE32.36EA6588@cisco.com> Date: Thu, 24 Apr 2003 17:09:38 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: vkompella@timetra.com, Kireeti Kompella , sajassi@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 References: <200304232034.h3NKYVE80568@kummer.juniper.net> <5.2.0.9.2.20030424105011.028bffc0@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > >BGP, to be precise, is not a pt-2-multipoint; it is a broadcast > >mechanism. That > >is the issue. At what size VPN does a broadcast mechanism start becoming a > >useful tool? Just because you have a route reflector (one common answer given > >for this issue), you don't reduce the number of BGP messages being sent. > > > >BGP policies is another answer I saw: the filtering of messages at each PE > >doesn't reduce the number of messages sent. Tailoring the policy to cover the > >PEs in a VPN also doesn't quite cut it because you lose the auto-discovery > >since > >the membership is essentially encoded into the policy. > > You also left out the fact that crafting these policies is not > always such a trivial effort. Well if we are into left out points sure RR does not reduce the number of BGP mesages send nor does filtering at each PE do so. But BGP mechanism like extended community ORF (or similar approaches based on policy propagation see draft-marques-ppvpn-rt-constrain-00.txt as a possible indication of more then peer to peer policy propagation) achive the very point of both above paragraphs at a per RT granularity quite well ;-). R. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 11:30:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20111 for ; Thu, 24 Apr 2003 11:30:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OFWPr18852 for ; Thu, 24 Apr 2003 11:32:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OFWLe22325 for ; Thu, 24 Apr 2003 11:32:21 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30A75.BA3FE06E" x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 Subject: ppvpn effort support Date: Thu, 24 Apr 2003 17:25:24 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A016DFDB8@lanmhs20.rd.francetelecom.fr> Thread-Topic: ppvpn effort support Thread-Index: AcMKdbozwHvfCj95RiCjU3zQ3s0FMw== From: "NIGER Philippe FTRD/RTA/LAN" To: Cc: "NIGER Philippe FTRD/RTA/LAN" X-OriginalArrivalTime: 24 Apr 2003 15:25:25.0695 (UTC) FILETIME=[BABDACF0:01C30A75] X-SMTP-HELO: p-mail1.rd.francetelecom.com X-SMTP-MAIL-FROM: philippe.niger@rd.francetelecom.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: p-mail1.rd.francetelecom.com [195.101.245.15] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30A75.BA3FE06E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some of our colleagues within France Telecom have already expressed = their support to draft-kompella-ppvpn-vpls, particularly for the support = of Ethernet service with a national or international coverage, using = well known BGP signalling already in use for L3 VPN. For a Service Provider like France Telecom there is another application = that need to be covered : the definition of local Ethernet service, = typically offered over a MAN. For this application others solutions = could be envisaged for a potential VPLS service, based on different = technical approaches. We think that the solutions described today in = draft-laserre-vkompella-ppvpn-vpls and draft-radoaca-ppvpn-gvpls propose = solutions with interesting components that should be considered and = study more in depth by the group. So in addition to the support mention earlier, I would support both = draft-laserre-vkompella-ppvpn-vpls and draft-radoaca-ppvpn-gvpls as = working group documents. Best regards, =20 Philippe Niger France Telecom R&D Branch. ------_=_NextPart_001_01C30A75.BA3FE06E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ppvpn effort support

Some of our colleagues within France = Telecom have already expressed their support to = draft-kompella-ppvpn-vpls, particularly for the support of Ethernet = service with a national or international coverage, using well known BGP = signalling already in use for L3 VPN.

For a Service Provider like France = Telecom there is another application that need to be covered : the = definition of local Ethernet service, typically offered over a MAN. For = this application others solutions could be envisaged for a potential = VPLS service, based on different technical approaches. We think that the = solutions described today in draft-laserre-vkompella-ppvpn-vpls and = draft-radoaca-ppvpn-gvpls propose solutions with interesting components = that should be considered and study more in depth by the = group.

So in addition to the support mention = earlier, I would support both draft-laserre-vkompella-ppvpn-vpls and draft-radoaca-ppvpn-gvpls as working group documents.

Best regards,
 
Philippe Niger
France Telecom R&D Branch.

------_=_NextPart_001_01C30A75.BA3FE06E-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 12:02:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21131 for ; Thu, 24 Apr 2003 12:02:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OG4Pr09877 for ; Thu, 24 Apr 2003 12:04:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OG4LA04720 for ; Thu, 24 Apr 2003 12:04:22 -0400 (EDT) Message-ID: <016f01c30a78$65912470$03c7380a@duckettm> From: "Mike Duckett \(Dotnet\)" To: References: <4.3.2.7.2.20030423090700.01bb31e0@airborne.cisco.com> <4.3.2.7.2.20030423142633.01d152a0@airborne.cisco.com> Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Date: Thu, 24 Apr 2003 11:44:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: imf46bis.bellsouth.net X-SMTP-MAIL-FROM: mduckett@bellsouth.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail134.mail.bellsouth.net [205.152.58.94] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, I think the WG goal is to move forward with a reduced set of proposals. Otherwise, efforts are diluted, costs are higher, interoperability issues abound, and the ability to impact the market is impaired. Reducing proposals requires evaluation of options and considering deficits. Therefore, corners will be considered. ----- Original Message ----- From: "Ali Sajassi" To: "Kireeti Kompella" ; ; Cc: ; Sent: Wednesday, April 23, 2003 6:48 PM Subject: Re: Draft-kpmpella-ppvpn-vpls-01 [snip] > > >My conclusion (so far; I will wait for your/Eric's responses) is that > >VPLS signaling is basically point-to-multipoint. That is bolstered by > >the fact that the LDP signaling defined in lasserre-vkompella doesn't > >actually have any parameters that are useful to signal to one PE in the > >VPLS but not any other. > > Not everything has been addressed by the draft-lasserre-vkompella at this > point but does it mean we should paints ourselves in the corner. > > -Ali > > > > >In the light of this conclusion, it seems much more natural to use a > >point-to-multipoint signaling mechanism (BGP) for VPLS rather than a > >point-to-point mechanism (LDP). > > > >Kireeti. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 12:09:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21671 for ; Thu, 24 Apr 2003 12:09:12 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OGBQr13805 for ; Thu, 24 Apr 2003 12:11:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OGBLA01209 for ; Thu, 24 Apr 2003 12:11:21 -0400 (EDT) From: "Jim Guichard" To: , "Thomas D. Nadeau" Cc: , "Kireeti Kompella" , , , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Thu, 24 Apr 2003 12:00:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3EA7FE32.36EA6588@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit yes, but why introduce all this machinery for L2 PW when you can just send it directly to the relevant peer using existing PWE3 defined mechanisms ? I think the other point that Tom was making is that maintenance of the filtering is not trivial even with tools such as ORF. Jim > >-----Original Message----- > >From: Robert Raszuk [mailto:raszuk@cisco.com] > >Sent: Thursday, April 24, 2003 11:10 AM > >To: Thomas D. Nadeau > >Cc: vkompella@timetra.com; Kireeti Kompella; sajassi@cisco.com; > >Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > > > >> >BGP, to be precise, is not a pt-2-multipoint; it is a broadcast > >> >mechanism. That > >> >is the issue. At what size VPN does a broadcast mechanism > >start becoming a > >> >useful tool? Just because you have a route reflector (one > >common answer given > >> >for this issue), you don't reduce the number of BGP messages > >being sent. > >> > > >> >BGP policies is another answer I saw: the filtering of > >messages at each PE > >> >doesn't reduce the number of messages sent. Tailoring the > >policy to cover the > >> >PEs in a VPN also doesn't quite cut it because you lose the > >auto-discovery > >> >since > >> >the membership is essentially encoded into the policy. > >> > >> You also left out the fact that crafting these policies is not > >> always such a trivial effort. > > > > > >Well if we are into left out points sure RR does not reduce the number > >of BGP mesages send nor does filtering at each PE do so. > > > >But BGP mechanism like extended community ORF (or similar approaches > >based on policy propagation see draft-marques-ppvpn-rt-constrain-00.txt > >as a possible indication of more then peer to peer policy propagation) > >achive the very point of both above paragraphs at a per RT granularity > >quite well ;-). > > > >R. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 12:40:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23016 for ; Thu, 24 Apr 2003 12:40:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OGgUr19891 for ; Thu, 24 Apr 2003 12:42:31 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OGgRj26425 for ; Thu, 24 Apr 2003 12:42:27 -0400 (EDT) Message-ID: <3EA8114F.8273D1B3@cisco.com> Date: Thu, 24 Apr 2003 18:31:11 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Guichard CC: "Thomas D. Nadeau" , vkompella@timetra.com, Kireeti Kompella , sajassi@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Well from my personal observations the dispute to use BGP or directed LDP for VPLS service can go on for months :). What I think we as ppvpn group should be looking at is a signaling protocol for VPLS aplication as such which could work for any transport ... p2p MPLS, p2mp MPLS, L2TPv3, realiable multicast etc .... Selection of signalling by all means should not be associated with auto-discovery by design. I think we all agree with this one. Although pushing forward only one signalling approach being now p2p MPLS very tightly associated with the transport seems IMHO not too future oriented vision. I think if we would have had deployed some other then BGP generalized flooding protocol kompella-vpls would use it. For the lack of it and presence of BGP commonly used the authors choice was clear. The reason I do have some sympathy to this approach is that today the trick/hack/clever design is to use a formula and calculate the label by reciever not by senders, tomorrow it could be extended to distribute L2TPv3 parameters or some multicast keys. Hopefully VPLS service in WANs will die soon but if not does the replication on ingress to SP core (for broadcast/multicats) is the best of flat ethernet distributions strategy which would be done for years to come ? On the other hand I fully support that for p2p L2 transport services p2p signalling should be a clear choice - today being directed LDP or L2TPv3. R. > Jim Guichard wrote: > > yes, but why introduce all this machinery for L2 PW when you can just send > it directly to the relevant peer using existing PWE3 defined mechanisms ? I > think the other point that Tom was making is that maintenance of the > filtering is not trivial even with tools such as ORF. Jim > > > >-----Original Message----- > > >From: Robert Raszuk [mailto:raszuk@cisco.com] > > >Sent: Thursday, April 24, 2003 11:10 AM > > >To: Thomas D. Nadeau > > >Cc: vkompella@timetra.com; Kireeti Kompella; sajassi@cisco.com; > > >Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > > > > > > > >> >BGP, to be precise, is not a pt-2-multipoint; it is a broadcast > > >> >mechanism. That > > >> >is the issue. At what size VPN does a broadcast mechanism > > >start becoming a > > >> >useful tool? Just because you have a route reflector (one > > >common answer given > > >> >for this issue), you don't reduce the number of BGP messages > > >being sent. > > >> > > > >> >BGP policies is another answer I saw: the filtering of > > >messages at each PE > > >> >doesn't reduce the number of messages sent. Tailoring the > > >policy to cover the > > >> >PEs in a VPN also doesn't quite cut it because you lose the > > >auto-discovery > > >> >since > > >> >the membership is essentially encoded into the policy. > > >> > > >> You also left out the fact that crafting these policies is not > > >> always such a trivial effort. > > > > > > > > >Well if we are into left out points sure RR does not reduce the number > > >of BGP mesages send nor does filtering at each PE do so. > > > > > >But BGP mechanism like extended community ORF (or similar approaches > > >based on policy propagation see draft-marques-ppvpn-rt-constrain-00.txt > > >as a possible indication of more then peer to peer policy propagation) > > >achive the very point of both above paragraphs at a per RT granularity > > >quite well ;-). > > > > > >R. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 13:25:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24248 for ; Thu, 24 Apr 2003 13:25:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OHRKr12412 for ; Thu, 24 Apr 2003 13:27:20 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OHRG025214 for ; Thu, 24 Apr 2003 13:27:17 -0400 (EDT) Message-Id: <200304241720.h3OHK9lY012002@rtp-core-1.cisco.com> To: steven.wright@BellSouth.com cc: ppvpn@nortelnetworks.com Subject: Re: ppvpn effort support In-reply-to: Your message of Wed, 23 Apr 2003 13:15:23 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 24 Apr 2003 13:20:09 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Steven> while the hierarchical concepts of draft lasserre are important, I Steven> expect these notions of hierarchy will be associated with Steven> administrative boundaries. Administrative boundaries also imply Steven> administrative policy and BGP is the accepted tool for managing Steven> this. I wonder if you could be more specific about this, perhaps an example of inter-AS L2VPN service where you want to set up policies at the inter-AS border. I'd like to understand better the degree to which the policy management is dependent on the underlying signaling protocol. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 13:47:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25042 for ; Thu, 24 Apr 2003 13:47:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OHnLr18158 for ; Thu, 24 Apr 2003 13:49:21 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OHnH409941 for ; Thu, 24 Apr 2003 13:49:18 -0400 (EDT) Reply-To: From: "Steven.Wright" To: Cc: Subject: RE: ppvpn effort support Date: Thu, 24 Apr 2003 13:42:33 -0400 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200304241720.h3OHK9lY012002@rtp-core-1.cisco.com> X-SMTP-HELO: aismtp4g.bellsouth.com X-SMTP-MAIL-FROM: steven.wright@BellSouth.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: aismtp4g.bellsouth.com [139.76.165.194] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Assume you have a large emulated Ethernet network that stretches across multiple service boundaries i.e multiple AS's. I expect you will want to have an Ethernet service abstraction corresponding to each AS, i.e. something like each AS will appear as a virtual switch in the emulated topology. I think those virtual switch notions are similar to the hierarchy notions identified as needed for vpls. My point is that there will be operational and administrative reasons for having some emulated service abstractions to match up with underlying network boundaries. I expect that the emulation of Ethernet services over a Multi-AS network will be of interest to a number of service providers, both within their own networks and between service providers. Even in the case of a single provider Multiple-AS instantiation of a vpls service, I expect BGP will be involved. I don't think there are any other viable alternatives for inter-AS MPLS. So we needs must make best use of what is available. Steven Wright > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, April 24, 2003 1:20 PM > To: steven.wright@bellsouth.com > Cc: ppvpn@nortelnetworks.com > Subject: Re: ppvpn effort support > > > > Steven> while the hierarchical concepts of draft lasserre > are important, I > Steven> expect these notions of hierarchy will be > associated with > Steven> administrative boundaries. Administrative > boundaries also imply > Steven> administrative policy and BGP is the accepted > tool for managing > Steven> this. > > I wonder if you could be more specific about this, perhaps > an example of > inter-AS L2VPN service where you want to set up policies > at the inter-AS > border. I'd like to understand better the degree to > which the policy > management is dependent on the underlying signaling protocol. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 14:05:38 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25596 for ; Thu, 24 Apr 2003 14:05:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OI7or07471 for ; Thu, 24 Apr 2003 14:07:50 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OI7k127079 for ; Thu, 24 Apr 2003 14:07:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16040.9406.852239.452284@harjus.eng.song.fi> Date: Thu, 24 Apr 2003 20:54:06 +0300 To: Cc: , Subject: RE: ppvpn effort support In-Reply-To: References: <200304241720.h3OHK9lY012002@rtp-core-1.cisco.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Steven.Wright writes: > I expect that the emulation of Ethernet services over a Multi-AS network > will be of interest to a number of service providers, both within their own > networks and between service providers. sure. > Even in the case of a single provider Multiple-AS instantiation of a vpls > service, I expect BGP will be involved. I don't think there are any other > viable alternatives for inter-AS MPLS. So we needs must make best use of > what is available. why would you need bgp or mpls if you have radius and l2tpv3? radius discovery works fine between providers and doesn't care about ASes. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 14:25:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26068 for ; Thu, 24 Apr 2003 14:25:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OIROr12213 for ; Thu, 24 Apr 2003 14:27:24 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OIRJD17334 for ; Thu, 24 Apr 2003 14:27:20 -0400 (EDT) Message-Id: <5.2.0.9.2.20030424140754.0293ee18@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 14:08:12 -0400 To: "Jim Guichard" , From: "Thomas D. Nadeau" Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Cc: , "Kireeti Kompella" , , , In-Reply-To: References: <3EA7FE32.36EA6588@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: >yes, but why introduce all this machinery for L2 PW when you can just send >it directly to the relevant peer using existing PWE3 defined mechanisms ? I >think the other point that Tom was making is that maintenance of the >filtering is not trivial even with tools such as ORF. Jim Precisely my point. --Tom > > >-----Original Message----- > > >From: Robert Raszuk [mailto:raszuk@cisco.com] > > >Sent: Thursday, April 24, 2003 11:10 AM > > >To: Thomas D. Nadeau > > >Cc: vkompella@timetra.com; Kireeti Kompella; sajassi@cisco.com; > > >Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > > >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > > > > > > > > > > >> >BGP, to be precise, is not a pt-2-multipoint; it is a broadcast > > >> >mechanism. That > > >> >is the issue. At what size VPN does a broadcast mechanism > > >start becoming a > > >> >useful tool? Just because you have a route reflector (one > > >common answer given > > >> >for this issue), you don't reduce the number of BGP messages > > >being sent. > > >> > > > >> >BGP policies is another answer I saw: the filtering of > > >messages at each PE > > >> >doesn't reduce the number of messages sent. Tailoring the > > >policy to cover the > > >> >PEs in a VPN also doesn't quite cut it because you lose the > > >auto-discovery > > >> >since > > >> >the membership is essentially encoded into the policy. > > >> > > >> You also left out the fact that crafting these policies is not > > >> always such a trivial effort. > > > > > > > > >Well if we are into left out points sure RR does not reduce the number > > >of BGP mesages send nor does filtering at each PE do so. > > > > > >But BGP mechanism like extended community ORF (or similar approaches > > >based on policy propagation see draft-marques-ppvpn-rt-constrain-00.txt > > >as a possible indication of more then peer to peer policy propagation) > > >achive the very point of both above paragraphs at a per RT granularity > > >quite well ;-). > > > > > >R. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 14:32:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26272 for ; Thu, 24 Apr 2003 14:32:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OIYhr16305 for ; Thu, 24 Apr 2003 14:34:43 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OIYeP25148 for ; Thu, 24 Apr 2003 14:34:40 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6764@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: jh@lohi.eng.song.fi, steven.wright@BellSouth.com Cc: erosen@cisco.com, ppvpn@nortelnetworks.com Subject: RE: ppvpn effort support Date: Thu, 24 Apr 2003 19:29:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Juha Heinanen wrote 24 April 2003 18:54 > Steven.Wright writes: > > > I expect that the emulation of Ethernet services over a > Multi-AS network > > will be of interest to a number of service providers, both > within their own > > networks and between service providers. > > sure. > > > Even in the case of a single provider Multiple-AS > instantiation of a vpls > > service, I expect BGP will be involved. I don't think > there are any other > > viable alternatives for inter-AS MPLS. So we needs must > make best use of > > what is available. > > why would you need bgp or mpls if you have radius and l2tpv3? radius > discovery works fine between providers and doesn't care about ASes. > > -- juha NH=> Juha, we are very interested in you ideas wrt radius, but I feel we need to decouple the forwarding mode from the discovery/signalling issues. If we put to one-side the unusual nature and problematic effects of LDP mp2p constructs, then p2p and p2mp constructs in MPLS would represent a valid co pkt-sw mode, and lt2pv3 a complimentary cnls mode. Both co pkt-sw and cnls forwarding modes are required in our opinion (and also co cct-sw modes for the L1 transport networks) because they offer different behaviours which we believe have value. regards, Neil > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 15:10:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28611 for ; Thu, 24 Apr 2003 15:10:37 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OJCpr07798 for ; Thu, 24 Apr 2003 15:12:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OJCj602908 for ; Thu, 24 Apr 2003 15:12:46 -0400 (EDT) Message-Id: <200304241857.h3OIvflY017376@rtp-core-1.cisco.com> To: Kireeti Kompella cc: raszuk@cisco.com, sajassi@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-reply-to: Your message of Wed, 23 Apr 2003 13:34:31 -0700. <200304232034.h3NKYVE80568@kummer.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 24 Apr 2003 14:57:41 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Kireeti> The most basic function of signaling is the exchange of labels. This Kireeti> is inherently point-to-multipoint -- all other PEs in a VPLS need to Kireeti> know what labels to use to send packets to the signaling PE. Well, if you owe $1.00 to each of 100 people, you owe $100, but you wouldn't send each one a $100 bill. Or would you? ;-) When a new PE, PE A, joins the VPLS, it must assign a label to each of the other PEs. PE A must distribute, to each of the other PEs, the label that A has assigned **to that particular PE**. Since a different label must be distributed to each of the other PEs, this signaling is inherently point-to-point, not point-to-multipoint. Further, each of the other PEs now has to assign a label for PE A to use, and distribute that label to PE A. Again, this is inherently point-to- point. No other PE needs to send any labels to anyone other than PE A. Certainly we don't want PE B telling PE C, "just for your information, here's the label I'm giving to PE A". Point-to-multipoint signaling would be required if PE A sent the same label to each of the other PEs, i.e., if the pseudowires were multipoint-to- point (as in IPLS). But you can't do VPLS with multipoint-to-point PWs, because there would be no way to do the MAC learning. By the way, if you agree that BGP signaling only makes sense when the signaling operations are inherently point-to-multipoint, perhaps we can dispense now with any proposal to use BGP signaling for VPWS! Kireeti> The next function of signaling is the withdrawal of labels, either Kireeti> because of administrative intervention or because the PE-CE link went Kireeti> down. Again, this is point-to-multipoint -- all other PEs in the VPLS Kireeti> need to be told. Well, yes, each PE needs to be told something, but each needs to be told a different thing, since each is using a different label. Kireeti> Another thing that needs to be communicated, be it during discovery or Kireeti> during signaling, is the MTU on the PE-CE interfaces. Again, this is Kireeti> point-to-multipoint -- the same value is sent to all peers. Here I agree; MTU must be the same on all interfaces, and is not a parameter that changes during normal operation. Communicating the MTU can be regarded as part of the auto-discovery, and it's okay to handle it via BGP. Kireeti> 2. Sequencing. It seems to me that for a given VPLS, one either does Kireeti> sequencing among all the PEs for this VPLS, or not. The situation Kireeti> where one does sequencing among some but not others seems excessively Kireeti> complex. In any case, sequencing is done in the data plane -- a Kireeti> sequence number of 0 means no sequencing; non-zero means do Kireeti> sequencing. In order to do sequencing, when a pseudowire first comes up, PE A needs to tell PE B which sequence number it is expecting. At any given time, PE A will expect the next packet from PE B to have one sequence number, while expecting the next packet from PE C to have a different sequence number. This notion of "next expected sequence number" is inherently point-to- point. Further, at any given time, PE A and PE B may lose sequence number synchronization (a sequence of packets whose sequence numbers are more than half the sequence space away from the next expected sequence number should probably be taken as loss of synchronization) their pseudowire, and may need to resynchronize, with A telling B what sequence number to reset to. There are two possible ways to do the sequence number synchronization: 1. Explicit point-to-point handshake when a pseudowire starts, or when resynch is required. Well, you couldn't do this effectively with BGP. 2. When a label is first received, start with sequence number 1. To resynchronize, withdraw the label, and then assign a new (or the same label) to indicate that the next expected sequence number is once again to be 1. (Actually, this doesn't seem so good, as you might not want to always restart with 1, but we'll ignore that for now.) a. If you withdraw a label, and then reassign the same label, BGP signaling is not guaranteed to convey the withdrawal to the remote PE. b. You could withdraw the label and assign a different label, but then I think you've given up any hope of using label blocks. c. You could withdraw the label and reassign the same label, but with some different attributes. Presumably for each remote PE, there'd be an attribute which specifies the starting sequence number. (Again, so much for label blocks.) And now it's not much different than 1; when PEs A and B have to resynch sequence numbers, all the other PEs get a message as well.) Kireeti> Even if a detailed traffic matrix ("pipe model") were desirable (for Kireeti> VPLS and for IP), i.e., site 1 can send 2M to site 2, 6M to site 3, Kireeti> etc., is there a need to signal this info? This is simply implemented Kireeti> locally at each PE. While there's no question that the hose model is more scalable, there is a place for the pipe model, even in L3VPN. But I think it will be more widely applicable to L2VPN, because "pipe" is really an L2 concept. Kireeti> is there a need to signal this info? This is simply implemented Kireeti> locally at each PE. Then you need to explicitly configure it on both ends; with signaling, you can configure it on one end and signal it to the other. Same applies to DSCP/EXP bit settings, and I don't see why those would necessarily want to be the same for all site pairs. This would also be very useful if you wanted to make QoS changes dynamically, based on time of day or network conditions or whatever. In fact, people have asked to be able to use RSVP-TE as the pseudowire signaling protocol, to help unify the QoS signaling with the pseudowire signaling. (Though I'm certainly not advocating that.) A closely related issue, of course, is congestion control. It's been made pretty clear that the IESG expects to see some congestion control mechanisms for pseudowires. Neither PWE3 nor PPVPN has paid much attention as yet. But this is likely to require some kind of reliable feedback between the endpoints of a pseudowire. For example, the endpoints might want to do a periodic exchange of "packets received on this pseudowire", "packets sent on this pseudowire" statistics, so they can tell whether packets are being lost in the network. That's just an example, I don't know if the ultimate scheme will be like that. But there does seem to be a need for some mechanism by which one endpoint can tell the other "slow down". This seems like a point-to-point interaction, not a point-to-multipoint interaction. Kireeti> If one goes down this path -- "we want a detailed traffic matrix, and Kireeti> we have to signal this" -- does one then abandon BGP signaling for IP Kireeti> VPNs and switch to LDP signaling? Well, that wouldn't do much good unless you can figure out a way to use LDP to distribute routing. And it still wouldn't do much good, because the L3VPN transport mechanisms are entirely multipoint-to-point; there's no point-to-point or point-to-multipoint stuff at all. Well, the pipe model is not nearly as good a fit to L3VPN as it is to L2VPN. Kireeti> 3. OOB OAM. Not sure what this means: what is to be signalled, and what Kireeti> makes it point-to-point (i.e., PE1 wants to tell PE2 but not PE3)? Kireeti> Could you elaborate? See my congestion control example above. Another example. A problem in the data plane is detected, and one wants to try "resetting" the pseudowire, to see if tearing it down and setting it up again gets around the problem. Naturally, one would prefer that both sides use different labels for the restored pseudowire, in case one end or the other is having some problem with a particular label. This is easily done with a point-to-point signaling mechanism. OAM problems are almost always point-to-point problems. I agree that signaling status of external interfaces is NOT relevant for VPLS, though of course it would be for VPWS. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 15:31:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29752 for ; Thu, 24 Apr 2003 15:31:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OJXmr13691 for ; Thu, 24 Apr 2003 15:33:48 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OJXis16690 for ; Thu, 24 Apr 2003 15:33:45 -0400 (EDT) Message-Id: <200304241926.h3OJQRlY026906@rtp-core-1.cisco.com> To: Quaizar Vohra cc: Ali Sajassi , Kireeti Kompella , raszuk@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-reply-to: Your message of Wed, 23 Apr 2003 17:16:56 -0700. <200304240016.h3O0GuS69024@fuinar.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 24 Apr 2003 15:26:27 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Quaizar> It seems that the argument for LDP signalling here is that it is Quaizar> flexible enough to allow for signalling of many a bells and whistles Quaizar> on a P2P basis. But if these bells and whistles are deduced from Quaizar> configuration then you end up loosing the benefits of autodiscovery. It is true that the more you need to configure on a point-to-point basis, the less benefit you get from auto-discovery. However, we don't have to choose one extreme or the other; I think it's best to provide for both and allow the provider to use the mix that best suits his needs. One of the perennial issues faced when designing auto-discovery procedures is that as time goes on, we keep figuring out more and more properties of the endpoints that need to be auto-discovered, with a consequent need to keep extending the auto-discovery mechanisms. One school of thought says that auto-discovery ought therefore to be minimal, telling you only who to connect to; then once you connect, you use signaling to discovery whatever else needs to be known before you can start operation. Another school of thought says that you should just keep extending the auto-discovery procedures as needed. The best practice is probably somewhere in the middle. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 15:35:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29902 for ; Thu, 24 Apr 2003 15:35:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OJbSr17446 for ; Thu, 24 Apr 2003 15:37:28 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OJbNs21258 for ; Thu, 24 Apr 2003 15:37:24 -0400 (EDT) Message-Id: <5.2.0.9.2.20030424152032.02986820@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 15:25:09 -0400 To: erosen@cisco.com, Kireeti Kompella From: "Thomas D. Nadeau" Subject: Re: Draft-kpmpella-ppvpn-vpls-01 Cc: raszuk@cisco.com, sajassi@cisco.com, Andrea.Ferrarese@agsm.it, ppvpn@nortelnetworks.com In-Reply-To: <200304241857.h3OIvflY017376@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: At 02:57 PM 4/24/2003 -0400, Eric Rosen wrote: >Kireeti> The most basic function of signaling is the exchange of labels. This >Kireeti> is inherently point-to-multipoint -- all other PEs in a VPLS need to >Kireeti> know what labels to use to send packets to the signaling PE. > >Well, if you owe $1.00 to each of 100 people, you owe $100, but you wouldn't >send each one a $100 bill. Or would you? ;-) > >When a new PE, PE A, joins the VPLS, it must assign a label to each of the >other >PEs. PE A must distribute, to each of the other PEs, the label that A has >assigned **to that particular PE**. > >Since a different label must be distributed to each of the other PEs, this >signaling is inherently point-to-point, not point-to-multipoint. > >Further, each of the other PEs now has to assign a label for PE A to use, >and distribute that label to PE A. Again, this is inherently point-to- >point. No other PE needs to send any labels to anyone other than PE A. >Certainly we don't want PE B telling PE C, "just for your information, >here's the label I'm giving to PE A". > >Point-to-multipoint signaling would be required if PE A sent the same label >to each of the other PEs, i.e., if the pseudowires were multipoint-to- point >(as in IPLS). But you can't do VPLS with multipoint-to-point PWs, because >there would be no way to do the MAC learning. > >By the way, if you agree that BGP signaling only makes sense when the >signaling operations are inherently point-to-multipoint, perhaps we can >dispense now with any proposal to use BGP signaling for VPWS! > >Kireeti> The next function of signaling is the withdrawal of labels, either >Kireeti> because of administrative intervention or because the PE-CE link went >Kireeti> down. Again, this is point-to-multipoint -- all other PEs in the >VPLS >Kireeti> need to be told. > >Well, yes, each PE needs to be told something, but each needs to be told a >different thing, since each is using a different label. > >Kireeti> Another thing that needs to be communicated, be it during >discovery or >Kireeti> during signaling, is the MTU on the PE-CE interfaces. Again, this is >Kireeti> point-to-multipoint -- the same value is sent to all peers. > >Here I agree; MTU must be the same on all interfaces, and is not a parameter >that changes during normal operation. Communicating the MTU can be regarded >as part of the auto-discovery, and it's okay to handle it via BGP. > >Kireeti> 2. Sequencing. It seems to me that for a given VPLS, one either does >Kireeti> sequencing among all the PEs for this VPLS, or not. The situation >Kireeti> where one does sequencing among some but not others seems >excessively >Kireeti> complex. In any case, sequencing is done in the data plane -- a >Kireeti> sequence number of 0 means no sequencing; non-zero means do >Kireeti> sequencing. > >In order to do sequencing, when a pseudowire first comes up, PE A needs to >tell PE B which sequence number it is expecting. At any given time, PE A >will expect the next packet from PE B to have one sequence number, while >expecting the next packet from PE C to have a different sequence number. >This notion of "next expected sequence number" is inherently point-to- >point. > >Further, at any given time, PE A and PE B may lose sequence number >synchronization (a sequence of packets whose sequence numbers are more than >half the sequence space away from the next expected sequence number should >probably be taken as loss of synchronization) their pseudowire, and may need >to resynchronize, with A telling B what sequence number to reset to. > >There are two possible ways to do the sequence number synchronization: > >1. Explicit point-to-point handshake when a pseudowire starts, or when > resynch is required. Well, you couldn't do this effectively with BGP. Right, which is easy to do with a protocol designed to be P2P. >2. When a label is first received, start with sequence number 1. To > resynchronize, withdraw the label, and then assign a new (or the same > label) to indicate that the next expected sequence number is once again > to be 1. (Actually, this doesn't seem so good, as you might not want to > always restart with 1, but we'll ignore that for now.) > > a. If you withdraw a label, and then reassign the same label, BGP > signaling is not guaranteed to convey the withdrawal to the remote > PE. > > b. You could withdraw the label and assign a different label, but then I > think you've given up any hope of using label blocks. > > c. You could withdraw the label and reassign the same label, but with some > different attributes. Presumably for each remote PE, there'd be an > attribute which specifies the starting sequence number. (Again, so > much for label blocks.) And now it's not much different than 1; when > PEs A and B have to resynch sequence numbers, all the other PEs get a > message as well.) But isn't withdrawing the label going to be potentially disruptive? --Tom >Kireeti> Even if a detailed traffic matrix ("pipe model") were >desirable (for >Kireeti> VPLS and for IP), i.e., site 1 can send 2M to site 2, 6M to >site 3, >Kireeti> etc., is there a need to signal this info? This is simply >implemented >Kireeti> locally at each PE. > >While there's no question that the hose model is more scalable, there is a >place for the pipe model, even in L3VPN. But I think it will be more widely >applicable to L2VPN, because "pipe" is really an L2 concept. > >Kireeti> is there a need to signal this info? This is simply implemented >Kireeti> locally at each PE. > >Then you need to explicitly configure it on both ends; with signaling, you >can configure it on one end and signal it to the other. Same applies to >DSCP/EXP bit settings, and I don't see why those would necessarily want to >be the same for all site pairs. This would also be very useful if you >wanted to make QoS changes dynamically, based on time of day or network >conditions or whatever. > >In fact, people have asked to be able to use RSVP-TE as the pseudowire >signaling protocol, to help unify the QoS signaling with the pseudowire >signaling. (Though I'm certainly not advocating that.) > >A closely related issue, of course, is congestion control. It's been made >pretty clear that the IESG expects to see some congestion control mechanisms >for pseudowires. Neither PWE3 nor PPVPN has paid much attention as yet. >But this is likely to require some kind of reliable feedback between the >endpoints of a pseudowire. For example, the endpoints might want to do a >periodic exchange of "packets received on this pseudowire", "packets sent on >this pseudowire" statistics, so they can tell whether packets are being lost >in the network. That's just an example, I don't know if the ultimate scheme >will be like that. But there does seem to be a need for some mechanism by >which one endpoint can tell the other "slow down". This seems like a >point-to-point interaction, not a point-to-multipoint interaction. > >Kireeti> If one goes down this path -- "we want a detailed traffic >matrix, and >Kireeti> we have to signal this" -- does one then abandon BGP signaling >for IP >Kireeti> VPNs and switch to LDP signaling? > >Well, that wouldn't do much good unless you can figure out a way to use LDP >to distribute routing. And it still wouldn't do much good, because the >L3VPN transport mechanisms are entirely multipoint-to-point; there's no >point-to-point or point-to-multipoint stuff at all. Well, the pipe model is >not nearly as good a fit to L3VPN as it is to L2VPN. > >Kireeti> 3. OOB OAM. Not sure what this means: what is to be signalled, >and what >Kireeti> makes it point-to-point (i.e., PE1 wants to tell PE2 but not PE3)? >Kireeti> Could you elaborate? > >See my congestion control example above. > >Another example. A problem in the data plane is detected, and one wants to >try "resetting" the pseudowire, to see if tearing it down and setting it up >again gets around the problem. Naturally, one would prefer that both sides >use different labels for the restored pseudowire, in case one end or the >other is having some problem with a particular label. This is easily done >with a point-to-point signaling mechanism. > >OAM problems are almost always point-to-point problems. > >I agree that signaling status of external interfaces is NOT relevant for >VPLS, though of course it would be for VPWS. From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 17:29:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04619 for ; Thu, 24 Apr 2003 17:29:10 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OLVOr20827 for ; Thu, 24 Apr 2003 17:31:24 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OLVKv21733 for ; Thu, 24 Apr 2003 17:31:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Thu, 24 Apr 2003 23:27:38 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMJ15H81Q44zlyVSwu2k/GND4NFTgAzyUWQ From: "Hector Avalos" To: "Jim Guichard" Cc: X-OriginalArrivalTime: 24 Apr 2003 21:27:39.0962 (UTC) FILETIME=[555FA1A0:01C30AA8] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA04619 Jim, -----Original Message----- From: Jim Guichard [mailto:jguichar@cisco.com] >> >-----Original Message----- >> >From: Hector Avalos [mailto:havalos@juniper.net] >> >Sent: Wednesday, April 23, 2003 4:26 PM >> >To: vkompella@timetra.com; jguichar@cisco.com; sajassi@cisco.com >> >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com >> >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 >> > >> > >> >Well, that's the nice thing of mp-bgp. >> >Which in addition provide us support for inter-as an CoC, which several >> >SPs would like to implement for vpls. >good luck 8^) Well, it works in our VPLS implementation ;-) From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 18:05:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06474 for ; Thu, 24 Apr 2003 18:05:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OM7kr02523 for ; Thu, 24 Apr 2003 18:07:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OM7f302827 for ; Thu, 24 Apr 2003 18:07:41 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-lasserre-vkompella-ppvpn-vpls Date: Thu, 24 Apr 2003 23:58:51 +0200 Message-ID: Thread-Topic: Draft-kpmpella-ppvpn-vpls-01 Thread-Index: AcMKmSUfirPTo21qSXSIFExDGs/SsAACcn3g From: "Hector Avalos" To: X-OriginalArrivalTime: 24 Apr 2003 21:58:52.0373 (UTC) FILETIME=[B16AE050:01C30AAC] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA06474 I would like to know which 'auto-discovery' mechanism is preferred by those SPs supporting lasserre-vkompella VPLS draft. and from all SP planning to deploy VPLS: - what are your expectations in terms of the biggest/average VPLS domain you plan to support - what may be the ratio of VPLS domains / P2P services deployment thanks for the info, Hector From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 18:34:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08699 for ; Thu, 24 Apr 2003 18:34:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OMb5r06992 for ; Thu, 24 Apr 2003 18:37:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3OMb2011416 for ; Thu, 24 Apr 2003 18:37:02 -0400 (EDT) Message-ID: <3EA86445.28FAC4FA@cisco.com> Date: Thu, 24 Apr 2003 15:25:09 -0700 From: Wei Luo X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: Kireeti Kompella CC: ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 References: <200304232034.h3NKYVE80568@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: luo@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > The most basic function of signaling is the exchange of labels. This > is inherently point-to-multipoint -- all other PEs in a VPLS need to > know what labels to use to send packets to the signaling PE. Only when the signaling PE wants all other PEs to use the same label, this type of point-to-multipoint signaling makes sense. Put in a different way, if the signaling PE wants to assign a different label to a different PE, there is no reason to tell all other PEs the labels they don't even use. But for VPLS, the signaling PE can not really assign the same label for all other PEs, because you will not be able to associate source MAC addresses with any particular PE based on the label. Therefore, you will not be able to perform any MAC address learning. I hope you did not suggest to flood all packets at all occasions for VPLS. > The next function of signaling is the withdrawal of labels, either > because of administrative intervention or because the PE-CE link went > down. Again, this is point-to-multipoint -- all other PEs in the VPLS > need to be told. The same applies to withdrawal. ---Wei From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 22:25: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 WAA13537 for ; Thu, 24 Apr 2003 22:25:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3P2Rir03960 for ; Thu, 24 Apr 2003 22:27:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3P2ReM20030 for ; Thu, 24 Apr 2003 22:27:40 -0400 (EDT) Date: Fri, 25 Apr 2003 10:24:28 +0800 From: lidefeng Subject: Re: Help on IEE802.1ad To: Lu Xiao Min , ppvpn@nortelnetworks.com Message-id: <002801c30ad1$ccb89f80$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_R2dNkqFtt55wwlQg0/ioxw)" X-Priority: 3 X-MSMail-priority: Normal References: <570B29DA89E90345B425CAF151BC0CFE022BDD@qqmail.qqtechnology.com> X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_R2dNkqFtt55wwlQg0/ioxw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Help on IEE802.1adME TOO ----- Original Message ----- From: Lu Xiao Min To: ppvpn@nortelnetworks.com Sent: Thursday, April 24, 2003 4:24 PM Subject: Help on IEE802.1ad Dear all, I am working on VPLS. Could I possibly get the IEEE802.1ad draft ( I am not the IEEE802.1 member yet). Thanks for your assistance. Xiaomin Lu --Boundary_(ID_R2dNkqFtt55wwlQg0/ioxw) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT Help on IEE802.1ad
ME TOO
----- Original Message -----
Sent: Thursday, April 24, 2003 4:24 PM
Subject: Help on IEE802.1ad

Dear all,

I am working on VPLS. Could I possibly get the IEEE802.1ad draft (
I am not the IEEE802.1 member yet). Thanks for your assistance.


Xiaomin Lu

--Boundary_(ID_R2dNkqFtt55wwlQg0/ioxw)-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Apr 24 23:13:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13978 for ; Thu, 24 Apr 2003 23:13:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3P3FPr15112 for ; Thu, 24 Apr 2003 23:15:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3P3FM521091 for ; Thu, 24 Apr 2003 23:15:23 -0400 (EDT) Date: Fri, 25 Apr 2003 11:05:44 +0800 From: lidefeng Subject: What is the difference between the Ethernet Service in PWE3 and VPLS? To: pwe3@ietf.org, ppvpn@nortelnetworks.com Message-id: <003901c30ad7$901138c0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, Could anyone please tell me the difference between the Ethernet Service in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site attached to VPLS when there is need to access each other? And how to process mac learning,flooding address unknows unicast,broadcast and multicast frames in PWE3? Regards Li Defeng From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 03:55: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 DAA00043 for ; Fri, 25 Apr 2003 03:55:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3P7vWi23185 for ; Fri, 25 Apr 2003 03:57:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3P7vS918734 for ; Fri, 25 Apr 2003 03:57:29 -0400 (EDT) Date: Fri, 25 Apr 2003 16:48:31 +0900 (JST) Message-Id: <20030425.164831.18307423.suzuki.muneyoshi@lab.ntt.co.jp> To: vkompella@timetra.com Cc: sganguly@yahoo.com, jwils@coriolisnet.com, nfinn@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: References: <20030424.112037.74674082.suzuki.muneyoshi@lab.ntt.co.jp> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, > Is something about the fact that we want to work with the IEEE 802.1ad wg > bothering you? Is it insufficient? Do we need to work with some other group? No. I don't have any political obstacles, but I think significant interest is needed to propose this kind of work. However, I think it is a good idea to lobby 802.1WG to reserve one octet for the TTL in 802.1AD frame format. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 05:11:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01006 for ; Fri, 25 Apr 2003 05:11:27 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3P9Dgi08336 for ; Fri, 25 Apr 2003 05:13:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3P9Dc315616 for ; Fri, 25 Apr 2003 05:13:38 -0400 (EDT) Subject: RE: PE-CE addressing draft To: jguichar@cisco.com, ppvpn@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Vincent.Parfait@equant.com Date: Fri, 25 Apr 2003 11:09:52 +0200 X-MIMETrack: Serialize by Router on Nice1/Nice/SITA/WW(Release 5.0.9a |January 7, 2002) at 04/25/2003 11:10:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SMTP-HELO: mx1.sita.int X-SMTP-MAIL-FROM: Vincent.Parfait@equant.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mx1.sita.int [57.250.224.237] X-LYRIS-Message-Id: In the case of Equant we manage more than 20K connections and should reach 50K connections by 2004. We have about the same figures for Transpac (the French domestic network). Considering that a class B allows for addressing 16K connections, we definitely need multiple class B. 16 class B (-> /12) will allow to support 260K ccts, which should be enough for the coming years. So for Equant this can be seen as a possible option. Another approach can be to request a larger range to provide enough margin for longer term evolution, in which case a /10 would be more adequate for large Service Providers -> more case studies wellcome Another argument for asking for a large range is that it lowers the possibility of conflicts between SPs for VPNs that span more than one Service Provider (in the case when one of the Service Provider must manage all the VPN connections). Vincent "Jim Guichard" 23/04/2003 21:11 To: , cc: bcc: Subject: RE: PE-CE addressing draft Hi Carlos, I think the size of the block is part of what the working group should evaluate. A /16 is already not enough for some networks. Jim > >-----Original Message----- > >From: carlos.gbraschi@telefonica-data.com > >[mailto:carlos.gbraschi@telefonica-data.com] > >Sent: Wednesday, April 23, 2003 2:55 PM > >To: ppvpn@nortelnetworks.com > >Subject: RE: PE-CE addressing draft > > > > > > > > > > > >Hi, > > > >I think this is something that will make administration of VPN > >networks much > >easier, so that being a workgroup document is something good for service > >providers. > > > >Knowing current policies of address assignment, is it > >foreseeable that IANA can > >grant so much address space (if any)? > > > >Clearly, the draft is missing some calculations that justify the > >amout of space > >needed. > > > >I don't know the size of the networks of Equant, France Telecom > >or ATT, but the > >request assumes VPNs with about 16 million management addresses. > >With high > >assignment efficiency, that could be enough for about 4-8 > >million connections. > >Having a real amount of points of presence (thousands), and assigning 256 > >address blocks, a 25-50% efficiency seems achievable (as there > >would be about > >500-1000 connections per PoP), obviously with smaller networks > >efficiency could > >be much less... but that is not a problem. > > > >Current limits for scalability of VPNs stand at about 1 million, > >but I doubt > >management systems can handle that much load, so with partitioning of the > >management system in some independent VPNs, smaller addressing > >requirements > >(what about a /12?) could also work. Clearly a /16 would be > >inconvenient, but > >it's probably on the limit of the workable (needs management > >system partitioning > >for DSL-scale networks). > > > >Regards, > > > > Carlos. > > > >>From: Ives Dekoninck > >>To: "'Vincent.Parfait@equant.com'" , > >"'ppvpn@nortelnetworks.com'" > >>Subject: RE: PE-CE addressing draft > >>Date: Wed, 23 Apr 2003 09:06:35 +0200 > >> > >>Hi, > >> > >>I would also like to support the "draft-guichard-pe-ce-addr-02.txt" to > >>become a workgroup document. > >> > >>An additional advantage of not having to coordinate addresses with the > >>client is that we can summarise a block towards the management VPN which > >>makes configuration more scalable and simpler. > >> > >>I am doing an implementation for a customer of ours and he also > >is in favour > >>of this draft document. > >> > >>-Ives- > >> > >> > >> > >>-----Original Message----- > >>From: Aleksey Tolchinskiy [mailto:Aleksey.Tolchinskiy@us.didata.com] > >>Sent: mardi 22 avril 2003 19:08 > >>To: Vincent.Parfait@equant.com; ppvpn@nortelnetworks.com > >>Subject: RE: PE-CE addressing draft > >> > >> > >>I would like to support the "draft-guichard-pe-ce-addr-02.txt" becoming > >>a WG document. > >> > >>This is a personal opinion and is not expressed on behalf of the company > >>I work for. > >> > >>Aleksey > >> > >>-----Original Message----- > >>From: Vincent.Parfait@equant.com [mailto:Vincent.Parfait@equant.com] > >>Sent: Tuesday, April 22, 2003 11:38 AM > >>To: ppvpn@nortelnetworks.com; Marco Carugi; rwilder@masergy.com > >>Subject: PE-CE addressing draft > >> > >> > >>This is to inform you that the draft-guichard-pe-ce-addr has been > >>updated : > >>http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt > >>I invite you to read through this new version and give your feedback to > >>the > >>list. > >> > >>The main motivation for this proposal is to simplify the Service > >>Providers > >>operations in the scenario where they monitor CE-PE links, and/or CE > >>routers, while at the same time conserving IPV4 address space. > >>Large Service Providers such as Equant, ATT and Arcor are supporting > >>this > >>draft and are requesting that it becomes a working group document. > >> > >>Vincent Parfait > >>Equant > >> > >> > >> > >> > >> > > > > > >Esperamos su visita en http://www.telefonica-data.es > > > >Este mensaje se dirige exclusivamente a su destinatario y puede contener > >informacion privilegiada o confidencial cuya divulgacion esta > >prohibida en > >virtud de la legislacion vigente. Si ha recibido este mensaje > >por error, le > >rogamos que nos lo comunique inmediatamente por esta misma via y > >proceda a su > >destruccion. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 06:59:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02607 for ; Fri, 25 Apr 2003 06:59:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PB1ii27610 for ; Fri, 25 Apr 2003 07:01:44 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PB1d626862 for ; Fri, 25 Apr 2003 07:01:40 -0400 (EDT) Message-ID: <3EA91464.9020809@cisco.com> Date: Fri, 25 Apr 2003 11:56:36 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lidefeng CC: pwe3@ietf.org, ppvpn@nortelnetworks.com Subject: Re: What is the difference between the Ethernet Service in PWE3 and VPLS? References: <003901c30ad7$901138c0$07436e0a@HUAWEI.COM> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: stbryant@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit PWE3 simply provides a point to point "wire" capable of carrying Ethernet frames. How the frames are chosen for transmission on the "wire", and what happens at the far end of the "wire" is outside the scope of PWE3. VPLS uses PWE3 as a point to point service to carry Ethernet packets between its PEs. Stewart lidefeng wrote: > Hi,all, > > Could anyone please tell me the difference between the Ethernet Service > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > attached to VPLS when there is > need to access each other? And how to process mac learning,flooding address > unknows unicast,broadcast and multicast frames in PWE3? > > Regards > > Li Defeng > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 09:44:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08561 for ; Fri, 25 Apr 2003 09:44:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PDl0i29415 for ; Fri, 25 Apr 2003 09:47:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PDktS20165 for ; Fri, 25 Apr 2003 09:46:56 -0400 (EDT) From: "Jim Guichard" To: "Hector Avalos" Cc: Subject: RE: Draft-kpmpella-ppvpn-vpls-01 Date: Fri, 25 Apr 2003 09:38:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hector, my point was that a flat bridged network between two AS's was, still is, and always will be a pretty bad idea. Jim > >-----Original Message----- > >From: Hector Avalos [mailto:havalos@juniper.net] > >Sent: Thursday, April 24, 2003 5:28 PM > >To: Jim Guichard > >Cc: ppvpn@nortelnetworks.com > >Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > > > > > >Jim, > > > >-----Original Message----- > >From: Jim Guichard [mailto:jguichar@cisco.com] > >>> >-----Original Message----- > >>> >From: Hector Avalos [mailto:havalos@juniper.net] > >>> >Sent: Wednesday, April 23, 2003 4:26 PM > >>> >To: vkompella@timetra.com; jguichar@cisco.com; sajassi@cisco.com > >>> >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > >>> >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > >>> > > >>> > > >>> >Well, that's the nice thing of mp-bgp. > >>> >Which in addition provide us support for inter-as an CoC, which > >several > >>> >SPs would like to implement for vpls. > > > >>good luck 8^) > > > >Well, it works in our VPLS implementation ;-) From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 09:52:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08728 for ; Fri, 25 Apr 2003 09:52:03 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PDsHi04363 for ; Fri, 25 Apr 2003 09:54:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PDsES29184 for ; Fri, 25 Apr 2003 09:54:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16041.15624.503758.306191@harjus.eng.song.fi> Date: Fri, 25 Apr 2003 16:50:00 +0300 To: "Jim Guichard" Cc: "Hector Avalos" , Subject: RE: Draft-kpmpella-ppvpn-vpls-01 In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Jim Guichard writes: > my point was that a flat bridged network between two AS's was, still is, and > always will be a pretty bad idea. Jim i don't see why a bridged network between ASes is any better or worse idea than a bridged network in general. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 09:57:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08858 for ; Fri, 25 Apr 2003 09:57:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PDxSi10476 for ; Fri, 25 Apr 2003 09:59:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PDxLS06539 for ; Fri, 25 Apr 2003 09:59:22 -0400 (EDT) Message-ID: From: "Schliesser, Benson" To: ppvpn@nortelnetworks.com Cc: "'Vincent.Parfait@equant.com'" , jguichar@cisco.com Subject: RE: PE-CE addressing draft Date: Fri, 25 Apr 2003 08:55:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-ECS-MailScanner: No virus is found X-SMTP-HELO: mailgate1b.savvis.net X-SMTP-MAIL-FROM: benson.schliesser@Savvis.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate1b.savvis.net [216.91.182.6] X-LYRIS-Message-Id: > In the case of Equant we manage more than 20K connections and > should reach 50K connections by 2004. Savvis has a similar number of connections, as well as some value-added services, that would be addressed by this draft. Adding these requirements together, I still agree with Vincent that a /12 would be adequate for near term growth, but a /16 would be entirely too small. (but a /8 would help hedge bets for IPv6 on the CE-PE link...) -Benson From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 10:16:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10506 for ; Fri, 25 Apr 2003 10:16:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PEIxi01258 for ; Fri, 25 Apr 2003 10:18:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PEItG09743 for ; Fri, 25 Apr 2003 10:18:56 -0400 (EDT) Message-Id: <200304251414.h3PEERu64790@merlot.juniper.net> To: "Jim Guichard" cc: "Hector Avalos" , ppvpn@nortelnetworks.com Subject: Re: Draft-kpmpella-ppvpn-vpls-01 In-Reply-To: Your message of "Fri, 25 Apr 2003 09:38:53 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1901.1051280067.1@juniper.net> Date: Fri, 25 Apr 2003 07:14:27 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Jim, > Hector, > > my point was that a flat bridged network between two AS's was, still is, and > always will be a pretty bad idea. Jim The point made by Hector is about being able to support VPLS service over more than one AS. Yakov. > > > >-----Original Message----- > > >From: Hector Avalos [mailto:havalos@juniper.net] > > >Sent: Thursday, April 24, 2003 5:28 PM > >To: Jim Guichard > > >Cc: ppvpn@nortelnetworks.com > > >Subject: RE: Draft-kpmpella-ppvpn-vpls-01 > > > > > > > > >Jim, > > > > > >-----Original Message----- > > >From: Jim Guichard [mailto:jguichar@cisco.com] > > >>> >-----Original Message----- > > >>> >From: Hector Avalos [mailto:havalos@juniper.net] > > >>> >Sent: Wednesday, April 23, 2003 4:26 PM > > >>> >To: vkompella@timetra.com; jguichar@cisco.com; sajassi@cisco.com > > >>> >Cc: Andrea.Ferrarese@agsm.it; ppvpn@nortelnetworks.com > > >>> >Subject: Re: Draft-kpmpella-ppvpn-vpls-01 > > >>> > > > >>> > > > >>> >Well, that's the nice thing of mp-bgp. > > >>> >Which in addition provide us support for inter-as an CoC, which > > >several > > >>> >SPs would like to implement for vpls. > > > > > >>good luck 8^) > > > > > >Well, it works in our VPLS implementation ;-) > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 11:32: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 LAA12495 for ; Fri, 25 Apr 2003 11:32:16 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PFYPi25755 for ; Fri, 25 Apr 2003 11:34:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PFYI902851 for ; Fri, 25 Apr 2003 11:34:19 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30B3F.56C352CC" x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 Subject: subscription to mailing list Date: Fri, 25 Apr 2003 17:28:36 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A016DFDC1@lanmhs20.rd.francetelecom.fr> Thread-Topic: subscription to mailing list Thread-Index: AcMLP1a7Xa+4flDPT6yaHAca6I+vnw== From: "NIGER Philippe FTRD/RTA/LAN" To: Cc: "NIGER Philippe FTRD/RTA/LAN" X-OriginalArrivalTime: 25 Apr 2003 15:28:36.0585 (UTC) FILETIME=[56EEED90:01C30B3F] X-SMTP-HELO: p-mail1.rd.francetelecom.com X-SMTP-MAIL-FROM: philippe.niger@rd.francetelecom.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: p-mail1.rd.francetelecom.com [195.101.245.15] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30B3F.56C352CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe ------_=_NextPart_001_01C30B3F.56C352CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscription to mailing list

subscribe

------_=_NextPart_001_01C30B3F.56C352CC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12:05: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 MAA13242 for ; Fri, 25 Apr 2003 12:05:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PG84i14167 for ; Fri, 25 Apr 2003 12:08:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PG7xO17983 for ; Fri, 25 Apr 2003 12:08:00 -0400 (EDT) Message-ID: <3EA95C0A.3077599@cisco.com> Date: Fri, 25 Apr 2003 09:02:18 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Muneyoshi Suzuki CC: ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <3E9F3E72.117D5369@cisco.com> <20030418.162712.41696376.suzuki.muneyoshi@lab.ntt.co.jp> <3EA08E50.7011B94@cisco.com> <20030421.134800.63057419.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, Muneyoshi Suzuki wrote: > > > One additional concept is required. The emulated port which the FF > > provides the upper layers has certain characteristics, among > > them an ifOperState, which is either UP or DOWN. > > This deeply depends on physical link characteristic such as full-duplex, > half-duplex bi-directional, and uni-directional. Especially, in an > uni-directional link such as LSP, it is difficult to timely notify a failure > from receiver side to sender side, because reverse path may not available. I don't think we're referring to the same model. The correct model for how a bridge interacts with full-meshes, one full-mesh per VPLS instance, is: |===========================================--------+ | | | forwarding | | | | | function +--- | E i --+ | untagged + VPLS 100 | | t n | Provider | | for BPDUs +--- | P r h t | Bridge | |------------| | s o e e | | | +--- | e u r r --+ | | forwarding | | u t n f | Each "+" in | VLAN 26 + function +--- | d i e a | the border of | | VPLS 200 | | o n t c | this block | mux- | +--- | w g e --+ represents one + demux |------------| | i s | bridge port | function | +--- | r f | | | | | e u | | | +--- | s n --+ | | forwarding | | c | | VLAN 589 + function +--- | i t | | | VPLS 300 | | n i | | | +--- | o --+ | | | | n |===========================================--------+ A B C The single interface above the "A" label at the bottom is the Provider Bridge's bridge port that opens to the L3 world. The three interfaces above the "B" label are the interfaces between the forwarding functions and the mux-demux unit that translates between the Provider Bridge's P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of the pseudowires. The physical ports on the routed side are of no interest to the bridge. :) In my last note, I was pointing out that the each forwarding function MUST control its "B" interface so that it provides 1) full service, or 2) no service. (Let's be honest -- my last note was a little confused between the "A" interface and the "B" interfaces.) Since VPLS meshes have one characteristic that physical LANs don't -- one VLAN can be disconnected, while another is working -- IEEE 802.1 needs to examine this situation, and figure out how to deal with it. Finally, let me note that only one VPLS -- the one used for BPDUs -- is absolutely required to prevent a meltdown of the Provider's network. A failure of one of the other VPLSs affects only that customer's traffic. > > Of course, data may flow through an emulated LAN port in either > > direction only when ifOperState == UP. The above rules mean, in > > in essence, that an FF doesn't pass data unless it thinks that it > > has a full mesh established. > > I understand your proposal is if an LSP between two PE fails, block > all LSPs connecting to these PEs. > > Is it wise to use links as serial system? > > Here, we assume N as number of PEs, and R as reliability of a single LSP. > In this case, reliability of a single PE in the proposal is: > > R ^ {2*(N -1)}. > > Obviously, it is ruinous under large N. We differ, if at all, only in our definition of "large". > I think there is a much simple and robust solution. Connect Provider Bridges > with point-to-point LSPs and use STP/RSTP in the network, and don't use > split-horizon scheme. Needless to say LSPs must be raw mode; tagged mode > violates the standard. > > In this case, if PEs are connected with full mesh LSPs, reliability of a > single PE is: > > 1- {(1- R^2) ^ (N -1)}. > > Obviously, this is a robust solution because it use LSPs as parallel system. > Furthermore, this does not need to revise the existing standards, it only > needs Q-in-Q or MAC-in-MAC specification in 802.1ad. As Ali points out, the problem with this approach is that the Provider Bridge must either send or receive one BPDU on each pseudowire. If a Provider Bridge is serving 2000 VPLSs, each with 10 pseudowires, that's 20,000 BPDUs per second. That would be a difficult task to accomplish. On the occasion when a failure occurs, and there are 20,000 state changes to process, I worry that the pseudowire spanning tree would melt down, as did networks with slow processors some years ago. -- Norm From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12:20: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 MAA13551 for ; Fri, 25 Apr 2003 12:20:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PGMGi19245 for ; Fri, 25 Apr 2003 12:22:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PGMCM11773 for ; Fri, 25 Apr 2003 12:22:12 -0400 (EDT) Message-ID: <3EA95F59.AEC52332@cisco.com> Date: Fri, 25 Apr 2003 09:16:25 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Muneyoshi Suzuki CC: jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <20030422.095728.07567803.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, If you use spanning tree among the pseudowires connecting Islands, as in: pw A island 1 --------------------- island 2 \ / pw B \_______ _________/ pw C \ / island 3 then one of pw A, pw B, or pw C must be blocked. Let's suppose it's pw C. Then, all traffic from island 2 to island 3 must be relayed by island 1. In other words, since wires are almost "free" in this space, one tends to have a lot of them. It the extreme case that you have a full mesh of connections among all the participants in a net, spanning tree is a particularly wasteful approach; it guarantees to block all but N of the N*(N-1)/2 pseudowires! (: Yes, a bridge-bigot is saying that spanning tree is not optimal for all interconnect plans. :) If you configure a relatively sparse interconnect plan, using just a few pseudowires, and if those pseudowires approximate physical reality, then spanning tree becomes more viable. The scaling problem for 3000 VPLS instances at 10 pseudowires each becomes 3000 VPLS instances at 2-3 pseudowires each, reducing the BPDU load from 20,000 to 7,500. I would remark that our best bridges top out at somewhere on the order of 1,000 - 2,000 BPDUs per second, at this time. I need to think a bit more before I agree that this solution "simple and robust". -- Norm Muneyoshi Suzuki wrote: > > Joris, > > > My question is: how do you deal with (portions of) the network, for which a > > spanning tree would be a very inefficient forwarding means, because the > > physical topology does not approximate a tree? > > Could you clarify this? What is spanning tree in the above context? > 802.1D STP, or STP/RSTP/MSTP? > > If you are claiming STP topology change time is inefficient, the use of > RSTP/MSTP should be considered. > > If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify > the issues? From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12:27:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13666 for ; Fri, 25 Apr 2003 12:27:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PGTMi23138 for ; Fri, 25 Apr 2003 12:29:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PGTJM18579 for ; Fri, 25 Apr 2003 12:29:19 -0400 (EDT) Message-Id: <200304251625.h3PGPtlY001725@rtp-core-1.cisco.com> To: steven.wright@BellSouth.com cc: ppvpn@nortelnetworks.com Subject: Re: ppvpn effort support In-reply-to: Your message of Thu, 24 Apr 2003 13:42:33 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 25 Apr 2003 12:25:55 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Steven> Assume you have a large emulated Ethernet network that stretches across Steven> multiple service boundaries i.e multiple AS's. I expect you will want to Steven> have an Ethernet service abstraction corresponding to each AS, i.e. Steven> something like each AS will appear as a virtual switch in the emulated Steven> topology. I think those virtual switch notions are similar to the hierarchy Steven> notions identified as needed for vpls. Are you suggesting that if a VPLS spans two ASes, a MAC lookup table for that VPLS needs to reside in the border routers that attach the two ASes? I think that would correspond to the hierarchy of the HVPLS scheme, but the need to do the MAC lookups on the border routers seems to place a pretty heavy load on them. Steven> My point is that there will be operational and administrative Steven> reasons for having some emulated service abstractions to match up Steven> with underlying network boundaries. I can see that you might want your control connections to terminate at the border routers, but I"d have thought that you still want to maintain the PE-to-PE pseudowire across the boundaries. Steven> Even in the case of a single provider Multiple-AS instantiation of a vpls Steven> service, I expect BGP will be involved. I don't think there are any other Steven> viable alternatives for inter-AS MPLS. I'd be happy to hear the specifics of what BGP features make it the only viable alternative. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12: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 MAA13908 for ; Fri, 25 Apr 2003 12:33:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PGaDi27638 for ; Fri, 25 Apr 2003 12:36:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PGa9E24159 for ; Fri, 25 Apr 2003 12:36:10 -0400 (EDT) Message-ID: <3EA962C2.A7FEF8D0@cisco.com> Date: Fri, 25 Apr 2003 09:30:58 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Muneyoshi Suzuki CC: jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <20030423.141232.41706744.suzuki.muneyoshi@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, I think that adding a TTL field to the MAC frame is an attractive idea. I also think that it is an extraordinarily bad idea. If I may paraphrase your argument, it is: (Forgive me, please, for putting words in your mouth.) 1. Routing is not reliable enough to establish the connections that we need. Bridge A might be able to talk to Bridge B, but not to Bridge C. 2. Spanning trees and full meshes, which don't require TTL, are not good enough, for the reasons thoroughly discussed. (By the way, I very much agree with you that, for large N, a full mesh will not be reliable. My solution is to keep N fairly small.) 3. Therefore, we'll add TTL and use OSPF to route the MAC frames. What I don't understand is how you have solved the problem that Bridge A could not talk to Bridge C! Why is your toy routing system going to be any more robust than the existing routing system? This approach is not flawed because it is reinventing bridging. It is flawed because it is reinventing routing. -- Norm Muneyoshi Suzuki wrote: > > Joris, > > Thanks for clarification. > > First, needless to say, I aware link block problem of STP/RSTP. We > definitely need a solution. However, the solution must be robust. > To enable large scale deployment, it must not force the operators > and users to reboot boxes even if the worst case. The full mesh > approach is a fragility solution that has loop, blackhole or unreliable > flaky PEs problems, so we have no choice other than the conventional scheme. > > Second, if we regard xSTP as routing protocols, obviously there are less > efficient than OSPF/BGP. However, if we regard xSTP as protocols for > protection, these are not bad. If we reserve paths for fast protection > for the mesh, there are active and standby meshes. I think this problem > is not much different form xSTP link block problem. > > Finally, as far as I know, currently providers don't use STP due to long > recovery time; instead manually configure a single tree topology. However, > a single tree topology is not bad. Please image conventional telephone > network architecture; it is a tree. A tree is one of fundamental network > architecture. However, needless to say, topology free is much better than > a tree. Therefore, I proposed OSPF or BGP-4 extension for MAC routing > in Atlanta meeting (please see my slides in the last November). I think > it is not easy to progress this work in the IETF, but I believe we need > this kind of work in the near future. > > Thanks, > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12:49: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 MAA14499 for ; Fri, 25 Apr 2003 12:49:41 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PGpti04127 for ; Fri, 25 Apr 2003 12:51:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PGpqk04042 for ; Fri, 25 Apr 2003 12:51:52 -0400 (EDT) Message-ID: <3EA966AF.8650D37@cisco.com> Date: Fri, 25 Apr 2003 09:47:43 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: erosen@cisco.com CC: Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200304221442.h3MEgm4W000458@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, I tend to agree. After more thought (I mention this in an earlier long message), I decided that the only full mesh that must follow this rather drastic paradigm is one that carries BPDUs. If BPDUs don't get everywhere they're supposed to get, then whatever network is depending on those BPDUs, Provider or Customer, will either loop or partition, and looping is more common than partitioning in this kind of failure. Fortunately, most VPLSs won't be carrying BPDUs, or if they are, they won't matter, since the customer is not multi-homed. But, for multi-homed customers' BPDUs, or for the Provider's BPDUs, it's all or nothing. -- Norm Eric Rosen wrote: > > Norm> Unless or until an FF has a pseudowire up and running to every member > Norm> of its [auto-discovered] list, it must present ifOperState == DOWN to > Norm> its upper layers. > > Then a single flaky PE would bring down the entire emulated LAN, and the > emulated LAN would stay down until either that PE comes back up, or the > discovery procedure successfully removes that PE from the list and > successfully informs all the other PEs. This doesn't seem that good. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12:52:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14677 for ; Fri, 25 Apr 2003 12:52:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PGsOi06812 for ; Fri, 25 Apr 2003 12:54:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PGsKk07287 for ; Fri, 25 Apr 2003 12:54:20 -0400 (EDT) Message-Id: <200304251645.h3PGjou74754@merlot.juniper.net> To: erosen@cisco.com cc: steven.wright@BellSouth.com, ppvpn@nortelnetworks.com Subject: Re: ppvpn effort support In-Reply-To: Your message of "Fri, 25 Apr 2003 12:25:55 EDT." <200304251625.h3PGPtlY001725@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42624.1051289150.1@juniper.net> Date: Fri, 25 Apr 2003 09:45:50 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Eric, > Steven> Assume you have a large emulated Ethernet network that stretches across > Steven> multiple service boundaries i.e multiple AS's. I expect you will want > Steven> to have an Ethernet service abstraction corresponding to each AS, i.e. > Steven> something like each AS will appear as a virtual switch in the emulated > Steven> topology. I think those virtual switch notions are similar to the hie > Steven> hierarchy notions identified as needed for vpls. > > Are you suggesting that if a VPLS spans two ASes, a MAC lookup table for > that VPLS needs to reside in the border routers that attach the two ASes? > I think that would correspond to the hierarchy of the HVPLS scheme, but the > need to do the MAC lookups on the border routers seems to place a pretty > heavy load on them. Isn't that what is suggested by draft-lasserre-vkompella-ppvpn-vpls-04.txt ? 10.3. Multi-domain VPLS service Hierarchy can also be used to create a large scale VPLS service within a single domain or a service that spans multiple domains without requiring full mesh connectivity between all VPLS capable devices. Two fully meshed VPLS networks are connected together using a single LSP tunnel between the VPLS gateway devices. A single spoke pseudowire is setup per VPLS service to connect the two domains together. The VPLS gateway device joins two VPLS services together to form a single multi-domain VPLS service. The requirements and functionality required from a VPLS gateway device will be explained in a future version of this document. I certainly agree with you that doing the MAC lookup on the border routers (aka VPLS gateways) would place a pretty heavy load on them, and more generally would adversely impact scalability. Moreover, doing MAC lookup on border routers (aka VPLS gateways) would also require the service provider to run STP on a per VPLS customer to make sure that there is no looping when either (a) a pair of ASs have more than one interconnect, or (b) VPLS service spans more than one AS and the topology at the AS level is richer than a spanning tree, or (c) both (a) and (b). Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12:55:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14738 for ; Fri, 25 Apr 2003 12:55:32 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PGvli10366 for ; Fri, 25 Apr 2003 12:57:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PGvhk11647 for ; Fri, 25 Apr 2003 12:57:44 -0400 (EDT) Message-ID: <3EA966EB.88496ADB@cisco.com> Date: Fri, 25 Apr 2003 09:48:43 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: erosen@cisco.com CC: Cheng-Yin.Lee@alcatel.com, Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200304221757.h3MHvi4W001390@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I second the motion. :) Eric Rosen wrote: > > (Of course, all these problems can be eliminated by making all the CE > devices be routers, and using an IPLS service instead ;-)) From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 12:59: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 MAA14839 for ; Fri, 25 Apr 2003 12:59:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PH1bi27855 for ; Fri, 25 Apr 2003 13:01:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PH1Vh21682 for ; Fri, 25 Apr 2003 13:01:32 -0400 (EDT) Message-ID: <3EA967B8.F95C066F@cisco.com> Date: Fri, 25 Apr 2003 09:52:08 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Ali Sajassi CC: erosen@cisco.com, Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <4.3.2.7.2.20030422173117.01cb2e98@airborne.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ali, No matter what, no matter how good our failure detection/recovery mechanisms are, there will always be short periods when connectivity is not correct. If we can bound those periods (and that was the point of my first long message), then cranking up the spanning tree timers will solve everything. If we cannot bound those periods (e.g. the full mesh can never be completed, because of some erroneous ACL in some router somewhere) then nothing will work. -- Norm Ali Sajassi wrote: > > At 10:42 AM 4/22/2003 -0400, Eric Rosen wrote: > > >Norm> Unless or until an FF has a pseudowire up and running to every member > >Norm> of its [auto-discovered] list, it must present ifOperState == DOWN to > >Norm> its upper layers. > > > >Then a single flaky PE would bring down the entire emulated LAN, and the > >emulated LAN would stay down until either that PE comes back up, or the > >discovery procedure successfully removes that PE from the list and > >successfully informs all the other PEs. This doesn't seem that good. > > It also seems to me that taking the entire Emulated LAN (set of PWs) down > and up as the result of a PW or node failure, might be too much (e.g., > causing unnecessary service interruption). With respect to failures > affecting the Emulated LAN, there can be two types: > > a) PW failure: PW failure should be taken care by PSN - if not, then there > is something wrong with the node and it should be consider as node failure, > right ? > b) node failure: If there is a redundant PE, then redundancy mechanism > takes care of it (e.g., intra-island STP) and if PE is not redundant, then > it gets removed from the mesh but the remaining PEs still maintain the > full-mesh with each other. > > It seems if the customer BPDU timer is adjusted to compensate for these two > caeses (PW recovery by PSN and node recovery by SP STP), then it should be O.K. > > -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 13:05:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15097 for ; Fri, 25 Apr 2003 13:05:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PH7ji18794 for ; Fri, 25 Apr 2003 13:07:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PH7eh12618 for ; Fri, 25 Apr 2003 13:07:40 -0400 (EDT) Message-Id: <200304251656.h3PGuGu75407@merlot.juniper.net> To: Norman Finn cc: erosen@cisco.com, Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents In-Reply-To: Your message of "Fri, 25 Apr 2003 09:47:43 PDT." <3EA966AF.8650D37@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44999.1051289776.1@juniper.net> Date: Fri, 25 Apr 2003 09:56:16 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Norm, > Eric, > > I tend to agree. After more thought (I mention this in an earlier long messag e), > I decided that the only full mesh that must follow this rather drastic paradig m > is one that carries BPDUs. If BPDUs don't get everywhere they're supposed to > get, then whatever network is depending on those BPDUs, Provider or Customer, > will either loop or partition, and looping is more common than partitioning in > this kind of failure. Fortunately, most VPLSs won't be carrying BPDUs, or if > they are, they won't matter, since the customer is not multi-homed. How do you know that for most VPLSs "the customer is not multi-homed" ? Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 13:17:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15523 for ; Fri, 25 Apr 2003 13:17:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PHJTi23759 for ; Fri, 25 Apr 2003 13:19:29 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PHJPo16706 for ; Fri, 25 Apr 2003 13:19:25 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Yakov Rekhter" , Cc: , Subject: RE: ppvpn effort support Date: Fri, 25 Apr 2003 10:04:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: <200304251645.h3PGjou74754@merlot.juniper.net> X-OriginalArrivalTime: 25 Apr 2003 17:04:15.0957 (UTC) FILETIME=[B3DD9850:01C30B4C] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, > > > > Are you suggesting that if a VPLS spans two ASes, a MAC lookup table for > > that VPLS needs to reside in the border routers that attach the two ASes? > > I think that would correspond to the hierarchy of the HVPLS scheme, but the > > need to do the MAC lookups on the border routers seems to place a pretty > > heavy load on them. > > Isn't that what is suggested by draft-lasserre-vkompella-ppvpn-vpls-04.txt ? > > 10.3. Multi-domain VPLS service > > Hierarchy can also be used to create a large scale VPLS service > within a single domain or a service that spans multiple domains > without requiring full mesh connectivity between all VPLS capable > devices. Two fully meshed VPLS networks are connected together > using a single LSP tunnel between the VPLS gateway devices. A > single spoke pseudowire is setup per VPLS service to connect the two > domains together. The VPLS gateway device joins two VPLS services > together to form a single multi-domain VPLS service. The > requirements and functionality required from a VPLS gateway device > will be explained in a future version of this document. > What does inter-AS mean? Some providers have a lot of AS's. Does it mean across provider boundaries, administrative domains, does it involve security considerations? Multi-domain VPLS is just to show that there is a way to connect metro areas (which is what the primary motivation that some providers gave us for that particular section). > > Yakov. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Apr 25 18:28:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25136 for ; Fri, 25 Apr 2003 18:28:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PMRdi17760 for ; Fri, 25 Apr 2003 18:27:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3PMRax19538 for ; Fri, 25 Apr 2003 18:27:36 -0400 (EDT) Message-ID: <3EA9B5B4.D44C958@cisco.com> Date: Fri, 25 Apr 2003 15:24:52 -0700 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Yakov Rekhter CC: erosen@cisco.com, Muneyoshi Suzuki , ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <200304251656.h3PGuGu75407@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, You don't know, for sure. On the other hand, there are some reasonable monetary incentives for a Provider to classify the Customers into those which are multi-homed, and those which are not. The reason is that uni-homed Customers require no BPDU snooping and no forgetting MAC addresses due to events in the Customers' networks. If I'm wrong, and most customers are multi-homed, and are running BPDUs, then each such customer's full-mesh must be operated in all-or-nothing mode. -- Norm Yakov Rekhter wrote: > > Norm, > > > Eric, > > > > I tend to agree. After more thought (I mention this in an earlier long messag > e), > > I decided that the only full mesh that must follow this rather drastic paradig > m > > is one that carries BPDUs. If BPDUs don't get everywhere they're supposed to > > get, then whatever network is depending on those BPDUs, Provider or Customer, > > will either loop or partition, and looping is more common than partitioning in > > this kind of failure. Fortunately, most VPLSs won't be carrying BPDUs, or if > > they are, they won't matter, since the customer is not multi-homed. > > How do you know that for most VPLSs "the customer is not multi-homed" ? > > Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 26 02:06:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12440 for ; Sat, 26 Apr 2003 02:06:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3Q67nI01129 for ; Sat, 26 Apr 2003 02:07:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3Q67kf02725 for ; Sat, 26 Apr 2003 02:07:46 -0400 (EDT) Message-ID: <20030426060425.51466.qmail@web13502.mail.yahoo.com> Date: Fri, 25 Apr 2003 23:04:25 -0700 (PDT) From: Mark Seery Subject: Re: Comments on the L2 VPN framework and solutions documents To: yakov@juniper.net Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13502.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13502.mail.yahoo.com [216.136.175.81] X-LYRIS-Message-Id: Yakov, There have been switched Ethernet networks implemented where dual links to a common entity (for example the subscriber) did not require STP. These architectures depended on non-Standard features in the Ethernet switches (e.g. layer 2 equivalent of HSRP/VRRP) + MAC address learning at the other end. Whether a non-standard approach is a solution or not....Whether this is better or worse than STP...... A valid question. There is no clarity in my crystal ball as to whether subscribers (in the majority) will find this option attractive, but SPs will (and do) offer it. Once again this problem can be solved without STP, but it does require additional mechanisms at the (virtual) switch. In addition to "multi-honing" by whatever definition, the history of transparent LAN service includes real world experience with subscribers inadvertently creating back door loops through a non-TLS service interface, this has led to the use of per-subscriber STP. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 26 03:32: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 DAA15107 for ; Sat, 26 Apr 2003 03:32:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3Q7YVI11767 for ; Sat, 26 Apr 2003 03:34:32 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3Q7YSk21256 for ; Sat, 26 Apr 2003 03:34:28 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6775@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: nfinn@cisco.com, suzuki.muneyoshi@lab.ntt.co.jp Cc: jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Sat, 26 Apr 2003 08:32:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Norman...I'd go further than saying that.....it's proposing reinventing cnls networking (data-plane aspects too). There is a massive difference in recognising the importance of ethernet as a key CPE *interface* and then (somehow) making the (wrong) extrapolation that this means ethernet is a great WAN technology. All *scalable* WAN networking modes (of which there are only 3, viz cnls, co pkt-sw and co cct-sw) must have at least 2 functional components: - addressing: from a space that is large enough, and carries semantics of 'where' (not 'who'...that is a name) and thus aggregatable; - consistent topological network map: whether centralised or distributed, to allow consistent route calculation. They must also have other functional components to make make them 'operationally viable', but addressing/routing are the min set. Ethernet as a technology does not have addressing/routing functional components that meet the WAN/scalability criteria. {Aside: As an aim (to stop doing stovepipes, ie 'technology==service' and to minimise problematic gateways for data/control-plane functions) we operators (or at least BT) are seeking functional convergence *within* each of the networking modes but not *across* them (that one makes no technical or commercial sense). So we agree with you that to try and turn ethernet into a next generation cnls network is a 'bad idea'....we have IP for that job.} Therefore, short of fundamentally re-working what ethernet is today, the only pragmatic way to handle ethernet services in the WAN is to accept that a proper WAN technology must act as a server layer to proxy for the missing functions. SDH/GFP is a good solution. MPLS *could* be a good solution.....but it would need recognition that: - it is a layer network in its own right, eg it needs its own addressing regime (actually it subconsciously(?) gets this, but its different for each signalling type used and that is not a good idea); - it belongs to the co pkt-sw mode (not the cnls mode, that is IP) and thus does *not* have to be constrained by the limitations of a cnls mode, eg in a client/server sense X/MPLS is *not* the same as X/IP.....and it saddens me to see PWE3 try to treat them like this as though this is a 'good idea' when its just dogma; - it needs proper OAM solutions......but the only topological constructs that make networking sense in a co pkt-sw mode are p2p and p2mp......mp2p constructs just create problems for no benefit (if one wants this sort of behaviour, use a proper IP/cnls mode which is designed for this behaviour and where these problems don't exist). Further, given X/MPLS and X/IP are different animals, then we want to see as much functional independence between the client (X) and the server layers (MPLS or IP).......and we don't want to see lots of in-between layer functions being created (like PW OAM) that we also have to manage (noting that we still have to manage the MPLS and IP layers anyway....so at least get these right in their own right). regards, Neil > -----Original Message----- > From: Norman Finn [mailto:nfinn@cisco.com] > Sent: 25 April 2003 17:31 > To: Muneyoshi Suzuki > Cc: jwils@coriolisnet.com; ppvpn@nortelnetworks.com > Subject: Re: Comments on the L2 VPN framework and solutions documents > > > Muneyoshi, > > I think that adding a TTL field to the MAC frame is an attractive > idea. I also think that it is an extraordinarily bad idea. If I > may paraphrase your argument, it is: (Forgive me, please, for putting > words in your mouth.) > > 1. Routing is not reliable enough to establish the connections > that we need. Bridge A might be able to talk to Bridge B, but > not to Bridge C. > > 2. Spanning trees and full meshes, which don't require TTL, are > not good enough, for the reasons thoroughly discussed. (By > the way, I very much agree with you that, for large N, a full > mesh will not be reliable. My solution is to keep N fairly > small.) > > 3. Therefore, we'll add TTL and use OSPF to route the MAC frames. > > What I don't understand is how you have solved the problem that > Bridge A could not talk to Bridge C! Why is your toy routing system > going to be any more robust than the existing routing system? > > This approach is not flawed because it is reinventing bridging. It > is flawed because it is reinventing routing. > > -- Norm > > Muneyoshi Suzuki wrote: > > > > Joris, > > > > Thanks for clarification. > > > > First, needless to say, I aware link block problem of STP/RSTP. We > > definitely need a solution. However, the solution must be robust. > > To enable large scale deployment, it must not force the operators > > and users to reboot boxes even if the worst case. The full mesh > > approach is a fragility solution that has loop, blackhole > or unreliable > > flaky PEs problems, so we have no choice other than the > conventional scheme. > > > > Second, if we regard xSTP as routing protocols, obviously > there are less > > efficient than OSPF/BGP. However, if we regard xSTP as protocols for > > protection, these are not bad. If we reserve paths for fast > protection > > for the mesh, there are active and standby meshes. I think > this problem > > is not much different form xSTP link block problem. > > > > Finally, as far as I know, currently providers don't use > STP due to long > > recovery time; instead manually configure a single tree > topology. However, > > a single tree topology is not bad. Please image > conventional telephone > > network architecture; it is a tree. A tree is one of > fundamental network > > architecture. However, needless to say, topology free is > much better than > > a tree. Therefore, I proposed OSPF or BGP-4 extension for > MAC routing > > in Atlanta meeting (please see my slides in the last > November). I think > > it is not easy to progress this work in the IETF, but I > believe we need > > this kind of work in the near future. > > > > Thanks, > > > > Muneyoshi Suzuki > > Nippon Telegraph and Telephone Corp. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 26 15:15:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26177 for ; Sat, 26 Apr 2003 15:15:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3QJIAI00458 for ; Sat, 26 Apr 2003 15:18:11 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3QJI7I29114 for ; Sat, 26 Apr 2003 15:18:08 -0400 (EDT) X-Originating-IP: [219.65.149.160] X-Originating-Email: [sylvia_sugar@hotmail.com] From: "Sylvia Sugar" To: ppvpn@nortelnetworks.com Subject: label generation algorithms Date: Sat, 26 Apr 2003 19:15:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Apr 2003 19:15:56.0802 (UTC) FILETIME=[438C9E20:01C30C28] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: sylvia_sugar@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: bay1-f80.bay1.hotmail.com [65.54.245.80] X-LYRIS-Message-Id: Hello friends, As usual I have come up with the dumbest of query. :( I would love it if someone could take time to answer the same. Is there anyway one can 'pinpoint' the end of an LSP without allocating the end point, a 'certain identifier'? -SylviaXO _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 26 18:17:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00285 for ; Sat, 26 Apr 2003 18:17:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3QMJhI17313 for ; Sat, 26 Apr 2003 18:19:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3QMJeZ24522 for ; Sat, 26 Apr 2003 18:19:40 -0400 (EDT) From: "Mark Seery" To: Cc: , , "Yakov Rekhter" , Subject: RE: ppvpn effort support Date: Sat, 26 Apr 2003 15:16:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: smtp018.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp018.mail.yahoo.com [216.136.174.115] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit >> Vach: What does inter-AS mean? << Let us take two common uses of domain/area and AS concepts a) to aid scaling b) to provide administrative boundaries. Remembering that we are creating a VPLS per subscriber company, reminds as that one of the benefits of using a server trail (arguments about Ethernet defficiencies aside for now) is to provide complete service transparency, i.e. the subscriber should be able to use any addressing (MAC, VLAN, etc.)they desire. Therefore, when going across an AS boundary, this service transparency should be maintained. If we just dump everything out again into native Ethernet at the AS boundaries, can we maintain this service transparency? There are probably more issues than just the burden of MAC address lookup on the border routers, there is the need to map back to QinQ for example to maintain service transparency across an aggregated link. Eric Rosen asked the question why not just extend the psuedowire across the boundaries. Beautiful. This maintains the VPN/VPLS and hence the service transparency. However, does it aid in scaling (does it limit the PE mesh - perhaps a spoke between two hubs?), and does it aid in administration (are there policy engines that can be applied to psuedowires; are policy engines required/useful for a signaled connection/NNI)? That we may come to a point where we observe that there is inter-domain work that is different and unique to intradomain work seems entirely consistent with our experience in other contexts. This may also be a reason why multiple VPLS proposals go forward, as has been suggested by Philippe Niger and Steven Wright. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Apr 26 21:57:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04618 for ; Sat, 26 Apr 2003 21:57:23 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3R1xaI09665 for ; Sat, 26 Apr 2003 21:59:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3R1xVr25826 for ; Sat, 26 Apr 2003 21:59:32 -0400 (EDT) Message-Id: From: "www.citcop.se" To: ppvpn@nortelnetworks.com Subject: Erbjudande X-Mailer: x-mailer Reply-To: telefonpost@citcop.se Date: Sun, 27 Apr 2003 04:02:10 +0100 Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 X-SMTP-HELO: ashd1-2.relay.mail.uu.net X-SMTP-MAIL-FROM: telefonpost@citcop.se X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ashd1-2.relay.mail.uu.net [199.171.54.246] X-LYRIS-Message-Id: Panasonic Erbjudande 6-pack
 

KÖP ETT SEXPACK!


POWER ECO INVERTER
VÄRMEPUMP


PASSA PÅ!!!
Köp ett 6-pack Panasonic E9 eller E12 till ett fantastiskt pris.
E9 för SEK 9900:-/st (59.400:-) och E12 för SEK 11900:-/st (71.400:-). Minsta antal 6 maskiner.
Detta erbjudandet är tidsbegränsat och gäller utan garanti.

BESTÄLL NU!!
Endast ett fåtal pumpar på lagret, beställ nu så får du garanterat en. Omgående leverans.

-Producerad för Nordiskt klimat.
-Miljövänligt kylmedia R410A.
-Betala säkert med kreditkort!
-2003 års modell

Köp på vår hemsida, så får du installations-kittet till halva priset. www.citcop.com

Vill du inte ha fler mail av oss? Klicka här
 

Begränsat antal!
Fraktkostnad 490:- (sverige) 1.490: -(norge)per pall (upptill 6 maskiner per pall)

Adress:
Citcop Sweden AB
Energigatan 15B
434 37 KUNGSBACKA
 Hemsida:
www.citcop.com
Tel:
+46-300-70700

From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Apr 27 16:42:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01613 for ; Sun, 27 Apr 2003 16:42:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3RKii225376 for ; Sun, 27 Apr 2003 16:44:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3RKifR26788 for ; Sun, 27 Apr 2003 16:44:41 -0400 (EDT) From: "Mark Seery" To: "Muneyoshi Suzuki" Cc: Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Sun, 27 Apr 2003 13:42:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: smtp016.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp016.mail.yahoo.com [216.136.174.113] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Muneyoshi, Just looking through some of your comments I was wondering which of the below "logical" networks is more preferable to you: 1) Emulated multipoint wire (where SP network is completely transparent) ------- | CE1 |---------------------------- ------- | | | | | | ------- ------- | CE2 | | CE3 | ------- ------- 2) Emulated switch (where the entire network looks like one switch) ------- -------------------------- | CE1 |--------| Ethernet Switch/Bridge | ------- -------------------------- | | | | ------- ------- | CE2 | | CE3 | ------- ------- 3) Network of switches (where each PE behaves like an Ethernet switch) ------- ------- ------- ------- | CE1 |--------| SW1 |-----------------| SW2 |-------| CE2 | ------- ------- ------- ------- | | | | | | | | | | | | ------- | SW3 | ------- | | ------- | CE3 | ------- Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 02:08:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18912 for ; Mon, 28 Apr 2003 02:08:55 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3S6BBl17516 for ; Mon, 28 Apr 2003 02:11:12 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3S6B8d06156 for ; Mon, 28 Apr 2003 02:11:08 -0400 (EDT) Date: Mon, 28 Apr 2003 14:08:43 +0800 From: lidefeng Subject: About draft-chen-ppvpn-dvpls-compare-01.txt To: ppvpn@nortelnetworks.com Message-id: <000501c30d4c$9f561400$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, In section "4.2.1 Core Network" of draft-chen-ppvpn-dvpls-compare-01.txt,there are the following comparision: GVPLS DTLS VPLS/HVPLS Number of O(n) per VPLS, where O(n*n) per O(n*n) per PWs n is number of N-PEs VPLS, where n VPLS, where n when using control is number of N- is number of N- word PEs PEs OR O(n*n) per VPLS when control word is not used. I wonder why the number of PWs is O(n) per VPLS(n is number of N-PEs ) when using control word.Does it mean that,when using control word,the PW is mp2p PW,so as to the number of PWs is O(n)? Could anyone please to clarify this question? 3x Regards Li Defeng From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 03:24:56 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22877 for ; Mon, 28 Apr 2003 03:24:56 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3S7RDl27983 for ; Mon, 28 Apr 2003 03:27:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3S7R9Q27878 for ; Mon, 28 Apr 2003 03:27:10 -0400 (EDT) Date: Mon, 28 Apr 2003 15:23:47 +0800 From: lidefeng Subject: Consult about draft-chen-ppvpn-dvpls-compare-01.txt To: ppvpn@nortelnetworks.com Message-id: <000701c30d57$1bedf000$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT hi,all In section "5.3 Packet replication/Flooding" of draft-chen-ppvpn-dvpls-compare-01.txt,it states that: "In a typical bridge, the flooding is performed across all the bridge ports, however, in VPLS applications, it is required that flooding, broadcast and multicast are performed within the VPLS domain, i.e. only to those customer end-points, that belong to the VPLS instance." I am not sure that in VPLS applications if the flooding domain includes the subtended customer end-points which belong to the VPLS instance? For example in the following figure,does the flooding domain of MTU-s include VC-1 PW,PW between PE1-rs and PE2-rs, PW between PE1-rs and PE3-rs besides CE-1 and CE-2,CE-3? or only include CE-1 and CE-2,CE-3 ? If the answer is the former one,I think there is no difference between the typical bridge. PE2-rs ------ / \ | -- | | / \ | CE-1 | \B / | \ \ -- / \ /------ \ MTU-s PE1-rs / | \ ------ ------ / | / \ / \ / | | \ -- | VC-1 | -- |---/ | | / \--|- - - - - - - - - - - |--/ \ | | | \B / | | \B / | | \ /-- / \ -- / ---\ | /----- ------ \ | / \ | ---- \ ------ |Agg | / \ ---- | -- | / \ | / \ | CE-2 CE-3 | \B / | \ -- / MTU-s = Bridging capable MTU ------ PE-rs = VPLS capable PE PE3-rs -- / \ \B / = Virtual VPLS(Bridge)Instance -- Agg = Layer-2 Aggregation Could anyone help me to clarify this question? 3x Regards Li Defeng From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 03:43:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23198 for ; Mon, 28 Apr 2003 03:43:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3S7k3l02068 for ; Mon, 28 Apr 2003 03:46:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3S7jwM03749 for ; Mon, 28 Apr 2003 03:45:59 -0400 (EDT) Date: Mon, 28 Apr 2003 15:43:00 +0800 From: lidefeng Subject: Consult about draft-chen-ppvpn-dvpls-compare-01.txt To: ppvpn@nortelnetworks.com Message-id: <000d01c30d59$cb54f960$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, In section "6.1 Scalability" of draft-chen-ppvpn-dvpls-compare-01.txt,there are following statements: "Let's suppose a network with n N-PE devices each with k EndPoints that belong to the same VPLS instance. The total number of EndPointPs for this particular VPLS instance is n*k. Based on these: In GVPLS the number of VC-Labels in the core is n*k*(k-1). In DTLS the number of VC-Labels in the core is n*k*(n*k -1). In HVPLS the number of VC-Labels in the core is k*(k-1). " I don't agree with that "In HVPLS the number of VC-Labels in the core is k*(k-1).", where HVPLS signifys the VPLS defined in "draft-lasserre-vkompella-ppvpn-vpls". Could you please explain how come those results? 3x Regards Li Defeng From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 04:58:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24491 for ; Mon, 28 Apr 2003 04:58:11 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3S90Tl24513 for ; Mon, 28 Apr 2003 05:00:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3S90O710179 for ; Mon, 28 Apr 2003 05:00:24 -0400 (EDT) Date: Mon, 28 Apr 2003 16:51:51 +0800 From: lidefeng Subject: How to use the "Source Control Flag" in GVPLS To: ppvpn@nortelnetworks.com Message-id: <001f01c30d63$69d388a0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, In section "5.4 Information Model entities" of draft-radoaca-ppvpn-gvpls-01.txt,there is a concept of "Source Control Flag",I don't know how to use it in implementation,and what this field is composed of ? And it states in the draft that"The VC-Labels calculation and the MAC source learning process are dependent on this flag.", I don't know how the VC-label calculation and MAC source learning process depend on this flag,could you please explain it in detail? Thank you! Li Defeng From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 07:59:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27882 for ; Mon, 28 Apr 2003 07:59:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SC24l14239 for ; Mon, 28 Apr 2003 08:02:05 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SC1w121741 for ; Mon, 28 Apr 2003 08:01:58 -0400 (EDT) Message-ID: <3EAD1754.40704@acm.org> Date: Mon, 28 Apr 2003 07:58:12 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: vkompella@timetra.com CC: schultz@io.iol.unh.edu, "O'Connor, Don" , "'Serbest, Yetik'" , Cheng-Yin.Lee@alcatel.com, "'Rick Wilder'" , ppvpn@nortelnetworks.com, tony@jeffree.co.uk, mick_seaman@ieee.org, Gerard Goubert Subject: Re: IEEE 802.1ad and VPLS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I apologize for jumping into this fray late, but I've been a wee bit behind in my email. The good thing about the current structure of the vkompella draft (IMHO) is that we can, at the end of the day, treat the VPLS like a LAN segment. So one could treat 802.1ad and VPLS independently, just as one can treat 802.1ad and Ethernet independently. 802.1ad can, at the edge, tunnel BPDUs over VPLS. As VPLS looks like a LAN segment to 802.1, it can tunnel BPDUs and other things over a VPLS. One can argue if thats a useful thing, but it can be done, as long as we continue with the VPLS=LAN model. As far as the orgnization between the groups, its unclear how much more is needed. Many people in 802.1 know whats happening in PPVPN, and vice-versa. As emulating LAN segments has been done in the past (ATM, FR, etc.), and there weren't really any 802.1 specific issues to deal with in the past, I don't expect there will be with VPLS unless we deviate from the model of LAN emulation. - Matt Vach Kompella wrote: > It's too early to say exactly how the pieces interact. Initial discussions with > members in the IEEE (particularly Mick Seaman, Norm Finn, Tony Jeffree, Matt > Squire) have shown that they think that draft-lasserre-vkompella can fit in the > IEEE model. On our side, the design team discussions have confirmed that. > > The IEEE believes it takes some definition on their part, which is what 802.1ad > is. Both 802.1ad and draft-lasserre-vkompella are "works in progress." The > IEEE has clearly gotten far enough that they got a draft0. We are still > deciding whether draft-lasserre-vkompella is a WG document or not. I'd say, > when we get past that stage in the IETF, we can ask for formal liaisons. > > That's why I've been pushing for IETF recognition that what we are working on > here in ppvpn is worth furthering. I don't think the process calls for > everything to be nailed down before the IETF recognizes the work as its own > rather than an individual contribution. > > As a final point, this has been a call to make draft-lasserre-vkompella a > working group document, nothing more. I (fondly) think that phase has been > achieved, but I'll wait for official confirmation from the chairs. > > -Vach > > >>-----Original Message----- >>From: schultz@io.iol.unh.edu [mailto:schultz@io.iol.unh.edu] >>Sent: Friday, April 18, 2003 9:17 AM >>To: Vach Kompella >>Cc: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com; >>mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; >>tony@jeffree.co.uk; mick_seaman@ieee.org; Gerard Goubert >>Subject: RE: IEEE 802.1ad and VPLS >> >> >> >>Vach, >> >>So is the plan here to come up with a 802.1ad solution and a separate >>ppvpn (L3 control plane) solution? Or is this ppvpn committee going to >>work with 802.1 to design a specific interoperable solution? These >>options are not mutually exclusive. >> >>I am unclear as to how this effort is being organized beyond norm finn's >>unofficial liason. >> >>Thanks, >>-Ben >> >>On Fri, 18 Apr 2003, Vach Kompella wrote: >> >> >>>I think we have agreed that tunneling BPDUs is going to be done. I >> >>think that >> >>>over and above that, it may be possible to use L3 control plane >> >>mechanisms to >> >>>assist the convergence. I'm only saying that it is possible that >> >>as we develop >> >>>some scenarios of customer and provider topologies, I don't want to >> >>assume that >> >>>the only solution lies in L2 protocols. >>> >>>-Vach >>> >>> >>>>-----Original Message----- >>>>From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] >>>>Sent: Friday, April 18, 2003 7:42 AM >>>>To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; >>>>Cheng-Yin.Lee@alcatel.com >>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; >>>>'tony@jeffree.co.uk'; 'mick_seaman@ieee.org' >>>>Subject: RE: IEEE 802.1ad and VPLS >>>> >>>> >>>>Vach, >>>> >>>>Are you suggesting that customer BPDUs should not be tunneled through the >>>>provider VPLS network? If this is the case it would not be possible for >>>>customers to run STP across multiple sites interconnected by the VPLS >>>>network. >>>> >>>>I agree with your point that it may also be possible to use L3 >> >>signaling for >> >>>>MAC unlearn signaling especially for the case where bridging and MPLS are >>>>supported in the same NE. This is relevant to my question >> >>pertaining to how >> >>>>the L2 control plane interacts with the L3 control plane. >>>> >>>>I think it would be good to have a more formalized liaison >> >>structure between >> >>>>ppvpn and 802.1AD - maybe some common email >>>>list. >>>> >>>>Don >>>> >>>> >>>>-----Original Message----- >>>>From: Vach Kompella [mailto:vkompella@timetra.com] >>>>Sent: Thursday, April 17, 2003 6:20 PM >>>>To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com >>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>Subject: RE: IEEE 802.1ad and VPLS >>>> >>>> >>>>Dan, >>>> >>>>It isn't clear to me yet that the only reliable way to deal with >> >>L2 control >> >>>>protocol packets such as BPDUs is to pass them through the data >> >>plane of the >> >>>>VPLS. It is possible that one of the ways to deal with unlearns, e.g., is >>>>to >>>>use LDP messages, such as the MAC TLVs for specific or scoped >> >>unlearns. So, >> >>>>if >>>>"by reference" means that we don't assist the L2 solution with >> >>extensions to >> >>>>the >>>>VPLS signaling draft, then I disagree. If it means cooperative use of the >>>>L3 >>>>control plane with the IEEE work, I agree. Basically, we don't want to >>>>re-invent what is already there, but when we have L3 control plane methods >>>>available, it makes sense to figure out a division of work that makes the >>>>service work the best. >>>> >>>>From Clause 16 of the 802.1ad-d0 document: >>>>... (stuff dealing with a potential topology with loops) ... requires an >>>>IETF >>>>connection (see also suggested Clause 6.6 Support of the Internal Sublayer >>>>Service by IETF foo) and to deal with some of the 'loop through a >> >>customer' >> >>>>questions and the partial answers that we have to those. >>>> >>>>-Vach >>>> >>>> >>>>>-----Original Message----- >>>>>From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] >>>>>Sent: Thursday, April 17, 2003 3:55 PM >>>>>To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; >>>>>Cheng-Yin.Lee@alcatel.com >>>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>>Subject: RE: IEEE 802.1ad and VPLS >>>>> >>>>> >>>>>Vach, >>>>> >>>>>To confirm the relationship with draft-lasserre - when 802.1AD defines >>>>>solutions for issues such as Provider Bridge customer BPDU snooping / >>>>>unlearn signaling (for customer STP reconfiguration with >> >>backdoors, etc) - >> >>>>>then this will be incorporated in draft-lasserre by reference. >> >>Is this an >> >>>>>accurate perception? >>>>> >>>>>One issue I have been wondering about with respect to 802.1AD & PPVPN / >>>>>draft-lasserre is for single ended L2 VPN >>>>>provisioning, where will the interface between the L2 Control Plane >>>> >>>>(defined >>>> >>>>>by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be >>>>>defined. >>>>> >>>>>Don >>>>> >>>>>-----Original Message----- >>>>>From: Vach Kompella [mailto:vkompella@timetra.com] >>>>>Sent: Thursday, April 17, 2003 5:06 PM >>>>>To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com >>>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>>Subject: IEEE 802.1ad and VPLS >>>>> >>>>> >>>>>Dan, >>>>> >>>>>Yes it is. One of the items in the ppvpn-wg minutes (note the date >>>>>pre-dates >>>>>the official PAR date which is Dec. 31, 2002, so we (as IETF >> >>participants) >> >>>>>have >>>>>been keeping in touch with the IEEE, albeit informally) for the Atlanta >>>>>meeting >>>>>shows: >>>>> >>>>>=== clipped from minutes === >>>>>Norm Finn - IEEE 802.1 unofficial liaison >>>>>----------------------------------------- >>>>> >>>>>Project authorization request (amendment to 802.1q VLANs) - >> >>enable a SP to >> >>>>>offer the equivalent of separate LAN segments, bridged or >> >>virtual bridged >> >>>>>LANs (network of bridges doing l2vpn type services). >>>>> >>>>>Name of project - 802.1AD. >>>>>MAC-in-MAC not possible with this amendment. >>>>> >>>>>Confident that IETF L2vpn and 802.1AD will be interoperable, compatible >>>> >>>>etc >>>> >>>>>if mailing discussions are carried through. >>>>>=== end of clip === >>>>> >>>>>-Vach >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] >>>>>>Sent: Thursday, April 17, 2003 1:54 PM >>>>>>To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' >>>>>>Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>>>Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working >> >>group draft >> >>>>>> >>>>>>Yetik & Cheng-Yin, >>>>>> >>>>>>Isn't the PPVPN group in theory working with the 802.1AD >> >>Provider Bridge >> >>>>>>Group to define solutions for these issues. >>>>>> >>>>>>Regards, >>>>>> >>>>>>Don From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 08:09:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28095 for ; Mon, 28 Apr 2003 08:09:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SCC7l19781 for ; Mon, 28 Apr 2003 08:12:07 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SCC3107017 for ; Mon, 28 Apr 2003 08:12:04 -0400 (EDT) Message-ID: From: "Florin Balus" To: lidefeng , ppvpn@nortelnetworks.com Subject: RE: About draft-chen-ppvpn-dvpls-compare-01.txt Date: Mon, 28 Apr 2003 08:09:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30D7F.095E4DAE" 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_01C30D7F.095E4DAE Content-Type: text/plain Hi Li, Yes you're right it is because of the source representation in the control word. Keep in mind the source means the service provider entry point not the customer source MAC (already represented in the packet). GVPLS doesn't exclude usage of pt2pt PW if you are not concerned with scalability of the VC labels/ILM table. Regards, Florin -----Original Message----- From: lidefeng [mailto:lidefeng@huawei.com] Sent: Monday, April 28, 2003 2:09 AM To: ppvpn@nortelnetworks.com Subject: About draft-chen-ppvpn-dvpls-compare-01.txt Hi,all, In section "4.2.1 Core Network" of draft-chen-ppvpn-dvpls-compare-01.txt,there are the following comparision: GVPLS DTLS VPLS/HVPLS Number of O(n) per VPLS, where O(n*n) per O(n*n) per PWs n is number of N-PEs VPLS, where n VPLS, where n when using control is number of N- is number of N- word PEs PEs OR O(n*n) per VPLS when control word is not used. I wonder why the number of PWs is O(n) per VPLS(n is number of N-PEs ) when using control word.Does it mean that,when using control word,the PW is mp2p PW,so as to the number of PWs is O(n)? Could anyone please to clarify this question? 3x Regards Li Defeng ------_=_NextPart_001_01C30D7F.095E4DAE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: About draft-chen-ppvpn-dvpls-compare-01.txt

Hi Li,
Yes you're right it is because of the source = representation in the control word. Keep in mind the source means the = service provider entry point not the customer source MAC (already = represented in the packet).

GVPLS doesn't exclude usage of pt2pt PW if you are = not concerned with scalability of the VC labels/ILM table.
Regards,
Florin

-----Original Message-----
From: lidefeng [mailto:lidefeng@huawei.com] =
Sent: Monday, April 28, 2003 2:09 AM
To: ppvpn@nortelnetworks.com
Subject: About = draft-chen-ppvpn-dvpls-compare-01.txt


Hi,all,

In section "4.2.1 Core Network" of = draft-chen-ppvpn-dvpls-compare-01.txt,there are the following = comparision:

          &nb= sp;    = GVPLS           &= nbsp;    = DTLS           &n= bsp; VPLS/HVPLS
 Number of    O(n) per VPLS, = where O(n*n) per       O(n*n) per
   = PWs          n is number = of N-PEs VPLS, where n    VPLS, where n
          &nb= sp;      when using control   is = number of N-  is number of N-
          &nb= sp;      = word           &n= bsp;     = PEs           &nb= sp;  PEs
          &nb= sp;      OR
          &nb= sp;      O(n*n) per VPLS when
          &nb= sp;      control word is not
          &nb= sp;      used.

I wonder why the number of PWs is  O(n) per = VPLS(n is number of N-PEs ) when using control word.Does it mean = that,when using control word,the PW is mp2p PW,so as to the number of = PWs is O(n)?

Could anyone please to clarify this question? = 3x

Regards

Li Defeng


------_=_NextPart_001_01C30D7F.095E4DAE-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 08:42: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 IAA28926 for ; Mon, 28 Apr 2003 08:42:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SCiQl28619 for ; Mon, 28 Apr 2003 08:44:26 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SCiMw20593 for ; Mon, 28 Apr 2003 08:44:23 -0400 (EDT) Message-ID: <76F47B8341A5D511BA1A006008F5E8B44B4650@asd003v3> From: s.s.m.tolsma@kpn.com To: ppvpn@nortelnetworks.com Cc: hoffmans@kpn.com Subject: Supporting the GVPLS draft Date: Mon, 28 Apr 2003 14:41:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a743b804-da53-4de8-9d97-ab31953ce226" X-SMTP-HELO: irelay1.intern.aots.nl X-SMTP-MAIL-FROM: s.s.m.tolsma@kpn.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: irelay1.aots.nl [145.7.191.7] 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. ------=_NextPartTM-000-a743b804-da53-4de8-9d97-ab31953ce226 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30D83.7B510510" ------_=_NextPart_001_01C30D83.7B510510 Content-Type: text/plain Dear Mr Carugi, We would like you to know that KPN is supporting the GVPLS draft as a working document. WKR, John Hoffmans Sander Tolsma J.A. (John) Hoffmans / S.S.M. (Sander) Tolsma Senior Architects Operations Fixed Networks, Fixed Network Architectures ------_=_NextPart_001_01C30D83.7B510510 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Supporting the GVPLS draft

Dear Mr Carugi,


We would like you to know = that KPN is supporting the GVPLS = draft as a working = document.

WKR,

John = Hoffmans

Sander = Tolsma


J.A. = (John) Hoffmans /  S.S.M. (Sander) Tolsma
Senior Architects
Operations Fixed Networks, Fixed Network Architectures
 

------_=_NextPart_001_01C30D83.7B510510-- ------=_NextPartTM-000-a743b804-da53-4de8-9d97-ab31953ce226-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 09:05: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 JAA29581 for ; Mon, 28 Apr 2003 09:05:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SD7Yl15826 for ; Mon, 28 Apr 2003 09:07:34 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SD6rD26034 for ; Mon, 28 Apr 2003 09:06:53 -0400 (EDT) Message-Id: <200304281300.h3SD0Uu96910@merlot.juniper.net> To: vkompella@timetra.com cc: steven.wright@BellSouth.com, ppvpn@nortelnetworks.com Subject: Re: ppvpn effort support In-Reply-To: Your message of "Fri, 25 Apr 2003 10:04:29 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50169.1051534830.1@juniper.net> Date: Mon, 28 Apr 2003 06:00:30 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Vach, >>> Are you suggesting that if a VPLS spans two ASes, a MAC lookup table for >>> that VPLS needs to reside in the border routers that attach the two ASes? >>> I think that would correspond to the hierarchy of the HVPLS scheme, but the >>> need to do the MAC lookups on the border routers seems to place >>> a prety heavy load on them. >> >> Isn't that what is suggested by draft-lasserre-vkompella-ppvpn-vpls-04.txt ? >> >> 10.3. Multi-domain VPLS service >> >> Hierarchy can also be used to create a large scale VPLS service >> within a single domain or a service that spans multiple domains >> without requiring full mesh connectivity between all VPLS capable >> devices. Two fully meshed VPLS networks are connected together >> using a single LSP tunnel between the VPLS gateway devices. A >> single spoke pseudowire is setup per VPLS service to connect the two >> domains together. The VPLS gateway device joins two VPLS services >> together to form a single multi-domain VPLS service. The >> requirements and functionality required from a VPLS gateway device >> will be explained in a future version of this document. >> > > What does inter-AS mean? Some providers have a lot of AS's. Does it mean > across provider boundaries, administrative domains, does it involve security > considerations? "inter-AS" means spanning more than one Autonomous System (AS). It should cover both the case where the ASs belong to the same provider, as well as to a group of providers. > Multi-domain VPLS is just to show that there is a way to connect metro areas > (which is what the primary motivation that some providers gave us for that > particular section). That is the *only* way documented so far in draft-lasserre-vkompella-ppvpn-vpls-04.txt. And as I mentioned before, it has fairly poor scaling properties due to (a) the need to perform the MAC lookups on the border routers, and (b) the need to run STP on a per VPLS basis for VPLSs that span multiple ASs. In fact, those familiar with BGP/MPLS VPNs (aka 2547 VPNs), and specifically with the inter-AS support could notice that the inter-AS support proposed in draft-lasserre-vkompella-ppvpn-vpls-04.txt is analogous to the option (a) in Section 10 of 2547bis. In contrast the inter-AS approach described in draft-kompella-ppvpn-vpls-01.txt can support what is analogous to the option (c) in Section 10 of 2547bis, which (as observed in 2547bis) is more scalable than option (a). Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 09:14: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 JAA29849 for ; Mon, 28 Apr 2003 09:14:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SDH1l24795 for ; Mon, 28 Apr 2003 09:17:01 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SDGqY23692 for ; Mon, 28 Apr 2003 09:16:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Support for draft-kompella-ppvpn-vpls-01.txt Date: Mon, 28 Apr 2003 15:06:11 +0200 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE8DB7E2D@TMS031MB.tcad.telia.se> Thread-Topic: Support for draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMNhvDRAX7k704eQAy2rr9pCqMnDQ== From: To: X-OriginalArrivalTime: 28 Apr 2003 13:06:11.0638 (UTC) FILETIME=[F0FCBD60:01C30D86] X-SMTP-HELO: tms002bb.han.telia.se X-SMTP-MAIL-FROM: Andreas.A.Mattsson@telia.se X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tms002bb.han.telia.se [131.115.230.133] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA29849 Hi! I would like to add my name to the list in favor of the kompella-vpls draft. The reason for this is this is partly that I like the concept of having only one protocol for signaling /discovery and partly that I would like to see further investigation of the BGP versus LDP signaling approach before rejecting one or the other. As a service provider with a BGP mesh with RR already deployed, I definitely think that the auto discovery part of the BGP approach is a very nice feature. I would also like to know how inter-AS with the LDP approach in lasserre-vkompella is to be solved. This could be an important issue for some service providers that have more than on AS in their networks. Another question I have is if there exists a breakpoint where one solution becomes more scalable than the other in respect to the numbers of PE routers that are involved. /Andreas From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 09:23:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00032 for ; Mon, 28 Apr 2003 09:23:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SDPKl00513 for ; Mon, 28 Apr 2003 09:25:21 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SDPGY01567 for ; Mon, 28 Apr 2003 09:25:16 -0400 (EDT) Message-ID: <3EAD2A92.B7265D3B@alcatel.be> Date: Mon, 28 Apr 2003 15:20:18 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter Cc: vkompella@timetra.com, steven.wright@BellSouth.com, ppvpn@nortelnetworks.com Subject: Re: ppvpn effort support References: <200304281300.h3SD0Uu96910@merlot.juniper.net> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/28/2003 15:20:20, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/28/2003 15:20:21, Serialize complete at 04/28/2003 15:20:21 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-SMTP-HELO: relay4.alcatel.be X-SMTP-MAIL-FROM: jeremy.de_clercq@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc245.alcatel.be [195.207.101.245] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, all, it has been suggested for draft-lasserre-vkompella to refer to draft-rosen-ppvpn-l2-signaling-02.txt for the LDP-based signaling. Is this planned for when/if draft-lasserre-vkompella becomes a WG draft ? This should enable one to use draft-rosen-ppvpn-l2-signaling, section 5.5 for inter-AS scenarios, which would be more like what draft-kompella-ppvpn-vpls proposes. Jeremy. -- Yakov Rekhter wrote: > > Vach, > > >>> Are you suggesting that if a VPLS spans two ASes, a MAC lookup table for > >>> that VPLS needs to reside in the border routers that attach the two ASes? > >>> I think that would correspond to the hierarchy of the HVPLS scheme, but the > >>> need to do the MAC lookups on the border routers seems to place > >>> a prety heavy load on them. > >> > >> Isn't that what is suggested by draft-lasserre-vkompella-ppvpn-vpls-04.txt ? > >> > >> 10.3. Multi-domain VPLS service > >> > >> Hierarchy can also be used to create a large scale VPLS service > >> within a single domain or a service that spans multiple domains > >> without requiring full mesh connectivity between all VPLS capable > >> devices. Two fully meshed VPLS networks are connected together > >> using a single LSP tunnel between the VPLS gateway devices. A > >> single spoke pseudowire is setup per VPLS service to connect the two > >> domains together. The VPLS gateway device joins two VPLS services > >> together to form a single multi-domain VPLS service. The > >> requirements and functionality required from a VPLS gateway device > >> will be explained in a future version of this document. > >> > > > > What does inter-AS mean? Some providers have a lot of AS's. Does it mean > > across provider boundaries, administrative domains, does it involve security > > considerations? > > "inter-AS" means spanning more than one Autonomous System (AS). It > should cover both the case where the ASs belong to the same provider, > as well as to a group of providers. > > > Multi-domain VPLS is just to show that there is a way to connect metro areas > > (which is what the primary motivation that some providers gave us for that > > particular section). > > That is the *only* way documented so far in > draft-lasserre-vkompella-ppvpn-vpls-04.txt. And as I mentioned > before, it has fairly poor scaling properties due to (a) the need to > perform the MAC lookups on the border routers, and (b) the need to > run STP on a per VPLS basis for VPLSs that span multiple ASs. > > In fact, those familiar with BGP/MPLS VPNs (aka 2547 VPNs), and > specifically with the inter-AS support could notice that the inter-AS > support proposed in draft-lasserre-vkompella-ppvpn-vpls-04.txt is > analogous to the option (a) in Section 10 of 2547bis. In contrast > the inter-AS approach described in draft-kompella-ppvpn-vpls-01.txt > can support what is analogous to the option (c) in Section 10 of 2547bis, > which (as observed in 2547bis) is more scalable than option (a). > > Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 09:30:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00257 for ; Mon, 28 Apr 2003 09:30:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SDWPl05899 for ; Mon, 28 Apr 2003 09:32:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SDWHk08118 for ; Mon, 28 Apr 2003 09:32:17 -0400 (EDT) Message-ID: <710197BD5AF9D4119E4400508BCFA136053E9251@zcard04u.ca.nortel.com> From: "Dinesh Mohan" To: "'lidefeng'" , "'ppvpn@nortelnetworks.com'" Subject: RE: Consult about draft-chen-ppvpn-dvpls-compare-01.txt Date: Mon, 28 Apr 2003 09:27:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30D88.0CA5A904" 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_01C30D88.0CA5A904 Content-Type: text/plain; charset="gb2312" Li, In VPLS application, you are correct in stating that flooding domain should include the subtended customer end-points, which belong to VPLS instance. In your example, the flooding domain of MTU-s, for VPLS instance to which CE-1, CE-2, and CE3 belong, should be (for optimized forwarding) limited to MTU-s. However, when any CE subtended across PE2-rs becomes part of same VPLS instance, PE2-rs should become part of flooding domain as well. Likewise PE3-rs, if it becomes part of VPLS instance. Cheers, Dinesh -----Original Message----- From: lidefeng [mailto:lidefeng@huawei.com] Sent: Monday, April 28, 2003 3:24 AM To: ppvpn@nortelnetworks.com Subject: Consult about draft-chen-ppvpn-dvpls-compare-01.txt hi,all In section "5.3 Packet replication/Flooding" of draft-chen-ppvpn-dvpls-compare-01.txt,it states that: "In a typical bridge, the flooding is performed across all the bridge ports, however, in VPLS applications, it is required that flooding, broadcast and multicast are performed within the VPLS domain, i.e. only to those customer end-points, that belong to the VPLS instance." I am not sure that in VPLS applications if the flooding domain includes the subtended customer end-points which belong to the VPLS instance? For example in the following figure,does the flooding domain of MTU-s include VC-1 PW,PW between PE1-rs and PE2-rs, PW between PE1-rs and PE3-rs besides CE-1 and CE-2,CE-3? or only include CE-1 and CE-2,CE-3 ? If the answer is the former one,I think there is no difference between the typical bridge. PE2-rs ------ / \ | -- | | / \ | CE-1 | \B / | \ \ -- / \ /------ \ MTU-s PE1-rs / | \ ------ ------ / | / \ / \ / | | \ -- | VC-1 | -- |---/ | | / \--|- - - - - - - - - - - |--/ \ | | | \B / | | \B / | | \ /-- / \ -- / ---\ | /----- ------ \ | / \ | ---- \ ------ |Agg | / \ ---- | -- | / \ | / \ | CE-2 CE-3 | \B / | \ -- / MTU-s = Bridging capable MTU ------ PE-rs = VPLS capable PE PE3-rs -- / \ \B / = Virtual VPLS(Bridge)Instance -- Agg = Layer-2 Aggregation Could anyone help me to clarify this question? 3x Regards Li Defeng ------_=_NextPart_001_01C30D88.0CA5A904 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable RE: Consult about draft-chen-ppvpn-dvpls-compare-01.txt

Li,

In VPLS application, you are correct in stating that = flooding domain should include the subtended customer end-points, which = belong to VPLS instance.

In your example, the flooding domain of MTU-s, for = VPLS instance to which CE-1, CE-2, and CE3 belong, should be (for = optimized forwarding) limited to MTU-s. However, when any CE subtended = across PE2-rs becomes part of same VPLS instance, PE2-rs should become = part of flooding domain as well. Likewise PE3-rs, if it becomes part of = VPLS instance.

Cheers, Dinesh
-----Original Message-----
From: lidefeng [mailto:lidefeng@huawei.com]
Sent: Monday, April 28, 2003 3:24 AM
To: ppvpn@nortelnetworks.com
Subject: Consult about = draft-chen-ppvpn-dvpls-compare-01.txt

hi,all

In section "5.3 Packet = replication/Flooding" of
draft-chen-ppvpn-dvpls-compare-01.txt,it states = that:

"In a typical bridge, the flooding is performed = across all
   the bridge ports, however, in VPLS = applications, it is required that
   flooding, broadcast and multicast are = performed within the VPLS
   domain, i.e. only to those customer = end-points, that belong to the
   VPLS instance."

I am not sure that in VPLS applications if the = flooding domain includes the
subtended customer end-points which belong to the = VPLS instance? For example
in the following figure,does the flooding domain of = MTU-s include VC-1 PW,PW
between PE1-rs and PE2-rs, PW between PE1-rs and = PE3-rs besides CE-1 and
CE-2,CE-3? or only include CE-1 and CE-2,CE-3 ? If = the answer is the former
one,I think there is no difference between the = typical bridge.

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         PE2-rs
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           = ------
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;          = /      \
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         |   = --   |
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         |  /  = \  |
    = CE-1           &n= bsp;           &n= bsp;           &n= bsp;            = |  \B /  |
     = \            = ;            = ;            = ;            = ;   \  --  /
      = \            = ;            = ;            = ;            = ;  /------
       \   = MTU-s           &= nbsp;           &= nbsp;  PE1-rs        = /   |
        \ = ------           =             =    ------       = /    |
         = /      = \            = ;            = /      \     = /     |
        | \ = --   |      = VC-1            = |   --   |---/      = |
        |  = /  \--|- - - - - - - - - - - |--/  \  = |          |
        |  = \B /  = |            = ;          |  \B = /  |          = |
         \ = /--  = /            = ;            = \  --  / ---\      |
          = /-----           =             =    ------      = \     |
         = /            = ;            = ;            = ;         \    = |
       = ----           &n= bsp;           &n= bsp;           &n= bsp;         \ ------
      |Agg = |            = ;            = ;            = ;         = /      \
       = ----           &n= bsp;           &n= bsp;           &n= bsp;         |  = --    |
      /    = \            = ;            = ;            = ;        | /  \   = |
     CE-2  = CE-3           &n= bsp;           &n= bsp;           &n= bsp;     | \B /   |
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;          \ = --   /
    MTU-s =3D Bridging capable = MTU           &nb= sp;           &nb= sp;  ------
    PE-rs =3D VPLS capable = PE           &nbs= p;           &nbs= p;       PE3-rs

    --
   /  \
   \B / =3D Virtual = VPLS(Bridge)Instance
    --
    Agg =3D Layer-2 = Aggregation



Could anyone help me to clarify this question? = 3x

Regards

Li Defeng

------_=_NextPart_001_01C30D88.0CA5A904-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 10:02:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01205 for ; Mon, 28 Apr 2003 10:02:28 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SE4ll18020 for ; Mon, 28 Apr 2003 10:04:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SE4fD05488 for ; Mon, 28 Apr 2003 10:04:41 -0400 (EDT) Message-ID: <710197BD5AF9D4119E4400508BCFA136053E9252@zcard04u.ca.nortel.com> From: "Dinesh Mohan" To: "'lidefeng'" , ppvpn@nortelnetworks.com Subject: RE: Consult about draft-chen-ppvpn-dvpls-compare-01.txt Date: Mon, 28 Apr 2003 09:58:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30D8C.863D33AA" 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_01C30D8C.863D33AA Content-Type: text/plain; charset="gb2312" Li, Could you further elaborate your disagreement? For HVPLS, it is referring to full mesh between k N-PEs (or PE-rs) devices. Maybe, you are referring to additional VC-labels required between N-PE and U-PE devices (for VC between PE-rs and MTU-s), which I agree would be additional depending on total number of U-PE devices. Cheers, Dinesh -----Original Message----- From: lidefeng [mailto:lidefeng@huawei.com] Sent: Monday, April 28, 2003 3:43 AM To: ppvpn@nortelnetworks.com Subject: Consult about draft-chen-ppvpn-dvpls-compare-01.txt Hi,all, In section "6.1 Scalability" of draft-chen-ppvpn-dvpls-compare-01.txt,there are following statements: "Let's suppose a network with n N-PE devices each with k EndPoints that belong to the same VPLS instance. The total number of EndPointPs for this particular VPLS instance is n*k. Based on these: In GVPLS the number of VC-Labels in the core is n*k*(k-1). In DTLS the number of VC-Labels in the core is n*k*(n*k -1). In HVPLS the number of VC-Labels in the core is k*(k-1). " I don't agree with that "In HVPLS the number of VC-Labels in the core is k*(k-1).", where HVPLS signifys the VPLS defined in "draft-lasserre-vkompella-ppvpn-vpls". Could you please explain how come those results? 3x Regards Li Defeng ------_=_NextPart_001_01C30D8C.863D33AA Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable RE: Consult about draft-chen-ppvpn-dvpls-compare-01.txt

Li,

Could you further elaborate your disagreement?

For HVPLS, it is referring to full mesh between k = N-PEs (or PE-rs) devices.

Maybe, you are referring to additional VC-labels = required between N-PE and U-PE devices (for VC between PE-rs and = MTU-s), which I agree would be additional depending on total number of = U-PE devices.

Cheers, Dinesh
-----Original Message-----
From: lidefeng [mailto:lidefeng@huawei.com]
Sent: Monday, April 28, 2003 3:43 AM
To: ppvpn@nortelnetworks.com
Subject: Consult about = draft-chen-ppvpn-dvpls-compare-01.txt

Hi,all,

In section "6.1 Scalability" of = draft-chen-ppvpn-dvpls-compare-01.txt,there
are following statements:

"Let's suppose a network with  n N-PE = devices each with k EndPoints that
belong to the same VPLS instance. The total number = of EndPointPs for this
particular VPLS instance is n*k.

   Based on these:
   In GVPLS the number of VC-Labels in the = core is n*k*(k-1).
   In DTLS the number of VC-Labels in the = core is n*k*(n*k -1).
   In HVPLS the number of VC-Labels in the = core is k*(k-1). "

I don't agree with that "In HVPLS the number of = VC-Labels in the core is
k*(k-1).", where HVPLS signifys the VPLS = defined in
"draft-lasserre-vkompella-ppvpn-vpls".

Could you please explain how come those results? = 3x

Regards

Li Defeng

------_=_NextPart_001_01C30D8C.863D33AA-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 10:30: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 KAA02972 for ; Mon, 28 Apr 2003 10:30:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SEXEl27540 for ; Mon, 28 Apr 2003 10:33:15 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SEX9I27123 for ; Mon, 28 Apr 2003 10:33:10 -0400 (EDT) Message-Id: <200304281429.h3SETMlY028514@rtp-core-1.cisco.com> To: Andreas.A.Mattsson@telia.se cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Mon, 28 Apr 2003 15:06:11 +0200. <7B64D9FB62EB42449683BA51E9AB2AE8DB7E2D@TMS031MB.tcad.telia.se> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 28 Apr 2003 10:29:22 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Andreas> I would also like to know how inter-AS with the LDP approach in Andreas> lasserre-vkompella is to be solved. Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 10:52: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 KAA03626 for ; Mon, 28 Apr 2003 10:52:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SEsil05806 for ; Mon, 28 Apr 2003 10:54:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SEscr16038 for ; Mon, 28 Apr 2003 10:54:38 -0400 (EDT) Message-Id: <200304281451.h3SEp5lY006195@rtp-core-1.cisco.com> To: Yakov Rekhter cc: ppvpn@nortelnetworks.com Subject: Re: ppvpn effort support In-reply-to: Your message of Mon, 28 Apr 2003 06:00:30 -0700. <200304281300.h3SD0Uu96910@merlot.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 28 Apr 2003 10:51:04 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Yakov> In fact, those familiar with BGP/MPLS VPNs (aka 2547 VPNs), and Yakov> specifically with the inter-AS support could notice that the inter-AS Yakov> support proposed in draft-lasserre-vkompella-ppvpn-vpls-04.txt is Yakov> analogous to the option (a) in Section 10 of 2547bis. There's nothing fundamental about the lasserre-vkompella procedures that forces one to have MAC lookup tables in the border routers. With a slight generalization of the signaling protocol (using the "Generalized ID FEC" of draft-ietf-pwe3-control-protocol), one can provide a model which is analogous to the other, more scalable, options of section 10 of 2547bis. See section 5.5.4 of draft-rosen-ppvpn-l2-signaling. (Thanks, Jeremy, for noticing!) That also shows how one can run the pseudowires across the boundary, while also providing a control point at the boundary that can be useful in doing OAM, and in determining whether packets are entering and leaving your system as they should be; this could be important in the multi-provider finger pointing exercises. ;-) I had thought that a suggestion was made to (a) provide a service boundary of some sort at the border routers, and (b) to use BGP-based signaling to do so. That's what I was asking for clarification about. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 11:26: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 LAA04538 for ; Mon, 28 Apr 2003 11:26:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SFSkl08232 for ; Mon, 28 Apr 2003 11:28:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SFSWn00356 for ; Mon, 28 Apr 2003 11:28:32 -0400 (EDT) Message-ID: <3EAD479D.1050205@marconi.com> Date: Mon, 28 Apr 2003 11:24:13 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030403 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: Sylvia Sugar CC: ppvpn@nortelnetworks.com Subject: Re: label generation algorithms References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: David.Charlap@marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Sylvia Sugar wrote: > > Is there anyway one can 'pinpoint' the end of an LSP without allocating > the end point, a 'certain identifier'? Well, if you trace the LSP and find a node that does a label-pop, then that node is the end of that LSP. Of course, there could be lower-level labels that will cause the packet to be label-switched to another router, but that label would correspond to a different LSP. When RSVP-TE is used for signaling, each LSP has a "tunnel endpoint address" which identifies the IP address where the LSP ends. When LDP is used for signaling, it's trickier. The FEC will tell you the address where the LSP is supposed to end, but if one or more nodes along the path to that address isn't participating in LDP (and downstream unsolicited label allocation is used), the LSP will end at an intermediate node somewhere. If you are looking for some kind of magic bullet to let you look at any node along any arbitrary LSP and say "the endpoint is w.x.y.z", I don't think there exists one. -- David From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 11:59:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05481 for ; Mon, 28 Apr 2003 11:59:36 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SG1ql00813 for ; Mon, 28 Apr 2003 12:01:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SG1ha24742 for ; Mon, 28 Apr 2003 12:01:43 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6B65@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'lidefeng'" , ppvpn@nortelnetworks.com Subject: RE: How to use the "Source Control Flag" in GVPLS Date: Mon, 28 Apr 2003 11:58:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30D9E.F4014F4A" 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_01C30D9E.F4014F4A Content-Type: text/plain Li, In the original definition of the PW, the VC-Label was suppose to represent the destination of the outgoing port [physical or virtual]. However, in the VPLS scope, in order to emulate a LAN in the VPLS core, the N-PE/U-PE needs to learn the source of the originating packets. There are different ways to provide such mechanism: - to overload the VC-Label semantic, with the source indication. For example this is the case of the vkompella-lasserre-vpls draft. Because the MAC learning is done entirely in the N-PE device, the VC-Label needs to represent both the Source and the Destination N-PE. This model doesn't scale from both MAC learning perspective and for the number of VC-Labels. In order to resolve the VC_Labels issue, the vpls model propose to extend with an access network [via Hub-and Spoke model, or via Q-in-Q]. The MAC learning accumulation is still not solved, instead is increasing pretty well if you consider that now you aggregate a larger access network. The other problem that Q-in-Q/Spoke model added is the granularity of the end-to end circuit. Because the source is indicated only from the N-PE device, there is no way to check a circuit from end-to-end Spoke. If the overload solution is used in the distributed model, then the number of VC-Labels would increase with an order of magnitude [O(N2)]. - to leave the VC-Label semantic as defined in the PWE3 and to represent the SRC in the Control Word. The solution solve both the non-distributed model and also the distributed model. The number of VC-Labels would stay relative low, regardless of the number of U-PE/ N-PE devices. Also, the issue of the circuit granularity end-to-end would no be a problem - the SRC can indicate the U-PE or N-PE device. Now, because GVPLS is built on top of vpls, the solution tries to preserve the overload model of the VC-Label, and in the same time to offer an alternative for performance and scalability, by using the Control Word model. The Source Control Flag [SRC-Flag] indicates such options - and it is provisioned and signaled in the control plan. If the SRC-Flag indicates the overload model, then a VC-Label is calculated for each pair (local U-PE[N-PE] and remote U-PE[N-PE]). If the SRC-Flag indicates the Control word model, then a VC-Label is calculated only for the local U-PE[N-PE] device as per PWE3 model. Cheers Vasile -----Original Message----- From: lidefeng [mailto:lidefeng@huawei.com] Sent: Monday, April 28, 2003 4:52 AM To: ppvpn@nortelnetworks.com Subject: How to use the "Source Control Flag" in GVPLS Hi,all, In section "5.4 Information Model entities" of draft-radoaca-ppvpn-gvpls-01.txt,there is a concept of "Source Control Flag",I don't know how to use it in implementation,and what this field is composed of ? And it states in the draft that"The VC-Labels calculation and the MAC source learning process are dependent on this flag.", I don't know how the VC-label calculation and MAC source learning process depend on this flag,could you please explain it in detail? Thank you! Li Defeng ------_=_NextPart_001_01C30D9E.F4014F4A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: How to use the "Source Control Flag" in = GVPLS

Li,

In the original definition of the PW, the VC-Label = was suppose to represent the destination of the outgoing port [physical = or virtual]. However, in the VPLS scope, in order to emulate a LAN in = the VPLS core,  the N-PE/U-PE needs to learn the source of the = originating packets. There are different ways to provide such = mechanism:

 - to overload the VC-Label semantic, with the = source indication. For example this is the case of the  = vkompella-lasserre-vpls draft. Because the MAC learning is done = entirely in the N-PE device, the VC-Label needs to represent both the = Source and the Destination N-PE. This model doesn't scale from both MAC = learning perspective and for the number of VC-Labels.  In order to = resolve the VC_Labels issue, the vpls model propose to extend with an = access network [via Hub-and Spoke model, or via Q-in-Q]. The MAC = learning accumulation is still not solved, instead is increasing pretty = well if you consider that now you aggregate a larger access network. = The other problem that Q-in-Q/Spoke model added is the granularity of = the end-to end circuit. Because the source is indicated only from the = N-PE device, there is no way to check a circuit from end-to-end Spoke. =

   If the overload solution is used in the = distributed model, then the number of VC-Labels would increase with an = order of magnitude [O(N2)].

 
 - to leave the VC-Label semantic as defined in = the PWE3 and to represent the SRC in the Control Word. The solution = solve both the non-distributed model and also the distributed model. = The number of VC-Labels would stay relative low, regardless of the = number of U-PE/ N-PE devices. Also, the issue of the circuit = granularity end-to-end would no be  a problem - the SRC can = indicate the U-PE or N-PE device.

Now, because GVPLS is built on top of vpls, the = solution tries to preserve the overload model of the VC-Label, and in = the same time to offer an alternative for performance and scalability, = by using the Control Word model. The Source Control Flag [SRC-Flag] = indicates such options - and it is provisioned and signaled in the = control plan.

If the SRC-Flag indicates the overload model, then a = VC-Label is calculated for each pair (local U-PE[N-PE] and remote = U-PE[N-PE]).

If the SRC-Flag indicates the Control word model, = then a VC-Label is calculated only for the local U-PE[N-PE] device as = per PWE3 model.


Cheers
  Vasile




-----Original Message-----
From: lidefeng [mailto:lidefeng@huawei.com] =
Sent: Monday, April 28, 2003 4:52 AM
To: ppvpn@nortelnetworks.com
Subject: How to use the "Source Control = Flag" in GVPLS


Hi,all,

In section "5.4 Information Model entities" = of draft-radoaca-ppvpn-gvpls-01.txt,there is a concept of "Source = Control Flag",I don't know how to use it in implementation,and = what this field is composed of ? And it states in the draft = that"The VC-Labels calculation and the MAC source learning process = are dependent on this flag.", I don't know how the VC-label = calculation and MAC source learning process depend on this flag,could = you please explain it in detail? Thank you!

Li Defeng




------_=_NextPart_001_01C30D9E.F4014F4A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 13:18:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07471 for ; Mon, 28 Apr 2003 13:18:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SHKNl06472 for ; Mon, 28 Apr 2003 13:20:23 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SHKGX00412 for ; Mon, 28 Apr 2003 13:20:17 -0400 (EDT) Message-ID: From: "Florin Balus" To: ppvpn@nortelnetworks.com Subject: RE: Supporting the GVPLS draft Date: Mon, 28 Apr 2003 13:16:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30DA9.E8C5A74C" 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_01C30DA9.E8C5A74C Content-Type: text/plain I would like also to add my support for GVPLS draft because it provides support for both BGP and LDP-based signaling besides the other points already made in the previous "support" emails sent to the distribution list. Regards, Florin -----Original Message----- From: s.s.m.tolsma@kpn.com [mailto:s.s.m.tolsma@kpn.com] Sent: Monday, April 28, 2003 8:41 AM To: ppvpn@nortelnetworks.com Cc: hoffmans@kpn.com Subject: Supporting the GVPLS draft Dear Mr Carugi, We would like you to know that KPN is supporting the GVPLS draft as a working document. BM__MailAutoSigWKR, John Hoffmans Sander Tolsma J.A. (John) Hoffmans / S.S.M. (Sander) Tolsma Senior Architects Operations Fixed Networks, Fixed Network Architectures ------_=_NextPart_001_01C30DA9.E8C5A74C Content-Type: text/html Message
 
I would like also to add my support for GVPLS draft because it provides support for both BGP and LDP-based signaling besides the other points already made in the previous "support" emails sent to the distribution list.
Regards,
Florin
 
-----Original Message-----
From: s.s.m.tolsma@kpn.com [mailto:s.s.m.tolsma@kpn.com]
Sent: Monday, April 28, 2003 8:41 AM
To: ppvpn@nortelnetworks.com
Cc: hoffmans@kpn.com
Subject: Supporting the GVPLS draft

Dear Mr Carugi,


We would like you to know that KPN is supporting the GVPLS draft as a working document.

WKR,

John Hoffmans

Sander Tolsma


J.A. (John) Hoffmans /  S.S.M. (Sander) Tolsma
Senior Architects
Operations Fixed Networks, Fixed Network Architectures
 

------_=_NextPart_001_01C30DA9.E8C5A74C-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 13:56:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08567 for ; Mon, 28 Apr 2003 13:56:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SHwql16796 for ; Mon, 28 Apr 2003 13:58:52 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SHwmW25323 for ; Mon, 28 Apr 2003 13:58:49 -0400 (EDT) X-Originating-IP: [66.131.17.94] X-Originating-Email: [ronjthompson@hotmail.com] From: "Ron Thompson" To: Subject: subscribe ppvpn Date: Mon, 28 Apr 2003 13:53:58 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C30D8D.9E411100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 28 Apr 2003 17:54:00.0095 (UTC) FILETIME=[25CA2AF0:01C30DAF] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: ronjthompson@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dav18.sea2.hotmail.com [207.68.164.122] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C30D8D.9E411100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit subscribe ppvpn ------=_NextPart_000_0000_01C30D8D.9E411100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable subscribe ppvpn

subscribe ppvpn



------=_NextPart_000_0000_01C30D8D.9E411100-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 15:16:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11854 for ; Mon, 28 Apr 2003 15:16:06 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SJINl01728 for ; Mon, 28 Apr 2003 15:18:23 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SJIFa22694 for ; Mon, 28 Apr 2003 15:18:16 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Yakov Rekhter" Cc: , Subject: RE: ppvpn effort support Date: Mon, 28 Apr 2003 12:14:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <200304281300.h3SD0Uu96910@merlot.juniper.net> X-OriginalArrivalTime: 28 Apr 2003 19:14:35.0779 (UTC) FILETIME=[6814FD30:01C30DBA] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, You misunderstand what is described in draft-lasserre-vkompella. The spoke connection between a "border" PE and another is a draft-martini pipe. The behavior is exactly analogous to that described in section 10(a) of draft-ietf-ppvpn-rfc2547. This behavior is precisely that of extending a customer sub-interface into the VPLS over an extension that may be an RFC1483 PVC, an RFC 1490 PVC, a draft-martini pipe, a q-tagged pipe, etc. Perhaps it seems that the spoke has those VPLS properties because it may be connected to an MTU that is bridging capable. That, however, is not a spoke property; rather it is the property of a bridge that has multiple spokes (aka interfaces, whether logical or physical). A spoke does not have learning associated with it. An ethernet packet put into a spoke is just transmitted down the spoke. In fact, this particular behavior is what makes the spoke a scalable addition to the basic VPLS model in the intra-metro HVPLS model. However, if you have two spokes, you have to replicate on the spokes (a VPLS function at the PE, and an 802.1d bridge function at an MTU, not a spoke function). No STP is needed for a VPLS. STP may be required on a spoke. However, if one is required on a spoke, it is because spokes are treated as extensions to customer interfaces, and STP may run on customer interfaces. -Vach > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Monday, April 28, 2003 6:01 AM > To: vkompella@timetra.com > Cc: steven.wright@BellSouth.com; ppvpn@nortelnetworks.com > Subject: Re: ppvpn effort support > > > Vach, > > >>> Are you suggesting that if a VPLS spans two ASes, a MAC lookup > table for > >>> that VPLS needs to reside in the border routers that attach > the two ASes? > >>> I think that would correspond to the hierarchy of the HVPLS > scheme, but the > >>> need to do the MAC lookups on the border routers seems to place > >>> a prety heavy load on them. > >> > >> Isn't that what is suggested by > draft-lasserre-vkompella-ppvpn-vpls-04.txt ? > >> > >> 10.3. Multi-domain VPLS service > >> > >> Hierarchy can also be used to create a large scale VPLS service > >> within a single domain or a service that spans multiple domains > >> without requiring full mesh connectivity between all VPLS capable > >> devices. Two fully meshed VPLS networks are connected together > >> using a single LSP tunnel between the VPLS gateway devices. A > >> single spoke pseudowire is setup per VPLS service to connect the two > >> domains together. The VPLS gateway device joins two VPLS services > >> together to form a single multi-domain VPLS service. The > >> requirements and functionality required from a VPLS gateway device > >> will be explained in a future version of this document. > >> > > > > What does inter-AS mean? Some providers have a lot of AS's. Does it mean > > across provider boundaries, administrative domains, does it involve security > > considerations? > > "inter-AS" means spanning more than one Autonomous System (AS). It > should cover both the case where the ASs belong to the same provider, > as well as to a group of providers. > > > Multi-domain VPLS is just to show that there is a way to connect metro areas > > (which is what the primary motivation that some providers gave us for that > > particular section). > > That is the *only* way documented so far in > draft-lasserre-vkompella-ppvpn-vpls-04.txt. And as I mentioned > before, it has fairly poor scaling properties due to (a) the need to > perform the MAC lookups on the border routers, and (b) the need to > run STP on a per VPLS basis for VPLSs that span multiple ASs. > > In fact, those familiar with BGP/MPLS VPNs (aka 2547 VPNs), and > specifically with the inter-AS support could notice that the inter-AS > support proposed in draft-lasserre-vkompella-ppvpn-vpls-04.txt is > analogous to the option (a) in Section 10 of 2547bis. In contrast > the inter-AS approach described in draft-kompella-ppvpn-vpls-01.txt > can support what is analogous to the option (c) in Section 10 of 2547bis, > which (as observed in 2547bis) is more scalable than option (a). > > Yakov. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 17:37: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 RAA15221 for ; Mon, 28 Apr 2003 17:37:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SLdll25250 for ; Mon, 28 Apr 2003 17:39:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SLdh614505 for ; Mon, 28 Apr 2003 17:39:43 -0400 (EDT) Date: Mon, 28 Apr 2003 17:37:19 -0400 (EDT) From: Siddharth Aanand X-X-Sender: saanand@boysenberry To: ppvpn@nortelnetworks.com Subject: Question regdg. MPLS/BGP VPN MIB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: saanand@pit.comms.marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely identify a row in this table ? Under what circumstances do we need both the vrfName as well as the ifIndex as keys? thanks, -Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 17:48:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15482 for ; Mon, 28 Apr 2003 17:48:51 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SLp7l00083 for ; Mon, 28 Apr 2003 17:51:07 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SLp2W24371 for ; Mon, 28 Apr 2003 17:51:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Question regdg. MPLS/BGP VPN MIB Date: Mon, 28 Apr 2003 14:48:46 -0700 Message-ID: Thread-Topic: Question regdg. MPLS/BGP VPN MIB Thread-Index: AcMNzniLtPFOyBM/QweBnEWfnmZ0LwAAR8aQ From: "Shiv Agarwal" To: "Siddharth Aanand" , X-SMTP-HELO: exch-srv.CoronaNetworks.com X-SMTP-MAIL-FROM: Shiv@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.219.34.104] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA15482 Without this additional index how else can you determine as to which interface is mapped to which VRF? Though if a VRF is modeled like a VR with a separate context, then this information may not be necessary as the VRF can then be determined by the SNMP context. Shiv. -----Original Message----- From: Siddharth Aanand [mailto:saanand@pit.comms.marconi.com] Sent: Monday, April 28, 2003 2:37 PM To: ppvpn@nortelnetworks.com Subject: Question regdg. MPLS/BGP VPN MIB The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely identify a row in this table ? Under what circumstances do we need both the vrfName as well as the ifIndex as keys? thanks, -Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 18:04: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 SAA15935 for ; Mon, 28 Apr 2003 18:04:25 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SM6gl16333 for ; Mon, 28 Apr 2003 18:06:42 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SM6ZP27128 for ; Mon, 28 Apr 2003 18:06:37 -0400 (EDT) Date: Mon, 28 Apr 2003 18:03:15 -0400 (EDT) From: Siddharth Aanand X-X-Sender: saanand@boysenberry To: Shiv Agarwal cc: ppvpn@nortelnetworks.com Subject: RE: Question regdg. MPLS/BGP VPN MIB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: saanand@pit.comms.marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Shiv, > > Without this additional index how else can you determine as to which > interface is mapped to which VRF? I am assuming that at the interface creation time it gets assigned to a VRF. For rest of the VPN related configuration (which is what this table seems to be used for), having the interface index is sufficient to determine the VRF as well. -Sidd > > Though if a VRF is modeled like a VR with a separate context, then this information may not be necessary as the VRF can then be determined by the SNMP context. > > Shiv. > > -----Original Message----- > From: Siddharth Aanand [mailto:saanand@pit.comms.marconi.com] > Sent: Monday, April 28, 2003 2:37 PM > To: ppvpn@nortelnetworks.com > Subject: Question regdg. MPLS/BGP VPN MIB > > > > The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had > was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > identify a row in this table ? Under what circumstances do we need both > the vrfName as well as the ifIndex as keys? > > thanks, > -Sidd > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 18:11: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 SAA16735 for ; Mon, 28 Apr 2003 18:11:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SMDol20593 for ; Mon, 28 Apr 2003 18:13:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SMDfP03761 for ; Mon, 28 Apr 2003 18:13:42 -0400 (EDT) Message-ID: From: "O'Connor, Don" To: "'mattsquire@acm.org'" , vkompella@timetra.com Cc: schultz@io.iol.unh.edu, "O'Connor, Don" , "'Serbest, Yetik'" , Cheng-Yin.Lee@alcatel.com, "'Rick Wilder'" , ppvpn@nortelnetworks.com, tony@jeffree.co.uk, mick_seaman@ieee.org, Gerard Goubert Subject: RE: IEEE 802.1ad and VPLS Date: Mon, 28 Apr 2003 17:06:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: fncimr02.fnc.fujitsu.com X-SMTP-MAIL-FROM: Don.OConnor@fnc.fujitsu.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: fncimr.fnc.fujitsu.com [168.127.0.4] X-LYRIS-Message-Id: For Hierarchical VPLS, draft-lasserre indicates that the MTU-s can support Q-in-Q. It would appear that the MTU-s could be a 802.1AD Provider Bridge or could contain a Provider Bridge component. The draft also indicates that LDP signaling can be used for distribution of Q tags. This raises the issue of how does the MPLS control plane interface with the 802.1AD control plane to support applications such as single ended provisioning? In theory the bridge function in draft-lasserre PE-rs could be a 802.1AD Provider Bridge. This is my perception of the "understanding" between of IETF PPVPN and IEEE 802.1. It would seem like the service interface (E-ISS in IEEE 802.1 terms) between the 802.1AD Provider Bridge function in the PE-rs and the LAN Emulation function defined by draft-lasserre should be jointly defined / agreed by IETF PPVPN and IEEE 802.1. There are other issues (e.g. bridge unlearn signaling) that should ideally be defined across these two groups, otherwise there could be multiple overlapping standards in the same area. My view is that: 1) draft-lasserre & other PPVPN working group drafts / eventual RFCs need future updates to be consistent with / mesh with 802.1AD 2) the final form of 802.1AD should correlate with PPVPN RFC(s) 3) More interaction is required between PPVPN and IEEE 802.1 on issues such as described above. I think this is potentially possible after: 1) PPVPN selects one or more drafts to progress as WG documents 2) IEEE 802.1AD adds more detail to the current draft. Don -----Original Message----- From: Matt Squire [mailto:mattsquire@acm.org] Sent: Monday, April 28, 2003 6:58 AM To: vkompella@timetra.com Cc: schultz@io.iol.unh.edu; O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com; 'Rick Wilder'; ppvpn@nortelnetworks.com; tony@jeffree.co.uk; mick_seaman@ieee.org; Gerard Goubert Subject: Re: IEEE 802.1ad and VPLS I apologize for jumping into this fray late, but I've been a wee bit behind in my email. The good thing about the current structure of the vkompella draft (IMHO) is that we can, at the end of the day, treat the VPLS like a LAN segment. So one could treat 802.1ad and VPLS independently, just as one can treat 802.1ad and Ethernet independently. 802.1ad can, at the edge, tunnel BPDUs over VPLS. As VPLS looks like a LAN segment to 802.1, it can tunnel BPDUs and other things over a VPLS. One can argue if thats a useful thing, but it can be done, as long as we continue with the VPLS=LAN model. As far as the orgnization between the groups, its unclear how much more is needed. Many people in 802.1 know whats happening in PPVPN, and vice-versa. As emulating LAN segments has been done in the past (ATM, FR, etc.), and there weren't really any 802.1 specific issues to deal with in the past, I don't expect there will be with VPLS unless we deviate from the model of LAN emulation. - Matt Vach Kompella wrote: > It's too early to say exactly how the pieces interact. Initial discussions with > members in the IEEE (particularly Mick Seaman, Norm Finn, Tony Jeffree, Matt > Squire) have shown that they think that draft-lasserre-vkompella can fit in the > IEEE model. On our side, the design team discussions have confirmed that. > > The IEEE believes it takes some definition on their part, which is what 802.1ad > is. Both 802.1ad and draft-lasserre-vkompella are "works in progress." The > IEEE has clearly gotten far enough that they got a draft0. We are still > deciding whether draft-lasserre-vkompella is a WG document or not. I'd say, > when we get past that stage in the IETF, we can ask for formal liaisons. > > That's why I've been pushing for IETF recognition that what we are working on > here in ppvpn is worth furthering. I don't think the process calls for > everything to be nailed down before the IETF recognizes the work as its own > rather than an individual contribution. > > As a final point, this has been a call to make draft-lasserre-vkompella a > working group document, nothing more. I (fondly) think that phase has been > achieved, but I'll wait for official confirmation from the chairs. > > -Vach > > >>-----Original Message----- >>From: schultz@io.iol.unh.edu [mailto:schultz@io.iol.unh.edu] >>Sent: Friday, April 18, 2003 9:17 AM >>To: Vach Kompella >>Cc: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com; >>mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; >>tony@jeffree.co.uk; mick_seaman@ieee.org; Gerard Goubert >>Subject: RE: IEEE 802.1ad and VPLS >> >> >> >>Vach, >> >>So is the plan here to come up with a 802.1ad solution and a separate >>ppvpn (L3 control plane) solution? Or is this ppvpn committee going to >>work with 802.1 to design a specific interoperable solution? These >>options are not mutually exclusive. >> >>I am unclear as to how this effort is being organized beyond norm finn's >>unofficial liason. >> >>Thanks, >>-Ben >> >>On Fri, 18 Apr 2003, Vach Kompella wrote: >> >> >>>I think we have agreed that tunneling BPDUs is going to be done. I >> >>think that >> >>>over and above that, it may be possible to use L3 control plane >> >>mechanisms to >> >>>assist the convergence. I'm only saying that it is possible that >> >>as we develop >> >>>some scenarios of customer and provider topologies, I don't want to >> >>assume that >> >>>the only solution lies in L2 protocols. >>> >>>-Vach >>> >>> >>>>-----Original Message----- >>>>From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] >>>>Sent: Friday, April 18, 2003 7:42 AM >>>>To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; >>>>Cheng-Yin.Lee@alcatel.com >>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com; >>>>'tony@jeffree.co.uk'; 'mick_seaman@ieee.org' >>>>Subject: RE: IEEE 802.1ad and VPLS >>>> >>>> >>>>Vach, >>>> >>>>Are you suggesting that customer BPDUs should not be tunneled through the >>>>provider VPLS network? If this is the case it would not be possible for >>>>customers to run STP across multiple sites interconnected by the VPLS >>>>network. >>>> >>>>I agree with your point that it may also be possible to use L3 >> >>signaling for >> >>>>MAC unlearn signaling especially for the case where bridging and MPLS are >>>>supported in the same NE. This is relevant to my question >> >>pertaining to how >> >>>>the L2 control plane interacts with the L3 control plane. >>>> >>>>I think it would be good to have a more formalized liaison >> >>structure between >> >>>>ppvpn and 802.1AD - maybe some common email >>>>list. >>>> >>>>Don >>>> >>>> >>>>-----Original Message----- >>>>From: Vach Kompella [mailto:vkompella@timetra.com] >>>>Sent: Thursday, April 17, 2003 6:20 PM >>>>To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com >>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>Subject: RE: IEEE 802.1ad and VPLS >>>> >>>> >>>>Dan, >>>> >>>>It isn't clear to me yet that the only reliable way to deal with >> >>L2 control >> >>>>protocol packets such as BPDUs is to pass them through the data >> >>plane of the >> >>>>VPLS. It is possible that one of the ways to deal with unlearns, e.g., is >>>>to >>>>use LDP messages, such as the MAC TLVs for specific or scoped >> >>unlearns. So, >> >>>>if >>>>"by reference" means that we don't assist the L2 solution with >> >>extensions to >> >>>>the >>>>VPLS signaling draft, then I disagree. If it means cooperative use of the >>>>L3 >>>>control plane with the IEEE work, I agree. Basically, we don't want to >>>>re-invent what is already there, but when we have L3 control plane methods >>>>available, it makes sense to figure out a division of work that makes the >>>>service work the best. >>>> >>>>From Clause 16 of the 802.1ad-d0 document: >>>>... (stuff dealing with a potential topology with loops) ... requires an >>>>IETF >>>>connection (see also suggested Clause 6.6 Support of the Internal Sublayer >>>>Service by IETF foo) and to deal with some of the 'loop through a >> >>customer' >> >>>>questions and the partial answers that we have to those. >>>> >>>>-Vach >>>> >>>> >>>>>-----Original Message----- >>>>>From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] >>>>>Sent: Thursday, April 17, 2003 3:55 PM >>>>>To: 'vkompella@timetra.com'; O'Connor, Don; 'Serbest, Yetik'; >>>>>Cheng-Yin.Lee@alcatel.com >>>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>>Subject: RE: IEEE 802.1ad and VPLS >>>>> >>>>> >>>>>Vach, >>>>> >>>>>To confirm the relationship with draft-lasserre - when 802.1AD defines >>>>>solutions for issues such as Provider Bridge customer BPDU snooping / >>>>>unlearn signaling (for customer STP reconfiguration with >> >>backdoors, etc) - >> >>>>>then this will be incorporated in draft-lasserre by reference. >> >>Is this an >> >>>>>accurate perception? >>>>> >>>>>One issue I have been wondering about with respect to 802.1AD & PPVPN / >>>>>draft-lasserre is for single ended L2 VPN >>>>>provisioning, where will the interface between the L2 Control Plane >>>> >>>>(defined >>>> >>>>>by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be >>>>>defined. >>>>> >>>>>Don >>>>> >>>>>-----Original Message----- >>>>>From: Vach Kompella [mailto:vkompella@timetra.com] >>>>>Sent: Thursday, April 17, 2003 5:06 PM >>>>>To: O'Connor, Don; 'Serbest, Yetik'; Cheng-Yin.Lee@alcatel.com >>>>>Cc: mattsquire@acm.org; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>>Subject: IEEE 802.1ad and VPLS >>>>> >>>>> >>>>>Dan, >>>>> >>>>>Yes it is. One of the items in the ppvpn-wg minutes (note the date >>>>>pre-dates >>>>>the official PAR date which is Dec. 31, 2002, so we (as IETF >> >>participants) >> >>>>>have >>>>>been keeping in touch with the IEEE, albeit informally) for the Atlanta >>>>>meeting >>>>>shows: >>>>> >>>>>=== clipped from minutes === >>>>>Norm Finn - IEEE 802.1 unofficial liaison >>>>>----------------------------------------- >>>>> >>>>>Project authorization request (amendment to 802.1q VLANs) - >> >>enable a SP to >> >>>>>offer the equivalent of separate LAN segments, bridged or >> >>virtual bridged >> >>>>>LANs (network of bridges doing l2vpn type services). >>>>> >>>>>Name of project - 802.1AD. >>>>>MAC-in-MAC not possible with this amendment. >>>>> >>>>>Confident that IETF L2vpn and 802.1AD will be interoperable, compatible >>>> >>>>etc >>>> >>>>>if mailing discussions are carried through. >>>>>=== end of clip === >>>>> >>>>>-Vach >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: O'Connor, Don [mailto:Don.OConnor@fnc.fujitsu.com] >>>>>>Sent: Thursday, April 17, 2003 1:54 PM >>>>>>To: 'Serbest, Yetik'; 'Cheng-Yin.Lee@alcatel.com' >>>>>>Cc: 'mattsquire@acm.org'; 'Rick Wilder'; ppvpn@nortelnetworks.com >>>>>>Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working >> >>group draft >> >>>>>> >>>>>>Yetik & Cheng-Yin, >>>>>> >>>>>>Isn't the PPVPN group in theory working with the 802.1AD >> >>Provider Bridge >> >>>>>>Group to define solutions for these issues. >>>>>> >>>>>>Regards, >>>>>> >>>>>>Don From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 18:16:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17180 for ; Mon, 28 Apr 2003 18:16:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SMIJl24015 for ; Mon, 28 Apr 2003 18:18:19 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3SMIDL08274 for ; Mon, 28 Apr 2003 18:18:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Question regdg. MPLS/BGP VPN MIB Date: Mon, 28 Apr 2003 15:10:36 -0700 Message-ID: Thread-Topic: Question regdg. MPLS/BGP VPN MIB Thread-Index: AcMN0g7QjO1H+40qS+W1SXtw4RBr9AAAMCCw From: "Shiv Agarwal" To: "Siddharth Aanand" Cc: X-SMTP-HELO: exch-srv.CoronaNetworks.com X-SMTP-MAIL-FROM: Shiv@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.219.34.104] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA17180 inline: -----Original Message----- From: Siddharth Aanand [mailto:saanand@pit.comms.marconi.com] Sent: Monday, April 28, 2003 3:03 PM To: Shiv Agarwal Cc: ppvpn@nortelnetworks.com Subject: RE: Question regdg. MPLS/BGP VPN MIB Shiv, > > Without this additional index how else can you determine as to which > interface is mapped to which VRF? >>I am assuming that at the interface creation time it gets assigned to a >>VRF. Shiv >> why is this necessary. you may just create an interface and not assign it to any VRF. >>For rest of the VPN related configuration (which is what this >>table seems to be used for), having the interface index is sufficient to >>determine the VRF as well. Shiv >> organizing it per VRF wise makes the management efficient. So if you want to find out all the interfaces that belong to a VRF, you can do a walk on this table with a partial index of that VRF and thus you don't have to scan the entire mib and do a search. There are other management advantages also. -Sidd > > Though if a VRF is modeled like a VR with a separate context, then this information may not be necessary as the VRF can then be determined by the SNMP context. > > Shiv. > > -----Original Message----- > From: Siddharth Aanand [mailto:saanand@pit.comms.marconi.com] > Sent: Monday, April 28, 2003 2:37 PM > To: ppvpn@nortelnetworks.com > Subject: Question regdg. MPLS/BGP VPN MIB > > > > The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had > was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > identify a row in this table ? Under what circumstances do we need both > the vrfName as well as the ifIndex as keys? > > thanks, > -Sidd > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 21:01:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20759 for ; Mon, 28 Apr 2003 21:01:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T13vl25503 for ; Mon, 28 Apr 2003 21:03:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T13pg02037 for ; Mon, 28 Apr 2003 21:03:51 -0400 (EDT) Message-ID: <006201c30dea$8e744a00$dcac0944@ri.cox.net> From: "Rick Osteen" To: "lidefeng" , , References: <003901c30ad7$901138c0$07436e0a@HUAWEI.COM> Subject: Re: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Mon, 28 Apr 2003 20:59:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: lakemtao03.cox.net X-SMTP-MAIL-FROM: rick.osteen@cox.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lakemtao03.cox.net [68.1.17.242] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Please remember, VPLS is "Cisco Centric". Their marketing department does a good job of placing a technological name/acronym onto a real name draft/technology. ----- Original Message ----- From: "lidefeng" To: ; Sent: Thursday, April 24, 2003 11:05 PM Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? > Hi,all, > > Could anyone please tell me the difference between the Ethernet Service > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > attached to VPLS when there is > need to access each other? And how to process mac learning,flooding address > unknows unicast,broadcast and multicast frames in PWE3? > > Regards > > Li Defeng > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 21:11:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20946 for ; Mon, 28 Apr 2003 21:11:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T1E8l28813 for ; Mon, 28 Apr 2003 21:14:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T1E4g07916 for ; Mon, 28 Apr 2003 21:14:04 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Rick Osteen" , "lidefeng" , , Subject: RE: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Mon, 28 Apr 2003 18:11:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <006201c30dea$8e744a00$dcac0944@ri.cox.net> X-OriginalArrivalTime: 29 Apr 2003 01:11:33.0360 (UTC) FILETIME=[45F47F00:01C30DEC] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick, I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra Networks) (along with a number of co-authors, not including cisco) wrote the original versions of VPLS. Those versions pre-date cisco's input. How do you come to the conclusion that VPLS is cisco-centric? If drafts are company-centric, then cisco shouldn't be the first one to spring to mind when you talk of VPLS. At least, not in my mind :-) Of course, some people have considerable marketing power... Every company wants to extract their marketing worth out of their employees' participation on drafts. But a draft presented at the IETF is NOT accepted as a company-centric draft; it is considered an individual submission until it is accepted as a working group document, and that with working group consensus. After that, it is the product of the working group. -Vach > -----Original Message----- > From: Rick Osteen [mailto:rick.osteen@cox.net] > Sent: Monday, April 28, 2003 5:59 PM > To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > Subject: Re: [PWE3] What is the difference between the Ethernet > Service in PWE3 and VPLS? > > > Please remember, VPLS is "Cisco Centric". Their marketing department does a > good job of placing a technological name/acronym onto a real name > draft/technology. > > > ----- Original Message ----- > From: "lidefeng" > To: ; > Sent: Thursday, April 24, 2003 11:05 PM > Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 > and VPLS? > > > > Hi,all, > > > > Could anyone please tell me the difference between the Ethernet > Service > > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > > attached to VPLS when there is > > need to access each other? And how to process mac learning,flooding > address > > unknows unicast,broadcast and multicast frames in PWE3? > > > > Regards > > > > Li Defeng > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 22:49:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22873 for ; Mon, 28 Apr 2003 22:49:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T2prl14486 for ; Mon, 28 Apr 2003 22:51:54 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T2poW18368 for ; Mon, 28 Apr 2003 22:51:50 -0400 (EDT) Date: Tue, 29 Apr 2003 10:49:24 +0800 From: lidefeng Subject: About draft-radoaca-ppvpn-gvpls-01.txt and draft-chen-ppvpn-dvpls-compare-01.txt To: ppvpn@nortelnetworks.com Message-id: <001f01c30df9$f1abece0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, In draft-radoaca-ppvpn-gvpls-01.txt,when control word is used(as mentioned in section 5.1.2 VSI-n of draft-chen-ppvpn-dvpls-compare-01.txt), the remote forwarding towards remote N-PE in the local N-PE is performed by splicing access PW corresponding to remote U-PE to core PW corresponding to the same remote U-PE-id,and local U-PE-id is added to control word,that is,take the U-PE-id as the SRC-CW-U-PE-ID field,however,U-PE-id is the is a 6-byte-long device id,and SRC-U-PE-ID represents the address of the originator U-PE deivece,is a 4-byte long IP address in IPv4,while the SRC-CW-U-PE-ID is 12 bits long,I wonder how to mapp these parameter in implementation. Could you please explain this questions? Thank you. Regards Li Defeng From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 23:29: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 XAA23449 for ; Mon, 28 Apr 2003 23:29:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T3W3l24255 for ; Mon, 28 Apr 2003 23:32:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T3VxO08736 for ; Mon, 28 Apr 2003 23:31:59 -0400 (EDT) Date: Tue, 29 Apr 2003 11:28:58 +0800 From: Du Wenhua Subject: Re: RE: [PWE3] What is the difference between the Ethernet Service in PWE3and VPLS? To: "vkompella@timetra.com" , Rick Osteen , lidefeng , "pwe3@ietf.org" , "ppvpn@nortelnetworks.com" Message-id: <0HE3002MD5MGAT@mta0.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23449 Hi, Vach Kompella I know Lasserre and you are the authors, and I suport HVPLS to become a working group draft. How do you think about the correspondence between a P-VLAN and a VPLS instance as follow? In setction 11 of the draft-lasserre-vkompella-ppvpn-vpls-04.txt, it say: * 11. Hierarchical VPLS model using Ethernet Access Network ..... * One approach of tunneling a customer?s Ethernet traffic via an * Ethernet access network is to add an additional VLAN tag to the * customer?s data (either tagged or untagged). The additional tag is * referred to as Provider?s VLAN (P-VLAN). Inside the provider?s * network each P-VLAN designates a customer or more specifically a VPLS ** instance for that customer. Therefore, there is a one to one ** correspondence between a P-VLAN and a VPLS instance. In my option, the last sentece in above is not true. There is also a many-to-one correspondence between a P-VLAN and a VPLS instance, not only a one-to-one. i.e, a customer with P-VLAN 3 and another customer with P-VLAN 4 belong to the same VPLS. Much more, to PE-rs the ethernet port is not a traditional standard port. When flooding, PE-rs need to send more than one copy for each ehternet port, because there are serveral custumers in one ethernet port each have different P-VLAN. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-04-29 At 18:11:00 2003-04-28, Vach Kompella wrote: >>Rick, > >I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra Networks) (along >with a number of co-authors, not including cisco) wrote the original versions of >VPLS. Those versions pre-date cisco's input. How do you come to the conclusion >that VPLS is cisco-centric? > >If drafts are company-centric, then cisco shouldn't be the first one to spring >to mind when you talk of VPLS. At least, not in my mind :-) Of course, some >people have considerable marketing power... > >Every company wants to extract their marketing worth out of their employees' >participation on drafts. But a draft presented at the IETF is NOT accepted as a >company-centric draft; it is considered an individual submission until it is >accepted as a working group document, and that with working group consensus. >After that, it is the product of the working group. > >-Vach > >> -----Original Message----- >> From: Rick Osteen [mailto:rick.osteen@cox.net] >> Sent: Monday, April 28, 2003 5:59 PM >> To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com >> Subject: Re: [PWE3] What is the difference between the Ethernet >> Service in PWE3 and VPLS? >> >> >> Please remember, VPLS is "Cisco Centric". Their marketing department does a >> good job of placing a technological name/acronym onto a real name >> draft/technology. >> >> >> ----- Original Message ----- >> From: "lidefeng" >> To: ; >> Sent: Thursday, April 24, 2003 11:05 PM >> Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 >> and VPLS? >> >> >> > Hi,all, >> > >> > Could anyone please tell me the difference between the Ethernet >> Service >> > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site >> > attached to VPLS when there is >> > need to access each other? And how to process mac learning,flooding >> address >> > unknows unicast,broadcast and multicast frames in PWE3? >> > >> > Regards >> > >> > Li Defeng >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> >> From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 23:44:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23728 for ; Mon, 28 Apr 2003 23:44:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T3kc728051 for ; Mon, 28 Apr 2003 23:46:38 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T3kXA14327 for ; Mon, 28 Apr 2003 23:46:34 -0400 (EDT) Date: Tue, 29 Apr 2003 11:44:05 +0800 From: lidefeng Subject: About draft-kompella-ppvpn-dtls-02.txt To: ppvpn@nortelnetworks.com Message-id: <002601c30e01$95acecc0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, In section "5.4. Packet Forwarding" of draft-kompella-ppvpn-dtls-02.txt,there is a paragraph illustrating an example,the figure and the forwarding procedure is as follows: " Figure 1 {A,0,k} <- +-------+ W -> +-------+ -> {A',0,k'} ============| PE X |<****************>| PE X' |=======[L2PE U'] | +-------+ W' <- +-------+ | announces {K,0,k} \ / announces {K',0,k'} | for L2PE U, site ID p\ / for L2PE U', site ID p' | .............. [L2PE U] . core . | .............. announces {L,0,l} for | announces {M,0,m} / \ L2PE V, site ID q | L2PE U, site ID r / announces \ -> {B,0,l} | +-------+ {L',0,l'} +-------+=======[ ] ============| PE Z | for L2PE V, | PE Y | [L2PE V] {C,0,m} <- +-------+ site ID q' +-------+=======[ ] -> {B',0,l'} Say an endpoint "behind" L2PE U decides to send a VPLS T packet to some endpoint "behind" L2PE U'. All L2PE U knows about L2PE U' is that its site ID is p', i.e., to send packets to L2PE U', L2PE U must use label (A+p') (how it arrives at this is described in the section on learning). The L2PE route at PE X states that the label (A+p') is swapped with (K'+p), and the packet is put in tunnel W to PE X'. When PE X' gets the packet, it removes the packet from the tunnel, and sees label (K'+p). PE X' swaps the label with (A'+p) per its L2PE route, and sends this packet to L2PE U'. Seeing label (A'+p), L2PE U' knows that the packet is a VPLS T packet which originated at L2PE U (i.e., the L2PE with site ID p). " What I am concerned is when the packet of the subtended customer site arrivs the local PE and is sent from the PE to L2PE,if the label is carried in the packet? From the above example,the packet is labeled,if so,then the label should be assigned and distributed by L2PE to PE,but in the above example,the label is assigned and distributed by PE to L2PE(the label A'+p is assigned by PE X' to L2PE U').If this procedure is somewhat incorrect? Could anyone please clarify this question? Thanks very much! Li Defeng From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Apr 28 23:50:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23874 for ; Mon, 28 Apr 2003 23:50:47 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T3r5701739 for ; Mon, 28 Apr 2003 23:53:06 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T3r2A18979 for ; Mon, 28 Apr 2003 23:53:02 -0400 (EDT) Reply-To: From: "Vach Kompella" To: , "Rick Osteen" , "lidefeng" , , Subject: RE: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Mon, 28 Apr 2003 20:50:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: X-OriginalArrivalTime: 29 Apr 2003 03:50:04.0860 (UTC) FILETIME=[6B4037C0:01C30E02] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit That was a little brusque. Individuals who work for TiMetra, Riverstone, PacketExchange, cisco, Hatteras, SBC, Masergy, Level3, and some who are true individual contributors, have assisted and in very helpful ways. I object to it being called cisco-centric. One hopes that the IETF doesn't descend to drafts being company-centric. -Vach > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Monday, April 28, 2003 6:12 PM > To: Rick Osteen; lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > Subject: RE: [PWE3] What is the difference between the Ethernet > Service in PWE3 and VPLS? > > > Rick, > > I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra Networks) (along > with a number of co-authors, not including cisco) wrote the original > versions of > VPLS. Those versions pre-date cisco's input. How do you come to the > conclusion > that VPLS is cisco-centric? > > If drafts are company-centric, then cisco shouldn't be the first one to spring > to mind when you talk of VPLS. At least, not in my mind :-) Of course, some > people have considerable marketing power... > > Every company wants to extract their marketing worth out of their employees' > participation on drafts. But a draft presented at the IETF is NOT > accepted as a > company-centric draft; it is considered an individual submission until it is > accepted as a working group document, and that with working group consensus. > After that, it is the product of the working group. > > -Vach > > > -----Original Message----- > > From: Rick Osteen [mailto:rick.osteen@cox.net] > > Sent: Monday, April 28, 2003 5:59 PM > > To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > > Subject: Re: [PWE3] What is the difference between the Ethernet > > Service in PWE3 and VPLS? > > > > > > Please remember, VPLS is "Cisco Centric". Their marketing department does a > > good job of placing a technological name/acronym onto a real name > > draft/technology. > > > > > > ----- Original Message ----- > > From: "lidefeng" > > To: ; > > Sent: Thursday, April 24, 2003 11:05 PM > > Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 > > and VPLS? > > > > > > > Hi,all, > > > > > > Could anyone please tell me the difference between the Ethernet > > Service > > > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > > > attached to VPLS when there is > > > need to access each other? And how to process mac learning,flooding > > address > > > unknows unicast,broadcast and multicast frames in PWE3? > > > > > > Regards > > > > > > Li Defeng > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 04:56: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 EAA10488 for ; Tue, 29 Apr 2003 04:56:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T8wW711525 for ; Tue, 29 Apr 2003 04:58:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T8wPI06692 for ; Tue, 29 Apr 2003 04:58:26 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt x-mimeole: Produced By Microsoft Exchange V6.0.6318.0 Date: Tue, 29 Apr 2003 10:53:45 +0200 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE8DB7E30@TMS031MB.tcad.telia.se> Thread-Topic: Support for draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMNkpYQ3J6SirZGQDKHe6Mtns39tAAmi+qg From: To: Cc: X-OriginalArrivalTime: 29 Apr 2003 08:54:18.0169 (UTC) FILETIME=[EB122290:01C30E2C] X-SMTP-HELO: tms001bb.han.telia.se X-SMTP-MAIL-FROM: Andreas.Mattsson@teliasonera.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tms001bb.han.telia.se [131.115.230.132] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA10488 Hi Eric As I understand it a requirement would be to have a full mesh of LDP sessions between the PEs in the participating AS domains. This means configuration of each PE when for example a new site is added to an already existing VPN. If BGP is used this is not necessary as RRs can be used, minimizing the configuration to the new PE and the RR. But perhaps there exist a solution similar to this for LDP as well? It seems appealing to reuse the 2547bis structure we have also for VPLS if it's possible. My point is that further investigation of the two different solutions before rejecting one or the other would be good /Andreas -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: den 28 april 2003 16:29 To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 Cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Andreas> I would also like to know how inter-AS with the LDP Andreas> approach in lasserre-vkompella is to be solved. Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 05:26:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10860 for ; Tue, 29 Apr 2003 05:26:05 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3T9SN725951 for ; Tue, 29 Apr 2003 05:28:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3T9SIE07272 for ; Tue, 29 Apr 2003 05:28:19 -0400 (EDT) Message-ID: <3EAE451C.C308E6AA@cisco.com> Date: Tue, 29 Apr 2003 11:25:48 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andreas.Mattsson@teliasonera.com CC: erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: <7B64D9FB62EB42449683BA51E9AB2AE8DB7E30@TMS031MB.tcad.telia.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Andres, AFAIK there is no need to configure anything rather then a site interface on the PEs. Autodiscovery will detect new addition and propagate the news to all participants. Then in the lasserre-vkompella scheme directed LDP if not already set get's automatically established between parties. Of course the drawback here is that you need to keep LDP ports open wide within inter-AS LDP src ranges which may or may not be an acceptable issue :-). R. > Andreas.Mattsson@teliasonera.com wrote: > > Hi Eric > > As I understand it a requirement would be to have a full mesh of LDP > sessions between the PEs in the participating AS domains. This means > configuration of each PE when for example a new site is added to an > already existing VPN. If BGP is used this is not necessary as RRs can be > used, minimizing the configuration to the new PE and the RR. > But perhaps there exist a solution similar to this for LDP as well? It > seems appealing to reuse the 2547bis structure we have also for VPLS if > it's possible. > > My point is that further investigation of the two different solutions > before rejecting one or the other would be good > > /Andreas > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: den 28 april 2003 16:29 > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > Cc: ppvpn@nortelnetworks.com > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > Andreas> I would also like to know how inter-AS with the LDP > Andreas> approach in lasserre-vkompella is to be solved. > > Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 06:55:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12006 for ; Tue, 29 Apr 2003 06:55:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TAvO716621 for ; Tue, 29 Apr 2003 06:57:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TAvK623137 for ; Tue, 29 Apr 2003 06:57:20 -0400 (EDT) Message-ID: <003601c30e3d$a74644e0$dcac0944@ri.cox.net> From: "Rick Osteen" To: , "lidefeng" , , References: Subject: Re: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? Date: Tue, 29 Apr 2003 06:54:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: lakemtao01.cox.net X-SMTP-MAIL-FROM: rick.osteen@cox.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lakemtao01.cox.net [68.1.17.244] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit All, My apologies. I suppose I've been to one too many presentations and did not intend to stir trouble. Thanks, Rick Osteen ----- Original Message ----- From: "Vach Kompella" To: ; "Rick Osteen" ; "lidefeng" ; ; Sent: Monday, April 28, 2003 11:50 PM Subject: RE: [PWE3] What is the difference between the Ethernet Service in PWE3 and VPLS? > That was a little brusque. Individuals who work for TiMetra, Riverstone, > PacketExchange, cisco, Hatteras, SBC, Masergy, Level3, and some who are true > individual contributors, have assisted and in very helpful ways. I object to it > being called cisco-centric. One hopes that the IETF doesn't descend to drafts > being company-centric. > > -Vach > > > -----Original Message----- > > From: Vach Kompella [mailto:vkompella@timetra.com] > > Sent: Monday, April 28, 2003 6:12 PM > > To: Rick Osteen; lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > > Subject: RE: [PWE3] What is the difference between the Ethernet > > Service in PWE3 and VPLS? > > > > > > Rick, > > > > I beg to differ. Marc Lasserre (Riverstone) and I (TiMetra Networks) (along > > with a number of co-authors, not including cisco) wrote the original > > versions of > > VPLS. Those versions pre-date cisco's input. How do you come to the > > conclusion > > that VPLS is cisco-centric? > > > > If drafts are company-centric, then cisco shouldn't be the first one to spring > > to mind when you talk of VPLS. At least, not in my mind :-) Of course, some > > people have considerable marketing power... > > > > Every company wants to extract their marketing worth out of their employees' > > participation on drafts. But a draft presented at the IETF is NOT > > accepted as a > > company-centric draft; it is considered an individual submission until it is > > accepted as a working group document, and that with working group consensus. > > After that, it is the product of the working group. > > > > -Vach > > > > > -----Original Message----- > > > From: Rick Osteen [mailto:rick.osteen@cox.net] > > > Sent: Monday, April 28, 2003 5:59 PM > > > To: lidefeng; pwe3@ietf.org; ppvpn@nortelnetworks.com > > > Subject: Re: [PWE3] What is the difference between the Ethernet > > > Service in PWE3 and VPLS? > > > > > > > > > Please remember, VPLS is "Cisco Centric". Their marketing department does a > > > good job of placing a technological name/acronym onto a real name > > > draft/technology. > > > > > > > > > ----- Original Message ----- > > > From: "lidefeng" > > > To: ; > > > Sent: Thursday, April 24, 2003 11:05 PM > > > Subject: [PWE3] What is the difference between the Ethernet Service in PWE3 > > > and VPLS? > > > > > > > > > > Hi,all, > > > > > > > > Could anyone please tell me the difference between the Ethernet > > > Service > > > > in PWE3 and VPLS,how to interoperte the site attached to PWE3 and the site > > > > attached to VPLS when there is > > > > need to access each other? And how to process mac learning,flooding > > > address > > > > unknows unicast,broadcast and multicast frames in PWE3? > > > > > > > > Regards > > > > > > > > Li Defeng > > > > > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 07:55:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13691 for ; Tue, 29 Apr 2003 07:55:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TBwE710969 for ; Tue, 29 Apr 2003 07:58:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TBwAV27689 for ; Tue, 29 Apr 2003 07:58:11 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A14649701494990@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com Cc: erosen@cisco.com, ppvpn@nortelnetworks.com Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 13:55:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E46.2D77EE80" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30E46.2D77EE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robert et al. As you hinted here, MP-BGP is much more designed for a *public* = inter-AS session for VPLS. Even if LDP/RSVP already present for the forwarding plane inside a MPLS domain, why should i used LDP for VPLS signalling when BGP already do = the job (IPv4,v6,rfc2547bis,...)??? Mourad -----Message d'origine----- De : Robert Raszuk [mailto:raszuk@cisco.com] Envoy=E9 : mardi 29 avril 2003 11:26 =C0 : Andreas.Mattsson@teliasonera.com Cc : erosen@cisco.com; ppvpn@nortelnetworks.com Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt Andres, AFAIK there is no need to configure anything rather then a site interface on the PEs. Autodiscovery will detect new addition and propagate the news to all participants. Then in the lasserre-vkompella scheme directed LDP if not already set get's automatically established between parties.=20 Of course the drawback here is that you need to keep LDP ports open = wide within inter-AS LDP src ranges which may or may not be an acceptable issue :-). R. > Andreas.Mattsson@teliasonera.com wrote: >=20 > Hi Eric >=20 > As I understand it a requirement would be to have a full mesh of LDP > sessions between the PEs in the participating AS domains. This means > configuration of each PE when for example a new site is added to an > already existing VPN. If BGP is used this is not necessary as RRs can = be > used, minimizing the configuration to the new PE and the RR. > But perhaps there exist a solution similar to this for LDP as well? = It > seems appealing to reuse the 2547bis structure we have also for VPLS = if > it's possible. >=20 > My point is that further investigation of the two different solutions > before rejecting one or the other would be good >=20 > /Andreas >=20 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: den 28 april 2003 16:29 > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > Cc: ppvpn@nortelnetworks.com > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt >=20 > Andreas> I would also like to know how inter-AS with the LDP > Andreas> approach in lasserre-vkompella is to be solved. >=20 > Could you say what the issue is that you think needs to be solved? ------_=_NextPart_001_01C30E46.2D77EE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

Robert et al.

As you hinted here, MP-BGP is much more designed for = a *public* inter-AS session for VPLS.

Even if LDP/RSVP already present for the forwarding = plane inside a MPLS domain, why should i used LDP for VPLS signalling = when BGP already do the job (IPv4,v6,rfc2547bis,...)???

Mourad


-----Message d'origine-----
De : Robert Raszuk [mailto:raszuk@cisco.com]
Envoy=E9 : mardi 29 avril 2003 11:26
=C0 : Andreas.Mattsson@teliasonera.com
Cc : erosen@cisco.com; = ppvpn@nortelnetworks.com
Objet : Re: Support for = draft-kompella-ppvpn-vpls-01.txt


Andres,

AFAIK there is no need to configure anything rather = then a site
interface on the PEs. Autodiscovery will detect new = addition and
propagate the news to all participants. Then in the = lasserre-vkompella
scheme directed LDP if not already set get's = automatically established
between parties.

Of course the drawback here is that you need to keep = LDP ports open wide
within inter-AS LDP src ranges which may or may not = be an acceptable
issue :-).

R.

> Andreas.Mattsson@teliasonera.com wrote:
>
> Hi Eric
>
> As I understand it a requirement would be to = have a full mesh of LDP
> sessions between the PEs in the participating = AS domains. This means
> configuration of each PE when for example a new = site is added to an
> already existing VPN. If BGP is used this is = not necessary as RRs can be
> used, minimizing the configuration to the new = PE and the RR.
> But perhaps there exist a solution similar to = this for LDP as well? It
> seems appealing to reuse the 2547bis structure = we have also for VPLS if
> it's possible.
>
> My point is that further investigation of the = two different solutions
> before rejecting one or the other would be = good
>
> /Andreas
>
> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: den 28 april 2003 16:29
> To: Mattsson, Andreas A. /Research /08-713 81 = 86, 070-618 67 67
> Cc: ppvpn@nortelnetworks.com
> Subject: Re: Support for = draft-kompella-ppvpn-vpls-01.txt
>
> Andreas> I would  also like to  = know how inter-AS  with the LDP
> Andreas> approach in lasserre-vkompella is = to be solved.
>
> Could you say what the issue is that you think = needs to be solved?

------_=_NextPart_001_01C30E46.2D77EE80-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 08: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 IAA14140 for ; Tue, 29 Apr 2003 08:10:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TCCa702096 for ; Tue, 29 Apr 2003 08:12:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TCCWg27609 for ; Tue, 29 Apr 2003 08:12:32 -0400 (EDT) Message-ID: <011101c30e47$24b2a460$03c7380a@duckettm> From: "Mike Duckett \(Dotnet\)" To: References: <7B64D9FB62EB42449683BA51E9AB2AE8DB7E30@TMS031MB.tcad.telia.se> Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 08:02:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: imf56bis.bellsouth.net X-SMTP-MAIL-FROM: mduckett@bellsouth.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail142.mail.bellsouth.net [205.152.58.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit To determine which approach is better, we need to have a generally accepted problem definition (a.k.a., requirements). With a robust set of present and forward looking requirements, we can make better decisions. Which draft represents a consensus relative to L2VPN (PWS[Frame Relay, .,.,*],VPLS) requirements? Is draft-augustyn-ppvpn-l2vpn-requirements-00.txt representative of the problem space? I am personally interested in a solution (where the solution has a minimal number of unique protocols) that not only addresses VPLS but also supports many AC types (e.g,. Frame Relay) and robust capabilities signalling/negotiation. IOW, a solution optimized for VPLS that is not suited for point to point is not desirable. Step one should be gaining agreement on requirements. Should we move to accept a single or small number of requirements documents? Did I miss this event? ----- Original Message ----- From: To: Cc: Sent: Tuesday, April 29, 2003 4:53 AM Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Hi Eric As I understand it a requirement would be to have a full mesh of LDP sessions between the PEs in the participating AS domains. This means configuration of each PE when for example a new site is added to an already existing VPN. If BGP is used this is not necessary as RRs can be used, minimizing the configuration to the new PE and the RR. But perhaps there exist a solution similar to this for LDP as well? It seems appealing to reuse the 2547bis structure we have also for VPLS if it's possible. My point is that further investigation of the two different solutions before rejecting one or the other would be good /Andreas -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: den 28 april 2003 16:29 To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 Cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Andreas> I would also like to know how inter-AS with the LDP Andreas> approach in lasserre-vkompella is to be solved. Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 08:21:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14357 for ; Tue, 29 Apr 2003 08:21:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TCNo708530 for ; Tue, 29 Apr 2003 08:23:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TCNkl06465 for ; Tue, 29 Apr 2003 08:23:47 -0400 (EDT) Message-ID: <3EAE6DBD.D0CB502F@alcatel.be> Date: Tue, 29 Apr 2003 14:19:09 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mourad BERKANE Cc: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: <8D91FF5277472A45A0A8F9654A14649701494990@frlnparexcha03.lambdanet.fr> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2003 14:19:10, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2003 14:19:11 Content-Type: text/plain; charset=iso-8859-1 X-SMTP-HELO: bt0rjw.god.bel.alcatel.be X-SMTP-MAIL-FROM: jeremy.de_clercq@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc240.alcatel.be [195.207.101.240] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA14357 Mourad, > As you hinted here, MP-BGP is much more designed for a *public* > inter-AS session for VPLS. I still don't understand why MP-BGP is more appropriate than LDP for this application. I probably need more than a "hint" to fully understand it ;-) > Even if LDP/RSVP already present for the forwarding plane inside a > MPLS domain, why should i used LDP for VPLS signalling when BGP > already do the job (IPv4,v6,rfc2547bis,...)??? You can turn this around: Even if BGP is already present for 2547bis, v4, v6 etc, why should I use BGP for VPLS signaling when LDP already does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 Pseudo-Wires, ...) ? [I guess the answer to both of the above questions is given in the large number of previous emails on this topic ;-)] Jeremy. > Mourad > > -----Message d'origine----- > De : Robert Raszuk [mailto:raszuk@cisco.com] > Envoyé : mardi 29 avril 2003 11:26 > À : Andreas.Mattsson@teliasonera.com > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > Andres, > > AFAIK there is no need to configure anything rather then a site > interface on the PEs. Autodiscovery will detect new addition and > propagate the news to all participants. Then in the lasserre-vkompella > > scheme directed LDP if not already set get's automatically established > > between parties. > > Of course the drawback here is that you need to keep LDP ports open > wide > within inter-AS LDP src ranges which may or may not be an acceptable > issue :-). > > R. > > > Andreas.Mattsson@teliasonera.com wrote: > > > > Hi Eric > > > > As I understand it a requirement would be to have a full mesh of LDP > > > sessions between the PEs in the participating AS domains. This means > > > configuration of each PE when for example a new site is added to an > > already existing VPN. If BGP is used this is not necessary as RRs > can be > > used, minimizing the configuration to the new PE and the RR. > > But perhaps there exist a solution similar to this for LDP as well? > It > > seems appealing to reuse the 2547bis structure we have also for VPLS > if > > it's possible. > > > > My point is that further investigation of the two different > solutions > > before rejecting one or the other would be good > > > > /Andreas > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: den 28 april 2003 16:29 > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Andreas> I would also like to know how inter-AS with the LDP > > Andreas> approach in lasserre-vkompella is to be solved. > > > > Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 08:23:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14440 for ; Tue, 29 Apr 2003 08:23:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TCQE711197 for ; Tue, 29 Apr 2003 08:26:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TCQAl09393 for ; Tue, 29 Apr 2003 08:26:10 -0400 (EDT) Message-ID: <3EAE6E6A.E0F1609C@cisco.com> Date: Tue, 29 Apr 2003 14:22:02 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mourad BERKANE CC: Andreas.Mattsson@teliasonera.com, erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: <8D91FF5277472A45A0A8F9654A14649701494990@frlnparexcha03.lambdanet.fr> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-2.cisco.com id h3TCM7UK027159 X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14440 Well I am taking a higher level view and honestly I am not biased towards either BGP or LDP used for signaling. In fact as I said both should proceed forward especially in the VPLS application. Now reg your comment that BGP is more designed for a public inter-as I can only agree ;). Coming very soon for BGP MD5 key exchanges improvements for operators making something hard to exchange today will be much easier tomorrow. With LDP any serious deployment should consider MD5 and correlation of all the keys on ALL of your and your peers PEs will be by all means much more challenging exercise :). Using blank directed LDP without protection could be fine within AS but inter-as (even to your trusted peer ... I don't know). And of course fact that you run LDP for regular forwarding or not is pretty much orthogonal to the exercise here. Cheers, R. > Mourad BERKANE wrote: > > Robert et al. > > As you hinted here, MP-BGP is much more designed for a *public* > inter-AS session for VPLS. > > Even if LDP/RSVP already present for the forwarding plane inside a > MPLS domain, why should i used LDP for VPLS signalling when BGP > already do the job (IPv4,v6,rfc2547bis,...)??? > > Mourad > > -----Message d'origine----- > De : Robert Raszuk [mailto:raszuk@cisco.com] > Envoyé : mardi 29 avril 2003 11:26 > À : Andreas.Mattsson@teliasonera.com > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > Andres, > > AFAIK there is no need to configure anything rather then a site > interface on the PEs. Autodiscovery will detect new addition and > propagate the news to all participants. Then in the lasserre-vkompella > > scheme directed LDP if not already set get's automatically established > > between parties. > > Of course the drawback here is that you need to keep LDP ports open > wide > within inter-AS LDP src ranges which may or may not be an acceptable > issue :-). > > R. > > > Andreas.Mattsson@teliasonera.com wrote: > > > > Hi Eric > > > > As I understand it a requirement would be to have a full mesh of LDP > > > sessions between the PEs in the participating AS domains. This means > > > configuration of each PE when for example a new site is added to an > > already existing VPN. If BGP is used this is not necessary as RRs > can be > > used, minimizing the configuration to the new PE and the RR. > > But perhaps there exist a solution similar to this for LDP as well? > It > > seems appealing to reuse the 2547bis structure we have also for VPLS > if > > it's possible. > > > > My point is that further investigation of the two different > solutions > > before rejecting one or the other would be good > > > > /Andreas > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: den 28 april 2003 16:29 > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Andreas> I would also like to know how inter-AS with the LDP > > Andreas> approach in lasserre-vkompella is to be solved. > > > > Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 08:38: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 IAA14806 for ; Tue, 29 Apr 2003 08:38:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TCed717441 for ; Tue, 29 Apr 2003 08:40:39 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TCeZZ15976 for ; Tue, 29 Apr 2003 08:40:35 -0400 (EDT) Message-ID: <013b01c30e4b$61ee2940$03c7380a@duckettm> From: "Mike Duckett \(Dotnet\)" To: References: <8D91FF5277472A45A0A8F9654A14649701494990@frlnparexcha03.lambdanet.fr> Subject: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 08:32:22 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0138_01C30E29.DACECDA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: imf38bis.bellsouth.net X-SMTP-MAIL-FROM: mduckett@bellsouth.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail121.mail.bellsouth.net [205.152.58.61] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0138_01C30E29.DACECDA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txtMourad, You have asked THE question. What problems do we need to solve that = drive us to a something that BGP cannot perform? Is BGP sufficiently = robust that we believe future unknowns can be sufficiently addressed = (intentionally vague)? Are there capabilities that require protracted = negotiation specific to a limited set (e.g., a pair) of PEs? =20 ----- Original Message -----=20 From: Mourad BERKANE=20 To: 'raszuk@cisco.com' ; Andreas.Mattsson@teliasonera.com=20 Cc: erosen@cisco.com ; ppvpn@nortelnetworks.com=20 Sent: Tuesday, April 29, 2003 7:55 AM Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Robert et al.=20 As you hinted here, MP-BGP is much more designed for a *public* = inter-AS session for VPLS.=20 Even if LDP/RSVP already present for the forwarding plane inside a = MPLS domain, why should i used LDP for VPLS signalling when BGP already = do the job (IPv4,v6,rfc2547bis,...)??? Mourad=20 -----Message d'origine-----=20 De : Robert Raszuk [mailto:raszuk@cisco.com]=20 Envoy=E9 : mardi 29 avril 2003 11:26=20 =C0 : Andreas.Mattsson@teliasonera.com=20 Cc : erosen@cisco.com; ppvpn@nortelnetworks.com=20 Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 Andres,=20 AFAIK there is no need to configure anything rather then a site=20 interface on the PEs. Autodiscovery will detect new addition and=20 propagate the news to all participants. Then in the lasserre-vkompella = scheme directed LDP if not already set get's automatically established = between parties.=20 Of course the drawback here is that you need to keep LDP ports open = wide=20 within inter-AS LDP src ranges which may or may not be an acceptable=20 issue :-).=20 R.=20 > Andreas.Mattsson@teliasonera.com wrote:=20 >=20 > Hi Eric=20 >=20 > As I understand it a requirement would be to have a full mesh of LDP = > sessions between the PEs in the participating AS domains. This means = > configuration of each PE when for example a new site is added to an=20 > already existing VPN. If BGP is used this is not necessary as RRs = can be=20 > used, minimizing the configuration to the new PE and the RR.=20 > But perhaps there exist a solution similar to this for LDP as well? = It=20 > seems appealing to reuse the 2547bis structure we have also for VPLS = if=20 > it's possible.=20 >=20 > My point is that further investigation of the two different = solutions=20 > before rejecting one or the other would be good=20 >=20 > /Andreas=20 >=20 > -----Original Message-----=20 > From: Eric Rosen [mailto:erosen@cisco.com]=20 > Sent: den 28 april 2003 16:29=20 > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67=20 > Cc: ppvpn@nortelnetworks.com=20 > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 >=20 > Andreas> I would also like to know how inter-AS with the LDP=20 > Andreas> approach in lasserre-vkompella is to be solved.=20 >=20 > Could you say what the issue is that you think needs to be solved?=20 ------=_NextPart_000_0138_01C30E29.DACECDA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for = draft-kompella-ppvpn-vpls-01.txt
Mourad,
 
You have asked THE question.  What = problems do=20 we need to solve that drive us to a something that BGP cannot=20 perform?   Is BGP sufficiently robust that we believe future = unknowns=20 can be sufficiently addressed (intentionally vague)?  Are there=20 capabilities that require protracted negotiation specific to a limited = set=20 (e.g., a pair) of PEs? 
 
 
 
----- Original Message -----
From:=20 Mourad BERKANE
To: 'raszuk@cisco.com' ; Andreas.Mattsson@teliaso= nera.com=20
Cc: erosen@cisco.com ; ppvpn@nortelnetworks.com =
Sent: Tuesday, April 29, 2003 = 7:55=20 AM
Subject: RE: Support for=20 draft-kompella-ppvpn-vpls-01.txt


Robert et al.

As you hinted here, MP-BGP is much more designed for = a=20 *public* inter-AS session for VPLS.

Even if LDP/RSVP already present for the forwarding = plane=20 inside a MPLS domain, why should i used LDP for VPLS signalling when = BGP=20 already do the job (IPv4,v6,rfc2547bis,...)???

Mourad


-----Message d'origine-----
De :=20 Robert Raszuk [mailto:raszuk@cisco.com] =
Envoy=E9 : mardi 29 avril 2003 11:26
=C0 : Andreas.Mattsson@teliaso= nera.com=20
Cc : erosen@cisco.com;=20 ppvpn@nortelnetworks.com=20
Objet : Re: Support for=20 draft-kompella-ppvpn-vpls-01.txt


Andres,

AFAIK there is no need to configure anything rather = then a=20 site
interface on the PEs. Autodiscovery = will detect=20 new addition and
propagate the news to all=20 participants. Then in the lasserre-vkompella
scheme=20 directed LDP if not already set get's automatically established =
between parties.

Of course the drawback here is that you need to keep = LDP ports=20 open wide
within inter-AS LDP src ranges = which may or=20 may not be an acceptable
issue :-). =

R.

> Andreas.Mattsson@teliasonera.com wrote: =
>
> Hi Eric
>=20
> As I understand it a requirement would = be to have=20 a full mesh of LDP
> sessions between the = PEs in=20 the participating AS domains. This means
>=20 configuration of each PE when for example a new site is added to = an=20
> already existing VPN. If BGP is used this is = not=20 necessary as RRs can be
> used, = minimizing the=20 configuration to the new PE and the RR.
> = But=20 perhaps there exist a solution similar to this for LDP as well? = It=20
> seems appealing to reuse the 2547bis structure = we have=20 also for VPLS if
> it's possible. =
>
> My point is that further=20 investigation of the two different solutions
>=20 before rejecting one or the other would be good
>=20
> /Andreas
> =
> -----Original Message----- =
> From: Eric Rosen [mailto:erosen@cisco.com] =
> Sent: den 28 april 2003 16:29
> To:=20 Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 =
> Cc: ppvpn@nortelnetworks.com
> Subject:=20 Re: Support for draft-kompella-ppvpn-vpls-01.txt
>=20
> Andreas> I would  also like = to  know=20 how inter-AS  with the LDP
> = Andreas>=20 approach in lasserre-vkompella is to be solved.
>=20
> Could you say what the issue is that = you think=20 needs to be solved?

------=_NextPart_000_0138_01C30E29.DACECDA0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 08:42: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 IAA14931 for ; Tue, 29 Apr 2003 08:42:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TCj2721582 for ; Tue, 29 Apr 2003 08:45:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TCj0Z20533 for ; Tue, 29 Apr 2003 08:45:00 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A14649701494991@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'jeremy.de_clercq@alcatel.be'" Cc: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, erosen@cisco.com, ppvpn@nortelnetworks.com Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 14:42:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E4C.C2B98F70" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30E4C.C2B98F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeremy, LDP is not used as a signaling protocol for IPv4, IPv6 or rfc2547bis = :-) BGP is in charge of it (and do the job very well). May be this will clarify all theses exchanges about signalling in VPLS: adding a new signaling protocol (LDP) whitout any added value versus = keeping the same signalling protocol (BGP) for differents services (IP,rfc2547bis,VPLS, futures needs) You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling = (LDP or BGP)? Mourad -----Message d'origine----- De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] Envoy=E9 : mardi 29 avril 2003 14:19 =C0 : Mourad BERKANE Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; erosen@cisco.com; ppvpn@nortelnetworks.com Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt Mourad, > As you hinted here, MP-BGP is much more designed for a *public* > inter-AS session for VPLS. I still don't understand why MP-BGP is more appropriate than LDP for this application. I probably need more than a "hint" to fully = understand it ;-) > Even if LDP/RSVP already present for the forwarding plane inside a > MPLS domain, why should i used LDP for VPLS signalling when BGP > already do the job (IPv4,v6,rfc2547bis,...)??? You can turn this around: Even if BGP is already present for 2547bis, v4, v6 etc, why should I use BGP for VPLS signaling when LDP already does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 Pseudo-Wires, ...) ? [I guess the answer to both of the above questions is given in the = large number of previous emails on this topic ;-)] Jeremy. > Mourad >=20 > -----Message d'origine----- > De : Robert Raszuk [mailto:raszuk@cisco.com] > Envoy=E9 : mardi 29 avril 2003 11:26 > =C0 : Andreas.Mattsson@teliasonera.com > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt >=20 > Andres, >=20 > AFAIK there is no need to configure anything rather then a site > interface on the PEs. Autodiscovery will detect new addition and > propagate the news to all participants. Then in the = lasserre-vkompella >=20 > scheme directed LDP if not already set get's automatically = established >=20 > between parties. >=20 > Of course the drawback here is that you need to keep LDP ports open > wide > within inter-AS LDP src ranges which may or may not be an acceptable > issue :-). >=20 > R. >=20 > > Andreas.Mattsson@teliasonera.com wrote: > > > > Hi Eric > > > > As I understand it a requirement would be to have a full mesh of = LDP >=20 > > sessions between the PEs in the participating AS domains. This = means >=20 > > configuration of each PE when for example a new site is added to an > > already existing VPN. If BGP is used this is not necessary as RRs > can be > > used, minimizing the configuration to the new PE and the RR. > > But perhaps there exist a solution similar to this for LDP as well? > It > > seems appealing to reuse the 2547bis structure we have also for = VPLS > if > > it's possible. > > > > My point is that further investigation of the two different > solutions > > before rejecting one or the other would be good > > > > /Andreas > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: den 28 april 2003 16:29 > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > Cc: ppvpn@nortelnetworks.com > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Andreas> I would also like to know how inter-AS with the LDP > > Andreas> approach in lasserre-vkompella is to be solved. > > > > Could you say what the issue is that you think needs to be solved? ------_=_NextPart_001_01C30E4C.C2B98F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

Hi Jeremy,

LDP is not used as a signaling protocol for IPv4, = IPv6 or rfc2547bis :-)

BGP is in charge of it (and do the job very = well).

May be this will clarify all theses exchanges about = signalling in VPLS: adding a new signaling protocol (LDP) whitout any = added value versus keeping the same signalling protocol (BGP) for = differents services (IP,rfc2547bis,VPLS, futures needs)

You may confuse MPLS signaling (LDP or RSVP) and and = VPLS signaling (LDP or BGP)?

Mourad

-----Message d'origine-----
De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alca= tel.be]
Envoy=E9 : mardi 29 avril 2003 14:19
=C0 : Mourad BERKANE
Cc : 'raszuk@cisco.com'; = Andreas.Mattsson@teliasonera.com;
erosen@cisco.com; ppvpn@nortelnetworks.com
Objet : Re: Support for = draft-kompella-ppvpn-vpls-01.txt


Mourad,

> As you hinted here, MP-BGP is much more designed = for a *public*
> inter-AS session for VPLS.

I still don't understand why MP-BGP is more = appropriate than LDP for
this application. I probably need more than a = "hint" to fully understand
it ;-)

> Even if LDP/RSVP already present for the = forwarding plane inside a
> MPLS domain, why should i used LDP for VPLS = signalling when BGP
> already do the job = (IPv4,v6,rfc2547bis,...)???

You can turn this around: Even if BGP is already = present for 2547bis,
v4, v6 etc, why should I use BGP for VPLS signaling = when LDP already
does the job (LDP for intra-AS tunnel LSPs, LDP for = individual PWE3
Pseudo-Wires, ...) ?

[I guess the answer to both of the above questions is = given in the large
number of previous emails on this topic ;-)]

Jeremy.

> Mourad
>
> -----Message d'origine-----
> De : Robert Raszuk [mailto:raszuk@cisco.com]
> Envoy=E9 : mardi 29 avril 2003 11:26
> =C0 : Andreas.Mattsson@teliasonera.com
> Cc : erosen@cisco.com; = ppvpn@nortelnetworks.com
> Objet : Re: Support for = draft-kompella-ppvpn-vpls-01.txt
>
> Andres,
>
> AFAIK there is no need to configure anything = rather then a site
> interface on the PEs. Autodiscovery will detect = new addition and
> propagate the news to all participants. Then in = the lasserre-vkompella
>
> scheme directed LDP if not already set get's = automatically established
>
> between parties.
>
> Of course the drawback here is that you need to = keep LDP ports open
> wide
> within inter-AS LDP src ranges which may or may = not be an acceptable
> issue :-).
>
> R.
>
> > Andreas.Mattsson@teliasonera.com = wrote:
> >
> > Hi Eric
> >
> > As I understand it a requirement would be = to have a full mesh of LDP
>
> > sessions between the PEs in the = participating AS domains. This means
>
> > configuration of each PE when for example = a new site is added to an
> > already existing VPN. If BGP is used this = is not necessary as RRs
> can be
> > used, minimizing the configuration to the = new PE and the RR.
> > But perhaps there exist a solution similar = to this for LDP as well?
> It
> > seems appealing to reuse the 2547bis = structure we have also for VPLS
> if
> > it's possible.
> >
> > My point is that further investigation of = the two different
> solutions
> > before rejecting one or the other would be = good
> >
> > /Andreas
> >
> > -----Original Message-----
> > From: Eric Rosen [mailto:erosen@cisco.com]
> > Sent: den 28 april 2003 16:29
> > To: Mattsson, Andreas A. /Research /08-713 = 81 86, 070-618 67 67
> > Cc: ppvpn@nortelnetworks.com
> > Subject: Re: Support for = draft-kompella-ppvpn-vpls-01.txt
> >
> > Andreas> I would  also like = to  know how inter-AS  with the LDP
> > Andreas> approach in lasserre-vkompella = is to be solved.
> >
> > Could you say what the issue is that you = think needs to be solved?

------_=_NextPart_001_01C30E4C.C2B98F70-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 09:00:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15424 for ; Tue, 29 Apr 2003 09:00:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TD2a716723 for ; Tue, 29 Apr 2003 09:02:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TD2U609453 for ; Tue, 29 Apr 2003 09:02:32 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E4F.13B79CCC" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 07:58:49 -0500 Message-ID: <1DA3AEE851515549A5D2C5BD7F8FB2471ED590@PKDWB06C.ad.sprint.com> Thread-Topic: Support for draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMOTSxBAiZ4WYxvT7mIpLk3xQCCKQAAaiBQ From: "Nagarajan, Ananth [CC]" To: "Mourad BERKANE" , Cc: , , , X-OriginalArrivalTime: 29 Apr 2003 12:58:49.0722 (UTC) FILETIME=[13FF75A0:01C30E4F] X-SMTP-HELO: smtpgw5.sprintspectrum.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpgw5.sprintspectrum.com [207.40.188.13] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30E4F.13B79CCC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mourad, What you say is perhaps good in an ideal world, but the world is far = from ideal. In an ideal world, one would use a washing machine that = also washes dishes (stealing an example from an esteemed colleague), but = that hasn't happened practically. =20 My 2 cents. Ananth =20 -----Original Message----- From: Mourad BERKANE [mailto:mourad.berkane@lambdanet.fr] Sent: Tuesday, April 29, 2003 7:42 AM To: 'jeremy.de_clercq@alcatel.be' Cc: 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; = erosen@cisco.com; ppvpn@nortelnetworks.com Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Hi Jeremy,=20 LDP is not used as a signaling protocol for IPv4, IPv6 or rfc2547bis :-) = BGP is in charge of it (and do the job very well).=20 May be this will clarify all theses exchanges about signalling in VPLS: = adding a new signaling protocol (LDP) whitout any added value versus = keeping the same signalling protocol (BGP) for differents services = (IP,rfc2547bis,VPLS, futures needs) You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling (LDP = or BGP)?=20 Mourad=20 -----Message d'origine-----=20 De : jeremy.de_clercq@alcatel.be [ mailto:jeremy.de_clercq@alcatel.be]=20 Envoy=E9 : mardi 29 avril 2003 14:19=20 =C0 : Mourad BERKANE=20 Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com;=20 erosen@cisco.com; ppvpn@nortelnetworks.com=20 Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 Mourad,=20 > As you hinted here, MP-BGP is much more designed for a *public*=20 > inter-AS session for VPLS.=20 I still don't understand why MP-BGP is more appropriate than LDP for=20 this application. I probably need more than a "hint" to fully understand = it ;-)=20 > Even if LDP/RSVP already present for the forwarding plane inside a=20 > MPLS domain, why should i used LDP for VPLS signalling when BGP=20 > already do the job (IPv4,v6,rfc2547bis,...)???=20 You can turn this around: Even if BGP is already present for 2547bis,=20 v4, v6 etc, why should I use BGP for VPLS signaling when LDP already=20 does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3=20 Pseudo-Wires, ...) ?=20 [I guess the answer to both of the above questions is given in the large = number of previous emails on this topic ;-)]=20 Jeremy.=20 > Mourad=20 >=20 > -----Message d'origine-----=20 > De : Robert Raszuk [ mailto:raszuk@cisco.com]=20 > Envoy=E9 : mardi 29 avril 2003 11:26=20 > =C0 : Andreas.Mattsson@teliasonera.com=20 > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com=20 > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 >=20 > Andres,=20 >=20 > AFAIK there is no need to configure anything rather then a site=20 > interface on the PEs. Autodiscovery will detect new addition and=20 > propagate the news to all participants. Then in the lasserre-vkompella = >=20 > scheme directed LDP if not already set get's automatically established = >=20 > between parties.=20 >=20 > Of course the drawback here is that you need to keep LDP ports open=20 > wide=20 > within inter-AS LDP src ranges which may or may not be an acceptable=20 > issue :-).=20 >=20 > R.=20 >=20 > > Andreas.Mattsson@teliasonera.com wrote:=20 > >=20 > > Hi Eric=20 > >=20 > > As I understand it a requirement would be to have a full mesh of LDP = >=20 > > sessions between the PEs in the participating AS domains. This means = >=20 > > configuration of each PE when for example a new site is added to an=20 > > already existing VPN. If BGP is used this is not necessary as RRs=20 > can be=20 > > used, minimizing the configuration to the new PE and the RR.=20 > > But perhaps there exist a solution similar to this for LDP as well?=20 > It=20 > > seems appealing to reuse the 2547bis structure we have also for VPLS = > if=20 > > it's possible.=20 > >=20 > > My point is that further investigation of the two different=20 > solutions=20 > > before rejecting one or the other would be good=20 > >=20 > > /Andreas=20 > >=20 > > -----Original Message-----=20 > > From: Eric Rosen [ mailto:erosen@cisco.com]=20 > > Sent: den 28 april 2003 16:29=20 > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67=20 > > Cc: ppvpn@nortelnetworks.com=20 > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 > >=20 > > Andreas> I would also like to know how inter-AS with the LDP=20 > > Andreas> approach in lasserre-vkompella is to be solved.=20 > >=20 > > Could you say what the issue is that you think needs to be solved?=20 ------_=_NextPart_001_01C30E4F.13B79CCC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt
Mourad,
What=20 you say is perhaps good in an ideal world, but the world is far from=20 ideal.  In an ideal world, one would use a washing machine that = also washes=20 dishes (stealing an example from an esteemed colleague), but that hasn't = happened practically.
 
My 2=20 cents.
Ananth
 
-----Original Message-----
From: Mourad BERKANE=20 [mailto:mourad.berkane@lambdanet.fr]
Sent: Tuesday, April = 29, 2003=20 7:42 AM
To: 'jeremy.de_clercq@alcatel.be'
Cc:=20 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; = erosen@cisco.com;=20 ppvpn@nortelnetworks.com
Subject: RE: Support for=20 draft-kompella-ppvpn-vpls-01.txt


Hi Jeremy,

LDP is not used as a signaling protocol for IPv4, = IPv6 or=20 rfc2547bis :-)

BGP is in charge of it (and do the job very = well).

May be this will clarify all theses exchanges about = signalling=20 in VPLS: adding a new signaling protocol (LDP) whitout any added value = versus=20 keeping the same signalling protocol (BGP) for differents services=20 (IP,rfc2547bis,VPLS, futures needs)

You may confuse MPLS signaling (LDP or RSVP) and and = VPLS=20 signaling (LDP or BGP)?

Mourad

-----Message d'origine-----
De :=20 jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcat= el.be]=20
Envoy=E9 : mardi 29 avril 2003 14:19 =
=C0=20 : Mourad BERKANE
Cc : 'raszuk@cisco.com';=20 Andreas.Mattsson@teliasonera.com;
erosen@cisco.com;=20 ppvpn@nortelnetworks.com
Objet : Re: Support = for=20 draft-kompella-ppvpn-vpls-01.txt


Mourad,

> As you hinted here, MP-BGP is much more = designed for a=20 *public*
> inter-AS session for = VPLS.

I still don't understand why MP-BGP is more = appropriate than=20 LDP for
this application. I probably need = more than a=20 "hint" to fully understand
it ;-) =

> Even if LDP/RSVP already present for the = forwarding plane=20 inside a
> MPLS domain, why should i used = LDP for=20 VPLS signalling when BGP
> already do the = job=20 (IPv4,v6,rfc2547bis,...)???

You can turn this around: Even if BGP is already = present for=20 2547bis,
v4, v6 etc, why should I use BGP = for VPLS=20 signaling when LDP already
does the job (LDP = for=20 intra-AS tunnel LSPs, LDP for individual PWE3
Pseudo-Wires, ...) ?

[I guess the answer to both of the above questions = is given in=20 the large
number of previous emails on this = topic=20 ;-)]

Jeremy.

> Mourad
> =
> -----Message d'origine-----
> De :=20 Robert Raszuk [mailto:raszuk@cisco.com] =
> Envoy=E9 : mardi 29 avril 2003 11:26
> =C0=20 : Andreas.Mattsson@teliasonera.com
> Cc : = erosen@cisco.com; ppvpn@nortelnetworks.com
> Objet=20 : Re: Support for draft-kompella-ppvpn-vpls-01.txt
>
> Andres,
>=20
> AFAIK there is no need to configure = anything=20 rather then a site
> interface on the = PEs.=20 Autodiscovery will detect new addition and
>=20 propagate the news to all participants. Then in the = lasserre-vkompella=20
>
> scheme directed = LDP if not=20 already set get's automatically established
>=20
> between parties.
>=20
> Of course the drawback here is that you = need to=20 keep LDP ports open
> wide =
> within inter-AS LDP src ranges which may or may not be = an=20 acceptable
> issue :-).
>
> R.
>=20
> > Andreas.Mattsson@teliasonera.com=20 wrote:
> >
> > Hi=20 Eric
> >
> > As I=20 understand it a requirement would be to have a full mesh of LDP =
>
> > sessions = between the=20 PEs in the participating AS domains. This means
>=20
> > configuration of each PE when for = example a=20 new site is added to an
> > already = existing=20 VPN. If BGP is used this is not necessary as RRs
>=20 can be
> > used, minimizing the = configuration to=20 the new PE and the RR.
> > But perhaps = there=20 exist a solution similar to this for LDP as well?
>=20 It
> > seems appealing to reuse the = 2547bis=20 structure we have also for VPLS
> = if=20
> > it's possible.
>=20 >
> > My point is that further = investigation=20 of the two different
> solutions =
> > before rejecting one or the other would be = good=20
> >
> > = /Andreas=20
> >
> > = -----Original=20 Message-----
> > From: Eric Rosen [mailto:erosen@cisco.com] =
> > Sent: den 28 april 2003 16:29
>=20 > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 = 67=20
> > Cc: ppvpn@nortelnetworks.com =
> > Subject: Re: Support for=20 draft-kompella-ppvpn-vpls-01.txt
> = >=20
> > Andreas> I would  also like = to  know=20 how inter-AS  with the LDP
> > = Andreas>=20 approach in lasserre-vkompella is to be solved.
>=20 >
> > Could you say what the issue = is that=20 you think needs to be solved?

------_=_NextPart_001_01C30E4F.13B79CCC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 09:09: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 JAA15633 for ; Tue, 29 Apr 2003 09:09:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TDBb704640 for ; Tue, 29 Apr 2003 09:11:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TDBV605024 for ; Tue, 29 Apr 2003 09:11:32 -0400 (EDT) Message-ID: <3EAE781A.DFC0852E@alcatel.be> Date: Tue, 29 Apr 2003 15:03:22 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mourad BERKANE CC: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: <8D91FF5277472A45A0A8F9654A14649701494991@frlnparexcha03.lambdanet.fr> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2003 15:03:23, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2003 15:03:25 Content-Type: text/plain; charset=iso-8859-1 X-SMTP-HELO: bt0rjw.god.bel.alcatel.be X-SMTP-MAIL-FROM: jeremy.de_clercq@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc240.alcatel.be [195.207.101.240] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA15633 Hi Mourad, > LDP is not used as a signaling protocol for IPv4, IPv6 or > rfc2547bis :-) > BGP is in charge of it (and do the job very well). BGP distributes routes, it doesn't establish Pseudo-Wires in the examples you give. > May be this will clarify all theses exchanges about signalling in > VPLS: adding a new signaling protocol (LDP) whitout any added value > versus keeping the same signalling protocol (BGP) for differents > services (IP,rfc2547bis,VPLS, futures needs) > > You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling > (LDP or BGP)? I'm sure I was not confused by the above ;-) What I meant was that LDP is used for pseudo-wire signaling (http://www.ietf.org/html.charters/pwe3-charter.html, "Pseudo-Wire Setup and Maintenance using LDP"), and that VPLS uses pseudo-wires. So arguments that say "BGP because it is also used for X" or "LDP because it is also used for Y" are not convincing enough for me, as you'll have BGP in some environments (2547) and LDP in other environments (PWE3) and LDP + BGP in many environments ;-) What I really wanted to know is what the difference is for inter-AS applications, as this seems to be one of the *technical* arguments. Jeremy. > > Mourad > > -----Message d'origine----- > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > Envoyé : mardi 29 avril 2003 14:19 > À : Mourad BERKANE > Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; > erosen@cisco.com; ppvpn@nortelnetworks.com > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > Mourad, > > > As you hinted here, MP-BGP is much more designed for a *public* > > inter-AS session for VPLS. > > I still don't understand why MP-BGP is more appropriate than LDP for > this application. I probably need more than a "hint" to fully > understand > it ;-) > > > Even if LDP/RSVP already present for the forwarding plane inside a > > MPLS domain, why should i used LDP for VPLS signalling when BGP > > already do the job (IPv4,v6,rfc2547bis,...)??? > > You can turn this around: Even if BGP is already present for 2547bis, > v4, v6 etc, why should I use BGP for VPLS signaling when LDP already > does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 > Pseudo-Wires, ...) ? > > [I guess the answer to both of the above questions is given in the > large > number of previous emails on this topic ;-)] > > Jeremy. > > > Mourad > > > > -----Message d'origine----- > > De : Robert Raszuk [mailto:raszuk@cisco.com] > > Envoyé : mardi 29 avril 2003 11:26 > > À : Andreas.Mattsson@teliasonera.com > > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Andres, > > > > AFAIK there is no need to configure anything rather then a site > > interface on the PEs. Autodiscovery will detect new addition and > > propagate the news to all participants. Then in the > lasserre-vkompella > > > > scheme directed LDP if not already set get's automatically > established > > > > between parties. > > > > Of course the drawback here is that you need to keep LDP ports open > > wide > > within inter-AS LDP src ranges which may or may not be an acceptable > > > issue :-). > > > > R. > > > > > Andreas.Mattsson@teliasonera.com wrote: > > > > > > Hi Eric > > > > > > As I understand it a requirement would be to have a full mesh of > LDP > > > > > sessions between the PEs in the participating AS domains. This > means > > > > > configuration of each PE when for example a new site is added to > an > > > already existing VPN. If BGP is used this is not necessary as RRs > > can be > > > used, minimizing the configuration to the new PE and the RR. > > > But perhaps there exist a solution similar to this for LDP as > well? > > It > > > seems appealing to reuse the 2547bis structure we have also for > VPLS > > if > > > it's possible. > > > > > > My point is that further investigation of the two different > > solutions > > > before rejecting one or the other would be good > > > > > > /Andreas > > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: den 28 april 2003 16:29 > > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > Andreas> I would also like to know how inter-AS with the LDP > > > Andreas> approach in lasserre-vkompella is to be solved. > > > > > > Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 09:14:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15805 for ; Tue, 29 Apr 2003 09:14:13 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TDGU709403 for ; Tue, 29 Apr 2003 09:16:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TDGPt18852 for ; Tue, 29 Apr 2003 09:16:26 -0400 (EDT) Message-ID: <3EAE77A7.9040300@acm.org> Date: Tue, 29 Apr 2003 09:01:27 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, pdf MIME-Version: 1.0 To: "O'Connor, Don" CC: vkompella@timetra.com, schultz@io.iol.unh.edu, "'Serbest, Yetik'" , Cheng-Yin.Lee@alcatel.com, "'Rick Wilder'" , ppvpn@nortelnetworks.com, tony@jeffree.co.uk, mick_seaman@ieee.org, Gerard Goubert Subject: Re: IEEE 802.1ad and VPLS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cpe-024-211-156-136.nc.rr.com [24.211.156.136] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Its not like 802.1ad is re-defining bridging. If you want to know if VPLS, or anything, will work with 802.1ad, then see if it works with 802.1. 802.1ad is only doing a few clarifications and additions, but nothing earth shattering. The issues you mention are valid things to talk about, and that have been talked about multiple times over. And I'm not arguing that PPVPN should be inconsistent with 802.1, I generally argue exactly the opposite. The final form of 802.1ad should be consistent with the historical approach to bridging, and I'm sure it will be. Anything above/outside the bridging layer including PPVPN should be consistent with 802.1, but that doesn't really put any put any restriction on 802.1 any more than MPLS required cooperation with Ethernet. The communication you seem to be asking for has happened and continues to happen as there are a number of 802.1 people that have given input to various PPVPN drafts, and there are more IETF people showing up in the 802.1 meetings every time. So its already happening, formally and informally. I'm not saying any of the VPLS drafts are perfect, and people are commenting on them all the time. And when they suggest violating the layering principal (e.g. signaling Q-tags with LDP), its generally a bad thing. And those will all come out during the comment reviews if not before. - Matt O'Connor, Don wrote: > For Hierarchical VPLS, draft-lasserre indicates that the MTU-s can support > Q-in-Q. It would appear that the MTU-s could be a 802.1AD Provider Bridge or > could contain a Provider Bridge component. The draft also indicates that LDP > signaling can be used for distribution of Q tags. This raises the issue of > how does the MPLS control plane interface with the 802.1AD control plane to > support applications such as single ended provisioning? In theory the bridge > function in draft-lasserre PE-rs could be a 802.1AD Provider Bridge. This is > my perception of the "understanding" between of IETF PPVPN and IEEE 802.1. > It would seem like the service interface (E-ISS in IEEE 802.1 terms) between > the 802.1AD Provider Bridge function in the PE-rs and the LAN Emulation > function defined by draft-lasserre should be jointly defined / agreed by > IETF PPVPN and IEEE 802.1. There are other issues (e.g. bridge unlearn > signaling) that should ideally be defined across these two groups, otherwise > there could be multiple overlapping standards in the same area. My view is > that: 1) draft-lasserre & other PPVPN working group drafts / eventual RFCs > need future updates to be consistent with / mesh with 802.1AD 2) the final > form of 802.1AD should correlate with PPVPN RFC(s) 3) More interaction is > required between PPVPN and IEEE 802.1 on issues such as described above. I > think this is potentially possible after: 1) PPVPN selects one or more > drafts to progress as WG documents 2) IEEE 802.1AD adds more detail to the > current draft. > > Don > > -----Original Message----- > From: Matt Squire [mailto:mattsquire@acm.org] > Sent: Monday, April 28, 2003 6:58 AM > To: vkompella@timetra.com > Cc: schultz@io.iol.unh.edu; O'Connor, Don; 'Serbest, Yetik'; > Cheng-Yin.Lee@alcatel.com; 'Rick Wilder'; ppvpn@nortelnetworks.com; > tony@jeffree.co.uk; mick_seaman@ieee.org; Gerard Goubert > Subject: Re: IEEE 802.1ad and VPLS > > > > I apologize for jumping into this fray late, but I've been a wee bit > behind in my email. > > The good thing about the current structure of the vkompella draft (IMHO) > is that we can, at the end of the day, treat the VPLS like a LAN > segment. So one could treat 802.1ad and VPLS independently, just as one > can treat 802.1ad and Ethernet independently. > > 802.1ad can, at the edge, tunnel BPDUs over VPLS. As VPLS looks like a > LAN segment to 802.1, it can tunnel BPDUs and other things over a VPLS. > One can argue if thats a useful thing, but it can be done, as long as > we continue with the VPLS=LAN model. > > As far as the orgnization between the groups, its unclear how much more > is needed. Many people in 802.1 know whats happening in PPVPN, and > vice-versa. As emulating LAN segments has been done in the past (ATM, > FR, etc.), and there weren't really any 802.1 specific issues to deal > with in the past, I don't expect there will be with VPLS unless we > deviate from the model of LAN emulation. > > - Matt > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 09:34:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17446 for ; Tue, 29 Apr 2003 09:34:49 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TDb6718056 for ; Tue, 29 Apr 2003 09:37:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TDb2h09888 for ; Tue, 29 Apr 2003 09:37:03 -0400 (EDT) Message-ID: <45799.61.11.33.123.1051625704.squirrel@mail.apara.com> Date: Tue, 29 Apr 2003 19:45:04 +0530 (IST) Subject: Re: label generation algorithms From: "Alok Dube" To: In-Reply-To: <3EAD479D.1050205@marconi.com> References: <3EAD479D.1050205@marconi.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: Reply-To: alok.dube@apara.com X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Hi David,Sylvia/All, > > Well, if you trace the LSP and find a node that does a label-pop, then > that node is the end of that LSP. Of course, there could be > lower-level labels that will cause the packet to be label-switched to > another router, but that label would correspond to a different LSP. > > When RSVP-TE is used for signaling, each LSP has a "tunnel endpoint > address" which identifies the IP address where the LSP ends. > > When LDP is used for signaling, it's trickier. The FEC will tell you > the address where the LSP is supposed to end, but if one or more nodes > along the path to that address isn't participating in LDP (and > downstream unsolicited label allocation is used), the LSP will end at > an intermediate node somewhere. > > If you are looking for some kind of magic bullet to let you look at any > node along any arbitrary LSP and say "the endpoint is w.x.y.z", I > don't think there exists one. this thread got me thinking... if I may ask, does this imply that to achieve the same: 1. either the end point be uniquely identified and propoated? (eg:PE:VRF should be uniquely identified) in some format so that every node can reach it?2. if 1 is true, this information has to be there with both P and Pe routers so that they know "what sending to a particular PE:VRF" means? in the sense every node has to know what this "PE:VRF" identifier is? it could be an IP, it could be something else...but that protocol running on the P needs to know and understand the meaning of this too. another question I have is: what if i use draft-kompella-ppvpn kind of signalling (BGP passing the labels and stuff) and take away the P routers? all nodes are PE and thats it, we have them in full mesh and thats it...? how does it work then? Would appreciate if someone could clarify. -rgds Alok From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 09:38:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17608 for ; Tue, 29 Apr 2003 09:38:40 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TDew722004 for ; Tue, 29 Apr 2003 09:40:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TDesh14419 for ; Tue, 29 Apr 2003 09:40:54 -0400 (EDT) Message-Id: <200304291334.h3TDYqu83845@merlot.juniper.net> To: "Nagarajan, Ananth [CC]" cc: "Mourad BERKANE" , jeremy.de_clercq@alcatel.be, raszuk@cisco.com, Andreas.Mattsson@teliasonera.com, erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 07:58:49 CDT." <1DA3AEE851515549A5D2C5BD7F8FB2471ED590@PKDWB06C.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29447.1051623292.1@juniper.net> Date: Tue, 29 Apr 2003 06:34:52 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Ananth, > Mourad, > What you say is perhaps good in an ideal world, but the world is far > from ideal. And what that has to do with Mourad's observation that BGP, and not LDP, is used for exchanging IPv4 routes, IPv6 routes, rfc2547bis, VR autodiscovery, L2VPNs, etc... ? > In an ideal world, one would use a washing machine that > also washes dishes (stealing an example from an esteemed colleague), but > that hasn't happened practically. Should this argument then be applied against using LDP for VPLS signaling (even if it is used for MPLS signaling) ? Yakov. > > My 2 cents. > Ananth > =20 > > -----Original Message----- > From: Mourad BERKANE [mailto:mourad.berkane@lambdanet.fr] > Sent: Tuesday, April 29, 2003 7:42 AM > To: 'jeremy.de_clercq@alcatel.be' > Cc: 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; = > erosen@cisco.com; ppvpn@nortelnetworks.com > Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > Hi Jeremy,=20 > > LDP is not used as a signaling protocol for IPv4, IPv6 or rfc2547bis :-) = > > BGP is in charge of it (and do the job very well).=20 > > May be this will clarify all theses exchanges about signalling in VPLS: = > adding a new signaling protocol (LDP) whitout any added value versus = > keeping the same signalling protocol (BGP) for differents services = > (IP,rfc2547bis,VPLS, futures needs) > > You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling (LDP = > or BGP)?=20 > > Mourad=20 > > -----Message d'origine-----=20 > De : jeremy.de_clercq@alcatel.be [ mailto:jeremy.de_clercq@alcatel.be]=20 > Envoy=E9 : mardi 29 avril 2003 14:19=20 > =C0 : Mourad BERKANE=20 > Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com;=20 > erosen@cisco.com; ppvpn@nortelnetworks.com=20 > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 > > > Mourad,=20 > > > As you hinted here, MP-BGP is much more designed for a *public*=20 > > inter-AS session for VPLS.=20 > > I still don't understand why MP-BGP is more appropriate than LDP for=20 > this application. I probably need more than a "hint" to fully understand = > > it ;-)=20 > > > Even if LDP/RSVP already present for the forwarding plane inside a=20 > > MPLS domain, why should i used LDP for VPLS signalling when BGP=20 > > already do the job (IPv4,v6,rfc2547bis,...)???=20 > > You can turn this around: Even if BGP is already present for 2547bis,=20 > v4, v6 etc, why should I use BGP for VPLS signaling when LDP already=20 > does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3=20 > Pseudo-Wires, ...) ?=20 > > [I guess the answer to both of the above questions is given in the large = > > number of previous emails on this topic ;-)]=20 > > Jeremy.=20 > > > Mourad=20 > >=20 > > -----Message d'origine-----=20 > > De : Robert Raszuk [ mailto:raszuk@cisco.com]=20 > > Envoy=E9 : mardi 29 avril 2003 11:26=20 > > =C0 : Andreas.Mattsson@teliasonera.com=20 > > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com=20 > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 > >=20 > > Andres,=20 > >=20 > > AFAIK there is no need to configure anything rather then a site=20 > > interface on the PEs. Autodiscovery will detect new addition and=20 > > propagate the news to all participants. Then in the lasserre-vkompella = > > >=20 > > scheme directed LDP if not already set get's automatically established = > > >=20 > > between parties.=20 > >=20 > > Of course the drawback here is that you need to keep LDP ports open=20 > > wide=20 > > within inter-AS LDP src ranges which may or may not be an acceptable=20 > > issue :-).=20 > >=20 > > R.=20 > >=20 > > > Andreas.Mattsson@teliasonera.com wrote:=20 > > >=20 > > > Hi Eric=20 > > >=20 > > > As I understand it a requirement would be to have a full mesh of LDP = > > >=20 > > > sessions between the PEs in the participating AS domains. This means = > > >=20 > > > configuration of each PE when for example a new site is added to an=20 > > > already existing VPN. If BGP is used this is not necessary as RRs=20 > > can be=20 > > > used, minimizing the configuration to the new PE and the RR.=20 > > > But perhaps there exist a solution similar to this for LDP as well?=20 > > It=20 > > > seems appealing to reuse the 2547bis structure we have also for VPLS = > > > if=20 > > > it's possible.=20 > > >=20 > > > My point is that further investigation of the two different=20 > > solutions=20 > > > before rejecting one or the other would be good=20 > > >=20 > > > /Andreas=20 > > >=20 > > > -----Original Message-----=20 > > > From: Eric Rosen [ mailto:erosen@cisco.com]=20 > > > Sent: den 28 april 2003 16:29=20 > > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67=20 > > > Cc: ppvpn@nortelnetworks.com=20 > > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 > > >=20 > > > Andreas> I would also like to know how inter-AS with the LDP=20 > > > Andreas> approach in lasserre-vkompella is to be solved.=20 > > >=20 > > > Could you say what the issue is that you think needs to be solved?=20 > > > ------_=_NextPart_001_01C30E4F.13B79CCC > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Diso-8859-1"> > RE: Support for draft-kompella-ppvpn-vpls-01.txt > > > >
> size=3D2>Mourad,
>
size=3D2>What=20 > you say is perhaps good in an ideal world, but the world is far from=20 > ideal.  In an ideal world, one would use a washing machine that = > also washes=20 > dishes (stealing an example from an esteemed colleague), but that hasn't = > > happened practically.
>
> size=3D2> 
>
size=3D2>My 2=20 > cents.
>
> size=3D2>Ananth
>
> size=3D2> 
>
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = > solid; MARGIN-RIGHT: 0px"> >
size=3D2>-----Original Message-----
From: Mourad BERKANE=20 > [mailto:mourad.berkane@lambdanet.fr]
Sent: Tuesday, April = > 29, 2003=20 > 7:42 AM
To: 'jeremy.de_clercq@alcatel.be'
Cc:=20 > 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; = > erosen@cisco.com;=20 > ppvpn@nortelnetworks.com
Subject: RE: Support for=20 > draft-kompella-ppvpn-vpls-01.txt


>

Hi Jeremy,

>

LDP is not used as a signaling protocol for IPv4, = > IPv6 or=20 > rfc2547bis :-)

>

BGP is in charge of it (and do the job very = > well).

>

May be this will clarify all theses exchanges about = > signalling=20 > in VPLS: adding a new signaling protocol (LDP) whitout any added value = > versus=20 > keeping the same signalling protocol (BGP) for differents services=20 > (IP,rfc2547bis,VPLS, futures needs)

>

You may confuse MPLS signaling (LDP or RSVP) and and = > VPLS=20 > signaling (LDP or BGP)?

>

Mourad

>

-----Message d'origine-----
size=3D2>De :=20 > jeremy.de_clercq@alcatel.be [ = > href=3D"mailto:jeremy.de_clercq@alcatel.be">mailto:jeremy.de_clercq@alcat= > el.be]=20 >
Envoy=E9 : mardi 29 avril 2003 14:19 = >
=C0=20 > : Mourad BERKANE
Cc : 'raszuk@cisco.com';=20 > Andreas.Mattsson@teliasonera.com;
size=3D2>erosen@cisco.com;=20 > ppvpn@nortelnetworks.com
Objet : Re: Support = > for=20 > draft-kompella-ppvpn-vpls-01.txt


>

Mourad,

>

> As you hinted here, MP-BGP is much more = > designed for a=20 > *public*
> inter-AS session for = > VPLS.

>

I still don't understand why MP-BGP is more = > appropriate than=20 > LDP for
this application. I probably need = > more than a=20 > "hint" to fully understand
it ;-) = >

>

> Even if LDP/RSVP already present for the = > forwarding plane=20 > inside a
> MPLS domain, why should i used = > LDP for=20 > VPLS signalling when BGP
> already do the = > job=20 > (IPv4,v6,rfc2547bis,...)???

>

You can turn this around: Even if BGP is already = > present for=20 > 2547bis,
v4, v6 etc, why should I use BGP = > for VPLS=20 > signaling when LDP already
does the job (LDP = > for=20 > intra-AS tunnel LSPs, LDP for individual PWE3
size=3D2>Pseudo-Wires, ...) ?

>

[I guess the answer to both of the above questions = > is given in=20 > the large
number of previous emails on this = > topic=20 > ;-)]

>

Jeremy.

>

> Mourad
> = >
size=3D2>> -----Message d'origine-----
size=3D2>> De :=20 > Robert Raszuk [ href=3D"mailto:raszuk@cisco.com">mailto:raszuk@cisco.com] = >
size=3D2>> Envoy=E9 : mardi 29 avril 2003 11:26
size=3D2>> =C0=20 > : Andreas.Mattsson@teliasonera.com
> Cc : = > > erosen@cisco.com; ppvpn@nortelnetworks.com
size=3D2>> Objet=20 > : Re: Support for draft-kompella-ppvpn-vpls-01.txt
size=3D2>>
> Andres,
size=3D2>>=20 >
> AFAIK there is no need to configure = > anything=20 > rather then a site
> interface on the = > PEs.=20 > Autodiscovery will detect new addition and
size=3D2>>=20 > propagate the news to all participants. Then in the = > lasserre-vkompella=20 >
>
> scheme directed = > LDP if not=20 > already set get's automatically established
size=3D2>>=20 >
> between parties.
size=3D2>>=20 >
> Of course the drawback here is that you = > need to=20 > keep LDP ports open
> wide = >
size=3D2>> within inter-AS LDP src ranges which may or may not be = > an=20 > acceptable
> issue :-).
size=3D2>>
> R.
size=3D2>>=20 >
> > Andreas.Mattsson@teliasonera.com=20 > wrote:
> >
size=3D2>> > Hi=20 > Eric
> >
size=3D2>> > As I=20 > understand it a requirement would be to have a full mesh of LDP = > >
>
> > sessions = > between the=20 > PEs in the participating AS domains. This means
size=3D2>>=20 >
> > configuration of each PE when for = > example a=20 > new site is added to an
> > already = > existing=20 > VPN. If BGP is used this is not necessary as RRs
size=3D2>>=20 > can be
> > used, minimizing the = > configuration to=20 > the new PE and the RR.
> > But perhaps = > there=20 > exist a solution similar to this for LDP as well?
size=3D2>>=20 > It
> > seems appealing to reuse the = > 2547bis=20 > structure we have also for VPLS
> = > if=20 >
> > it's possible.
size=3D2>>=20 > >
> > My point is that further = > investigation=20 > of the two different
> solutions = >
size=3D2>> > before rejecting one or the other would be = > good=20 >
> >
> > = > /Andreas=20 >
> >
> > = > -----Original=20 > Message-----
> > From: Eric Rosen [ href=3D"mailto:erosen@cisco.com">mailto:erosen@cisco.com] = >
size=3D2>> > Sent: den 28 april 2003 16:29
size=3D2>>=20 > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 = > 67=20 >
> > Cc: ppvpn@nortelnetworks.com = >
size=3D2>> > Subject: Re: Support for=20 > draft-kompella-ppvpn-vpls-01.txt
> = > >=20 >
> > Andreas> I would  also like = > to  know=20 > how inter-AS  with the LDP
> > = > Andreas>=20 > approach in lasserre-vkompella is to be solved.
size=3D2>>=20 > >
> > Could you say what the issue = > is that=20 > you think needs to be solved?

> > ------_=_NextPart_001_01C30E4F.13B79CCC-- > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 09:44:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18372 for ; Tue, 29 Apr 2003 09:44:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TDkL726319 for ; Tue, 29 Apr 2003 09:46:21 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TDkG420798 for ; Tue, 29 Apr 2003 09:46:16 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A14649701494995@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'jeremy.de_clercq@alcatel.be'" Cc: ppvpn@nortelnetworks.com Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 15:41:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E55.037EB370" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30E55.037EB370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeremy (sorry about the non confusion) The "argument" is that today Providers don't (want to) have a (useless) = LDP peering sessions for VPLS application because BGP already present = between Providers (IP world). Suppose you would like to extend a VPLS domain out of your network, you = will need to extend signaling between theses networks ("hi i am PE1 from = Carrier A ASN=3D1 and I would like to join VPLS Z in your domain Carrier B = ASN=3D2, please use label L to send traffic to me"). The fact is that Carrier A = and Carrier B could already communicated over IPv4 Public network: a BGP = session already exist between A and B and could be used for many services (v4,v6,2547bis AND VPLS) If you use BGP as VPLS signaling protocols, you will need to setup a = MP-eBGP session between AS --> re use of existing BGP session between A and B Forwarding Tunnels used proposed in draft-kompella-ppvpn-vpls could be MPLS,IP or GRE tunnels between A and B. Someone who don't (or can't) discuss LDP could be a candidate for an extension of a VPLS domain since the signaling protocol is BGP :-) If you use LDP as VPLS signaling protocols, you will need to open LDP = ports between A and B. This new session is dedicated to VPLS services. Of course, It work but = why should I manage/troubleshoot this LDP inter-AS sessions since BGP = already present for others services? Mourad -----Message d'origine----- De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] Envoy=E9 : mardi 29 avril 2003 15:03 =C0 : Mourad BERKANE Cc : ppvpn@nortelnetworks.com Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt Hi Mourad, > LDP is not used as a signaling protocol for IPv4, IPv6 or=20 > rfc2547bis :-)=20 > BGP is in charge of it (and do the job very well). BGP distributes routes, it doesn't establish Pseudo-Wires in the examples you give. > May be this will clarify all theses exchanges about signalling in > VPLS: adding a new signaling protocol (LDP) whitout any added value > versus keeping the same signalling protocol (BGP) for differents > services (IP,rfc2547bis,VPLS, futures needs) >=20 > You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling > (LDP or BGP)? I'm sure I was not confused by the above ;-) What I meant was that LDP is used for pseudo-wire signaling (http://www.ietf.org/html.charters/pwe3-charter.html, "Pseudo-Wire = Setup and Maintenance using LDP"), and that VPLS uses pseudo-wires. So arguments that say "BGP because it is also used for X" or "LDP because it is also used for Y" are not convincing enough for me, as you'll have BGP in some environments (2547) and LDP in other environments (PWE3) and LDP + BGP in many environments ;-) What I really wanted to know is what the difference is for inter-AS applications, as this seems to be one of the *technical* arguments. Jeremy. >=20 > Mourad >=20 > -----Message d'origine----- > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > Envoy=E9 : mardi 29 avril 2003 14:19 > =C0 : Mourad BERKANE > Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; > erosen@cisco.com; ppvpn@nortelnetworks.com > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt >=20 > Mourad, >=20 > > As you hinted here, MP-BGP is much more designed for a *public* > > inter-AS session for VPLS. >=20 > I still don't understand why MP-BGP is more appropriate than LDP for > this application. I probably need more than a "hint" to fully > understand > it ;-) >=20 > > Even if LDP/RSVP already present for the forwarding plane inside a > > MPLS domain, why should i used LDP for VPLS signalling when BGP > > already do the job (IPv4,v6,rfc2547bis,...)??? >=20 > You can turn this around: Even if BGP is already present for 2547bis, > v4, v6 etc, why should I use BGP for VPLS signaling when LDP already > does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 > Pseudo-Wires, ...) ? >=20 > [I guess the answer to both of the above questions is given in the > large > number of previous emails on this topic ;-)] >=20 > Jeremy. >=20 > > Mourad > > > > -----Message d'origine----- > > De : Robert Raszuk [mailto:raszuk@cisco.com] > > Envoy=E9 : mardi 29 avril 2003 11:26 > > =C0 : Andreas.Mattsson@teliasonera.com > > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Andres, > > > > AFAIK there is no need to configure anything rather then a site > > interface on the PEs. Autodiscovery will detect new addition and > > propagate the news to all participants. Then in the > lasserre-vkompella > > > > scheme directed LDP if not already set get's automatically > established > > > > between parties. > > > > Of course the drawback here is that you need to keep LDP ports open > > wide > > within inter-AS LDP src ranges which may or may not be an = acceptable >=20 > > issue :-). > > > > R. > > > > > Andreas.Mattsson@teliasonera.com wrote: > > > > > > Hi Eric > > > > > > As I understand it a requirement would be to have a full mesh of > LDP > > > > > sessions between the PEs in the participating AS domains. This > means > > > > > configuration of each PE when for example a new site is added to > an > > > already existing VPN. If BGP is used this is not necessary as RRs > > can be > > > used, minimizing the configuration to the new PE and the RR. > > > But perhaps there exist a solution similar to this for LDP as > well? > > It > > > seems appealing to reuse the 2547bis structure we have also for > VPLS > > if > > > it's possible. > > > > > > My point is that further investigation of the two different > > solutions > > > before rejecting one or the other would be good > > > > > > /Andreas > > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: den 28 april 2003 16:29 > > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > > Cc: ppvpn@nortelnetworks.com > > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > Andreas> I would also like to know how inter-AS with the LDP > > > Andreas> approach in lasserre-vkompella is to be solved. > > > > > > Could you say what the issue is that you think needs to be = solved? ------_=_NextPart_001_01C30E55.037EB370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

Hi Jeremy

(sorry about the non confusion)

The "argument" is that today Providers = don't (want to) have a (useless) LDP peering sessions for VPLS = application because BGP already present between Providers (IP = world).

Suppose you would like to extend a VPLS domain out of = your network, you will need to extend signaling between theses networks = ("hi i am PE1 from Carrier A ASN=3D1 and I would like to join VPLS = Z in your domain Carrier B ASN=3D2, please use label L to send traffic = to me"). The fact is that Carrier A and Carrier B could already = communicated over IPv4 Public network: a BGP session already exist = between A and B and could be used for many services (v4,v6,2547bis AND = VPLS)

If you use BGP as VPLS signaling protocols, you will = need to setup a MP-eBGP session between AS
--> re use of existing BGP session between A and = B

Forwarding Tunnels used proposed in = draft-kompella-ppvpn-vpls could be MPLS,IP or GRE tunnels between A and = B.
Someone who don't (or can't) discuss LDP could be a = candidate for an extension of a VPLS domain since the signaling = protocol is BGP :-)

If you use LDP as VPLS signaling protocols, you will = need to open LDP ports between A and B.
This new session is dedicated to VPLS services. Of = course, It work but why should I manage/troubleshoot this LDP inter-AS = sessions since BGP already present for others services?

Mourad

-----Message d'origine-----
De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alca= tel.be]
Envoy=E9 : mardi 29 avril 2003 15:03
=C0 : Mourad BERKANE
Cc : ppvpn@nortelnetworks.com
Objet : Re: Support for = draft-kompella-ppvpn-vpls-01.txt


Hi Mourad,

> LDP is not used as a signaling protocol for = IPv4, IPv6 or
> rfc2547bis :-)
> BGP is in charge of it (and do the job very = well).

BGP distributes routes, it doesn't establish = Pseudo-Wires in the
examples you give.

> May be this will clarify all theses exchanges = about signalling in
> VPLS: adding a new signaling protocol (LDP) = whitout any added value
> versus keeping the same signalling protocol = (BGP) for differents
> services (IP,rfc2547bis,VPLS, futures = needs)
>
> You may confuse MPLS signaling (LDP or RSVP) = and and VPLS signaling
> (LDP or BGP)?

I'm sure I was not confused by the above ;-)

What I meant was that LDP is used for pseudo-wire = signaling
(http://www.ietf.org/html.charters/pwe3-charter.html, "Pseudo-Wire Setup
and Maintenance using LDP"), and that VPLS uses = pseudo-wires.

So arguments that say "BGP because it is also = used for X" or "LDP
because it is also used for Y" are not = convincing enough for me, as
you'll have BGP in some environments (2547) and LDP = in other
environments (PWE3) and LDP + BGP in many = environments ;-)

What I really wanted to know is what the difference = is for inter-AS
applications, as this seems to be one of the = *technical* arguments.

Jeremy.

>
> Mourad
>
> -----Message d'origine-----
> De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alca= tel.be]
> Envoy=E9 : mardi 29 avril 2003 14:19
> =C0 : Mourad BERKANE
> Cc : 'raszuk@cisco.com'; = Andreas.Mattsson@teliasonera.com;
> erosen@cisco.com; = ppvpn@nortelnetworks.com
> Objet : Re: Support for = draft-kompella-ppvpn-vpls-01.txt
>
> Mourad,
>
> > As you hinted here, MP-BGP is much more = designed for a *public*
> > inter-AS session for VPLS.
>
> I still don't understand why MP-BGP is more = appropriate than LDP for
> this application. I probably need more than a = "hint" to fully
> understand
> it ;-)
>
> > Even if LDP/RSVP already present for the = forwarding plane inside a
> > MPLS domain, why should i used LDP for = VPLS signalling when BGP
> > already do the job = (IPv4,v6,rfc2547bis,...)???
>
> You can turn this around: Even if BGP is = already present for 2547bis,
> v4, v6 etc, why should I use BGP for VPLS = signaling when LDP already
> does the job (LDP for intra-AS tunnel LSPs, LDP = for individual PWE3
> Pseudo-Wires, ...) ?
>
> [I guess the answer to both of the above = questions is given in the
> large
> number of previous emails on this topic = ;-)]
>
> Jeremy.
>
> > Mourad
> >
> > -----Message d'origine-----
> > De : Robert Raszuk [mailto:raszuk@cisco.com]
> > Envoy=E9 : mardi 29 avril 2003 = 11:26
> > =C0 : = Andreas.Mattsson@teliasonera.com
> > Cc : erosen@cisco.com; = ppvpn@nortelnetworks.com
> > Objet : Re: Support for = draft-kompella-ppvpn-vpls-01.txt
> >
> > Andres,
> >
> > AFAIK there is no need to configure = anything rather then a site
> > interface on the PEs. Autodiscovery will = detect new addition and
> > propagate the news to all participants. = Then in the
> lasserre-vkompella
> >
> > scheme directed LDP if not already set = get's automatically
> established
> >
> > between parties.
> >
> > Of course the drawback here is that you = need to keep LDP ports open
> > wide
> > within inter-AS LDP src ranges which may = or may not be an acceptable
>
> > issue :-).
> >
> > R.
> >
> > > Andreas.Mattsson@teliasonera.com = wrote:
> > >
> > > Hi Eric
> > >
> > > As I understand it a requirement = would be to have a full mesh of
> LDP
> >
> > > sessions between the PEs in the = participating AS domains. This
> means
> >
> > > configuration of each PE when for = example a new site is added to
> an
> > > already existing VPN. If BGP is used = this is not necessary as RRs
> > can be
> > > used, minimizing the configuration to = the new PE and the RR.
> > > But perhaps there exist a solution = similar to this for LDP as
> well?
> > It
> > > seems appealing to reuse the 2547bis = structure we have also for
> VPLS
> > if
> > > it's possible.
> > >
> > > My point is that further = investigation of the two different
> > solutions
> > > before rejecting one or the other = would be good
> > >
> > > /Andreas
> > >
> > > -----Original Message-----
> > > From: Eric Rosen [mailto:erosen@cisco.com]
> > > Sent: den 28 april 2003 16:29
> > > To: Mattsson, Andreas A. /Research = /08-713 81 86, 070-618 67 67
> > > Cc: ppvpn@nortelnetworks.com
> > > Subject: Re: Support for = draft-kompella-ppvpn-vpls-01.txt
> > >
> > > Andreas> I would  also like = to  know how inter-AS  with the LDP
> > > Andreas> approach in = lasserre-vkompella is to be solved.
> > >
> > > Could you say what the issue is that = you think needs to be solved?

------_=_NextPart_001_01C30E55.037EB370-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 10:02:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20116 for ; Tue, 29 Apr 2003 10:02:57 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TE5F706435 for ; Tue, 29 Apr 2003 10:05:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TE57219023 for ; Tue, 29 Apr 2003 10:05:07 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A14649701494998@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'Mike Duckett (Dotnet)'" Cc: ppvpn@nortelnetworks.com Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 16:00:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E57.BC379A10" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30E57.BC379A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 I don't see in this mailing list something that BGP cannot perform for = a PE-to-PE signaling messages. =20 I'm sure BGP is enough robust to support VPLS applications. =20 The real question already posted in ppvpn discussion is could a PE = support many services (v4,v6,rfc2547bis,l2vpn,VPLS, next services)? =20 The answer is yes. =20 Mourad -----Message d'origine----- De : Mike Duckett (Dotnet) [mailto:mduckett@bellsouth.net] Envoy=E9 : mardi 29 avril 2003 14:32 =C0 : ppvpn@nortelnetworks.com Objet : Support for draft-kompella-ppvpn-vpls-01.txt Mourad, =20 You have asked THE question. What problems do we need to solve that = drive us to a something that BGP cannot perform? Is BGP sufficiently robust = that we believe future unknowns can be sufficiently addressed (intentionally vague)? Are there capabilities that require protracted negotiation = specific to a limited set (e.g., a pair) of PEs? =20 =20 =20 =20 ----- Original Message -----=20 From: Mourad BERKANE =20 To: 'raszuk@cisco.com' ; Andreas.Mattsson@teliasonera.com = =20 Cc: erosen@cisco.com ; = ppvpn@nortelnetworks.com =20 Sent: Tuesday, April 29, 2003 7:55 AM Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Robert et al.=20 As you hinted here, MP-BGP is much more designed for a *public* = inter-AS session for VPLS.=20 Even if LDP/RSVP already present for the forwarding plane inside a MPLS domain, why should i used LDP for VPLS signalling when BGP already do = the job (IPv4,v6,rfc2547bis,...)??? Mourad=20 -----Message d'origine-----=20 De : Robert Raszuk [ mailto:raszuk@cisco.com = ]=20 Envoy=E9 : mardi 29 avril 2003 11:26=20 =C0 : Andreas.Mattsson@teliasonera.com =20 Cc : erosen@cisco.com ; = ppvpn@nortelnetworks.com =20 Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 Andres,=20 AFAIK there is no need to configure anything rather then a site=20 interface on the PEs. Autodiscovery will detect new addition and=20 propagate the news to all participants. Then in the lasserre-vkompella=20 scheme directed LDP if not already set get's automatically established=20 between parties.=20 Of course the drawback here is that you need to keep LDP ports open = wide=20 within inter-AS LDP src ranges which may or may not be an acceptable=20 issue :-).=20 R.=20 > Andreas.Mattsson@teliasonera.com wrote:=20 >=20 > Hi Eric=20 >=20 > As I understand it a requirement would be to have a full mesh of LDP=20 > sessions between the PEs in the participating AS domains. This means=20 > configuration of each PE when for example a new site is added to an=20 > already existing VPN. If BGP is used this is not necessary as RRs can = be=20 > used, minimizing the configuration to the new PE and the RR.=20 > But perhaps there exist a solution similar to this for LDP as well? = It=20 > seems appealing to reuse the 2547bis structure we have also for VPLS = if=20 > it's possible.=20 >=20 > My point is that further investigation of the two different solutions = > before rejecting one or the other would be good=20 >=20 > /Andreas=20 >=20 > -----Original Message-----=20 > From: Eric Rosen [ mailto:erosen@cisco.com = ]=20 > Sent: den 28 april 2003 16:29=20 > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67=20 > Cc: ppvpn@nortelnetworks.com=20 > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 >=20 > Andreas> I would also like to know how inter-AS with the LDP=20 > Andreas> approach in lasserre-vkompella is to be solved.=20 >=20 > Could you say what the issue is that you think needs to be solved?=20 ------_=_NextPart_001_01C30E57.BC379A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt
Hi Mike,
 
I don't see in this mailing list something = that BGP=20 cannot perform for a PE-to-PE signaling messages.
 
I'm sure BGP is enough robust to support = VPLS=20 applications.
 
The real question already posted in ppvpn = discussion is=20 could a PE support many services (v4,v6,rfc2547bis,l2vpn,VPLS, next=20 services)?
 
The answer is yes.
 
Mourad
-----Message d'origine-----
De : Mike Duckett = (Dotnet)=20 [mailto:mduckett@bellsouth.net]
Envoy=E9 : mardi 29 = avril 2003=20 14:32
=C0 : = ppvpn@nortelnetworks.com
Objet :=20 Support for draft-kompella-ppvpn-vpls-01.txt

Mourad,
 
You have asked THE question.  = What problems=20 do we need to solve that drive us to a something that BGP cannot=20 perform?   Is BGP sufficiently robust that we believe = future=20 unknowns can be sufficiently addressed (intentionally vague)?  = Are there=20 capabilities that require protracted negotiation specific to a = limited set=20 (e.g., a pair) of PEs? 
 
 
 
----- Original Message -----
From:=20 Mourad BERKANE =
To: 'raszuk@cisco.com' ; Andreas.Mattsson@telias= onera.com=20
Cc: erosen@cisco.com ; ppvpn@nortelnetworks.com =
Sent: Tuesday, April 29, = 2003 7:55=20 AM
Subject: RE: Support for=20 draft-kompella-ppvpn-vpls-01.txt


Robert et al.

As you hinted here, MP-BGP is much more designed = for a=20 *public* inter-AS session for VPLS.

Even if LDP/RSVP already present for the = forwarding plane=20 inside a MPLS domain, why should i used LDP for VPLS signalling = when BGP=20 already do the job (IPv4,v6,rfc2547bis,...)???

Mourad


-----Message d'origine-----
De :=20 Robert Raszuk [mailto:raszuk@cisco.com] =
Envoy=E9 : mardi 29 avril 2003 11:26
=C0 : Andreas.Mattsson@telias= onera.com=20
Cc : erosen@cisco.com; ppvpn@nortelnetworks.com=20
Objet : Re: Support for=20 draft-kompella-ppvpn-vpls-01.txt


Andres,

AFAIK there is no need to configure anything = rather then a=20 site
interface on the PEs. Autodiscovery = will detect=20 new addition and
propagate the news to = all=20 participants. Then in the lasserre-vkompella
scheme=20 directed LDP if not already set get's automatically = established=20
between parties.

Of course the drawback here is that you need to = keep LDP=20 ports open wide
within inter-AS LDP src = ranges which=20 may or may not be an acceptable
issue = :-).=20

R.

> Andreas.Mattsson@teliasonera.com = wrote:=20
>
> Hi = Eric
>
> As I understand it a = requirement=20 would be to have a full mesh of LDP
> = sessions=20 between the PEs in the participating AS domains. This means =
> configuration of each PE when for example a new site = is added to=20 an
> already existing VPN. If BGP is = used this is=20 not necessary as RRs can be
> used, = minimizing=20 the configuration to the new PE and the RR.
> But=20 perhaps there exist a solution similar to this for LDP as well? = It=20
> seems appealing to reuse the 2547bis = structure we have=20 also for VPLS if
> it's = possible.=20
>
> My point is = that further=20 investigation of the two different solutions
>=20 before rejecting one or the other would be good
>=20
> /Andreas
>=20
> -----Original Message----- =
> From: Eric Rosen [mailto:erosen@cisco.com] =
> Sent: den 28 april 2003 16:29
> To:=20 Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 =
> Cc: ppvpn@nortelnetworks.com
>=20 Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt =
>
> Andreas> I = would  also like=20 to  know how inter-AS  with the LDP
>=20 Andreas> approach in lasserre-vkompella is to be solved. =
>
> Could you say what the = issue is=20 that you think needs to be solved?=20

------_=_NextPart_001_01C30E57.BC379A10-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 10:39:03 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24787 for ; Tue, 29 Apr 2003 10:39:02 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TEfK729039 for ; Tue, 29 Apr 2003 10:41:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TEfFt28365 for ; Tue, 29 Apr 2003 10:41:16 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E5C.943AEBE4" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 09:35:28 -0500 Message-ID: <1DA3AEE851515549A5D2C5BD7F8FB2471ED592@PKDWB06C.ad.sprint.com> Thread-Topic: Support for draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMOW9t3Saa1UVibRkaHBwolTnIrhwAAFXmg From: "Nagarajan, Ananth [CC]" To: "Yakov Rekhter" Cc: X-OriginalArrivalTime: 29 Apr 2003 14:35:30.0450 (UTC) FILETIME=[95804F20:01C30E5C] X-SMTP-HELO: smtpgw6.sprintspectrum.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpgw6.sprintspectrum.com [207.40.188.14] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30E5C.943AEBE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yakov, > > > > > > Should this argument then be applied against using LDP for VPLS > > > signaling (even if it is used for MPLS signaling) ? > > > > >=20 > > It could. I guess operators would have to determine which=20 > is the lesser=20 > > of the evils - and I am not denying that you would find=20 > operators on=20 > > both sides of the equation. My point was that one size=20 > doesn't fit all=20 > > - so neither BGP nor LDP is the absolute best solution.=20 > We've got to=20 > > determine which one makes most sense, and that answer is not as=20 > > immediately obvious as some of the comments on this thread=20 > make it out=20 > > to be. >=20 > If you agree that there will be "operators on both sides of the > equation" and that "one size doesn't fit all", then you would > probably also agree that what "makes most sense" for one operator > may not necessarily make most sense for another operator. With > this in mind should "we" really "got to determine which one makes > most sense" ? >=20 Sure - you are saying exactly what I said. Ultimately, whatever = solutions are developed, we've got to decide if it suits us. Again - = all I was saying was that the choice is not as simple as was being = portrayed by posts on this thread. Also, I don't want to derail the thread - I think I made my point. I'll = shut up now. Ananth > Yakov. >=20 > >=20 > > Ananth > >=20 > > >=3D20 > >=20 > > ------_=3D_NextPart_001_01C30E5A.36CB5F0C > > Content-Type: text/html; > > charset=3D"iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > >=20 > > > > > > > > charset=3D3Diso-8859-1"> > > > 6.0.6389.0"> > > RE: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > > >=20 > >

> And what that has to do with=20 > Mourad's observation =3D > > that BGP, and > >=20 > >
Yakov, > >

> >
> >=20 > >

> > In an ideal world, one would=20 > use a washing =3D > > machine that > >=20 > >
> > also washes dishes (stealing=20 > an example =3D > > from an esteemed > >=20 > >
> colleague), but > >=20 > >
> > that hasn't happened=20 > practically. > >=20 > >
> > >=20 > >
> Should this argument then be=20 > applied against =3D > > using LDP for VPLS > >=20 > >
> signaling (even if it is used for MPLS =3D > > signaling) ? > >=20 > >
> > >

> >=20 > >

It could.  I guess operators would have to = =3D > > determine which is the lesser of the evils - and I am not=20 > denying that =3D > > you would find operators on both sides of the=20 > equation.  My point =3D > > was that one size doesn't fit all - so neither BGP nor LDP is the = =3D > > absolute best solution. We've got to determine which one=20 > makes most =3D > > sense, and that answer is not as immediately obvious as=20 > some of the =3D > > comments on this thread make it out to be.

> >=20 > >

Ananth > >

> >=20 > >

> > >

> >=20 > > > > > > ------_=3D_NextPart_001_01C30E5A.36CB5F0C-- >=20 ------_=_NextPart_001_01C30E5C.943AEBE4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

Yakov,

> > >
> > > Should this argument then be applied = against using LDP for VPLS
> > > signaling (even if it is used for MPLS = signaling) ?
> > >
> >
> > It could.  I guess operators would = have to determine which
> is the lesser
> > of the evils - and I am not denying that = you would find
> operators on
> > both sides of the equation.  My point = was that one size
> doesn't fit all
> > - so neither BGP nor LDP is the absolute = best solution.
> We've got to
> > determine which one makes most sense, and = that answer is not as
> > immediately obvious as some of the comments = on this thread
> make it out
> > to be.
>
> If you agree that there will be "operators = on both sides of the
> equation" and that "one size doesn't = fit all", then you would
> probably also agree that what "makes most = sense" for one operator
> may not necessarily make most sense for another = operator. With
> this in mind should "we" really = "got to determine which one makes
> most sense" ?
>

Sure - you are saying exactly what I said. Ultimately, = whatever solutions are developed, we've got to decide if it suits = us.  Again - all I was saying was that the choice is not as simple = as was being portrayed by posts on this thread.

Also, I don't want to derail the thread - I think I = made my point. I'll shut up now.

Ananth


> Yakov.
>
> >
> > Ananth
> >
> > >=3D20
> >
> > = ------_=3D_NextPart_001_01C30E5A.36CB5F0C
> > Content-Type: text/html;
> >     = charset=3D"iso-8859-1"
> > Content-Transfer-Encoding: = quoted-printable
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD = HTML 3.2//EN">
> <HTML>
> > <HEAD>
> > <META = HTTP-EQUIV=3D3D"Content-Type" CONTENT=3D3D"text/html; = =3D
> > charset=3D3Diso-8859-1">
> > <META NAME=3D3D"Generator" = CONTENT=3D3D"MS Exchange Server version =3D
> > 6.0.6389.0">
> > <TITLE>RE: Support for = draft-kompella-ppvpn-vpls-01.txt </TITLE>
> > </HEAD>
> > <BODY>
> > <!-- Converted from text/plain format = -->
> >
> > <P><FONT SIZE=3D3D2>&gt; = And what that has to do with
> Mourad's observation =3D
> > that BGP, and</FONT>
> >
> > <BR><FONT = SIZE=3D3D2>Yakov,</FONT>
> > </P>
> > <BR>
> >
> > <P><FONT SIZE=3D3D2>&gt; = &gt; In an ideal world, one would
> use a washing =3D
> > machine that </FONT>
> >
> > <BR><FONT SIZE=3D3D2>&gt; = &gt; also washes dishes (stealing
> an example =3D
> > from an esteemed </FONT>
> >
> > <BR><FONT SIZE=3D3D2>&gt; = colleague), but </FONT>
> >
> > <BR><FONT SIZE=3D3D2>&gt; = &gt; that hasn't happened
> practically.</FONT>
> >
> > <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> >
> > <BR><FONT SIZE=3D3D2>&gt; = Should this argument then be
> applied against =3D
> > using LDP for VPLS</FONT>
> >
> > <BR><FONT SIZE=3D3D2>&gt; = signaling (even if it is used for MPLS =3D
> > signaling) ?</FONT>
> >
> > <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> > </P>
> >
> > <P><FONT SIZE=3D3D2>It = could.&nbsp; I guess operators would have to =3D
> > determine which is the lesser of the evils = - and I am not
> denying that =3D
> > you would find operators on both sides of = the
> equation.&nbsp; My point =3D
> > was that one size doesn't fit all - so = neither BGP nor LDP is the =3D
> > absolute best solution. We've got to = determine which one
> makes most =3D
> > sense, and that answer is not as = immediately obvious as
> some of the =3D
> > comments on this thread make it out to = be.</FONT></P>
> >
> > <P><FONT = SIZE=3D3D2>Ananth</FONT>
> > </P>
> >
> > <P><FONT SIZE=3D3D2>&gt; = </FONT>
> > </P>
> >
> > </BODY>
> > </HTML>
> > = ------_=3D_NextPart_001_01C30E5A.36CB5F0C--
>

------_=_NextPart_001_01C30E5C.943AEBE4-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 10:42: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 KAA25139 for ; Tue, 29 Apr 2003 10:42:24 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TEig702484 for ; Tue, 29 Apr 2003 10:44:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TEiZt02053 for ; Tue, 29 Apr 2003 10:44:35 -0400 (EDT) Message-Id: <200304291434.h3TEYLHo024195@rtp-core-1.cisco.com> To: Mourad BERKANE cc: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Tue, 29 Apr 2003 13:55:06 +0200. <8D91FF5277472A45A0A8F9654A14649701494990@frlnparexcha03.lambdanet.fr> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 10:34:21 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Mourad> MP-BGP is much more designed for a *public* inter-AS session for Mourad> VPLS. Could you tell us exactly which features of BGP you are referring to here? Please be specific. Mourad> Even if LDP/RSVP already present for the forwarding plane inside a Mourad> MPLS domain, why should i used LDP for VPLS signalling when BGP Mourad> already do the job (IPv4,v6,rfc2547bis,...)??? In several previous messages, I tried to give some specific examples of signaling interactions that BGP cannot do or cannot do well. Mourad> LDP is not used as a signaling protocol for IPv4, I don't know why you would say this. LDP is primarily used today to bind MPLS labels to IPv4 routes. I'm not sure why you say it is "not used as a signaling protocol for IPv4". Mourad> or rfc2547bis :-) BGP is in charge of it (and do the job very Mourad> well). So, if BGP is good for 2547, it must be good for VPLS too? Isn't that the issue under discussion? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 10:43: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 KAA25307 for ; Tue, 29 Apr 2003 10:43:58 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TEkG703754 for ; Tue, 29 Apr 2003 10:46:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TEkAH03698 for ; Tue, 29 Apr 2003 10:46:10 -0400 (EDT) Message-Id: <5.2.0.9.2.20030429101924.027604f8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Apr 2003 10:20:41 -0400 To: Siddharth Aanand , Shiv Agarwal From: "Thomas D. Nadeau" Subject: RE: Question regdg. MPLS/BGP VPN MIB Cc: ppvpn@nortelnetworks.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: At 06:03 PM 4/28/2003 -0400, Siddharth Aanand wrote: >Shiv, > > > > > Without this additional index how else can you determine as to which > > interface is mapped to which VRF? > >I am assuming that at the interface creation time it gets assigned to a >VRF. This is not a correct assumption. Interfaces (or sub-interfaces) may be bound to or associated with a VRF much later. It depends on the configuration. Also, associations may change. --Tom >For rest of the VPN related configuration (which is what this >table seems to be used for), having the interface index is sufficient to >determine the VRF as well. >-Sidd > > > > > Though if a VRF is modeled like a VR with a separate context, then this > information may not be necessary as the VRF can then be determined by the > SNMP context. > > > > Shiv. > > > > -----Original Message----- > > From: Siddharth Aanand [mailto:saanand@pit.comms.marconi.com] > > Sent: Monday, April 28, 2003 2:37 PM > > To: ppvpn@nortelnetworks.com > > Subject: Question regdg. MPLS/BGP VPN MIB > > > > > > > > The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > > mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had > > was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > > identify a row in this table ? Under what circumstances do we need both > > the vrfName as well as the ifIndex as keys? > > > > thanks, > > -Sidd > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 10:50:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25917 for ; Tue, 29 Apr 2003 10:50:05 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TEqN705686 for ; Tue, 29 Apr 2003 10:52:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TEqIH10014 for ; Tue, 29 Apr 2003 10:52:18 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E5A.36CB5F0C" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 09:18:32 -0500 Message-ID: <1DA3AEE851515549A5D2C5BD7F8FB2471FF2B8@PKDWB06C.ad.sprint.com> Thread-Topic: Support for draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMOVC0p136Hn3nwTGu8Fdacj1tYEgABP77A From: "Nagarajan, Ananth [CC]" To: , "Yakov Rekhter" X-OriginalArrivalTime: 29 Apr 2003 14:18:33.0747 (UTC) FILETIME=[377FBE30:01C30E5A] X-SMTP-HELO: smtpgw6.sprintspectrum.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpgw6.sprintspectrum.com [207.40.188.14] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30E5A.36CB5F0C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > And what that has to do with Mourad's observation that BGP, and Yakov, > > In an ideal world, one would use a washing machine that=20 > > also washes dishes (stealing an example from an esteemed=20 > colleague), but=20 > > that hasn't happened practically. >=20 > Should this argument then be applied against using LDP for VPLS > signaling (even if it is used for MPLS signaling) ? >=20 It could. I guess operators would have to determine which is the lesser = of the evils - and I am not denying that you would find operators on = both sides of the equation. My point was that one size doesn't fit all = - so neither BGP nor LDP is the absolute best solution. We've got to = determine which one makes most sense, and that answer is not as = immediately obvious as some of the comments on this thread make it out = to be. Ananth >=20 ------_=_NextPart_001_01C30E5A.36CB5F0C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

> And what that has to do with Mourad's observation = that BGP, and
Yakov,


> > In an ideal world, one would use a washing = machine that
> > also washes dishes (stealing an example = from an esteemed
> colleague), but
> > that hasn't happened practically.
>
> Should this argument then be applied against = using LDP for VPLS
> signaling (even if it is used for MPLS = signaling) ?
>

It could.  I guess operators would have to = determine which is the lesser of the evils - and I am not denying that = you would find operators on both sides of the equation.  My point = was that one size doesn't fit all - so neither BGP nor LDP is the = absolute best solution. We've got to determine which one makes most = sense, and that answer is not as immediately obvious as some of the = comments on this thread make it out to be.

Ananth

>

------_=_NextPart_001_01C30E5A.36CB5F0C-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 10:52:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26176 for ; Tue, 29 Apr 2003 10:52:50 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TEt8708147 for ; Tue, 29 Apr 2003 10:55:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TEt4H12969 for ; Tue, 29 Apr 2003 10:55:04 -0400 (EDT) Message-Id: <5.2.0.9.2.20030429101754.02752558@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Apr 2003 10:18:54 -0400 To: Siddharth Aanand , ppvpn@nortelnetworks.com From: "Thomas D. Nadeau" Subject: Re: Question regdg. MPLS/BGP VPN MIB In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: >The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and >mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had >was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely >identify a row in this table ? Under what circumstances do we need both >the vrfName as well as the ifIndex as keys? Yes, but the operational feedback was that operators wanted to cycle through interfaces belonging to each VRF. We need to update this slightly because there are cases where one interface may belong to multiple VRFs. --Tom From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 10:58:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26379 for ; Tue, 29 Apr 2003 10:58:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TF11713415 for ; Tue, 29 Apr 2003 11:01:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TF0gh21406 for ; Tue, 29 Apr 2003 11:00:43 -0400 (EDT) Message-Id: <200304291425.h3TEPdHo020975@rtp-core-1.cisco.com> To: Andreas.Mattsson@teliasonera.com cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Tue, 29 Apr 2003 10:53:45 +0200. <7B64D9FB62EB42449683BA51E9AB2AE8DB7E30@TMS031MB.tcad.telia.se> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 10:25:37 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Andreas> As I understand it a requirement would be to have a full mesh of Andreas> LDP sessions between the PEs in the participating AS domains. This Andreas> means configuration of each PE when for example a new site is added Andreas> to an already existing VPN. As Robert has pointed out, the auto-discovery procedure (BGP, Radius, or whatever) would dynamically produce the list of PEs, and the targeted LDP sessions would then be created automatically. The configuration and provisioning model is exactly the same in both schemes, so this is not a reason to prefer one signaling protocol over another. You might want to look at draft-rosen-ppvpn-l2-signaling, which explains how every provisioning and configuration model we've ever discussed can be accommodated by point-to-point signaling. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 11:09:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26957 for ; Tue, 29 Apr 2003 11:08:59 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TFBI719168 for ; Tue, 29 Apr 2003 11:11:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TFBAh20585 for ; Tue, 29 Apr 2003 11:11:11 -0400 (EDT) Message-Id: <200304291429.h3TETqu86182@merlot.juniper.net> To: "Nagarajan, Ananth [CC]" cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 09:18:32 CDT." <1DA3AEE851515549A5D2C5BD7F8FB2471FF2B8@PKDWB06C.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42618.1051626591.1@juniper.net> Date: Tue, 29 Apr 2003 07:29:51 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Ananth, > > And what that has to do with Mourad's observation that BGP, and > Yakov, > > > > In an ideal world, one would use a washing machine that=20 > > > also washes dishes (stealing an example from an esteemed=20 > > colleague), but > > > that hasn't happened practically. > > > > Should this argument then be applied against using LDP for VPLS > > signaling (even if it is used for MPLS signaling) ? > > > > It could. I guess operators would have to determine which is the lesser > of the evils - and I am not denying that you would find operators on > both sides of the equation. My point was that one size doesn't fit all > - so neither BGP nor LDP is the absolute best solution. We've got to > determine which one makes most sense, and that answer is not as > immediately obvious as some of the comments on this thread make it out > to be. If you agree that there will be "operators on both sides of the equation" and that "one size doesn't fit all", then you would probably also agree that what "makes most sense" for one operator may not necessarily make most sense for another operator. With this in mind should "we" really "got to determine which one makes most sense" ? Yakov. > > Ananth > > >=20 > > ------_=_NextPart_001_01C30E5A.36CB5F0C > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Diso-8859-1"> > 6.0.6389.0"> > RE: Support for draft-kompella-ppvpn-vpls-01.txt > > > > >

> And what that has to do with Mourad's observation = > that BGP, and > >
Yakov, >

>
> >

> > In an ideal world, one would use a washing = > machine that > >
> > also washes dishes (stealing an example = > from an esteemed > >
> colleague), but > >
> > that hasn't happened practically. > >
> > >
> Should this argument then be applied against = > using LDP for VPLS > >
> signaling (even if it is used for MPLS = > signaling) ? > >
> >

> >

It could.  I guess operators would have to = > determine which is the lesser of the evils - and I am not denying that = > you would find operators on both sides of the equation.  My point = > was that one size doesn't fit all - so neither BGP nor LDP is the = > absolute best solution. We've got to determine which one makes most = > sense, and that answer is not as immediately obvious as some of the = > comments on this thread make it out to be.

> >

Ananth >

> >

> >

> > > > ------_=_NextPart_001_01C30E5A.36CB5F0C-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 11:21:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27411 for ; Tue, 29 Apr 2003 11:21:30 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TFNm725740 for ; Tue, 29 Apr 2003 11:23:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TFNi725189 for ; Tue, 29 Apr 2003 11:23:45 -0400 (EDT) Date: Tue, 29 Apr 2003 10:46:55 -0400 (EDT) From: Siddharth Aanand X-X-Sender: saanand@boysenberry To: "Thomas D. Nadeau" cc: ppvpn@nortelnetworks.com Subject: Re: Question regdg. MPLS/BGP VPN MIB In-Reply-To: <5.2.0.9.2.20030429101754.02752558@bucket.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: saanand@pit.comms.marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: > >The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > >mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had > >was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > >identify a row in this table ? Under what circumstances do we need both > >the vrfName as well as the ifIndex as keys? > > Yes, but the operational feedback was that operators > wanted to cycle through interfaces belonging to each VRF. > We need to update this slightly because there are cases where > one interface may belong to multiple VRFs. Yes. If one interface belongs to multiple VRFs then we'd need the vrfName as a key. Do you know what distinguishing feature of the incoming traffic, on that interface, would be used to decide which VRF to use? -Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 11:28:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27699 for ; Tue, 29 Apr 2003 11:28:39 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TFUu702138 for ; Tue, 29 Apr 2003 11:30:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TFUq913368 for ; Tue, 29 Apr 2003 11:30:53 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E63.689B8B1C" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 10:24:21 -0500 Message-ID: <1DA3AEE851515549A5D2C5BD7F8FB2471ED595@PKDWB06C.ad.sprint.com> Thread-Topic: Support for draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMOX+tBIP4+exkjTGSDniOuNVZaRQAA1QiA From: "Nagarajan, Ananth [CC]" To: "Yakov Rekhter" Cc: X-OriginalArrivalTime: 29 Apr 2003 15:24:25.0528 (UTC) FILETIME=[6AF1AB80:01C30E63] X-SMTP-HELO: smtpgw5.sprintspectrum.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpgw5.sprintspectrum.com [207.40.188.13] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30E63.689B8B1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=20 > And just to be crystal clear - the choice is up to *individual* > providers. >=20 No arguments there. But unlike the above statement, the choice itself = is not crystal clear :-) Ananth ------_=_NextPart_001_01C30E63.689B8B1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

>
> And just to be crystal clear - the choice is up = to *individual*
> providers.
>

No arguments there.  But unlike the above = statement, the choice itself is not crystal clear :-)

Ananth

------_=_NextPart_001_01C30E63.689B8B1C-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 11:45:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28154 for ; Tue, 29 Apr 2003 11:45:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TFlR709555 for ; Tue, 29 Apr 2003 11:47:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TFlJN00208 for ; Tue, 29 Apr 2003 11:47:19 -0400 (EDT) Message-Id: <200304291536.h3TFaUYg005802@rtp-core-1.cisco.com> To: Mourad BERKANE cc: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Tue, 29 Apr 2003 17:23:28 +0200. <8D91FF5277472A45A0A8F9654A14649701494999@frlnparexcha03.lambdanet.fr> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 11:36:30 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Eric> Could you tell us exactly which features of BGP you are referring to Eric> here? Please be specific. Mourad> VPLS autodiscovery and signaling over 2 different networks Well, no one is proposing to use LDP for VPLS autodiscovery. And one can use LDP between two different networks as easily as one can use BGP between two different networks. Mourad> If the forwarding plane is MPLS then LDP could be used as MPLS Mourad> signaling protocol but in this case LDP is not used for Mourad> signaling/controling IPv4 routes, LDP isn t a routing protocol Certainly it's true that LDP is NOT a routing protocol, and that BGP IS a routing protocol. It's also true that both are used, in varying circumstances, for distributing MPLS labels. As VPLS does not require a routing protocol, I'm not sure how one is supposed to conclude from this that BGP is a better signaling protocol for VPLS. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 11:55:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28700 for ; Tue, 29 Apr 2003 11:55:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TFvp718014 for ; Tue, 29 Apr 2003 11:57:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TFvlN10747 for ; Tue, 29 Apr 2003 11:57:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16046.41048.835166.995600@harjus.eng.song.fi> Date: Tue, 29 Apr 2003 18:55:04 +0300 To: "Nagarajan, Ananth [CC]" Cc: , "Yakov Rekhter" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: <1DA3AEE851515549A5D2C5BD7F8FB2471FF2B8@PKDWB06C.ad.sprint.com> References: <1DA3AEE851515549A5D2C5BD7F8FB2471FF2B8@PKDWB06C.ad.sprint.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Nagarajan, Ananth [CC] writes: > I guess operators would have to determine which is the > lesser of the evils - and I am not denying that you would find > operators on both sides of the equation. My point was that one size > doesn't fit all - so neither BGP nor LDP is the absolute best > solution. We've got to determine which one makes most sense, and that > answer is not as immediately obvious as some of the comments on this > thread make it out to be. rather than choosing a lesser evil, how about choosing the good solution: radius + l2tp. should be a perfect match especially for sprint, which recently announced an l2tp based vpn solution. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 11:58:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28771 for ; Tue, 29 Apr 2003 11:58:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TG0J726995 for ; Tue, 29 Apr 2003 12:00:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TG0DY14890 for ; Tue, 29 Apr 2003 12:00:13 -0400 (EDT) Message-Id: <200304291457.h3TEvmu87628@merlot.juniper.net> To: "Nagarajan, Ananth [CC]" cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 09:35:28 CDT." <1DA3AEE851515549A5D2C5BD7F8FB2471ED592@PKDWB06C.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <49812.1051628268.1@juniper.net> Date: Tue, 29 Apr 2003 07:57:48 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Ananth, > Yakov, > > > > > > > > > Should this argument then be applied against using LDP for VPLS > > > > signaling (even if it is used for MPLS signaling) ? > > > > > > > > > > It could. I guess operators would have to determine which=20 > > > is the lesser > > > of the evils - and I am not denying that you would find=20 > > > operators on > > > both sides of the equation. My point was that one size=20 > > > doesn't fit all > > > - so neither BGP nor LDP is the absolute best solution.=20 > > > We've got to > > > determine which one makes most sense, and that answer is not as > > > immediately obvious as some of the comments on this thread > > > make it out > > > to be. > > > > If you agree that there will be "operators on both sides of the > > equation" and that "one size doesn't fit all", then you would > > probably also agree that what "makes most sense" for one operator > > may not necessarily make most sense for another operator. With > > this in mind should "we" really "got to determine which one makes > > most sense" ? > > Sure - you are saying exactly what I said. Ultimately, whatever > solutions are developed, we've got to decide if it suits us. Again - > all I was saying was that the choice is not as simple as was being > portrayed by posts on this thread. And just to be crystal clear - the choice is up to *individual* providers. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:00: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 MAA28844 for ; Tue, 29 Apr 2003 12:00:21 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TG2e710685 for ; Tue, 29 Apr 2003 12:02:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TG2XY20659 for ; Tue, 29 Apr 2003 12:02:34 -0400 (EDT) Reply-To: From: "Vach Kompella" To: , "Mourad BERKANE" Cc: , , Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 08:55:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <3EAE6E6A.E0F1609C@cisco.com> X-OriginalArrivalTime: 29 Apr 2003 15:55:23.0967 (UTC) FILETIME=[BEA8F4F0:01C30E67] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Robert, > > Well I am taking a higher level view and honestly I am not biased > towards either BGP or LDP used for signaling. In fact as I said both > should proceed forward especially in the VPLS application. > > Now reg your comment that BGP is more designed for a public inter-as I > can only agree ;). Coming very soon for BGP MD5 key exchanges > improvements for operators making something hard to exchange today will > be much easier tomorrow. The MD5 protection is at the TCP level, not at the BGP level. LDP security through the use of MD5 is advocated in RFC3036. I would, of course, prefer that IPSEC be used, but the argument there is that TCP MD5 exists and works fine. > > With LDP any serious deployment should consider MD5 and correlation of > all the keys on ALL of your and your peers PEs will be by all means much > more challenging exercise :). Using blank directed LDP without > protection could be fine within AS but inter-as (even to your trusted > peer ... I don't know). And of course fact that you run LDP for regular > forwarding or not is pretty much orthogonal to the exercise here. My last discussion with some graybeards at the IETF showed that there was no strong inclination towards using MD5 inter-AS for BGP. Does this persist? > > Cheers, > R. > -Vach From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:04:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28989 for ; Tue, 29 Apr 2003 12:04:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TG6i701390 for ; Tue, 29 Apr 2003 12:06:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TG6dY01426 for ; Tue, 29 Apr 2003 12:06:39 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A1464970149499A@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'erosen@cisco.com'" Cc: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 17:51:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E67.2898D1B0" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30E67.2898D1B0 Content-Type: text/plain; charset="iso-8859-1" Eric> Certainly it's true that LDP is NOT a routing protocol, and that BGP IS a Eric> routing protocol. It's also true that both are used, in varying Eric> circumstances, for distributing MPLS labels. As VPLS does not require a Eric> routing protocol, I'm not sure how one is supposed to conclude from this Eric> that BGP is a better signaling protocol for VPLS. If you consider VPLS service without others ones then OK both LDP and BGP could be used as signaling protocol I can add that as you said LDP is not able to autodiscovery but BGP could How will planed to offer VPLS service whitout IPv4 v6 L3VPN L2VPN ???? Now if you consider VPLS on a multiservices network then you will conclude that BGP is more than well positionned for the control plane of theses multiservices ------_=_NextPart_001_01C30E67.2898D1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

Eric> Certainly it's true  that LDP is = NOT  a routing protocol, and that  BGP IS a
Eric> routing  protocol.   = It's   also  true  that  both  = are   used,  in  varying
Eric> circumstances, for  distributing = MPLS  labels.  As VPLS  does not  require a
Eric> routing protocol,  I'm not sure  = how one is  supposed to conclude  from this
Eric> that BGP is a better signaling protocol for = VPLS.


If you consider VPLS service without others ones then = OK both LDP and BGP could be used as signaling protocol
I can add that as you said LDP is not able to = autodiscovery but BGP could

How will planed to offer VPLS service whitout IPv4 v6 = L3VPN L2VPN ????

Now if you consider VPLS on a multiservices network = then you will conclude that BGP is more than well positionned for the = control plane of theses multiservices

------_=_NextPart_001_01C30E67.2898D1B0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:10:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29229 for ; Tue, 29 Apr 2003 12:10:19 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TGCc706500 for ; Tue, 29 Apr 2003 12:12:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TGCRY16127 for ; Tue, 29 Apr 2003 12:12:27 -0400 (EDT) Message-Id: <5.2.0.9.2.20030429105728.0273a040@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Apr 2003 10:59:36 -0400 To: Siddharth Aanand From: "Thomas D. Nadeau" Subject: Re: Question regdg. MPLS/BGP VPN MIB Cc: ppvpn@nortelnetworks.com, "Harmen Van der Linde"hvdl@att.com In-Reply-To: References: <5.2.0.9.2.20030429101754.02752558@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: At 10:46 AM 4/29/2003 -0400, Siddharth Aanand wrote: > > >The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > > >mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had > > >was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > > >identify a row in this table ? Under what circumstances do we need both > > >the vrfName as well as the ifIndex as keys? > > > > Yes, but the operational feedback was that operators > > wanted to cycle through interfaces belonging to each VRF. > > We need to update this slightly because there are cases where > > one interface may belong to multiple VRFs. > >Yes. If one interface belongs to multiple VRFs then we'd need the vrfName >as a key. Do you know what distinguishing feature of the incoming traffic, >on that interface, would be used to decide which VRF to use? I think that is orthogonal to the discussion at hand. What is important is that the MIB can handle these cases without regard to how the choice is being made. The reason being that it is often a proprietary feature/configuration that does the choosing. My implementation for instance, uses several rules to make this determination. I know of another that makes a simple choice based on source address. --Tom >-Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:17:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29576 for ; Tue, 29 Apr 2003 12:17:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TGJr711601 for ; Tue, 29 Apr 2003 12:19:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TGJgn03909 for ; Tue, 29 Apr 2003 12:19:42 -0400 (EDT) Message-ID: <3EAE9694.34251DD@cisco.com> Date: Tue, 29 Apr 2003 08:13:24 -0700 From: Wei Luo X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN MIME-Version: 1.0 To: Mourad BERKANE CC: "'jeremy.de_clercq@alcatel.be'" , ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: <8D91FF5277472A45A0A8F9654A14649701494995@frlnparexcha03.lambdanet.fr> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-2.cisco.com id h3TFDQQi003593 X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: luo@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA29576 Why is it so evil to have inter-AS connectivity and open up LDP ports? Suppose service providers want to provide pseudowire services including point-to-point and VPLS across multi-AS non-MPLS network, i.e. IP only. The non-MPLS pseudowire signaling protocol is L2TPv3, which is a point-to-point protocol. It also requires inter-AS connectivity and to open up L2TPv3 ports. It seems that by your way of reasoning, we should use BGP to set up L2TP tunnels in an inter-AS environment as well? ---Wei > Mourad BERKANE wrote: > > Hi Jeremy > > (sorry about the non confusion) > > The "argument" is that today Providers don't (want to) have a (useless) LDP > peering sessions for VPLS application because BGP already present between > Providers (IP world). > > Suppose you would like to extend a VPLS domain out of your network, you will > need to extend signaling between theses networks ("hi i am PE1 from Carrier A > ASN=1 and I would like to join VPLS Z in your domain Carrier B ASN=2, please > use label L to send traffic to me"). The fact is that Carrier A and Carrier B > could already communicated over IPv4 Public network: a BGP session already > exist between A and B and could be used for many services (v4,v6,2547bis AND > VPLS) > > If you use BGP as VPLS signaling protocols, you will need to setup a MP-eBGP > session between AS > --> re use of existing BGP session between A and B > > Forwarding Tunnels used proposed in draft-kompella-ppvpn-vpls could be MPLS,IP > or GRE tunnels between A and B. > Someone who don't (or can't) discuss LDP could be a candidate for an extension > of a VPLS domain since the signaling protocol is BGP :-) > > If you use LDP as VPLS signaling protocols, you will need to open LDP ports > between A and B. > This new session is dedicated to VPLS services. Of course, It work but why > should I manage/troubleshoot this LDP inter-AS sessions since BGP already > present for others services? > > Mourad > > -----Message d'origine----- > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > Envoyé : mardi 29 avril 2003 15:03 > À : Mourad BERKANE > Cc : ppvpn@nortelnetworks.com > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > Hi Mourad, > > > LDP is not used as a signaling protocol for IPv4, IPv6 or > > rfc2547bis :-) > > BGP is in charge of it (and do the job very well). > > BGP distributes routes, it doesn't establish Pseudo-Wires in the > examples you give. > > > May be this will clarify all theses exchanges about signalling in > > VPLS: adding a new signaling protocol (LDP) whitout any added value > > versus keeping the same signalling protocol (BGP) for differents > > services (IP,rfc2547bis,VPLS, futures needs) > > > > You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling > > (LDP or BGP)? > > I'm sure I was not confused by the above ;-) > > What I meant was that LDP is used for pseudo-wire signaling > (http://www.ietf.org/html.charters/pwe3-charter.html, "Pseudo-Wire Setup > and Maintenance using LDP"), and that VPLS uses pseudo-wires. > > So arguments that say "BGP because it is also used for X" or "LDP > because it is also used for Y" are not convincing enough for me, as > you'll have BGP in some environments (2547) and LDP in other > environments (PWE3) and LDP + BGP in many environments ;-) > > What I really wanted to know is what the difference is for inter-AS > applications, as this seems to be one of the *technical* arguments. > > Jeremy. > > > > > Mourad > > > > -----Message d'origine----- > > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > > Envoyé : mardi 29 avril 2003 14:19 > > À : Mourad BERKANE > > Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; > > erosen@cisco.com; ppvpn@nortelnetworks.com > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Mourad, > > > > > As you hinted here, MP-BGP is much more designed for a *public* > > > inter-AS session for VPLS. > > > > I still don't understand why MP-BGP is more appropriate than LDP for > > this application. I probably need more than a "hint" to fully > > understand > > it ;-) > > > > > Even if LDP/RSVP already present for the forwarding plane inside a > > > MPLS domain, why should i used LDP for VPLS signalling when BGP > > > already do the job (IPv4,v6,rfc2547bis,...)??? > > > > You can turn this around: Even if BGP is already present for 2547bis, > > v4, v6 etc, why should I use BGP for VPLS signaling when LDP already > > does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 > > Pseudo-Wires, ...) ? > > > > [I guess the answer to both of the above questions is given in the > > large > > number of previous emails on this topic ;-)] > > > > Jeremy. > > > > > Mourad > > > > > > -----Message d'origine----- > > > De : Robert Raszuk [mailto:raszuk@cisco.com] > > > Envoyé : mardi 29 avril 2003 11:26 > > > À : Andreas.Mattsson@teliasonera.com > > > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > Andres, > > > > > > AFAIK there is no need to configure anything rather then a site > > > interface on the PEs. Autodiscovery will detect new addition and > > > propagate the news to all participants. Then in the > > lasserre-vkompella > > > > > > scheme directed LDP if not already set get's automatically > > established > > > > > > between parties. > > > > > > Of course the drawback here is that you need to keep LDP ports open > > > wide > > > within inter-AS LDP src ranges which may or may not be an acceptable > > > > > issue :-). > > > > > > R. > > > > > > > Andreas.Mattsson@teliasonera.com wrote: > > > > > > > > Hi Eric > > > > > > > > As I understand it a requirement would be to have a full mesh of > > LDP > > > > > > > sessions between the PEs in the participating AS domains. This > > means > > > > > > > configuration of each PE when for example a new site is added to > > an > > > > already existing VPN. If BGP is used this is not necessary as RRs > > > can be > > > > used, minimizing the configuration to the new PE and the RR. > > > > But perhaps there exist a solution similar to this for LDP as > > well? > > > It > > > > seems appealing to reuse the 2547bis structure we have also for > > VPLS > > > if > > > > it's possible. > > > > > > > > My point is that further investigation of the two different > > > solutions > > > > before rejecting one or the other would be good > > > > > > > > /Andreas > > > > > > > > -----Original Message----- > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > Sent: den 28 april 2003 16:29 > > > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > > > Cc: ppvpn@nortelnetworks.com > > > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > > > Andreas> I would also like to know how inter-AS with the LDP > > > > Andreas> approach in lasserre-vkompella is to be solved. > > > > > > > > Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:41:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00370 for ; Tue, 29 Apr 2003 12:41:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TGhG722414 for ; Tue, 29 Apr 2003 12:43:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TGh8I22286 for ; Tue, 29 Apr 2003 12:43:08 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E68.D7CA4624" Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 11:03:15 -0500 Message-ID: <1DA3AEE851515549A5D2C5BD7F8FB2471ED596@PKDWB06C.ad.sprint.com> Thread-Topic: Support for draft-kompella-ppvpn-vpls-01.txt Thread-Index: AcMOZ55zG6A8UTHlQlqdaGZsHcVRdgAANgZg From: "Nagarajan, Ananth [CC]" To: "Juha Heinanen" Cc: , "Yakov Rekhter" X-OriginalArrivalTime: 29 Apr 2003 16:03:16.0388 (UTC) FILETIME=[D83EAE40:01C30E68] X-SMTP-HELO: smtpgw6.sprintspectrum.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtpgw6.sprintspectrum.com [207.40.188.14] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C30E68.D7CA4624 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juha, >=20 > > I guess operators would have to determine which is the > > lesser of the evils - and I am not denying that you would find > > operators on both sides of the equation. My point was=20 > that one size > > doesn't fit all - so neither BGP nor LDP is the absolute best > > solution. We've got to determine which one makes most=20 > sense, and that > > answer is not as immediately obvious as some of the=20 > comments on this > > thread make it out to be. >=20 > rather than choosing a lesser evil, how about choosing the good > solution: radius + l2tp. should be a perfect match especially for > sprint, which recently announced an l2tp based vpn solution. >=20 Of course. My point was regarding the specific vpls proposal that was = being discussed on the thread -I should have said - if you have an = mpls-based vpls, then we have to choose between the lesser of the evils = :-) Ananth ------_=_NextPart_001_01C30E68.D7CA4624 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

Juha,


>
>  > I guess operators would have to = determine which is the
>  > lesser of the evils - and I am not = denying that you would find
>  > operators on both sides of the = equation.  My point was
> that one size
>  > doesn't fit all - so neither BGP nor = LDP is the absolute best
>  > solution. We've got to determine = which one makes most
> sense, and that
>  > answer is not as immediately obvious = as some of the
> comments on this
>  > thread make it out to be.
>
> rather than choosing a lesser evil, how about = choosing the good
> solution: radius + l2tp.  should be a = perfect match especially for
> sprint, which recently announced an l2tp based = vpn solution.
>

Of course.  My point was regarding the specific = vpls proposal that was being discussed on the thread -I should have said = - if you have an mpls-based vpls, then we have to choose between the = lesser of the evils :-)

Ananth

------_=_NextPart_001_01C30E68.D7CA4624-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:45:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00575 for ; Tue, 29 Apr 2003 12:45:34 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TGlp726729 for ; Tue, 29 Apr 2003 12:47:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TGlkA27045 for ; Tue, 29 Apr 2003 12:47:46 -0400 (EDT) Message-ID: <3EAEA274.80E5BEA@cisco.com> Date: Tue, 29 Apr 2003 18:04:04 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vkompella@timetra.com CC: Mourad BERKANE , Andreas.Mattsson@teliasonera.com, erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, > The MD5 protection is at the TCP level, not at the BGP level. LDP security > through the use of MD5 is advocated in RFC3036. I would, of course, prefer that > IPSEC be used, but the argument there is that TCP MD5 exists and works fine. :) ... of course it is for TCP :)... But there could be a slight difference in number of TCP sessions you maintain in the BGP versus LDP proposals (especially those TCP which do cross inter-as boundary), hence number of TCP peers you need to somehow agree on using the same keys. Not too mention that there is clear desire to change those keys periodically which doesn't make the key maintenance between all PEs easier. > My last discussion with some graybeards at the IETF showed that there was no > strong inclination towards using MD5 inter-AS for BGP. Does this persist? Well at IETF I usually stay focused to talk to operators & service providers rather then graybeards ...;) R. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:50:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00975 for ; Tue, 29 Apr 2003 12:50:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TGqx701302 for ; Tue, 29 Apr 2003 12:52:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TGqtA02383 for ; Tue, 29 Apr 2003 12:52:55 -0400 (EDT) Message-Id: <200304291607.h3TG7qu91994@merlot.juniper.net> To: erosen@cisco.com cc: Mourad BERKANE , "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 11:36:30 EDT." <200304291536.h3TFaUYg005802@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68627.1051632472.1@juniper.net> Date: Tue, 29 Apr 2003 09:07:52 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Eric, > Eric> Could you tell us exactly which features of BGP you are referring to > Eric> here? Please be specific. > > Mourad> VPLS autodiscovery and signaling over 2 different networks > > Well, no one is proposing to use LDP for VPLS autodiscovery. From draft-lasserre-vkompella-ppvpn-vpls-04.txt (please pay attention to "[LDP-DISC]"): 6. Discovery Currently, no discovery mechanism has been prescribed for VPLS. There are three potential candidates, [BGP-DISC], [DNS-DISC], [LDP- DISC]. > And one can > use LDP between two different networks as easily as one can use BGP between > two different networks. Not really. One difference is in the issue of using TCP MD5 for authentication. > Mourad> If the forwarding plane is MPLS then LDP could be used as MPLS > Mourad> signaling protocol but in this case LDP is not used for > Mourad> signaling/controling IPv4 routes, LDP isn t a routing protocol > > Certainly it's true that LDP is NOT a routing protocol, and that BGP IS a > routing protocol. It's also true that both are used, in varying > circumstances, for distributing MPLS labels. As VPLS does not require a > routing protocol, I'm not sure how one is supposed to conclude from this > that BGP is a better signaling protocol for VPLS. As I (as well as other folks) said several times before, it is not that meaningful to compare LDP vs BGP just for signaling - one needs to take the whole system into perspective. And the whole system includes not just signaling but autodiscovery as well. So, a meanigful comparison should be BGP for both signaling and autodiscovery vs BGP for autodiscovery + LDP for signaling. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 12:58:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01295 for ; Tue, 29 Apr 2003 12:58:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TH0O713497 for ; Tue, 29 Apr 2003 13:00:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TH0J712238 for ; Tue, 29 Apr 2003 13:00:19 -0400 (EDT) Reply-To: From: "Vach Kompella" To: Cc: "Mourad BERKANE" , , , Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 09:22:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <3EAEA274.80E5BEA@cisco.com> X-OriginalArrivalTime: 29 Apr 2003 16:22:07.0572 (UTC) FILETIME=[7A7BA940:01C30E6B] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Robert, > > Vach, > > > The MD5 protection is at the TCP level, not at the BGP level. LDP security > > through the use of MD5 is advocated in RFC3036. I would, of > course, prefer that > > IPSEC be used, but the argument there is that TCP MD5 exists and works fine. > > :) ... of course it is for TCP :)... But there could be a slight > difference in number of TCP sessions you maintain in the BGP versus LDP > proposals (especially those TCP which do cross inter-as boundary), hence > number of TCP peers you need to somehow agree on using the same keys. > Not too mention that there is clear desire to change those keys > periodically which doesn't make the key maintenance between all PEs > easier. > Sure, but the number of TCP connections inter-AS is as many as LDP, unless you are telling me that eBGP uses RR! As for the changing the keys, it's a simple instantiation of IKE. This is just about the simplest use of IKE/IPSEC I can think of. > > My last discussion with some graybeards at the IETF showed that there was no > > strong inclination towards using MD5 inter-AS for BGP. Does this persist? > > Well at IETF I usually stay focused to talk to operators & service > providers rather then graybeards ...;) > Actually, they were graybeard operators. > R. > -Vach From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 13:13: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 NAA02094 for ; Tue, 29 Apr 2003 13:13:44 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3THG1719392 for ; Tue, 29 Apr 2003 13:16:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3THFuk21174 for ; Tue, 29 Apr 2003 13:15:56 -0400 (EDT) Message-ID: <3EAEA8A1.40532814@cisco.com> Date: Tue, 29 Apr 2003 18:30:25 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vkompella@timetra.com CC: Mourad BERKANE , Andreas.Mattsson@teliasonera.com, erosen@cisco.com, ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Vach, > Sure, but the number of TCP connections inter-AS is as many as LDP, unless you > are telling me that eBGP uses RR! What ??? Notice that in 99.9% of deployments I am familiar with each AS will most likely use IBGP mesh to RRs within each AS and one or two EBGP sessions between RRs or ASBRs Inter-AS. R. PS: No I am yet not there to suggest of using route servers for VPLS Inter-AS and even if I would it would be for a quite a number of ASes peering together not just 2-5 like I think in most of todays Inter-AS cases. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 13:19:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02213 for ; Tue, 29 Apr 2003 13:19:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3THLO723905 for ; Tue, 29 Apr 2003 13:21:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3THLKk04816 for ; Tue, 29 Apr 2003 13:21:20 -0400 (EDT) Message-Id: <200304291638.h3TGc5Yg027483@rtp-core-1.cisco.com> To: Yakov Rekhter , raszuk@cisco.com Cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-reply-to: Your message of Tue, 29 Apr 2003 09:07:52 -0700. <200304291607.h3TG7qu91994@merlot.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 12:38:05 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Eric> Well, no one is proposing to use LDP for VPLS autodiscovery. Yakov> please pay attention to "[LDP-DISC]" Okay, it serves me right for saying "no one" ;-) How about "almost no one"? Yakov> One difference is in the issue of using TCP MD5 for authentication. Last I heard, LDP used TCP as its transport, and used TCP MD5 for authentication. I don't believe that there is any BGP-specific authentication mechanism in use. Robert> there could be a slight difference in number of TCP sessions you Robert> maintain in the BGP versus LDP proposals (especially those TCP which Robert> do cross inter-as boundary), hence number of TCP peers you need to Robert> somehow agree on using the same keys. That's one of the issues that led me to the suggestion of confining the inter-AS LDP control connections to the border routers (as in section 5.5 of you know what draft); then you have the same number of inter-AS connections whether you use LDP or BGP. But even if you didn't do that, I'm not sure you'd really need a distinct key for each pair of peers. Vach> Sure, but the number of TCP connections inter-AS is as many as LDP, Vach> unless you are telling me that eBGP uses RR! I think Vach's model is the following. Each VPLS has, within each AS, one or more "hub PEs". If more than one, they are fully meshed. If the VPLS extends over two ASes, there is a point-to-point link between a hub in one AS and a hub in the other. Each hub sees the other as a spoke, meaning primarily that neither applies split horizon to the pw that leads out of the AS. It is correct that this is a way of reducing the number of inter-AS LDP connections so that there aren't any more of them than would be needed with BGP. It's not completely clear to me that this is analogous to the infamous option 10a from 2547bis, but it does require an extra level of MAC lookup. Yakov> one needs to take the whole system into perspective. I thought that was my point ;-) And that means we don't just consider what happens at time zero, that we consider what happens in various operational fault scenarios, and that we also consider, as part of "the whole system", VPWS services and p2p layer 2 services generally. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 13:27:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02577 for ; Tue, 29 Apr 2003 13:27:00 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3THTI726616 for ; Tue, 29 Apr 2003 13:29:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3THTEk23811 for ; Tue, 29 Apr 2003 13:29:14 -0400 (EDT) Message-ID: <8D91FF5277472A45A0A8F9654A14649701494999@frlnparexcha03.lambdanet.fr> From: Mourad BERKANE To: "'erosen@cisco.com'" Cc: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 17:23:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E63.48EA4650" X-SMTP-HELO: frlnparexcha03.lambdanet.fr X-SMTP-MAIL-FROM: mourad.berkane@lambdanet.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: frlnparexcha03.lambdanet.fr [217.71.101.91] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30E63.48EA4650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric> Could you tell us exactly which features of BGP you are referring = to here?=20 Eric> Please be specific.=20 VPLS autodiscovery and signaling over 2 differents networks =20 Mourad> LDP is not used as a signaling protocol for IPv4,=20 Eric> I don't know why you would say this. LDP is primarily used = today to bind Eric> MPLS labels to IPv4 routes. I'm not sure why you say it is = "not used as a Eric> signaling protocol for IPv4". by VPLS signaling i mean the protocol used for VPLS control plane (LDP = or BGP) by IPv4 signaling i mean the protocol used for IPv4 control plane (IGP = or BGP) If the forwarding plane is MPLS then LDP could be used as MPLS = signaling protocol but in this case LDP is not used for signaling/controling IPv4 routes, LDP isn t a routing protocol Mourad -----Message d'origine----- De : Eric Rosen [mailto:erosen@cisco.com] Envoy=E9 : mardi 29 avril 2003 16:34 =C0 : Mourad BERKANE Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; ppvpn@nortelnetworks.com Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt=20 Mourad> MP-BGP is much more designed for a *public* inter-AS = session for Mourad> VPLS.=20 Could you tell us exactly which features of BGP you are referring to = here?=20 Please be specific.=20 Mourad> Even if LDP/RSVP already present for the forwarding plane = inside a Mourad> MPLS domain, why should i used LDP for VPLS signalling = when BGP Mourad> already do the job (IPv4,v6,rfc2547bis,...)???=20 In several previous messages, I tried to give some specific = examples of signaling interactions that BGP cannot do or cannot do well.=20 Mourad> LDP is not used as a signaling protocol for IPv4,=20 I don't know why you would say this. LDP is primarily used today to = bind MPLS labels to IPv4 routes. I'm not sure why you say it is "not used = as a signaling protocol for IPv4". =20 Mourad> or rfc2547bis :-) BGP is in charge of it (and do the job = very Mourad> well).=20 So, if BGP is good for 2547, it must be good for VPLS too? Isn't = that the issue under discussion?=20 ------_=_NextPart_001_01C30E63.48EA4650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Support for draft-kompella-ppvpn-vpls-01.txt

Eric> Could you tell us exactly which features of = BGP you are referring to here?
Eric> Please be specific.

VPLS autodiscovery and signaling over 2 differents = networks 

Mourad> LDP is not used as a signaling protocol = for IPv4,

Eric> I don't know  why you would say  = this.  LDP is primarily used  today to bind
Eric> MPLS labels to IPv4  routes.  I'm = not sure why you say it  is "not used as a
Eric> signaling protocol for IPv4".

by VPLS signaling i mean the protocol used for VPLS = control plane (LDP or BGP)
by IPv4 signaling i mean the protocol used for IPv4 = control plane (IGP or BGP)

If the forwarding plane is MPLS then LDP could be = used as MPLS signaling protocol but in this case LDP is not used for = signaling/controling IPv4 routes, LDP isn t a routing = protocol

Mourad


-----Message d'origine-----
De : Eric Rosen [mailto:erosen@cisco.com]
Envoy=E9 : mardi 29 avril 2003 16:34
=C0 : Mourad BERKANE
Cc : 'raszuk@cisco.com'; = Andreas.Mattsson@teliasonera.com;
ppvpn@nortelnetworks.com
Objet : Re: Support for = draft-kompella-ppvpn-vpls-01.txt



Mourad> MP-BGP is  much more  designed = for a  *public* inter-AS  session for
Mourad> VPLS.

Could you tell us exactly which features of BGP you = are referring to here?
Please be specific.

Mourad> Even if LDP/RSVP  already present for = the forwarding  plane inside a
Mourad> MPLS  domain, why should  i = used  LDP for  VPLS signalling  when BGP
Mourad> already do the job = (IPv4,v6,rfc2547bis,...)???

In  several previous messages,  I = tried  to give  some specific  examples of
signaling interactions that BGP cannot do or cannot = do well.

Mourad> LDP is not used as a signaling protocol = for IPv4,

I don't know  why you would say  = this.  LDP is primarily used  today to bind
MPLS labels to IPv4  routes.  I'm not sure = why you say it  is "not used as a
signaling protocol for IPv4". 

Mourad> or  rfc2547bis :-)  BGP is  = in charge  of it  (and do  the  job very
Mourad> well).

So, if BGP is  good for 2547, it must be good = for  VPLS too?  Isn't that the
issue under discussion?


------_=_NextPart_001_01C30E63.48EA4650-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 13:31:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02812 for ; Tue, 29 Apr 2003 13:31:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3THXQ729988 for ; Tue, 29 Apr 2003 13:33:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3THXLM03891 for ; Tue, 29 Apr 2003 13:33:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20030429130353.02ce4530@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Apr 2003 13:09:04 -0400 To: Yakov Rekhter From: Rajiv Asati Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Cc: erosen@cisco.com, Mourad BERKANE , "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com In-Reply-To: <200304291607.h3TG7qu91994@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: rajiva@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: Yakov, >Not really. One difference is in the issue of using TCP MD5 for >authentication. And why would "TCP MD5 for authentication" become an issue for LDP !! Cheers, Rajiv At 12:07 PM 4/29/2003, Yakov Rekhter wrote: >Eric, > > > Eric> Could you tell us exactly which features of BGP you are > referring to > > Eric> here? Please be specific. > > > > Mourad> VPLS autodiscovery and signaling over 2 different networks > > > > Well, no one is proposing to use LDP for VPLS autodiscovery. > > From draft-lasserre-vkompella-ppvpn-vpls-04.txt (please pay attention >to "[LDP-DISC]"): > > 6. Discovery > > Currently, no discovery mechanism has been prescribed for VPLS. > There are three potential candidates, [BGP-DISC], [DNS-DISC], [LDP- > DISC]. > > > And one can > > use LDP between two different networks as easily as one can use BGP > between > > two different networks. > >Not really. One difference is in the issue of using TCP MD5 for >authentication. > > > Mourad> If the forwarding plane is MPLS then LDP could be used as > MPLS > > Mourad> > signaling protocol but in this case LDP is not used for > > Mourad> signaling/controling IPv4 routes, LDP isn t a routing protocol > > > > Certainly it's true that LDP is NOT a routing protocol, and that BGP > IS a > > > routing protocol. It's also true that both are used, in varying > > circumstances, for distributing MPLS labels. As VPLS does > not require a > > routing protocol, I'm not sure how one is supposed to conclude from > this > > that BGP is a better signaling protocol for VPLS. > >As I (as well as other folks) said several times before, it is >not that meaningful to compare LDP vs BGP just for signaling - one >needs to take the whole system into perspective. And the whole >system includes not just signaling but autodiscovery as well. So, >a meanigful comparison should be BGP for both signaling and >autodiscovery vs BGP for autodiscovery + LDP for signaling. > >Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 13:45:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03343 for ; Tue, 29 Apr 2003 13:45:53 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3THmA709268 for ; Tue, 29 Apr 2003 13:48:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3THm5a22465 for ; Tue, 29 Apr 2003 13:48:05 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Yakov Rekhter" , Cc: "Mourad BERKANE" , , , Subject: Auto-discovery for VPLS in BGP Date: Tue, 29 Apr 2003 10:21:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <200304291607.h3TG7qu91994@merlot.juniper.net> X-OriginalArrivalTime: 29 Apr 2003 17:20:46.0803 (UTC) FILETIME=[AC1BB230:01C30E73] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov, I asked Hector but he didn't answer this. There is some magic here in the auto-discovery. How does a PE know its site ID? Does it auto-discover it? Is it configured? If it is configured, how can you guarantee the uniqueness? With or without reference to all the other PEs in the VPLS? If with reference to them, then what's the point of auto-discovery? Are site IDs reused? Can one PE be site ID 1 in one VPN and site ID n (!= 1) in another? If I understand correctly, the real identifier for a PE in an L2VPN is: VPNID.PE.siteId. Without that, it won't work. (And I'm not talking of the remote PE's site ID which is in the NLRI, I'm talking of the local PE's site ID). If you remove a site from the VPLS, do you renumber site IDs? Or waste labels? If you remove a range of sites from the NLRI, do you advertise dummy label ranges to avoid renumbering sites? The auto-discovery for 2547 is pretty straightforward because all you need to know is the VPN ID and the PE, which comes from the NLRI. That comes because the label is "advertised" not "signaled" with the distinction being that the former is useable across the PEs in question and the latter is per-PE. You can just use loopback address based RDs to ensure route uniqueness, and the only common piece of info that you need for correlation is the VPN ID. -Vach From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 14:00: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 OAA03751 for ; Tue, 29 Apr 2003 14:00:18 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TI2a706494 for ; Tue, 29 Apr 2003 14:02:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TI2SQ13425 for ; Tue, 29 Apr 2003 14:02:29 -0400 (EDT) Message-Id: <200304291739.h3THd4u99612@merlot.juniper.net> To: Rajiv Asati cc: ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 13:09:04 EDT." <4.3.2.7.2.20030429130353.02ce4530@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <510.1051637943.1@juniper.net> Date: Tue, 29 Apr 2003 10:39:04 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Rajiv, > >Not really. One difference is in the issue of using TCP MD5 for > >authentication. > > And why would "TCP MD5 for authentication" become an issue for LDP !! Because of the difference between the number of LDP sessions vs BGP sessions. Yakov. > > Cheers, > Rajiv > > At 12:07 PM 4/29/2003, Yakov Rekhter wrote: > >Eric, > > > > > Eric> Could you tell us exactly which features of BGP you are > > referring to > > > Eric> here? Please be specific. > > > > > > Mourad> VPLS autodiscovery and signaling over 2 different networks > > > > > > Well, no one is proposing to use LDP for VPLS autodiscovery. > > > > From draft-lasserre-vkompella-ppvpn-vpls-04.txt (please pay attention > >to "[LDP-DISC]"): > > > > 6. Discovery > > > > Currently, no discovery mechanism has been prescribed for VPLS. > > There are three potential candidates, [BGP-DISC], [DNS-DISC], [LDP- > > DISC]. > > > > > And one can > > > use LDP between two different networks as easily as one can use BGP > > between > > > two different networks. > > > >Not really. One difference is in the issue of using TCP MD5 for > >authentication. > > > > > Mourad> If the forwarding plane is MPLS then LDP could be used as > > MPLS > > > Mourad> > > signaling protocol but in this case LDP is not used for > > > Mourad> signaling/controling IPv4 routes, LDP isn t a routing protocol > > > > > > Certainly it's true that LDP is NOT a routing protocol, and that BGP > > IS a > > > > > routing protocol. It's also true that both are used, in varyin g > > > circumstances, for distributing MPLS labels. As VPLS does > > not require a > > > routing protocol, I'm not sure how one is supposed to conclude from > > this > > > that BGP is a better signaling protocol for VPLS. > > > >As I (as well as other folks) said several times before, it is > >not that meaningful to compare LDP vs BGP just for signaling - one > >needs to take the whole system into perspective. And the whole > >system includes not just signaling but autodiscovery as well. So, > >a meanigful comparison should be BGP for both signaling and > >autodiscovery vs BGP for autodiscovery + LDP for signaling. > > > >Yakov. > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 14:03:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03912 for ; Tue, 29 Apr 2003 14:03:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TI63721943 for ; Tue, 29 Apr 2003 14:06:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TI5xQ21528 for ; Tue, 29 Apr 2003 14:05:59 -0400 (EDT) Message-Id: <200304291714.h3THESu97304@merlot.juniper.net> To: vkompella@timetra.com cc: raszuk@cisco.com, "Mourad BERKANE" , ppvpn@nortelnetworks.com Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt In-Reply-To: Your message of "Tue, 29 Apr 2003 09:22:25 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91116.1051636468.1@juniper.net> Date: Tue, 29 Apr 2003 10:14:28 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Vach, > > Vach, > > > > > The MD5 protection is at the TCP level, not at the BGP level. LDP securi ty > > > through the use of MD5 is advocated in RFC3036. I would, of > > course, prefer that > > > IPSEC be used, but the argument there is that TCP MD5 exists and works fi ne. > > > > :) ... of course it is for TCP :)... But there could be a slight > > difference in number of TCP sessions you maintain in the BGP versus LDP > > proposals (especially those TCP which do cross inter-as boundary), hence > > number of TCP peers you need to somehow agree on using the same keys. > > Not too mention that there is clear desire to change those keys > > periodically which doesn't make the key maintenance between all PEs > > easier. > > > > Sure, but the number of TCP connections inter-AS is as many as LDP, unless > you are telling me that eBGP uses RR! If one would read 2547bis, then one should be able to fine the following: To improve scalability, one can have the multi-hop EBGP connections exist only between a route reflector in one AS and a route reflector in another. (However, when the route reflectors distribute routes over this connection, they do not modify the BGP next hop attribute of the routes.) Precisely the same applies for VPLS when autodiscovery and signaling is done via BGP. Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 14:21: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 OAA04387 for ; Tue, 29 Apr 2003 14:21:22 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TINe728377 for ; Tue, 29 Apr 2003 14:23:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TINY205487 for ; Tue, 29 Apr 2003 14:23:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030429134447.02d0cfe8@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Apr 2003 13:56:37 -0400 To: Yakov Rekhter From: Rajiv Asati Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Cc: ppvpn@nortelnetworks.com In-Reply-To: <200304291739.h3THd4u99612@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: rajiva@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: Yakov , So the issue is not "TCP MD5 authentication", rather no of sessions. Rajiv At 01:39 PM 4/29/2003, Yakov Rekhter wrote: >Rajiv, > > > >Not really. One difference is in the issue of using TCP MD5 for > > >authentication. > > > > And why would "TCP MD5 for authentication" become an issue for LDP !! > >Because of the difference between the number of LDP sessions >vs BGP sessions. > >Yakov. > > > > > Cheers, > > Rajiv > > > > At 12:07 PM 4/29/2003, Yakov Rekhter wrote: > > >Eric, > > > > > > > Eric> Could you tell us exactly which features of BGP you are > > > referring to > > > > Eric> here? Please be specific. > > > > > > > > Mourad> VPLS autodiscovery and signaling over 2 different networks > > > > > > > > Well, no one is proposing to use LDP for VPLS autodiscovery. > > > > > > From draft-lasserre-vkompella-ppvpn-vpls-04.txt (please pay attention > > >to "[LDP-DISC]"): > > > > > > 6. Discovery > > > > > > Currently, no discovery mechanism has been prescribed for VPLS. > > > There are three potential candidates, [BGP-DISC], [DNS-DISC], [LDP- > > > DISC]. > > > > > > > And one can > > > > use LDP between two different networks as easily as one can use BGP > > > between > > > > two different networks. > > > > > >Not really. One difference is in the issue of using TCP MD5 for > > >authentication. > > > > > > > Mourad> If the forwarding plane is MPLS then LDP could be > used as > > > MPLS > > > > Mourad> > > > signaling protocol but in this case LDP is not used for > > > > Mourad> signaling/controling IPv4 routes, LDP isn t a routing protocol > > > > > > > > Certainly it's true that LDP is NOT a routing protocol, and > that BGP > > > IS a > > > > > > > > routing protocol. It's also true that both are used, in varyin >g > > > > circumstances, for distributing MPLS labels. As VPLS does > > > not require a > > > > routing protocol, I'm not sure how one is supposed to > conclude from > > > this > > > > that BGP is a better signaling protocol for VPLS. > > > > > >As I (as well as other folks) said several times before, it is > > >not that meaningful to compare LDP vs BGP just for signaling - one > > >needs to take the whole system into perspective. And the whole > > >system includes not just signaling but autodiscovery as well. So, > > >a meanigful comparison should be BGP for both signaling and > > >autodiscovery vs BGP for autodiscovery + LDP for signaling. > > > > > >Yakov. > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 14:37:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04995 for ; Tue, 29 Apr 2003 14:37:35 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TIdr701901 for ; Tue, 29 Apr 2003 14:39:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TIdkN08580 for ; Tue, 29 Apr 2003 14:39:46 -0400 (EDT) Message-Id: <200304291422.h3TEMlu85954@merlot.juniper.net> To: vkompella@timetra.com cc: "Yakov Rekhter" , steven.wright@BellSouth.com, ppvpn@nortelnetworks.com Subject: Re: ppvpn effort support In-Reply-To: Your message of "Mon, 28 Apr 2003 12:14:56 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40927.1051626167.1@juniper.net> Date: Tue, 29 Apr 2003 07:22:47 -0700 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Vach, > Yakov, > > You misunderstand what is described in draft-lasserre-vkompella. I don't think so... > The spoke connection between a "border" PE and another is a > draft-martini pipe. The behavior is exactly analogous to that > described in section 10(a) of draft-ietf-ppvpn-rfc2547. Glad that you agree with me that the inter-AS solution proposed in draft-lasserre-vkompella is exactly analogous to the option (a) in Section 10 of rfc2547bis. > This behavior is precisely that of extending a customer sub-interface > into the VPLS over an extension that may be an RFC1483 PVC, an RFC > 1490 PVC, a draft-martini pipe, a q-tagged pipe, etc. Perhaps it > seems that the spoke has those VPLS properties because it may be > connected to an MTU that is bridging capable. That, however, is > not a spoke property; rather it is the property of a bridge that > has multiple spokes (aka interfaces, whether logical or physical). > > A spoke does not have learning associated with it. An ethernet > packet put in to a spoke is just transmitted down the spoke. In > fact, this particular behavior is what makes the spoke a scalable > addition to the basic VPLS model in the intra-metro HVPLS model. > > However, if you have two spokes, you have to replicate on the spokes > (a VPLS function at the PE, and an 802.1d bridge function at an > MTU, not a spoke function). > > No STP is needed for a VPLS. STP may be required on a spoke. > However, if on e is required on a spoke, it is because spokes are > treated as extensions to customer interfaces, and STP may run on > customer interfaces. To make the discussion more specific let's look at couple of examples: Example 1: CE1, CE2, and CE3 belong to the same VPLS that spans three ASs (AS1, AS2, and AS3): Border --- AS 3 -- PE C - CE3 Router 31 / / CE1 -- PE A ------- AS 1 --- Border ----- Border ------ AS 2 -- PE B -- CE2 Router 12 Router 21 Q1: When some host behind CE1 sends a packet destined to some host behind CE2, and the packet arrives at Border Router 12, how would this border router know whether to send this packet to Border Router 21 or to Border Router 31 (other than by performing MAC address learning) ? Q2: When this packet arrives at Border Router 21, how would this border router know that it has to send the packet to PE B, rather than to some other PE (other than by performing MAC address learning) ? Example 2: CE1, CE2, and CE3 belong to the same VPLS that spans two ASs (AS1 and AS2), and these ASs have multiple interconnects): - Border---- Border -- | Router 23 Router 32 | | | | | CE1 -- PE A ------- AS 1 --- Border ----- Border ------ AS 2 -- PE B -- CE2 Router 12 Router 21 | | PE C | | CE3 Q3: Since AS1 and AS2 are interconnected not by one, but by two pairs of ASBRs, would both ASBRs simultaneously be used for forwarding VPLS traffic for the VPLS formed by CE1, CE2 and CE3 ? If not, then what are the procedures by which only one of those pairs be selected ? If only one of these pairs is selected, then what are the procedures to handle either failure of an ASBR in the selected pair or a link between the selected ASBRs ? Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 15:15:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07145 for ; Tue, 29 Apr 2003 15:15:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TJHR713725 for ; Tue, 29 Apr 2003 15:17:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TJHNC18943 for ; Tue, 29 Apr 2003 15:17:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20030429115928.04d053c0@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Apr 2003 12:13:44 -0700 To: Mourad BERKANE From: Chris Metz Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Cc: "'jeremy.de_clercq@alcatel.be'" , ppvpn@nortelnetworks.com In-Reply-To: <8D91FF5277472A45A0A8F9654A14649701494995@frlnparexcha03.la mbdanet.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_100821113==_.ALT" X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: chmetz@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: --=====================_100821113==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 03:41 PM 4/29/2003 +0200, Mourad BERKANE wrote: >Hi Jeremy > >(sorry about the non confusion) > >The "argument" is that today Providers don't (want to) have a (useless)=20 >LDP peering sessions for VPLS application because BGP already present=20 >between Providers (IP world). Hey Mourad- I would not call them "useless". They are as efficient and useful as they=20 are in intra-AS case for conveying PW labels and state between PEs. >Suppose you would like to extend a VPLS domain out of your network, you=20 >will need to extend signaling between theses networks ("hi i am PE1 from=20 >Carrier A ASN=3D1 and I would like to join VPLS Z in your domain Carrier B= =20 >ASN=3D2, please use label L to send traffic to me"). The fact is that=20 >Carrier A and Carrier B could already communicated over IPv4 Public=20 >network: a BGP session already exist between A and B and could be used for= =20 >many services (v4,v6,2547bis AND VPLS) > >If you use BGP as VPLS signaling protocols, you will need to setup a=20 >MP-eBGP session between AS >--> re use of existing BGP session between A and B > >Forwarding Tunnels used proposed in draft-kompella-ppvpn-vpls could be=20 >MPLS,IP or GRE tunnels between A and B. >Someone who don't (or can't) discuss LDP could be a candidate for an=20 >extension of a VPLS domain since the signaling protocol is BGP :-) > >If you use LDP as VPLS signaling protocols, you will need to open LDP=20 >ports between A and B. >This new session is dedicated to VPLS services. Of course, It work but why= =20 >should I manage/troubleshoot this LDP inter-AS sessions since BGP already= =20 >present for others services? Specious argument ... you won't troubleshoot the session ... what, it is a= =20 TCP session, it's either active or not. What you will troubleshoot is the=20 status of the PW and ACs at each end. It is seems to me at least the most=20 pt-pt reliable PW control channel (i.e. LDP or L2TPv3) is best suited for=20 that task. Cheers ,,, >Mourad > >-----Message d'origine----- >De : jeremy.de_clercq@alcatel.be=20 >[mailto:jeremy.de_clercq@alcatel.be] >Envoy=E9 : mardi 29 avril 2003 15:03 >=C0 : Mourad BERKANE >Cc : ppvpn@nortelnetworks.com >Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > >Hi Mourad, > > > LDP is not used as a signaling protocol for IPv4, IPv6 or > > rfc2547bis :-) > > BGP is in charge of it (and do the job very well). > >BGP distributes routes, it doesn't establish Pseudo-Wires in the >examples you give. > > > May be this will clarify all theses exchanges about signalling in > > VPLS: adding a new signaling protocol (LDP) whitout any added value > > versus keeping the same signalling protocol (BGP) for differents > > services (IP,rfc2547bis,VPLS, futures needs) > > > > You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling > > (LDP or BGP)? > >I'm sure I was not confused by the above ;-) > >What I meant was that LDP is used for pseudo-wire signaling >(http://www.ietf.org/h= tml.charters/pwe3-charter.html,=20 >"Pseudo-Wire Setup >and Maintenance using LDP"), and that VPLS uses pseudo-wires. > >So arguments that say "BGP because it is also used for X" or "LDP >because it is also used for Y" are not convincing enough for me, as >you'll have BGP in some environments (2547) and LDP in other >environments (PWE3) and LDP + BGP in many environments ;-) > >What I really wanted to know is what the difference is for inter-AS >applications, as this seems to be one of the *technical* arguments. > >Jeremy. > > > > > Mourad > > > > -----Message d'origine----- > > De : jeremy.de_clercq@alcatel.be=20 > [mailto:jeremy.de_clercq@alcatel.be] > > Envoy=E9 : mardi 29 avril 2003 14:19 > > =C0 : Mourad BERKANE > > Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; > > erosen@cisco.com; ppvpn@nortelnetworks.com > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Mourad, > > > > > As you hinted here, MP-BGP is much more designed for a *public* > > > inter-AS session for VPLS. > > > > I still don't understand why MP-BGP is more appropriate than LDP for > > this application. I probably need more than a "hint" to fully > > understand > > it ;-) > > > > > Even if LDP/RSVP already present for the forwarding plane inside a > > > MPLS domain, why should i used LDP for VPLS signalling when BGP > > > already do the job (IPv4,v6,rfc2547bis,...)??? > > > > You can turn this around: Even if BGP is already present for 2547bis, > > v4, v6 etc, why should I use BGP for VPLS signaling when LDP already > > does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 > > Pseudo-Wires, ...) ? > > > > [I guess the answer to both of the above questions is given in the > > large > > number of previous emails on this topic ;-)] > > > > Jeremy. > > > > > Mourad > > > > > > -----Message d'origine----- > > > De : Robert Raszuk [mailto:raszuk@cisco.com] > > > Envoy=E9 : mardi 29 avril 2003 11:26 > > > =C0 : Andreas.Mattsson@teliasonera.com > > > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > Andres, > > > > > > AFAIK there is no need to configure anything rather then a site > > > interface on the PEs. Autodiscovery will detect new addition and > > > propagate the news to all participants. Then in the > > lasserre-vkompella > > > > > > scheme directed LDP if not already set get's automatically > > established > > > > > > between parties. > > > > > > Of course the drawback here is that you need to keep LDP ports open > > > wide > > > within inter-AS LDP src ranges which may or may not be an acceptable > > > > > issue :-). > > > > > > R. > > > > > > > Andreas.Mattsson@teliasonera.com wrote: > > > > > > > > Hi Eric > > > > > > > > As I understand it a requirement would be to have a full mesh of > > LDP > > > > > > > sessions between the PEs in the participating AS domains. This > > means > > > > > > > configuration of each PE when for example a new site is added to > > an > > > > already existing VPN. If BGP is used this is not necessary as RRs > > > can be > > > > used, minimizing the configuration to the new PE and the RR. > > > > But perhaps there exist a solution similar to this for LDP as > > well? > > > It > > > > seems appealing to reuse the 2547bis structure we have also for > > VPLS > > > if > > > > it's possible. > > > > > > > > My point is that further investigation of the two different > > > solutions > > > > before rejecting one or the other would be good > > > > > > > > /Andreas > > > > > > > > -----Original Message----- > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > Sent: den 28 april 2003 16:29 > > > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > > > Cc: ppvpn@nortelnetworks.com > > > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > > > Andreas> I would also like to know how inter-AS with the LDP > > > > Andreas> approach in lasserre-vkompella is to be solved. > > > > > > > > Could you say what the issue is that you think needs to be solved? --=====================_100821113==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 03:41 PM 4/29/2003 +0200, Mourad BERKANE wrote:

Hi Jeremy

(sorry about the non confusion)

The "argument" is that today Providers don't (want to) have a (useless) LDP peering sessions for VPLS application because BGP already present between Providers (IP world).

Hey Mourad-
I would not call them "useless". They are as efficient and useful as they are in intra-AS case for conveying PW labels and state between PEs.


Suppose you would like to extend a VPLS domain out of your network, you will need to extend signaling between theses networks ("hi i am PE1 from Carrier A ASN=3D1 and I would like to join VPLS Z in your domain Carrier B ASN=3D2, please use label L to send traffic to me"). The fact is that Carrier A and Carrier B could already communicated over IPv4 Public network: a BGP session already exist between A and B and could be used for many services (v4,v6,2547bis AND VPLS)

If you use BGP as VPLS signaling protocols, you will need to setup a MP-eBGP session between AS
--> re use of existing BGP session between A and B

Forwarding Tunnels used proposed in draft-kompella-ppvpn-vpls= could be MPLS,IP or GRE tunnels between A and B.
Someone who don't (or can't) discuss LDP could be a candidate= for an extension of a VPLS domain since the signaling protocol is BGP= :-)

If you use LDP as VPLS signaling protocols, you will need to= open LDP ports between A and B.
This new session is dedicated to VPLS services. Of course, It= work but why should I manage/troubleshoot this LDP inter-AS sessions since= BGP already present for others services?

Specious argument ... you won't troubleshoot the session ... what, it is a= TCP session, it's either active or not. What you will troubleshoot is the= status of the PW and ACs at each end. It is seems to me at least the most= pt-pt reliable PW control channel (i.e. LDP or L2TPv3) is best suited for= that task.

Cheers ,,,



Mourad

-----Message d'origine-----
De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel= .be]
Envoy=E9 : mardi 29 avril 2003 15:03
=C0 : Mourad BERKANE
Cc : ppvpn@nortelnetworks.com
Objet : Re: Support for= draft-kompella-ppvpn-vpls-01.txt

Hi Mourad,

> LDP is not used as a signaling protocol for IPv4, IPv6= or
> rfc2547bis :-)
> BGP is in charge of it (and do the job very= well).

BGP distributes routes, it doesn't establish Pseudo-Wires in= the
examples you give.

> May be this will clarify all theses exchanges about= signalling in
> VPLS: adding a new signaling protocol (LDP) whitout any= added value
> versus keeping the same signalling protocol (BGP) for= differents
> services (IP,rfc2547bis,VPLS, futures needs)
>
> You may confuse MPLS signaling (LDP or RSVP) and and= VPLS signaling
> (LDP or BGP)?

I'm sure I was not confused by the above ;-)

What I meant was that LDP is used for pseudo-wire= signaling
(http://www.iet= f.org/html.charters/pwe3-charter.html, "Pseudo-Wire Setup=
and Maintenance using LDP"), and that VPLS uses= pseudo-wires.

So arguments that say "BGP because it is also used for= X" or "LDP
because it is also used for Y" are not convincing enough= for me, as
you'll have BGP in some environments (2547) and LDP in= other
environments (PWE3) and LDP + BGP in many environments= ;-)

What I really wanted to know is what the difference is for= inter-AS
applications, as this seems to be one of the *technical*= arguments.

Jeremy.

>
> Mourad
>
> -----Message d'origine-----
> De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel= .be]
> Envoy=E9 : mardi 29 avril 2003 14:19
> =C0 : Mourad BERKANE
> Cc : 'raszuk@cisco.com';= Andreas.Mattsson@teliasonera.com;
> erosen@cisco.com; ppvpn@nortelnetworks.com
> Objet : Re: Support for= draft-kompella-ppvpn-vpls-01.txt
>
> Mourad,
>
> > As you hinted here, MP-BGP is much more designed= for a *public*
> > inter-AS session for VPLS.
>
> I still don't understand why MP-BGP is more appropriate= than LDP for
> this application. I probably need more than a= "hint" to fully
> understand
> it ;-)
>
> > Even if LDP/RSVP already present for the forwarding= plane inside a
> > MPLS domain, why should i used LDP for VPLS= signalling when BGP
> > already do the job= (IPv4,v6,rfc2547bis,...)???
>
> You can turn this around: Even if BGP is already present= for 2547bis,
> v4, v6 etc, why should I use BGP for VPLS signaling when= LDP already
> does the job (LDP for intra-AS tunnel LSPs, LDP for= individual PWE3
> Pseudo-Wires, ...) ?
>
> [I guess the answer to both of the above questions is= given in the
> large
> number of previous emails on this topic ;-)]
>
> Jeremy.
>
> > Mourad
> >
> > -----Message d'origine-----
> > De : Robert Raszuk [mailto:raszuk@cisco.com]
> > Envoy=E9 : mardi 29 avril 2003 11:26
> > =C0 : Andreas.Mattsson@teliasonera.com
> > Cc : erosen@cisco.com;= ppvpn@nortelnetworks.com
> > Objet : Re: Support for= draft-kompella-ppvpn-vpls-01.txt
> >
> > Andres,
> >
> > AFAIK there is no need to configure anything rather= then a site
> > interface on the PEs. Autodiscovery will detect new= addition and
> > propagate the news to all participants. Then in= the
> lasserre-vkompella
> >
> > scheme directed LDP if not already set get's= automatically
> established
> >
> > between parties.
> >
> > Of course the drawback here is that you need to= keep LDP ports open
> > wide
> > within inter-AS LDP src ranges which may or may not= be an acceptable
>
> > issue :-).
> >
> > R.
> >
> > > Andreas.Mattsson@teliasonera.com wrote:=
> > >
> > > Hi Eric
> > >
> > > As I understand it a requirement would be to= have a full mesh of
> LDP
> >
> > > sessions between the PEs in the participating= AS domains. This
> means
> >
> > > configuration of each PE when for example a= new site is added to
> an
> > > already existing VPN. If BGP is used this is= not necessary as RRs
> > can be
> > > used, minimizing the configuration to the new= PE and the RR.
> > > But perhaps there exist a solution similar to= this for LDP as
> well?
> > It
> > > seems appealing to reuse the 2547bis structure= we have also for
> VPLS
> > if
> > > it's possible.
> > >
> > > My point is that further investigation of the= two different
> > solutions
> > > before rejecting one or the other would be= good
> > >
> > > /Andreas
> > >
> > > -----Original Message-----
> > > From: Eric Rosen [mailto:erosen@cisco.com]
> > > Sent: den 28 april 2003 16:29
> > > To: Mattsson, Andreas A. /Research /08-713 81= 86, 070-618 67 67
> > > Cc: ppvpn@nortelnetworks.com
> > > Subject: Re: Support for= draft-kompella-ppvpn-vpls-01.txt
> > >
> > > Andreas> I would  also like to = know how inter-AS  with the LDP
> > > Andreas> approach in lasserre-vkompella is= to be solved.
> > >
> > > Could you say what the issue is that you think= needs to be solved?
--=====================_100821113==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 16:04: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 QAA08702 for ; Tue, 29 Apr 2003 16:04:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TK6c710720 for ; Tue, 29 Apr 2003 16:06:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TK6V710649 for ; Tue, 29 Apr 2003 16:06:32 -0400 (EDT) Message-ID: <3EAEDA74.470FBB30@alcatel.com> Date: Tue, 29 Apr 2003 16:03:00 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Norman Finn CC: Muneyoshi Suzuki , jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <20030422.095728.07567803.suzuki.muneyoshi@lab.ntt.co.jp> <3EA95F59.AEC52332@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Norm, Muneyoshi, Norman Finn wrote: > > Muneyoshi, > > If you use spanning tree among the pseudowires connecting Islands, > as in: > pw A > island 1 --------------------- island 2 > \ / > pw B \_______ _________/ pw C > \ / > island 3 > > then one of pw A, pw B, or pw C must be blocked. Let's suppose it's > pw C. Then, all traffic from island 2 to island 3 must be relayed > by island 1. > > In other words, since wires are almost "free" in this space, one > tends to have a lot of them. It the extreme case that you have a > full mesh of connections among all the participants in a net, spanning > tree is a particularly wasteful approach; it guarantees to block all > but N of the N*(N-1)/2 pseudowires! (: Yes, a bridge-bigot is saying > that spanning tree is not optimal for all interconnect plans. :) If in the problem we are trying to solve, the islands are end customers LAN, and the traffic are mostly flowing to/from one or few hubs to a larger number of spokes, then there is no need to have a full-mesh of PW (partial mesh is sufficient), and the case where traffic flow is not optimal is infrequent then. I think it's fine to solve 80% of the problem well and optimize for the remaining 20%. A full-meshed with split-horizon seems to be optimized for the minority of requirements, but not solving the majority of the problem well (issues already being discussed and acknowledged on this list). If the problem we are trying to solve is building very large LANs, then I think it's worth considering Neil Harrison point that "There is a massive difference in recognising the importance of ethernet as a key CPE *interface* and then (somehow) making the (wrong) extrapolation that this means ethernet is a great WAN technology." > If you configure a relatively sparse interconnect plan, using just > a few pseudowires, and if those pseudowires approximate physical > reality, then spanning tree becomes more viable. The scaling > problem for 3000 VPLS instances at 10 pseudowires each becomes 3000 > VPLS instances at 2-3 pseudowires each, reducing the BPDU load from > 20,000 to 7,500. I would remark that our best bridges top out at > somewhere on the order of 1,000 - 2,000 BPDUs per second, at this > time. I need to think a bit more before I agree that this solution > "simple and robust". If we keep bridging to the furthest edge possible (e.g. in CLE or MTU if need be), then the number of VPLS instances is drastically reduced. Perhaps until we agree on the problem we are trying to solve, it's hard to scope VPLS problem space. Regards, Cheng-Yin > > -- Norm > > Muneyoshi Suzuki wrote: > > > > Joris, > > > > > My question is: how do you deal with (portions of) the network, for which a > > > spanning tree would be a very inefficient forwarding means, because the > > > physical topology does not approximate a tree? > > > > Could you clarify this? What is spanning tree in the above context? > > 802.1D STP, or STP/RSTP/MSTP? > > > > If you are claiming STP topology change time is inefficient, the use of > > RSTP/MSTP should be considered. > > > > If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify > > the issues? From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 16:11:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08934 for ; Tue, 29 Apr 2003 16:11:29 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TKDl715121 for ; Tue, 29 Apr 2003 16:13:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TKDh718358 for ; Tue, 29 Apr 2003 16:13:43 -0400 (EDT) Message-ID: <3EAEDB23.50CAFD9F@alcatel.com> Date: Tue, 29 Apr 2003 16:05:55 -0400 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: nfinn@cisco.com, suzuki.muneyoshi@lab.ntt.co.jp, jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: Re: Comments on the L2 VPN framework and solutions documents References: <0536FC9B908BEC4597EE721BE6A35389025D6775@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx2.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Neil, > There is a massive difference in > > recognising the importance of ethernet as a key CPE *interface* and then > > (somehow) making the (wrong) extrapolation that this means ethernet is a > > great WAN technology. I think this is an important point. The next question then is what should end-customers with multiple sites but a single Ethernet interface to provider do? Thanks Cheng-Yin. neil.2.harrison@bt.com wrote: > > Norman...I'd go further than saying that.....it's proposing reinventing cnls > networking (data-plane aspects too). There is a massive difference in > recognising the importance of ethernet as a key CPE *interface* and then > (somehow) making the (wrong) extrapolation that this means ethernet is a > great WAN technology. All *scalable* WAN networking modes (of which there > are only 3, viz cnls, co pkt-sw and co cct-sw) must have at least 2 > functional components: > - addressing: from a space that is large enough, and carries > semantics of 'where' (not 'who'...that is a name) and thus aggregatable; > - consistent topological network map: whether centralised or > distributed, to allow consistent route calculation. > > They must also have other functional components to make make them > 'operationally viable', but addressing/routing are the min set. Ethernet as > a technology does not have addressing/routing functional components that > meet the WAN/scalability criteria. > > {Aside: As an aim (to stop doing stovepipes, ie 'technology==service' and > to minimise problematic gateways for data/control-plane functions) we > operators (or at least BT) are seeking functional convergence *within* each > of the networking modes but not *across* them (that one makes no technical > or commercial sense). So we agree with you that to try and turn ethernet > into a next generation cnls network is a 'bad idea'....we have IP for that > job.} > > Therefore, short of fundamentally re-working what ethernet is today, the > only pragmatic way to handle ethernet services in the WAN is to accept that > a proper WAN technology must act as a server layer to proxy for the missing > functions. SDH/GFP is a good solution. MPLS *could* be a good > solution.....but it would need recognition that: > - it is a layer network in its own right, eg it needs its own > addressing regime (actually it subconsciously(?) gets this, but its > different for each signalling type used and that is not a good idea); > - it belongs to the co pkt-sw mode (not the cnls mode, that is IP) and > thus does *not* have to be constrained by the limitations of a cnls mode, eg > in a client/server sense X/MPLS is *not* the same as X/IP.....and it saddens > me to see PWE3 try to treat them like this as though this is a 'good idea' > when its just dogma; > - it needs proper OAM solutions......but the only topological > constructs that make networking sense in a co pkt-sw mode are p2p and > p2mp......mp2p constructs just create problems for no benefit (if one wants > this sort of behaviour, use a proper IP/cnls mode which is designed for this > behaviour and where these problems don't exist). Further, given X/MPLS and > X/IP are different animals, then we want to see as much functional > independence between the client (X) and the server layers (MPLS or > IP).......and we don't want to see lots of in-between layer functions being > created (like PW OAM) that we also have to manage (noting that we still have > to manage the MPLS and IP layers anyway....so at least get these right in > their own right). > > regards, Neil > > > -----Original Message----- > > From: Norman Finn [mailto:nfinn@cisco.com] > > Sent: 25 April 2003 17:31 > > To: Muneyoshi Suzuki > > Cc: jwils@coriolisnet.com; ppvpn@nortelnetworks.com > > Subject: Re: Comments on the L2 VPN framework and solutions documents > > > > > > Muneyoshi, > > > > I think that adding a TTL field to the MAC frame is an attractive > > idea. I also think that it is an extraordinarily bad idea. If I > > may paraphrase your argument, it is: (Forgive me, please, for putting > > words in your mouth.) > > > > 1. Routing is not reliable enough to establish the connections > > that we need. Bridge A might be able to talk to Bridge B, but > > not to Bridge C. > > > > 2. Spanning trees and full meshes, which don't require TTL, are > > not good enough, for the reasons thoroughly discussed. (By > > the way, I very much agree with you that, for large N, a full > > mesh will not be reliable. My solution is to keep N fairly > > small.) > > > > 3. Therefore, we'll add TTL and use OSPF to route the MAC frames. > > > > What I don't understand is how you have solved the problem that > > Bridge A could not talk to Bridge C! Why is your toy routing system > > going to be any more robust than the existing routing system? > > > > This approach is not flawed because it is reinventing bridging. It > > is flawed because it is reinventing routing. > > > > -- Norm > > > > Muneyoshi Suzuki wrote: > > > > > > Joris, > > > > > > Thanks for clarification. > > > > > > First, needless to say, I aware link block problem of STP/RSTP. We > > > definitely need a solution. However, the solution must be robust. > > > To enable large scale deployment, it must not force the operators > > > and users to reboot boxes even if the worst case. The full mesh > > > approach is a fragility solution that has loop, blackhole > > or unreliable > > > flaky PEs problems, so we have no choice other than the > > conventional scheme. > > > > > > Second, if we regard xSTP as routing protocols, obviously > > there are less > > > efficient than OSPF/BGP. However, if we regard xSTP as protocols for > > > protection, these are not bad. If we reserve paths for fast > > protection > > > for the mesh, there are active and standby meshes. I think > > this problem > > > is not much different form xSTP link block problem. > > > > > > Finally, as far as I know, currently providers don't use > > STP due to long > > > recovery time; instead manually configure a single tree > > topology. However, > > > a single tree topology is not bad. Please image > > conventional telephone > > > network architecture; it is a tree. A tree is one of > > fundamental network > > > architecture. However, needless to say, topology free is > > much better than > > > a tree. Therefore, I proposed OSPF or BGP-4 extension for > > MAC routing > > > in Atlanta meeting (please see my slides in the last > > November). I think > > > it is not easy to progress this work in the IETF, but I > > believe we need > > > this kind of work in the near future. > > > > > > Thanks, > > > > > > Muneyoshi Suzuki > > > Nippon Telegraph and Telephone Corp. > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 17:02:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10562 for ; Tue, 29 Apr 2003 17:02:48 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TL56709555 for ; Tue, 29 Apr 2003 17:05:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TL53q02364 for ; Tue, 29 Apr 2003 17:05:03 -0400 (EDT) Date: Tue, 29 Apr 2003 22:58:48 +0200 From: Antonio Pinizzotto Subject: draft-kompella-ppvpn-vpls-01.txt To: ppvpn@nortelnetworks.com Message-id: <3EAEE788.283E439F@iit.cnr.it> Organization: CNR-IIT MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en X-SMTP-HELO: mx1.isti.cnr.it X-SMTP-MAIL-FROM: Antonio.Pinizzotto@iit.cnr.it X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mx1.isti.cnr.it [146.48.80.3] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit CNR is the National R&E institute in Italy. We would like to support draft-kompella-ppvpn-vpls-01.txt. We like the BGP approach, the scalability and flexibility of this solution. Thank you -- Antonio Pinizzotto C.N.R. Phone: +39 050 3152115 Ist. di Informatica e Telematica Mobile: +39 348 7981033 c/o Area della Ricerca di Pisa Fax: +39 050 3152593 Via Giuseppe Moruzzi, 1 mailto:Antonio.Pinizzotto@iit.cnr.it I-56124 Pisa (Italy) http://www.iit.cnr.it From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 17:14:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10862 for ; Tue, 29 Apr 2003 17:14:15 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TLCp712815 for ; Tue, 29 Apr 2003 17:12:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TLCjq23501 for ; Tue, 29 Apr 2003 17:12:45 -0400 (EDT) Date: Tue, 29 Apr 2003 17:08:23 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <133172974363.20030429170823@psg.com> To: ppvpn@nortelnetworks.com Subject: Re: draft-kompella-ppvpn-vpls-01.txt In-Reply-To: <3EAEE788.283E439F@iit.cnr.it> References: <3EAEE788.283E439F@iit.cnr.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Antonio, Just out of curiosity, do you read this mailing list? -- Alex Tuesday, April 29, 2003, 4:58:48 PM, Antonio Pinizzotto wrote: > CNR is the National R&E institute in Italy. > We would like to support draft-kompella-ppvpn-vpls-01.txt. > We like the BGP approach, the scalability and flexibility of this solution. > Thank you > -- > Antonio Pinizzotto > C.N.R. Phone: +39 050 3152115 > Ist. di Informatica e Telematica Mobile: +39 348 7981033 > c/o Area della Ricerca di Pisa Fax: +39 050 3152593 > Via Giuseppe Moruzzi, 1 mailto:Antonio.Pinizzotto@iit.cnr.it > I-56124 Pisa (Italy) http://www.iit.cnr.it From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 18:19: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 SAA14479 for ; Tue, 29 Apr 2003 18:19:04 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TMLO701415 for ; Tue, 29 Apr 2003 18:21:24 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TMLJo04460 for ; Tue, 29 Apr 2003 18:21:19 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , ppvpn@nortelnetworks.com Subject: RE: draft-kompella-ppvpn-vpls-01.txt Date: Tue, 29 Apr 2003 18:18:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E9D.518C89C8" 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_01C30E9D.518C89C8 Content-Type: text/plain; charset="iso-8859-1" Alex, Out of curiosity, why are you asking this question? Hamid. > > > Antonio, > > Just out of curiosity, do you read this mailing list? > > -- > Alex > > Tuesday, April 29, 2003, 4:58:48 PM, Antonio Pinizzotto wrote: > > > CNR is the National R&E institute in Italy. > > We would like to support draft-kompella-ppvpn-vpls-01.txt. > > We like the BGP approach, the scalability and flexibility > of this solution. > > > Thank you > > > -- > > Antonio Pinizzotto > > > C.N.R. Phone: +39 050 3152115 > > Ist. di Informatica e Telematica Mobile: +39 348 7981033 > > c/o Area della Ricerca di Pisa Fax: +39 050 3152593 > > Via Giuseppe Moruzzi, 1 > mailto:Antonio.Pinizzotto@iit.cnr.it > > I-56124 Pisa (Italy) http://www.iit.cnr.it > > > ------_=_NextPart_001_01C30E9D.518C89C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-kompella-ppvpn-vpls-01.txt

Alex,

Out of curiosity, why are you asking this = question?

Hamid.

>
>
> Antonio,
>
>  Just out of curiosity, do you read this = mailing list?
>
> --
> Alex
>
> Tuesday, April 29, 2003, 4:58:48 PM, Antonio = Pinizzotto wrote:
>
> > CNR is the National R&E institute in = Italy.
> > We would like to support = draft-kompella-ppvpn-vpls-01.txt.
> > We like the BGP approach, the scalability = and flexibility
> of this solution.
>
> > Thank you
>
> > --
> > Antonio Pinizzotto
>
> > = C.N.R.           =             =       Phone:  +39 050 3152115
> > Ist. di Informatica e = Telematica   Mobile: +39 348 7981033
> > c/o Area della Ricerca di = Pisa     Fax:    +39 050 = 3152593
> > Via Giuseppe Moruzzi, = 1            =
> mailto:Antonio.Pinizzotto@= iit.cnr.it
> > I-56124  Pisa = (Italy)           = ;   http://www.iit.cnr.it
>
>
>

------_=_NextPart_001_01C30E9D.518C89C8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 18:46:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15473 for ; Tue, 29 Apr 2003 18:46:20 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TMmb705710 for ; Tue, 29 Apr 2003 18:48:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TMmXh15272 for ; Tue, 29 Apr 2003 18:48:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Auto-discovery for VPLS in BGP Date: Wed, 30 Apr 2003 00:46:02 +0200 Message-ID: Thread-Topic: Auto-discovery for VPLS in BGP Thread-Index: AcMOd5qpIsziEOMhSp+2q2WDq8PsiwAImJAg From: "Hector Avalos" To: Cc: X-OriginalArrivalTime: 29 Apr 2003 22:46:03.0379 (UTC) FILETIME=[1CE4DC30:01C30EA1] X-SMTP-HELO: strange-smtp.jnpr.net X-SMTP-MAIL-FROM: havalos@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dublin-nat.juniper.net [193.110.50.4] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA15473 Vach, Sorry for the delay in answering your questions.... See below, Cheers, Hector > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: mardi 29 avril 2003 19:21 > To: Yakov Rekhter; erosen@cisco.com > Cc: Mourad BERKANE; raszuk@cisco.com; > Andreas.Mattsson@teliasonera.com; ppvpn@nortelnetworks.com > Subject: Auto-discovery for VPLS in BGP > > > Yakov, > > I asked Hector but he didn't answer this. There is some > magic here in the auto-discovery. How does a PE know its > site ID? Does it auto-discover it? Is it configured? If it > is configured, how can you guarantee the uniqueness? With or > without reference to all the other PEs in the VPLS? If with > reference to them, then what's the point of auto-discovery? > Within a VPLS domain, each VPLS instance has a VE ID...which is manually configured or automatically assigned by a provisioning system. So on a PE participating on a given VPLS domain, there will be one single VE ID, regardless of how may local connections (sites) are attached to it. This VE ID is unique within the VPLS domain only. A given PE can have several identical VE IDs.....which by definition should belong to different VPLS domains > Are site IDs reused? Can one PE be site ID 1 in one VPN and > site ID n (!= 1) in another? > Yes the VE-IDs are reused. Yes a PE can host the VE-ID 1 of VPLS domain X, and VE-ID 2 of VPLS domain y, and VE-ID 1 for VPLS domain z. VE-ID are unique ONLY within their VPLS domain. There is no relationship between the VE-ID numbering and the PE as you think. > If I understand correctly, the real identifier for a PE in an > L2VPN is: VPNID.PE.siteId. Without that, it won't work. > (And I'm not talking of the remote PE's site ID which is in > the NLRI, I'm talking of the local PE's site ID). > The NLRI is here after...and it does not include anything about remote site IDs.......as you mention. It only includes the VE-ID which is doing the NLRI advertisement. The extended community Route Target associated with this NLRI defines the VPLS domain. The real identifier for a PE is its next-hop announced with the BGP advertisement. Like in 2547bis. +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | Label-block Offset (2 octets) | +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ | Variable TLVs (0 to N octets) | | ... | +------------------------------------+ > If you remove a site from the VPLS, do you renumber site IDs? > Or waste labels? > If a PE has two sites belonging to the same VPLS domain (there is one single VE-ID), and you remove one of this sites, VE-ID does not need to change. If the second site is removed, the the VE-ID is removed. There is no need to renumber the VE-IDs. Do we waste labels ?.....one label on each PE participating to this VPLS domain. But again...I would like to know how big a VPLS domain will be. I asked the question and nobody has answered this yet. I do believe that VPLS domains will not be bigger than 50 VPLS instances. So in a VPLS domain of 100 instances, if we remove one VPLS instance, we only 'waste' one single label per PE. If you remove 50 site, you 'waste' 50 labels. ....as I said before, I know other VPNs implementations that do waste huge label blocks and seem to work fine from this perspective, at least nobody complains... So I believe that this is not really an issue.... > If you remove a range of sites from the NLRI, do you > advertise dummy label ranges to avoid renumbering sites? > No need to renumber....you still send the same base and offset values. > The auto-discovery for 2547 is pretty straightforward because > all you need to know is the VPN ID and the PE, which comes > from the NLRI. That comes because the label is "advertised" > not "signaled" with the distinction being that the former is > useable across the PEs in question and the latter is per-PE. As I described before...your statement is not true. > You can just use loopback address based RDs to ensure route > uniqueness, and the only common piece of info that you need > for correlation is the VPN ID. > > -Vach > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 19:34:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16634 for ; Tue, 29 Apr 2003 19:34:05 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TNaMT19355 for ; Tue, 29 Apr 2003 19:36:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TNaIk18957 for ; Tue, 29 Apr 2003 19:36:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20030429154015.01b61c98@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Apr 2003 16:33:48 -0700 To: Mourad BERKANE , "'erosen@cisco.com'" From: Ali Sajassi Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt Cc: "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com In-Reply-To: <8D91FF5277472A45A0A8F9654A1464970149499A@frlnparexcha03.la mbdanet.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_80818000==_.ALT" X-SMTP-HELO: sj-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-2.cisco.com [171.71.177.254] X-LYRIS-Message-Id: --=====================_80818000==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:51 PM 4/29/2003 +0200, Mourad BERKANE wrote: >Eric> Certainly it's true that LDP is NOT a routing protocol, and >that BGP IS a >Eric> >routing protocol. It's also true that both are used, in varying >Eric> circumstances, for distributing MPLS labels. As VPLS does >not require a >Eric> routing protocol, I'm not sure how one is supposed to >conclude from this >Eric> that BGP is a better signaling protocol for VPLS. > >If you consider VPLS service without others ones then OK both LDP and BGP >could be used as signaling protocol >I can add that as you said LDP is not able to autodiscovery but BGP could > >How will planed to offer VPLS service whitout IPv4 v6 L3VPN L2VPN ???? > >Now if you consider VPLS on a multiservices network then you will conclude >that BGP is more than well positionned for the control plane of theses >multiservices Yes, we all agree that we should leverage BGP as control plane among different VPN services such as VPWS, VPLS, and L3VPN but that doesn't mean to force the BGP for applications that is not suitable for. BGP is used for auto-discovery and distribution of IPv4 routes in L3VPN; whereas, in L2VPN applications (VPWS or VPLS) they are talking about auto-discovery and signaling (and the signaling part for PtP PWs didn't exist in L3VPN as has been discussed so many times). So the idea is to use best of both worlds: a) to leverage BGP as auto-discovery mechanism across all VPN types and b) to leverage PtP signaling mechanism of VPWS (which is already used and deployed) for VPLS which also requires PtP PWs. -Ali --=====================_80818000==_.ALT Content-Type: text/html; charset="us-ascii" At 05:51 PM 4/29/2003 +0200, Mourad BERKANE wrote:

Eric> Certainly it's true  that LDP is NOT  a routing protocol, and that  BGP IS a
Eric> routing  protocol.   It's   also  true  that  both  are   used,  in  varying
Eric> circumstances, for  distributing MPLS  labels.  As VPLS  does not  require a
Eric> routing protocol,  I'm not sure  how one is  supposed to conclude  from this
Eric> that BGP is a better signaling protocol for VPLS.

If you consider VPLS service without others ones then OK both LDP and BGP could be used as signaling protocol
I can add that as you said LDP is not able to autodiscovery but BGP could

How will planed to offer VPLS service whitout IPv4 v6 L3VPN L2VPN ????

Now if you consider VPLS on a multiservices network then you will conclude that BGP is more than well positionned for the control plane of theses multiservices

Yes, we all agree that we should leverage BGP as control plane among different VPN services such as VPWS, VPLS, and L3VPN but that doesn't mean to force the BGP for applications that is not suitable for. BGP is used for auto-discovery and distribution of IPv4 routes in L3VPN; whereas, in L2VPN applications (VPWS or VPLS) they are talking about auto-discovery and signaling (and the signaling part for PtP PWs didn't exist in L3VPN as has been discussed so many times).
So the idea is to use best of both worlds: a) to leverage BGP as auto-discovery mechanism across all VPN types and b) to leverage PtP signaling mechanism of VPWS (which is already used and deployed) for VPLS which also requires PtP PWs.

-Ali

--=====================_80818000==_.ALT-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 19:46:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17025 for ; Tue, 29 Apr 2003 19:46:01 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TNmJT23013 for ; Tue, 29 Apr 2003 19:48:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TNmF226684 for ; Tue, 29 Apr 2003 19:48:16 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6799@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: Cheng-Yin.Lee@alcatel.com Cc: nfinn@cisco.com, suzuki.muneyoshi@lab.ntt.co.jp, jwils@coriolisnet.com, ppvpn@nortelnetworks.com Subject: RE: Comments on the L2 VPN framework and solutions documents Date: Wed, 30 Apr 2003 00:45:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Cheng-Yin.....well, our current view is that VLANs live in the customer/corporate domain, and that the safest solution at this time is to use hard BW partitioning at L1/2 to isolate them. regards, Neil > -----Original Message----- > From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Sent: 29 April 2003 21:06 > To: Harrison,N,Neil,IKL2 R > Cc: nfinn@cisco.com; suzuki.muneyoshi@lab.ntt.co.jp; > jwils@coriolisnet.com; ppvpn@nortelnetworks.com > Subject: Re: Comments on the L2 VPN framework and solutions documents > > > Neil, > > There is a massive difference in > > > recognising the importance of ethernet as a key CPE > *interface* and then > > > (somehow) making the (wrong) extrapolation that this > means ethernet is a > > > great WAN technology. > I think this is an important point. > The next question then is what should end-customers with > multiple sites > but a single Ethernet interface to provider do? > > Thanks > Cheng-Yin. > > neil.2.harrison@bt.com wrote: > > > > Norman...I'd go further than saying that.....it's proposing > reinventing cnls > > networking (data-plane aspects too). There is a massive > difference in > > recognising the importance of ethernet as a key CPE > *interface* and then > > (somehow) making the (wrong) extrapolation that this means > ethernet is a > > great WAN technology. All *scalable* WAN networking modes > (of which there > > are only 3, viz cnls, co pkt-sw and co cct-sw) must have at least 2 > > functional components: > > - addressing: from a space that is large enough, and carries > > semantics of 'where' (not 'who'...that is a name) and thus > aggregatable; > > - consistent topological network map: whether centralised or > > distributed, to allow consistent route calculation. > > > > They must also have other functional components to make make them > > 'operationally viable', but addressing/routing are the min > set. Ethernet as > > a technology does not have addressing/routing functional > components that > > meet the WAN/scalability criteria. > > > > {Aside: As an aim (to stop doing stovepipes, ie > 'technology==service' and > > to minimise problematic gateways for data/control-plane > functions) we > > operators (or at least BT) are seeking functional > convergence *within* each > > of the networking modes but not *across* them (that one > makes no technical > > or commercial sense). So we agree with you that to try and > turn ethernet > > into a next generation cnls network is a 'bad idea'....we > have IP for that > > job.} > > > > Therefore, short of fundamentally re-working what ethernet > is today, the > > only pragmatic way to handle ethernet services in the WAN > is to accept that > > a proper WAN technology must act as a server layer to proxy > for the missing > > functions. SDH/GFP is a good solution. MPLS *could* be a good > > solution.....but it would need recognition that: > > - it is a layer network in its own right, eg it needs its own > > addressing regime (actually it subconsciously(?) gets this, but its > > different for each signalling type used and that is not a > good idea); > > - it belongs to the co pkt-sw mode (not the cnls > mode, that is IP) and > > thus does *not* have to be constrained by the limitations > of a cnls mode, eg > > in a client/server sense X/MPLS is *not* the same as > X/IP.....and it saddens > > me to see PWE3 try to treat them like this as though this > is a 'good idea' > > when its just dogma; > > - it needs proper OAM solutions......but the only topological > > constructs that make networking sense in a co pkt-sw mode > are p2p and > > p2mp......mp2p constructs just create problems for no > benefit (if one wants > > this sort of behaviour, use a proper IP/cnls mode which is > designed for this > > behaviour and where these problems don't exist). Further, > given X/MPLS and > > X/IP are different animals, then we want to see as much functional > > independence between the client (X) and the server layers (MPLS or > > IP).......and we don't want to see lots of in-between layer > functions being > > created (like PW OAM) that we also have to manage (noting > that we still have > > to manage the MPLS and IP layers anyway....so at least get > these right in > > their own right). > > > > regards, Neil > > > > > -----Original Message----- > > > From: Norman Finn [mailto:nfinn@cisco.com] > > > Sent: 25 April 2003 17:31 > > > To: Muneyoshi Suzuki > > > Cc: jwils@coriolisnet.com; ppvpn@nortelnetworks.com > > > Subject: Re: Comments on the L2 VPN framework and > solutions documents > > > > > > > > > Muneyoshi, > > > > > > I think that adding a TTL field to the MAC frame is an attractive > > > idea. I also think that it is an extraordinarily bad idea. If I > > > may paraphrase your argument, it is: (Forgive me, > please, for putting > > > words in your mouth.) > > > > > > 1. Routing is not reliable enough to establish the connections > > > that we need. Bridge A might be able to talk to Bridge B, but > > > not to Bridge C. > > > > > > 2. Spanning trees and full meshes, which don't require TTL, are > > > not good enough, for the reasons thoroughly discussed. (By > > > the way, I very much agree with you that, for large N, a full > > > mesh will not be reliable. My solution is to keep N fairly > > > small.) > > > > > > 3. Therefore, we'll add TTL and use OSPF to route the MAC frames. > > > > > > What I don't understand is how you have solved the problem that > > > Bridge A could not talk to Bridge C! Why is your toy > routing system > > > going to be any more robust than the existing routing system? > > > > > > This approach is not flawed because it is reinventing > bridging. It > > > is flawed because it is reinventing routing. > > > > > > -- Norm > > > > > > Muneyoshi Suzuki wrote: > > > > > > > > Joris, > > > > > > > > Thanks for clarification. > > > > > > > > First, needless to say, I aware link block problem of > STP/RSTP. We > > > > definitely need a solution. However, the solution must > be robust. > > > > To enable large scale deployment, it must not force the > operators > > > > and users to reboot boxes even if the worst case. The full mesh > > > > approach is a fragility solution that has loop, blackhole > > > or unreliable > > > > flaky PEs problems, so we have no choice other than the > > > conventional scheme. > > > > > > > > Second, if we regard xSTP as routing protocols, obviously > > > there are less > > > > efficient than OSPF/BGP. However, if we regard xSTP as > protocols for > > > > protection, these are not bad. If we reserve paths for fast > > > protection > > > > for the mesh, there are active and standby meshes. I think > > > this problem > > > > is not much different form xSTP link block problem. > > > > > > > > Finally, as far as I know, currently providers don't use > > > STP due to long > > > > recovery time; instead manually configure a single tree > > > topology. However, > > > > a single tree topology is not bad. Please image > > > conventional telephone > > > > network architecture; it is a tree. A tree is one of > > > fundamental network > > > > architecture. However, needless to say, topology free is > > > much better than > > > > a tree. Therefore, I proposed OSPF or BGP-4 extension for > > > MAC routing > > > > in Atlanta meeting (please see my slides in the last > > > November). I think > > > > it is not easy to progress this work in the IETF, but I > > > believe we need > > > > this kind of work in the near future. > > > > > > > > Thanks, > > > > > > > > Muneyoshi Suzuki > > > > Nippon Telegraph and Telephone Corp. > > > > > > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 19:53:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17308 for ; Tue, 29 Apr 2003 19:53:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TNu3T26662 for ; Tue, 29 Apr 2003 19:56:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3TNtx201913 for ; Tue, 29 Apr 2003 19:56:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20030429162252.01db9050@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Apr 2003 16:53:26 -0700 To: Yakov Rekhter , vkompella@timetra.com From: Ali Sajassi Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Cc: raszuk@cisco.com, "Mourad BERKANE" , ppvpn@nortelnetworks.com In-Reply-To: <200304291714.h3THESu97304@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Yakov, > > Sure, but the number of TCP connections inter-AS is as many as LDP, unless > > you are telling me that eBGP uses RR! > >If one would read 2547bis, then one should be able to fine the following: > > To improve scalability, one can have the multi-hop EBGP > connections exist only between a route reflector in one AS and > a route reflector in another. (However, when the route > reflectors distribute routes over this connection, they do not > modify the BGP next hop attribute of the routes.) > >Precisely the same applies for VPLS when autodiscovery and signaling >is done via BGP. No, it doesn't !! You forgot to mention the magic word, PtP PW scalability, which doesn't exist in L3VPN. By connecting all the PEs of a VPLS instance in one AS in a full-mesh to all other PEs of the same VPLS instance in a different AS, you've just increased the number of PWs by four-folds. Now as number of ASs increases, the number of PWs increases by N^2. The reason for hierarchical-VPLS topology which is also referred to in your draft is to address such scalability issues and to reduce the number of PWs. Therefore, connecting different ASes via hubs is intended to address such scalability issue and make the number of PWs grow linearly with number of ASes. So if number of PWs among ASes are small, then there is no issue with MD5 among small number of sessions and if the number of PWs is large, then you have scalability issue of PWs itsef (and maintenance of them). Also it is interesting that how arguments switch sides :-) At one point you were arguing in favor of such hub scheme for different ASes with different signaling types (e.g., between BGP and L2TPv3/LDP) and now you're arguing against it :-) -Ali >Yakov. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 21:17: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 VAA19793 for ; Tue, 29 Apr 2003 21:17:52 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3U1KAT17365 for ; Tue, 29 Apr 2003 21:20:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3U1K7w27358 for ; Tue, 29 Apr 2003 21:20:07 -0400 (EDT) Date: Tue, 29 Apr 2003 21:16:08 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <851465817.20030429211608@psg.com> To: ppvpn@nortelnetworks.com Subject: Re: draft-kompella-ppvpn-vpls-01.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hamid, > Out of curiosity, why are you asking this question? http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0304&L=ppvpn&T=0&F=&S=&P=26751 HTH. Alex From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Apr 29 23:19:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23320 for ; Tue, 29 Apr 2003 23:19:07 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3U3LPT00832 for ; Tue, 29 Apr 2003 23:21:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3U3LMo17310 for ; Tue, 29 Apr 2003 23:21:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20030428192627.01c62150@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Apr 2003 19:42:13 -0700 To: Norman Finn , Ali Sajassi From: Ali Sajassi Subject: Re: Comments on the L2 VPN framework and solutions documents Cc: erosen@cisco.com, Muneyoshi Suzuki , ppvpn@nortelnetworks.com In-Reply-To: <3EA967B8.F95C066F@cisco.com> References: <4.3.2.7.2.20030422173117.01cb2e98@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: At 09:52 AM 4/25/2003 -0700, Norman Finn wrote: >Ali, > >No matter what, no matter how good our failure detection/recovery mechanisms >are, there will always be short periods when connectivity is not correct. >If we can bound those periods (and that was the point of my first long >message), >then cranking up the spanning tree timers will solve everything. If we cannot >bound those periods (e.g. the full mesh can never be completed, because of >some >erroneous ACL in some router somewhere) then nothing will work. Yes I agree, but this is independent from which VPLS model is being used. In other words, the same problems that can exist with VLAN emulation model (using the full mesh of PWs) can also exist with the virtual port model where a partial mesh of PWs is used with STP over them (e.g., running STP over the core network between different islands). So I don't see any advantages of running STP over the core in this regard but the disadvantages in terms of scalability as mentioned previously are clear. -Ali >-- Norm > >Ali Sajassi wrote: > > > > At 10:42 AM 4/22/2003 -0400, Eric Rosen wrote: > > > > >Norm> Unless or until an FF has a pseudowire up and running to every > member > > >Norm> of its [auto-discovered] list, it must present ifOperState == > DOWN to > > >Norm> its upper layers. > > > > > >Then a single flaky PE would bring down the entire emulated > LAN, and the > > >emulated LAN would stay down until either that PE comes back > up, or the > > >discovery procedure successfully removes that PE from the > list and > > >successfully informs all the other PEs. This doesn't seem that good. > > > > It also seems to me that taking the entire Emulated LAN (set of PWs) down > > and up as the result of a PW or node failure, might be too much (e.g., > > causing unnecessary service interruption). With respect to failures > > affecting the Emulated LAN, there can be two types: > > > > a) PW failure: PW failure should be taken care by PSN - if not, then there > > is something wrong with the node and it should be consider as node failure, > > right ? > > b) node failure: If there is a redundant PE, then redundancy mechanism > > takes care of it (e.g., intra-island STP) and if PE is not redundant, then > > it gets removed from the mesh but the remaining PEs still maintain the > > full-mesh with each other. > > > > It seems if the customer BPDU timer is adjusted to compensate for these two > > caeses (PW recovery by PSN and node recovery by SP STP), then it should > be O.K. > > > > -Ali From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 04:13: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 EAA25048 for ; Wed, 30 Apr 2003 04:13:17 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3U8Fad29942 for ; Wed, 30 Apr 2003 04:15:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3U8FWc22811 for ; Wed, 30 Apr 2003 04:15:32 -0400 (EDT) Date: Wed, 30 Apr 2003 17:13:12 +0900 (JST) Message-Id: <20030430.171312.41636959.suzuki.muneyoshi@lab.ntt.co.jp> To: nfinn@cisco.com Cc: ppvpn@nortelnetworks.com, Cheng-Yin.Lee@alcatel.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: <3EA95C0A.3077599@cisco.com> References: <3EA08E50.7011B94@cisco.com> <20030421.134800.63057419.suzuki.muneyoshi@lab.ntt.co.jp> <3EA95C0A.3077599@cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Norm, > I don't think we're referring to the same model. The correct model > for how a bridge interacts with full-meshes, one full-mesh per VPLS > instance, is: The discussion is in the context of WG last call of the L2 FW doc and how to progress related solution drafts. So, I'm referring Eric's model describe in the FW doc. The following model completely differ from Eric's, so the following is disagreement to the FW doc, isn't it? > |===========================================--------+ > | | | forwarding | | > | | | function +--- | > E i --+ | untagged + VPLS 100 | | > t n | Provider | | for BPDUs +--- | P r > h t | Bridge | |------------| | s o > e e | | | +--- | e u > r r --+ | | forwarding | | u t > n f | Each "+" in | VLAN 26 + function +--- | d i > e a | the border of | | VPLS 200 | | o n > t c | this block | mux- | +--- | w g > e --+ represents one + demux |------------| | i > s | bridge port | function | +--- | r f > | | | | | e u > | | | +--- | s n > --+ | | forwarding | | c > | | VLAN 589 + function +--- | i t > | | | VPLS 300 | | n i > | | | +--- | o > --+ | | | | n > |===========================================--------+ > A B C > > The single interface above the "A" label at the bottom is the Provider > Bridge's bridge port that opens to the L3 world. The three interfaces > above the "B" label are the interfaces between the forwarding functions > and the mux-demux unit that translates between the Provider Bridge's > P-VLAN space and the VPLS VCID space. The "C" ports are the mouths of > the pseudowires. The physical ports on the routed side are of no > interest to the bridge. :) > > In my last note, I was pointing out that the each forwarding function > MUST control its "B" interface so that it provides 1) full service, or > 2) no service. (Let's be honest -- my last note was a little confused > between the "A" interface and the "B" interfaces.) > > Since VPLS meshes have one characteristic that physical LANs don't -- > one VLAN can be disconnected, while another is working -- IEEE 802.1 > needs to examine this situation, and figure out how to deal with it. > > Finally, let me note that only one VPLS -- the one used for BPDUs -- > is absolutely required to prevent a meltdown of the Provider's network. > A failure of one of the other VPLSs affects only that customer's traffic. (1) It seems to me, in the above model, PEs are interconnected with per customer meshes, where the PEs attached to the customer are interconnected with a full mesh. Therefore, in the worst case, there 2000 full meshes between PEs, if number of customers are 2000. Originally, full mesh has the O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem. Furthermore, if fast protection is supported to avoid the protection racing problem and partial mesh, there are double meshes between the PEs. So, I don't feel any reality from the above model. (2) Frankly, I don't well understand the above model, because it illustrates some implementation, but is not a protocol architecture. In the Bridge architecture defined in a series of the IEEE standards, a Bridge consists of MAC entities, a MAC relay entity, and a Higher layer entity. Could you clarify where these entities are located in the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located? If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located? What is VLAN mux-demux function? According to the standards, the VLAN ID value is effective only inside the MAC relay entity, so it does not identify MSAP. I'm not sure whether this conforms with the standards or not, but I think to realize this architecture big changes are needed to the current standards. ------ > If you use spanning tree among the pseudowires connecting Islands, > as in: > pw A > island 1 --------------------- island 2 > \ / > pw B \_______ _________/ pw C > \ / > island 3 > then one of pw A, pw B, or pw C must be blocked. Let's suppose it's > pw C. Then, all traffic from island 2 to island 3 must be relayed > by island 1. > In other words, since wires are almost "free" in this space, one > tends to have a lot of them. It the extreme case that you have a > full mesh of connections among all the participants in a net, spanning > tree is a particularly wasteful approach; it guarantees to block all > but N of the N*(N-1)/2 pseudowires! (: Yes, a bridge-bigot is saying > that spanning tree is not optimal for all interconnect plans. :) If xSTP (STP/RSTP/MSTP) is running in the SP network, there is no need to interconnect PEs with full mesh. But it has the link block problem; some links are blocked and unused in the network. However, as I mentioned in the mailing list, the full mesh scheme proposed in the FW doc has a similar problem, if it supports fast protection to avoid the protection racing problem and partial mesh. It needs double full meshes and 50% are not usually used. This problem is not much different from xSTP link block problem. And if the per customer meshes are used and if fast protection is supported, it wastes too many paths. I think xSTP link block problem is much better than it. ------ > > Obviously, this is a robust solution because it use LSPs as parallel system. > > Furthermore, this does not need to revise the existing standards, it only > > needs Q-in-Q or MAC-in-MAC specification in 802.1ad. > > As Ali points out, the problem with this approach is that the Provider Bridge > must either send or receive one BPDU on each pseudowire. If a Provider Bridge > is serving 2000 VPLSs, each with 10 pseudowires, that's 20,000 BPDUs per > second. That would be a difficult task to accomplish. On the occasion when > a failure occurs, and there are 20,000 state changes to process, I worry that > the pseudowire spanning tree would melt down, as did networks with slow > processors some years ago. > If you configure a relatively sparse interconnect plan, using just > a few pseudowires, and if those pseudowires approximate physical > reality, then spanning tree becomes more viable. The scaling > problem for 3000 VPLS instances at 10 pseudowires each becomes 3000 > VPLS instances at 2-3 pseudowires each, reducing the BPDU load from > 20,000 to 7,500. I would remark that our best bridges top out at > somewhere on the order of 1,000 - 2,000 BPDUs per second, at this > time. I need to think a bit more before I agree that this solution > "simple and robust". I'm not sure what is the issue in the above contexts. If you are claiming that the full mesh scheme/per customer meshes don't need to process customer BPDUs and xSTP based SP network need process all of customer BPDUs, thus the former is scale, it is completely nonsensical. In my understanding, in the SP network, customer BPDUs are o forwarded transparently and the network does not look up BPDUs contents. o forwarded transparently but the network snoop BPDUs and update states. o terminated and discarded regardless BPDUs contents. o terminated and discarded but the network snoop BPDUs and updates states. o terminated and discarded but a new BPDU is created based on the BPDU. And the SP network may create a BPDU and insert for a customer. Anyway, in the following, how to process xSTP is discussed because most interests relate on it. (1) The SP must ensure a single tree topology in the SP network. Manual configuration, provider-STP, and provider-RSTP can support it without any difficulties. In this process, the SP don't care customer-xSTP, because it is the SP's responsibility to ensure a tree topology, thus it is determined under the SP's policy and control. It is a quite unrealistic scenario that the SP network topology is changed by the customer-xSTP. (2) It is customer responsibility to ensure a single tree topology in the customer network which consists of customer sites interconnected by the SP network and backdoor links. This is because, the customer can cause a loop whether the SP forwards customer-xSTP transparently or the SP provides per-customer xSTP instances. If the customer does no use xSTP, there is a possibility to cause a loop. (3) If the SP forwards customer-xSTP transparently, and if the customer use customer-xSTP, it can avoid a loop even if it pass through the SP network. This is because, the SP ensures a single tree topology and a single customer Bridge that supports customer-xSTP in a loop is sufficient to detect and cut the loop. (4) However, it is highly desired to detect a customer loop in the SP network. But, (a) detection is not limited xSTP, another technology can also detect a loop, (b) provider core Bridges don't need to support per-customer xSTP instances, because Provider Edge Bridges that support pre-customer xSTP instances are sufficient to detect and cut the loop, and (c) the full-mesh scheme also has completely the same issues. (5) And it is highly desired for the SP network to detect customer network topology change and clear the cache for the customer, if the customer use xSTP and is multihomed. In this case, provider Bridges need to snoop customer-xSTP then forwards it transparently. However, both the xSTP based SP network and full-mesh scheme have completely the same issues. In summary, I don't find any disadvantage in the xSTP based SP network scheme compare with the full-mesh scheme. Furthermore, it does not have black hole, loop, and flaky PEs problems, because it based on the standards. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 05:40: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 FAA26627 for ; Wed, 30 Apr 2003 05:40:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3U9gMd13268 for ; Wed, 30 Apr 2003 05:42:22 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3U9gHV05660 for ; Wed, 30 Apr 2003 05:42:18 -0400 (EDT) Date: Wed, 30 Apr 2003 18:40:13 +0900 (JST) Message-Id: <20030430.184013.130229373.suzuki.muneyoshi@lab.ntt.co.jp> To: mark@mseery.com Cc: ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: Comments on the L2 VPN framework and solutions documents From: Muneyoshi Suzuki In-Reply-To: References: X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark, > Just looking through some of your comments I was wondering which of the > below "logical" networks is more preferable to you: Thanks. > 1) Emulated multipoint wire (where SP network is completely transparent) I'm not sure what is a logical wire in the LAN technology area. Is it a LAN segment? I don't understand meaning of the following diagram. > ------- > | CE1 |---------------------------- > ------- | | > | | > | | > ------- ------- > | CE2 | | CE3 | > ------- ------- > 2) Emulated switch (where the entire network looks like one switch) > ------- -------------------------- > | CE1 |--------| Ethernet Switch/Bridge | > ------- -------------------------- > | | > | | > ------- ------- > | CE2 | | CE3 | > ------- ------- > 3) Network of switches (where each PE behaves like an Ethernet switch) > ------- ------- ------- ------- > | CE1 |--------| SW1 |-----------------| SW2 |-------| CE2 | > ------- ------- ------- ------- > | | > | | Could you clarify what is Bridge in the above contexts. Is it Bridge defined in 802.1D-1998 or VLAN-aware Bridge defined in 802.1Q-1998? (please see page 2 in http://www.ietf.org/proceedings/02nov/slides/ppvpn-1.pdf ) Otherwise, is it 1982-style Bridge or VLAN-aware Bridge without the Bridge Protocol Entity? In these case, it is not much meaningful to distinguish 2) and 3). Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 07:41:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28931 for ; Wed, 30 Apr 2003 07:41:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UBhRd01336 for ; Wed, 30 Apr 2003 07:43:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3UBhMn04730 for ; Wed, 30 Apr 2003 07:43:23 -0400 (EDT) Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt From: Giles Heron To: Mourad BERKANE Cc: "'erosen@cisco.com'" , "'raszuk@cisco.com'" , Andreas.Mattsson@teliasonera.com, ppvpn@nortelnetworks.com In-Reply-To: <8D91FF5277472A45A0A8F9654A1464970149499A@frlnparexcha03.lambdanet.fr> References: <8D91FF5277472A45A0A8F9654A1464970149499A@frlnparexcha03.lambdanet.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 30 Apr 2003 12:37:33 +0000 Message-Id: <1051706253.1568.18.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On Tue, 2003-04-29 at 15:51, Mourad BERKANE wrote: > > Eric> Certainly it's true that LDP is NOT a routing protocol, and that > BGP IS a > Eric> routing protocol. It's also true that both are used, in > varying > Eric> circumstances, for distributing MPLS labels. As VPLS does not > require a > Eric> routing protocol, I'm not sure how one is supposed to conclude > from this > Eric> that BGP is a better signaling protocol for VPLS. > > > If you consider VPLS service without others ones then OK both LDP and BGP > could be used as signaling protocol > I can add that as you said LDP is not able to autodiscovery but BGP could > > How will planed to offer VPLS service whitout IPv4 v6 L3VPN L2VPN ???? in fact there are a few carriers who offer L2 services only... In that environment LDP seems like a good choice for VPLS - since it is already in use for VPWS (and in some cases for setting up the PE to PE LSPs). Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 11:29:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08748 for ; Wed, 30 Apr 2003 11:29:26 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UFVjT20418 for ; Wed, 30 Apr 2003 11:31:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3UFVbb04805 for ; Wed, 30 Apr 2003 11:31:37 -0400 (EDT) Message-ID: <006e01c30f2a$63cf7810$03c7380a@duckettm> From: "Mike Duckett \(Dotnet\)" To: References: <8D91FF5277472A45A0A8F9654A14649701494995@frlnparexcha03.lambdanet.fr> <3EAE9694.34251DD@cisco.com> Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Date: Wed, 30 Apr 2003 11:08:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SMTP-HELO: imf54bis.bellsouth.net X-SMTP-MAIL-FROM: mduckett@bellsouth.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail129.mail.bellsouth.net [205.152.58.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Potential tangent: I'd like the implementation decisions of an administrative domain (e.g,. a single operator) decoupled from interdomain configuration. This may be a unique requirement (e.g., a form of interworking). As noted, operators will make individual implementation decisions as will enterprises (I envision enterprise interdomain as well). In order to maximize on all our work, we need flexibility in provider/enterprise interconnections that are distinct from internal implementations. Again, one size does not fit all. Therefore, interprovider "interworking" may drive a unique set of requirements. ----- Original Message ----- From: "Wei Luo" To: "Mourad BERKANE" Cc: ; Sent: Tuesday, April 29, 2003 11:13 AM Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Why is it so evil to have inter-AS connectivity and open up LDP ports? Suppose service providers want to provide pseudowire services including point-to-point and VPLS across multi-AS non-MPLS network, i.e. IP only. The non-MPLS pseudowire signaling protocol is L2TPv3, which is a point-to-point protocol. It also requires inter-AS connectivity and to open up L2TPv3 ports. It seems that by your way of reasoning, we should use BGP to set up L2TP tunnels in an inter-AS environment as well? ---Wei > Mourad BERKANE wrote: > > Hi Jeremy > > (sorry about the non confusion) > > The "argument" is that today Providers don't (want to) have a (useless) LDP > peering sessions for VPLS application because BGP already present between > Providers (IP world). > > Suppose you would like to extend a VPLS domain out of your network, you will > need to extend signaling between theses networks ("hi i am PE1 from Carrier A > ASN=1 and I would like to join VPLS Z in your domain Carrier B ASN=2, please > use label L to send traffic to me"). The fact is that Carrier A and Carrier B > could already communicated over IPv4 Public network: a BGP session already > exist between A and B and could be used for many services (v4,v6,2547bis AND > VPLS) > > If you use BGP as VPLS signaling protocols, you will need to setup a MP-eBGP > session between AS > --> re use of existing BGP session between A and B > > Forwarding Tunnels used proposed in draft-kompella-ppvpn-vpls could be MPLS,IP > or GRE tunnels between A and B. > Someone who don't (or can't) discuss LDP could be a candidate for an extension > of a VPLS domain since the signaling protocol is BGP :-) > > If you use LDP as VPLS signaling protocols, you will need to open LDP ports > between A and B. > This new session is dedicated to VPLS services. Of course, It work but why > should I manage/troubleshoot this LDP inter-AS sessions since BGP already > present for others services? > > Mourad > > -----Message d'origine----- > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > Envoyé : mardi 29 avril 2003 15:03 > À : Mourad BERKANE > Cc : ppvpn@nortelnetworks.com > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > Hi Mourad, > > > LDP is not used as a signaling protocol for IPv4, IPv6 or > > rfc2547bis :-) > > BGP is in charge of it (and do the job very well). > > BGP distributes routes, it doesn't establish Pseudo-Wires in the > examples you give. > > > May be this will clarify all theses exchanges about signalling in > > VPLS: adding a new signaling protocol (LDP) whitout any added value > > versus keeping the same signalling protocol (BGP) for differents > > services (IP,rfc2547bis,VPLS, futures needs) > > > > You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling > > (LDP or BGP)? > > I'm sure I was not confused by the above ;-) > > What I meant was that LDP is used for pseudo-wire signaling > (http://www.ietf.org/html.charters/pwe3-charter.html, "Pseudo-Wire Setup > and Maintenance using LDP"), and that VPLS uses pseudo-wires. > > So arguments that say "BGP because it is also used for X" or "LDP > because it is also used for Y" are not convincing enough for me, as > you'll have BGP in some environments (2547) and LDP in other > environments (PWE3) and LDP + BGP in many environments ;-) > > What I really wanted to know is what the difference is for inter-AS > applications, as this seems to be one of the *technical* arguments. > > Jeremy. > > > > > Mourad > > > > -----Message d'origine----- > > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > > Envoyé : mardi 29 avril 2003 14:19 > > À : Mourad BERKANE > > Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; > > erosen@cisco.com; ppvpn@nortelnetworks.com > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Mourad, > > > > > As you hinted here, MP-BGP is much more designed for a *public* > > > inter-AS session for VPLS. > > > > I still don't understand why MP-BGP is more appropriate than LDP for > > this application. I probably need more than a "hint" to fully > > understand > > it ;-) > > > > > Even if LDP/RSVP already present for the forwarding plane inside a > > > MPLS domain, why should i used LDP for VPLS signalling when BGP > > > already do the job (IPv4,v6,rfc2547bis,...)??? > > > > You can turn this around: Even if BGP is already present for 2547bis, > > v4, v6 etc, why should I use BGP for VPLS signaling when LDP already > > does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 > > Pseudo-Wires, ...) ? > > > > [I guess the answer to both of the above questions is given in the > > large > > number of previous emails on this topic ;-)] > > > > Jeremy. > > > > > Mourad > > > > > > -----Message d'origine----- > > > De : Robert Raszuk [mailto:raszuk@cisco.com] > > > Envoyé : mardi 29 avril 2003 11:26 > > > À : Andreas.Mattsson@teliasonera.com > > > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > Andres, > > > > > > AFAIK there is no need to configure anything rather then a site > > > interface on the PEs. Autodiscovery will detect new addition and > > > propagate the news to all participants. Then in the > > lasserre-vkompella > > > > > > scheme directed LDP if not already set get's automatically > > established > > > > > > between parties. > > > > > > Of course the drawback here is that you need to keep LDP ports open > > > wide > > > within inter-AS LDP src ranges which may or may not be an acceptable > > > > > issue :-). > > > > > > R. > > > > > > > Andreas.Mattsson@teliasonera.com wrote: > > > > > > > > Hi Eric > > > > > > > > As I understand it a requirement would be to have a full mesh of > > LDP > > > > > > > sessions between the PEs in the participating AS domains. This > > means > > > > > > > configuration of each PE when for example a new site is added to > > an > > > > already existing VPN. If BGP is used this is not necessary as RRs > > > can be > > > > used, minimizing the configuration to the new PE and the RR. > > > > But perhaps there exist a solution similar to this for LDP as > > well? > > > It > > > > seems appealing to reuse the 2547bis structure we have also for > > VPLS > > > if > > > > it's possible. > > > > > > > > My point is that further investigation of the two different > > > solutions > > > > before rejecting one or the other would be good > > > > > > > > /Andreas > > > > > > > > -----Original Message----- > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > Sent: den 28 april 2003 16:29 > > > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > > > Cc: ppvpn@nortelnetworks.com > > > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > > > Andreas> I would also like to know how inter-AS with the LDP > > > > Andreas> approach in lasserre-vkompella is to be solved. > > > > > > > > Could you say what the issue is that you think needs to be solved? From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 11:48:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09558 for ; Wed, 30 Apr 2003 11:48:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UFopT28619 for ; Wed, 30 Apr 2003 11:50:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3UFokQ20131 for ; Wed, 30 Apr 2003 11:50:46 -0400 (EDT) Message-ID: <20030430154647.72161.qmail@web13504.mail.yahoo.com> Date: Wed, 30 Apr 2003 08:46:47 -0700 (PDT) From: Mark Seery Subject: Re: Comments on the L2 VPN framework and solutions documents To: Muneyoshi Suzuki Cc: ppvpn@nortelnetworks.com In-Reply-To: <20030430.184013.130229373.suzuki.muneyoshi@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13504.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13504.mail.yahoo.com [216.136.175.83] X-LYRIS-Message-Id: --- Muneyoshi Suzuki wrote: > Is it a LAN segment? I don't understand meaning of > the following diagram. < Yes - LAN segment. > Could you clarify what is Bridge in the above > contexts. Is it Bridge > defined in 802.1D-1998 or VLAN-aware Bridge defined > in 802.1Q-1998? > (please see page 2 in > http://www.ietf.org/proceedings/02nov/slides/ppvpn-1.pdf > ) For the purposes of what I was inquiry about I don't think it makes difference - more interesting in the spanning tree processing points you are interested in. But, for the sake of argument lets assume it is a VLAN-aware Bridge (I realize there are important differnces based on installed based interoperability) > Otherwise, is it 1982-style Bridge or VLAN-aware > Bridge without the Bridge Protocol Entity? > In these case, it is not > much meaningful to > distinguish 2) and 3). > I was assuming with the Bridge Protocol Entity, in which case there would be a difference, I believe. In 3) Spanning tree may influence routing within the VPLS, whereas it would not in 2) and obviously not in 1) Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 12:02: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 MAA10099 for ; Wed, 30 Apr 2003 12:02:43 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UG53T23201 for ; Wed, 30 Apr 2003 12:05:03 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3UG4w118511 for ; Wed, 30 Apr 2003 12:04:59 -0400 (EDT) Message-ID: <20030430160111.89545.qmail@web13501.mail.yahoo.com> Date: Wed, 30 Apr 2003 09:01:11 -0700 (PDT) From: Mark Seery Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt To: giles@packetexchange.net Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13501.mail.yahoo.com X-SMTP-MAIL-FROM: m_seery@yahoo.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13501.mail.yahoo.com [216.136.175.80] X-LYRIS-Message-Id: Giles, >> in fact there are a few carriers who offer L2 services only... In that environment LDP seems like a good choice for VPLS - since it is already in use for VPWS (and in some cases for setting up the PE to PE LSPs). << Yes, but there are a number of carriers who offer these services on different networks. Some offer them in different business units, and in some cases one set of services are offered on the regulated side and another set on the unregulated side which "Chinese Wall" dividers. We can argue the appropriateness of such arrangements, but to say carriers offer both services and lead it at that is misleading (IMO). The point being, that each of these services may be in a different operational domain, and an operations staff may choose to implement the technology/architecture which they feel is most appropriate for what they are doing. Not making an argument against LDP. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 15:26:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21393 for ; Wed, 30 Apr 2003 15:26:42 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UJT1T23899 for ; Wed, 30 Apr 2003 15:29:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3UJSwS19768 for ; Wed, 30 Apr 2003 15:28:58 -0400 (EDT) Message-ID: <39469E08BD83D411A3D900204840EC55F2F9F8@vie-msgusr-01.dc.fore.com> From: "Shmunis, Gregory" To: "'Thomas D. Nadeau'" Cc: ppvpn@nortelnetworks.com Subject: RE: Question regdg. MPLS/BGP VPN MIB Date: Wed, 30 Apr 2003 15:25:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: Gregory.Shmunis@marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Tom, can you please point to a previous thread where concrete operational scenarios with an interface belonging to more than one VRF were discussed ? If it is simpler for you, can you just mention a case or two ? thank you, Greg. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Tuesday, April 29, 2003 11:00 AM To: Siddharth Aanand Cc: ppvpn@nortelnetworks.com; "Harmen Van der Linde"hvdl@att.com Subject: Re: Question regdg. MPLS/BGP VPN MIB At 10:46 AM 4/29/2003 -0400, Siddharth Aanand wrote: > > >The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > > >mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I had > > >was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > > >identify a row in this table ? Under what circumstances do we need both > > >the vrfName as well as the ifIndex as keys? > > > > Yes, but the operational feedback was that operators > > wanted to cycle through interfaces belonging to each VRF. > > We need to update this slightly because there are cases where > > one interface may belong to multiple VRFs. > >Yes. If one interface belongs to multiple VRFs then we'd need the vrfName >as a key. Do you know what distinguishing feature of the incoming traffic, >on that interface, would be used to decide which VRF to use? I think that is orthogonal to the discussion at hand. What is important is that the MIB can handle these cases without regard to how the choice is being made. The reason being that it is often a proprietary feature/configuration that does the choosing. My implementation for instance, uses several rules to make this determination. I know of another that makes a simple choice based on source address. --Tom >-Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 16:18: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 QAA22650 for ; Wed, 30 Apr 2003 16:18:31 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UKKnT24614 for ; Wed, 30 Apr 2003 16:20:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3UKKhS19283 for ; Wed, 30 Apr 2003 16:20:44 -0400 (EDT) X-Originating-IP: [219.65.34.150] X-Originating-Email: [rtrfwdfrccie@hotmail.com] From: "Amit Singh" To: "Mark Seery" Cc: References: <20030430160111.89545.qmail@web13501.mail.yahoo.com> Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Date: Wed, 30 Apr 2003 12:52:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 30 Apr 2003 20:17:20.0169 (UTC) FILETIME=[80A8D190:01C30F55] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: rtrfwdfrccie@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: oe47.law11.hotmail.com [64.4.16.19] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark, L3 VPN services will be needed if that is one of the services you are mentioning but in big network deployments no Service Provider customer is willingly interested in handling its customers routing table no Service Provider customer wants to run mVPN on stupid non-standard they rather have the customer handle thier multicast network In Metro ethernet deployments the customer will have Minimum 200-300 customers coming via l2 switches i dont want to be putting 200 static routes or run ospf with one customer rip with another and screw around with already unstable vendors boxes Finally point to point is really useless no customer will have only 2 sites and i dont want to build multiple vc's they will have multiple sites VPLS seems to be a gr8 thing for it as far as cheap services to a customer goes using BGP or LDP goes from what i have read LDP looks fine too me but then i leave it to the experts like the eric rosens the vach's and sajassi's Finally I hope VPLS gets standardized with martini flavour and we go ahead and focuss on issues like giving restricted access to other vpls domains so that restricted internet access (like one port in a customer vpls dom and the same port also in a l2 vpls dom which gives internet access) Thanks & Regards Amit S ----- Original Message ----- From: "Mark Seery" To: Cc: Sent: Wednesday, April 30, 2003 9:01 AM Subject: RE: Support for draft-kompella-ppvpn-vpls-01.txt > Giles, > > >> in fact there are a few carriers who offer L2 > services only... In that > environment LDP seems like a good choice for VPLS - > since it is already > in use for VPWS (and in some cases for setting up the > PE to PE LSPs). << > > Yes, but there are a number of carriers who offer > these services on different networks. Some offer them > in different business units, and in some cases one set > of services are offered on the regulated side and > another set on the unregulated side which "Chinese > Wall" dividers. We can argue the appropriateness of > such arrangements, but to say carriers offer both > services and lead it at that is misleading (IMO). > > The point being, that each of these services may be in > a different operational domain, and an operations > staff may choose to implement the > technology/architecture which they feel is most > appropriate for what they are doing. > > Not making an argument against LDP. > > Mark > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 16:48: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 QAA23629 for ; Wed, 30 Apr 2003 16:48:33 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UKoYT00874 for ; Wed, 30 Apr 2003 16:50:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3UKoTH01404 for ; Wed, 30 Apr 2003 16:50:29 -0400 (EDT) Message-Id: <5.2.0.9.2.20030430164438.0160e0c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 16:47:13 -0400 To: "Shmunis, Gregory" From: "Thomas D. Nadeau" Subject: RE: Question regdg. MPLS/BGP VPN MIB Cc: ppvpn@nortelnetworks.com, Yacine.El_Mghazli@alcatel.fr In-Reply-To: <39469E08BD83D411A3D900204840EC55F2F9F8@vie-msgusr-01.dc.fo re.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: >Tom, > >can you please point to a previous thread where concrete operational >scenarios with an interface belonging to more than one VRF were discussed ? >If it is simpler for you, can you just mention a case or two ? I have two examples. First, Yacine pointed out a case a while back that we discussed -- perhaps he can explain his scenario. In my case, my products allow for multiple VRFs to be associated with the same interface, and then based on the source address, one of the VRFs is chosen to do the route lookup. Admittedly, this is not a widely used case, but I think it is still one that is used enough that the standard MIB should handle it. --Tom >thank you, > >Greg. > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Tuesday, April 29, 2003 11:00 AM >To: Siddharth Aanand >Cc: ppvpn@nortelnetworks.com; "Harmen Van der Linde"hvdl@att.com >Subject: Re: Question regdg. MPLS/BGP VPN MIB > > >At 10:46 AM 4/29/2003 -0400, Siddharth Aanand wrote: > > > >The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > > > >mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I >had > > > >was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > > > >identify a row in this table ? Under what circumstances do we need both > > > >the vrfName as well as the ifIndex as keys? > > > > > > Yes, but the operational feedback was that operators > > > wanted to cycle through interfaces belonging to each VRF. > > > We need to update this slightly because there are cases where > > > one interface may belong to multiple VRFs. > > > >Yes. If one interface belongs to multiple VRFs then we'd need the vrfName > >as a key. Do you know what distinguishing feature of the incoming traffic, > >on that interface, would be used to decide which VRF to use? > > I think that is orthogonal to the discussion at hand. >What is important is that the MIB can handle these >cases without regard to how the choice is being made. >The reason being that it is often a proprietary feature/configuration >that does the choosing. My implementation for instance, >uses several rules to make this determination. I know of >another that makes a simple choice based on source >address. > > --Tom > > > > >-Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 17:09:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24345 for ; Wed, 30 Apr 2003 17:09:14 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ULBYT20595 for ; Wed, 30 Apr 2003 17:11:34 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ULBSI09310 for ; Wed, 30 Apr 2003 17:11:29 -0400 (EDT) Message-ID: <20030430210257.15833.qmail@web13503.mail.yahoo.com> Date: Wed, 30 Apr 2003 14:02:57 -0700 (PDT) From: Mark Seery Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt To: Amit Singh Cc: ppvpn@nortelnetworks.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13503.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13503.mail.yahoo.com [216.136.175.82] X-LYRIS-Message-Id: Hi Amit, --- Amit Singh wrote: > Mark, > L3 VPN services will be needed if that is one of the > services you are mentioning but.......< I am not entirely sure how to parse your email, but it came across (to me) as a list of problems you see with layer 3 VPNs (perhaps u wre suggesting VPLS is the only thing anyone would ever run?). Happy to discuss offline; not sure if that is pertinent to this working group; other than to observe that the more we attempt to turn VPLS into Ethernet switches running atop routers, the more attractive layer 3 VPNs begin to look ;-) > .....focuss on issues like giving restricted access > to other vpls domains > so that restricted internet access (like one port in > a customer vpls dom and > the same port also in a l2 vpls dom which gives > internet access) I think this is an idea worth exploring, I have discussed already with at least one carrier, and think it could provide value. There are some philisophical issues to be considered such as if all the attached service networks are IP-based then what is the best solution etc (i.e. multiprotocol transport is needed for enterprise LAN interconnection but not for IP-service interconnection, so how to mix the best of VPLS and IPLS or indeed L3VPN). I believe someone today has already called for separation of intra and inter-domain work. Seems like this would be another reason to do so. Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 17:27:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24756 for ; Wed, 30 Apr 2003 17:27:08 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ULTQT24727 for ; Wed, 30 Apr 2003 17:29:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ULTME19914 for ; Wed, 30 Apr 2003 17:29:22 -0400 (EDT) Message-ID: <39469E08BD83D411A3D900204840EC55F2F9FF@vie-msgusr-01.dc.fore.com> From: "Shmunis, Gregory" To: "'Thomas D. Nadeau'" Cc: ppvpn@nortelnetworks.com, Yacine.El_Mghazli@alcatel.fr Subject: RE: Question regdg. MPLS/BGP VPN MIB Date: Wed, 30 Apr 2003 17:26:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: Gregory.Shmunis@marconi.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: Tom, thanks. I understand the technical aspect of using various criteria (including the source address) in the PE-incoming traffic to identify the right lookup VRF. What I'm trying to figure out is a concrete deployment case where sharing of a PE interface between VRFs would be required, and also - what are potential side-effects of such use. For instance, the example of using the source address alone on a VRF-shared interface implies that the VRFs that share the interface cannot use overlapping address spaces - otherwise the traffic in the reverse (PE-to-CE) direction would be untreatable. Perhaps Yasin can give his example. Having said all the above I want to make it clear that the question is less of a MIB nature - it pertains to the general operational aspect of 2547bis. greg. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, April 30, 2003 4:47 PM To: Shmunis, Gregory Cc: ppvpn@nortelnetworks.com; Yacine.El_Mghazli@alcatel.fr Subject: RE: Question regdg. MPLS/BGP VPN MIB >Tom, > >can you please point to a previous thread where concrete operational >scenarios with an interface belonging to more than one VRF were discussed ? >If it is simpler for you, can you just mention a case or two ? I have two examples. First, Yacine pointed out a case a while back that we discussed -- perhaps he can explain his scenario. In my case, my products allow for multiple VRFs to be associated with the same interface, and then based on the source address, one of the VRFs is chosen to do the route lookup. Admittedly, this is not a widely used case, but I think it is still one that is used enough that the standard MIB should handle it. --Tom >thank you, > >Greg. > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Tuesday, April 29, 2003 11:00 AM >To: Siddharth Aanand >Cc: ppvpn@nortelnetworks.com; "Harmen Van der Linde"hvdl@att.com >Subject: Re: Question regdg. MPLS/BGP VPN MIB > > >At 10:46 AM 4/29/2003 -0400, Siddharth Aanand wrote: > > > >The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > > > >mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I >had > > > >was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > > > >identify a row in this table ? Under what circumstances do we need both > > > >the vrfName as well as the ifIndex as keys? > > > > > > Yes, but the operational feedback was that operators > > > wanted to cycle through interfaces belonging to each VRF. > > > We need to update this slightly because there are cases where > > > one interface may belong to multiple VRFs. > > > >Yes. If one interface belongs to multiple VRFs then we'd need the vrfName > >as a key. Do you know what distinguishing feature of the incoming traffic, > >on that interface, would be used to decide which VRF to use? > > I think that is orthogonal to the discussion at hand. >What is important is that the MIB can handle these >cases without regard to how the choice is being made. >The reason being that it is often a proprietary feature/configuration >that does the choosing. My implementation for instance, >uses several rules to make this determination. I know of >another that makes a simple choice based on source >address. > > --Tom > > > > >-Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 17:50:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25310 for ; Wed, 30 Apr 2003 17:50:46 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3ULqoT29971 for ; Wed, 30 Apr 2003 17:52:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h3ULqkx29628 for ; Wed, 30 Apr 2003 17:52:46 -0400 (EDT) Message-Id: <5.2.0.9.2.20030430174711.0160cfd0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 17:49:43 -0400 To: "Shmunis, Gregory" From: "Thomas D. Nadeau" Subject: RE: Question regdg. MPLS/BGP VPN MIB Cc: ppvpn@nortelnetworks.com, Yacine.El_Mghazli@alcatel.fr In-Reply-To: <39469E08BD83D411A3D900204840EC55F2F9FF@vie-msgusr-01.dc.fo re.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] X-LYRIS-Message-Id: >thanks. I understand the technical aspect of using various criteria >(including the source address) in the PE-incoming traffic to identify the >right lookup VRF. What I'm trying to figure out is a concrete deployment >case where sharing of a PE interface between VRFs would be required, and >also - what are potential side-effects of such use. For instance, the >example of using the source address alone on a VRF-shared interface implies >that the VRFs that share the interface cannot use overlapping address spaces >- otherwise the traffic in the reverse (PE-to-CE) direction would be >untreatable. Go to www.cisco.com and search for "multi-vrf" or "vrf lite". --Tom >Perhaps Yasin can give his example. Having said all the above I want to make >it clear that the question is less of a MIB nature - it pertains to the >general operational aspect of 2547bis. > > >greg. > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Wednesday, April 30, 2003 4:47 PM >To: Shmunis, Gregory >Cc: ppvpn@nortelnetworks.com; Yacine.El_Mghazli@alcatel.fr >Subject: RE: Question regdg. MPLS/BGP VPN MIB > > > > >Tom, > > > >can you please point to a previous thread where concrete operational > >scenarios with an interface belonging to more than one VRF were discussed ? > >If it is simpler for you, can you just mention a case or two ? > > I have two examples. First, Yacine pointed out >a case a while back that we discussed -- perhaps >he can explain his scenario. In my case, my products >allow for multiple VRFs to be associated with the same >interface, and then based on the source address, one >of the VRFs is chosen to do the route lookup. Admittedly, >this is not a widely used case, but I think it is still one >that is used enough that the standard MIB should handle >it. > > --Tom > > > > > > >thank you, > > > >Greg. > > > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Tuesday, April 29, 2003 11:00 AM > >To: Siddharth Aanand > >Cc: ppvpn@nortelnetworks.com; "Harmen Van der Linde"hvdl@att.com > >Subject: Re: Question regdg. MPLS/BGP VPN MIB > > > > > >At 10:46 AM 4/29/2003 -0400, Siddharth Aanand wrote: > > > > >The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and > > > > >mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I > >had > > > > >was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely > > > > >identify a row in this table ? Under what circumstances do we need >both > > > > >the vrfName as well as the ifIndex as keys? > > > > > > > > Yes, but the operational feedback was that operators > > > > wanted to cycle through interfaces belonging to each VRF. > > > > We need to update this slightly because there are cases where > > > > one interface may belong to multiple VRFs. > > > > > >Yes. If one interface belongs to multiple VRFs then we'd need the vrfName > > >as a key. Do you know what distinguishing feature of the incoming >traffic, > > >on that interface, would be used to decide which VRF to use? > > > > I think that is orthogonal to the discussion at hand. > >What is important is that the MIB can handle these > >cases without regard to how the choice is being made. > >The reason being that it is often a proprietary feature/configuration > >that does the choosing. My implementation for instance, > >uses several rules to make this determination. I know of > >another that makes a simple choice based on source > >address. > > > > --Tom > > > > > > > > >-Sidd From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Apr 30 20:00:46 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00581 for ; Wed, 30 Apr 2003 20:00:45 -0400 (EDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4102mT26213 for ; Wed, 30 Apr 2003 20:02:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h4102iU03947 for ; Wed, 30 Apr 2003 20:02:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20030430163325.048bc6f8@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Apr 2003 16:59:21 -0700 To: "Mike Duckett \(Dotnet\)" From: Chris Metz Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt Cc: In-Reply-To: <006e01c30f2a$63cf7810$03c7380a@duckettm> References: <8D91FF5277472A45A0A8F9654A14649701494995@frlnparexcha03.lambdanet.fr> <3EAE9694.34251DD@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: chmetz@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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA00581 At 11:08 AM 4/30/2003 -0400, Mike Duckett \(Dotnet\) wrote: >Potential tangent: > >I'd like the implementation decisions of an administrative domain (e.g,. a >single operator) decoupled from interdomain configuration. This may be a >unique requirement (e.g., a form of interworking). As noted, operators will >make individual implementation decisions as will enterprises (I envision >enterprise interdomain as well). In order to maximize on all our work, we >need flexibility in provider/enterprise interconnections that are distinct >from internal implementations. I agree. I can imagine scenarios where two PEs belonging to different ASes that employ a different PW signaling and encapsulation scheme (i.e. LDP and L2TPv3) need to source/sink a PW. An analogy can be drawn with routing in which each AS is free to employ their IGP of choice. >Again, one size does not fit all. Therefore, interprovider "interworking" >may drive a unique set of requirements. > > >----- Original Message ----- >From: "Wei Luo" >To: "Mourad BERKANE" >Cc: ; >Sent: Tuesday, April 29, 2003 11:13 AM >Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > >Why is it so evil to have inter-AS connectivity and open up LDP ports? > >Suppose service providers want to provide pseudowire services including >point-to-point and VPLS across multi-AS non-MPLS network, i.e. IP only. The >non-MPLS pseudowire signaling protocol is L2TPv3, which is a point-to-point >protocol. It also requires inter-AS connectivity and to open up L2TPv3 >ports. > >It seems that by your way of reasoning, we should use BGP to set up L2TP >tunnels >in an inter-AS environment as well? > >---Wei > > > Mourad BERKANE wrote: > > > > Hi Jeremy > > > > (sorry about the non confusion) > > > > The "argument" is that today Providers don't (want to) have a (useless) >LDP > > peering sessions for VPLS application because BGP already present between > > Providers (IP world). > > > > Suppose you would like to extend a VPLS domain out of your network, you >will > > need to extend signaling between theses networks ("hi i am PE1 from >Carrier A > > ASN=1 and I would like to join VPLS Z in your domain Carrier B ASN=2, >please > > use label L to send traffic to me"). The fact is that Carrier A and >Carrier B > > could already communicated over IPv4 Public network: a BGP session already > > exist between A and B and could be used for many services (v4,v6,2547bis >AND > > VPLS) > > > > If you use BGP as VPLS signaling protocols, you will need to setup a >MP-eBGP > > session between AS > > --> re use of existing BGP session between A and B > > > > Forwarding Tunnels used proposed in draft-kompella-ppvpn-vpls could be >MPLS,IP > > or GRE tunnels between A and B. > > Someone who don't (or can't) discuss LDP could be a candidate for an >extension > > of a VPLS domain since the signaling protocol is BGP :-) > > > > If you use LDP as VPLS signaling protocols, you will need to open LDP >ports > > between A and B. > > This new session is dedicated to VPLS services. Of course, It work but why > > should I manage/troubleshoot this LDP inter-AS sessions since BGP already > > present for others services? > > > > Mourad > > > > -----Message d'origine----- > > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > > Envoyé : mardi 29 avril 2003 15:03 > > À : Mourad BERKANE > > Cc : ppvpn@nortelnetworks.com > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > Hi Mourad, > > > > > LDP is not used as a signaling protocol for IPv4, IPv6 or > > > rfc2547bis :-) > > > BGP is in charge of it (and do the job very well). > > > > BGP distributes routes, it doesn't establish Pseudo-Wires in the > > examples you give. > > > > > May be this will clarify all theses exchanges about signalling in > > > VPLS: adding a new signaling protocol (LDP) whitout any added value > > > versus keeping the same signalling protocol (BGP) for differents > > > services (IP,rfc2547bis,VPLS, futures needs) > > > > > > You may confuse MPLS signaling (LDP or RSVP) and and VPLS signaling > > > (LDP or BGP)? > > > > I'm sure I was not confused by the above ;-) > > > > What I meant was that LDP is used for pseudo-wire signaling > > (http://www.ietf.org/html.charters/pwe3-charter.html, "Pseudo-Wire Setup > > and Maintenance using LDP"), and that VPLS uses pseudo-wires. > > > > So arguments that say "BGP because it is also used for X" or "LDP > > because it is also used for Y" are not convincing enough for me, as > > you'll have BGP in some environments (2547) and LDP in other > > environments (PWE3) and LDP + BGP in many environments ;-) > > > > What I really wanted to know is what the difference is for inter-AS > > applications, as this seems to be one of the *technical* arguments. > > > > Jeremy. > > > > > > > > Mourad > > > > > > -----Message d'origine----- > > > De : jeremy.de_clercq@alcatel.be [mailto:jeremy.de_clercq@alcatel.be] > > > Envoyé : mardi 29 avril 2003 14:19 > > > À : Mourad BERKANE > > > Cc : 'raszuk@cisco.com'; Andreas.Mattsson@teliasonera.com; > > > erosen@cisco.com; ppvpn@nortelnetworks.com > > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > Mourad, > > > > > > > As you hinted here, MP-BGP is much more designed for a *public* > > > > inter-AS session for VPLS. > > > > > > I still don't understand why MP-BGP is more appropriate than LDP for > > > this application. I probably need more than a "hint" to fully > > > understand > > > it ;-) > > > > > > > Even if LDP/RSVP already present for the forwarding plane inside a > > > > MPLS domain, why should i used LDP for VPLS signalling when BGP > > > > already do the job (IPv4,v6,rfc2547bis,...)??? > > > > > > You can turn this around: Even if BGP is already present for 2547bis, > > > v4, v6 etc, why should I use BGP for VPLS signaling when LDP already > > > does the job (LDP for intra-AS tunnel LSPs, LDP for individual PWE3 > > > Pseudo-Wires, ...) ? > > > > > > [I guess the answer to both of the above questions is given in the > > > large > > > number of previous emails on this topic ;-)] > > > > > > Jeremy. > > > > > > > Mourad > > > > > > > > -----Message d'origine----- > > > > De : Robert Raszuk [mailto:raszuk@cisco.com] > > > > Envoyé : mardi 29 avril 2003 11:26 > > > > À : Andreas.Mattsson@teliasonera.com > > > > Cc : erosen@cisco.com; ppvpn@nortelnetworks.com > > > > Objet : Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > > > Andres, > > > > > > > > AFAIK there is no need to configure anything rather then a site > > > > interface on the PEs. Autodiscovery will detect new addition and > > > > propagate the news to all participants. Then in the > > > lasserre-vkompella > > > > > > > > scheme directed LDP if not already set get's automatically > > > established > > > > > > > > between parties. > > > > > > > > Of course the drawback here is that you need to keep LDP ports open > > > > wide > > > > within inter-AS LDP src ranges which may or may not be an acceptable > > > > > > > issue :-). > > > > > > > > R. > > > > > > > > > Andreas.Mattsson@teliasonera.com wrote: > > > > > > > > > > Hi Eric > > > > > > > > > > As I understand it a requirement would be to have a full mesh of > > > LDP > > > > > > > > > sessions between the PEs in the participating AS domains. This > > > means > > > > > > > > > configuration of each PE when for example a new site is added to > > > an > > > > > already existing VPN. If BGP is used this is not necessary as RRs > > > > can be > > > > > used, minimizing the configuration to the new PE and the RR. > > > > > But perhaps there exist a solution similar to this for LDP as > > > well? > > > > It > > > > > seems appealing to reuse the 2547bis structure we have also for > > > VPLS > > > > if > > > > > it's possible. > > > > > > > > > > My point is that further investigation of the two different > > > > solutions > > > > > before rejecting one or the other would be good > > > > > > > > > > /Andreas > > > > > > > > > > -----Original Message----- > > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > > Sent: den 28 april 2003 16:29 > > > > > To: Mattsson, Andreas A. /Research /08-713 81 86, 070-618 67 67 > > > > > Cc: ppvpn@nortelnetworks.com > > > > > Subject: Re: Support for draft-kompella-ppvpn-vpls-01.txt > > > > > > > > > > Andreas> I would also like to know how inter-AS with the LDP > > > > > Andreas> approach in lasserre-vkompella is to be solved. > > > > > > > > > > Could you say what the issue is that you think needs to be solved?