From exim@www1.ietf.org Wed Oct 1 13:14:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24166 for ; Wed, 1 Oct 2003 13:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kYA-0007E3-8n for l3vpn-archive@odin.ietf.org; Wed, 01 Oct 2003 13:14:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91HE69j027769 for l3vpn-archive@odin.ietf.org; Wed, 1 Oct 2003 13:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kYA-0007Dn-4d for l3vpn-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:14:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24144 for ; Wed, 1 Oct 2003 13:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kY8-0002Ne-00 for l3vpn-web-archive@ietf.org; Wed, 01 Oct 2003 13:14:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4kY7-0002Na-00 for l3vpn-web-archive@ietf.org; Wed, 01 Oct 2003 13:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kY5-0007C3-7K; Wed, 01 Oct 2003 13:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kXB-00073l-Jr for l3vpn@optimus.ietf.org; Wed, 01 Oct 2003 13:13:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24059 for ; Wed, 1 Oct 2003 13:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kX9-0002Lo-00 for l3vpn@ietf.org; Wed, 01 Oct 2003 13:13:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A4kX9-0002Kr-00 for l3vpn@ietf.org; Wed, 01 Oct 2003 13:13:03 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2003 19:10:59 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h91HCSpu026309; Wed, 1 Oct 2003 19:12:28 +0200 (MET DST) Received: from MBEHRING-W2K1.cisco.com (dhcp-mad-wer4-vl1264-103-20-96.cisco.com [64.103.20.96]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA29990; Wed, 1 Oct 2003 19:12:30 +0200 (MET DST) Message-Id: <4.3.2.7.2.20031001190721.05434930@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Oct 2003 19:12:36 +0200 To: Ron Bonica , Jim Guichard , l3vpn@ietf.org From: "Michael H. Behringer" Subject: RE: draft-ietf-l3vpn-l3vpn-auth-00 and draft-behringer-mpls-vpn-auth-02.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ron! Sorry for the long silence - I was on vacations and am catching up now. To your point: "the SP deactivates draft-behringer": You make it sound like flicking a switch, but it is not actually a single event and would be noticed. Unless you switch off the mechanism on *all* PEs at *exactly* the same moment, there is bound to be a state in which a pair of PEs is inconsistent: One has it configured, the other not. That would lead to logging messages that would be noticed. So whilst what you describe sounds easy, I don't think it is. [In that light, we probably need to scan the draft again to make sure we've allowed for incremental deployment ;-) ] Michael At 18:14 21/09/2003, Ron Bonica wrote: > > > > If the SP misconfigures the authentication mechanism then the > > PE-router will > > reject routing updates from the CE-router as the MD5 key will not > > match and > > therefore local authentication will fail. Likewise, if a remote > > PE-router is > > misconfigured then a PE-router that receives an update from this > > router will > > fail authentication because of the key mismatch. > > > > Jim > > > > > >Hi Jim, > >Is this always the case? Consider the following scenario: > >Draft-behringer has been working nicely in a network for months. While >working another issue, the SP deactivates draft-behringer, network-wide. The >SP is unaware of this misconfiguration and the network runs unprotected for >weeks. The customer is also unaware that the network is running unprotected. >During this period, more misconfigurations follow. > >This is the worst example of authentication mechanism misconfiguration that >I can think of. There are more subtle misconfigurations that can come into >play when the customer uses a different authentication key on each PE-CE >interface. > > Ron From exim@www1.ietf.org Thu Oct 2 12:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00024 for ; Thu, 2 Oct 2003 12:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Tp-00032m-OE for l3vpn-archive@odin.ietf.org; Thu, 02 Oct 2003 12:39:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Gd52o011693 for l3vpn-archive@odin.ietf.org; Thu, 2 Oct 2003 12:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Tp-00032W-K8 for l3vpn-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29961 for ; Thu, 2 Oct 2003 12:38:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56To-0003KY-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 12:39:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56Tn-0003KV-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 12:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Tl-0002zi-NU; Thu, 02 Oct 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56TL-0002yJ-65 for l3vpn@optimus.ietf.org; Thu, 02 Oct 2003 12:38:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29949; Thu, 2 Oct 2003 12:38:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56TJ-0003KE-00; Thu, 02 Oct 2003 12:38:33 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A56TI-0003Jp-00; Thu, 02 Oct 2003 12:38:32 -0400 Received: from rcallon-lt.juniper.net (securepptp071.static.jnpr.net [172.24.253.71]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h92Gc0j39040; Thu, 2 Oct 2003 09:38:00 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20031002122810.01425db0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 02 Oct 2003 12:37:43 -0400 To: l3vpn@ietf.org, l2vpn@ietf.org From: Ross Callon Subject: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We would like to solicit comments on accepting draft-andersson-ppvpn-terminology-04.txt as an l3vpn working group document. Note that the terminology in this draft covers both L2 and L3 vpns, and that the document is referenced in the l2vpn framework. The draft was presented to the ppvpn wg twice, both times with quite a bit of support. In part the reason that this wasn't made a working group draft was because Loa and others pondered what to do with it. Since it is now referenced in the l2-framework we need to either progress the terminology draft (presumably in the direction of an informational draft), or do considerable editing to the l2vpn framework. I am told that it is this terminology draft that holds the l2-framework at the moment. thanks, Ross >Subject: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt >Date: Thu, 02 Oct 2003 07:35:58 -0400 >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >To: IETF-Announce: ; > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : PPVPN Terminology > Author(s) : L. Andersson, T. Madsen > Filename : draft-andersson-ppvpn-terminology-04.txt > Pages : 21 > Date : 2003-10-1 > >The provider provisioned VPN solutions has attracted a great deal >of interest. Memos proposing different and overlapping solution >have been discussed on the PPVPN mailing list and in the Working >Group meetings. This has lead to a development of a partly new >set of concepts used to describe the set of VPN services. To a >certain extent there are more than one term covering the same >concept and sometimes the same term covers more than on concept. >The terminology needs to be made clearer and more intuitive. This >document seeks to fill at least part of that need. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-andersson-ppvpn-terminology-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-andersson-ppvpn-terminology-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-andersson-ppvpn-terminology-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. From exim@www1.ietf.org Thu Oct 2 13:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15638 for ; Thu, 2 Oct 2003 13:42:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Sr-00073C-Kc for l3vpn-archive@odin.ietf.org; Thu, 02 Oct 2003 13:42:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Hg987027096 for l3vpn-archive@odin.ietf.org; Thu, 2 Oct 2003 13:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Sr-00072x-GB for l3vpn-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 13:42:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15606 for ; Thu, 2 Oct 2003 13:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Sp-00041j-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 13:42:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A57So-00041e-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 13:42:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Sj-0006z7-Ls; Thu, 02 Oct 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57S3-0006sx-00 for l3vpn@optimus.ietf.org; Thu, 02 Oct 2003 13:41:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15565; Thu, 2 Oct 2003 13:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Ry-000416-00; Thu, 02 Oct 2003 13:41:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A57Ry-00040L-00; Thu, 02 Oct 2003 13:41:14 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Oct 2003 10:46:22 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h92HefJs013676; Thu, 2 Oct 2003 10:40:41 -0700 (PDT) Received: from tnadeauw2k02 (che-vpn-cluster-2-80.cisco.com [10.86.242.80]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACV80254; Thu, 2 Oct 2003 13:40:40 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Ross Callon'" , , Subject: RE: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] Date: Thu, 2 Oct 2003 13:40:40 -0400 Organization: Cisco Systems, inc. Message-ID: <03e601c3890c$4be222f0$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <4.3.2.20031002122810.01425db0@zircon.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >-----Original Message----- >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On >Behalf Of Ross Callon >Sent: Thursday, October 02, 2003 12:38 PM >To: l3vpn@ietf.org; l2vpn@ietf.org >Subject: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] > > >We would like to solicit comments on accepting >draft-andersson-ppvpn-terminology-04.txt as an l3vpn working >group document. Note that the terminology in this draft covers >both L2 and L3 vpns, and that the document is referenced in >the l2vpn framework. > >The draft was presented to the ppvpn wg twice, both times with >quite a bit of support. In part the reason that this wasn't made a >working group draft was because Loa and others pondered what >to do with it. Since it is now referenced in the l2-framework we >need to either progress the terminology draft (presumably in the >direction of an informational draft), or do considerable editing to >the l2vpn framework. I am told that it is this terminology draft that >holds the l2-framework at the moment. I too supported the document, as it is a good idea to keep track of the termonolgy. However, it seems more appropriate to push these into the framework rather than being stand-alone. If we come up with more acronyms after the framework is published we can always push out a supplemental document, or define them in their respective drafts which seems to be how things have been done in the past in other WGs. --Tom >thanks, Ross > >>Subject: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt >>Date: Thu, 02 Oct 2003 07:35:58 -0400 >>From: Internet-Drafts@ietf.org >>Reply-To: Internet-Drafts@ietf.org >>To: IETF-Announce: ; >> >>A New Internet-Draft is available from the on-line >Internet-Drafts directories. >> >> >> Title : PPVPN Terminology >> Author(s) : L. Andersson, T. Madsen >> Filename : draft-andersson-ppvpn-terminology-04.txt >> Pages : 21 >> Date : 2003-10-1 >> >>The provider provisioned VPN solutions has attracted a great deal >>of interest. Memos proposing different and overlapping solution >>have been discussed on the PPVPN mailing list and in the Working >>Group meetings. This has lead to a development of a partly new >>set of concepts used to describe the set of VPN services. To a >>certain extent there are more than one term covering the same >>concept and sometimes the same term covers more than on concept. >>The terminology needs to be made clearer and more intuitive. This >>document seeks to fill at least part of that need. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-andersson-ppvpn-term inology-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-andersson-ppvpn-terminology-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-andersson-ppvpn-terminology-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. From exim@www1.ietf.org Thu Oct 2 13:44:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15734 for ; Thu, 2 Oct 2003 13:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Uh-0007GH-Tj for l3vpn-archive@odin.ietf.org; Thu, 02 Oct 2003 13:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Hi3wa027849 for l3vpn-archive@odin.ietf.org; Thu, 2 Oct 2003 13:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Uh-0007CD-G0 for l3vpn-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 13:44:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15695 for ; Thu, 2 Oct 2003 13:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Uf-00042t-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 13:44:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A57Ue-00042p-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 13:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Ug-0007A3-49; Thu, 02 Oct 2003 13:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57U1-00077o-2r for l3vpn@optimus.ietf.org; Thu, 02 Oct 2003 13:43:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15675; Thu, 2 Oct 2003 13:43:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Ty-00042U-00; Thu, 02 Oct 2003 13:43:18 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A57Ty-000425-00; Thu, 02 Oct 2003 13:43:18 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92Hgf529135; Thu, 2 Oct 2003 13:42:41 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 13:42:41 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Ross Callon , l3vpn@ietf.org, l2vpn@ietf.org Subject: RE: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] Date: Thu, 2 Oct 2003 13:42:39 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ross, Given the nature of l2/3 vpn services and solutions having a terminology draft is a useful thing. I think it should progress to WG doc status. Hamid. > > > We would like to solicit comments on accepting > draft-andersson-ppvpn-terminology-04.txt as an l3vpn working > group document. Note that the terminology in this draft covers > both L2 and L3 vpns, and that the document is referenced in > the l2vpn framework. > > The draft was presented to the ppvpn wg twice, both times with > quite a bit of support. In part the reason that this wasn't made a > working group draft was because Loa and others pondered what > to do with it. Since it is now referenced in the l2-framework we > need to either progress the terminology draft (presumably in the > direction of an informational draft), or do considerable editing to > the l2vpn framework. I am told that it is this terminology draft that > holds the l2-framework at the moment. > > thanks, Ross > > >Subject: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt > >Date: Thu, 02 Oct 2003 07:35:58 -0400 > >From: Internet-Drafts@ietf.org > >Reply-To: Internet-Drafts@ietf.org > >To: IETF-Announce: ; > > > >A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : PPVPN Terminology > > Author(s) : L. Andersson, T. Madsen > > Filename : draft-andersson-ppvpn-terminology-04.txt > > Pages : 21 > > Date : 2003-10-1 > > > >The provider provisioned VPN solutions has attracted a great deal > >of interest. Memos proposing different and overlapping solution > >have been discussed on the PPVPN mailing list and in the Working > >Group meetings. This has lead to a development of a partly new > >set of concepts used to describe the set of VPN services. To a > >certain extent there are more than one term covering the same > >concept and sometimes the same term covers more than on concept. > >The terminology needs to be made clearer and more intuitive. This > >document seeks to fill at least part of that need. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-andersson-ppvpn-ter minology-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-andersson-ppvpn-terminology-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-andersson-ppvpn-terminology-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. From exim@www1.ietf.org Thu Oct 2 13:57:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16673 for ; Thu, 2 Oct 2003 13:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57hG-00088g-29 for l3vpn-archive@odin.ietf.org; Thu, 02 Oct 2003 13:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Hv2Ej031280 for l3vpn-archive@odin.ietf.org; Thu, 2 Oct 2003 13:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57hF-00088R-Qv for l3vpn-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 13:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16651 for ; Thu, 2 Oct 2003 13:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57hD-0004Jl-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 13:56:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A57hD-0004Ji-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 13:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57hE-00087R-JP; Thu, 02 Oct 2003 13:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57gI-000869-Hk for l3vpn@optimus.ietf.org; Thu, 02 Oct 2003 13:56:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16625; Thu, 2 Oct 2003 13:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57gF-0004J4-00; Thu, 02 Oct 2003 13:55:59 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A57gF-0004IG-00; Thu, 02 Oct 2003 13:55:59 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92HtQI05513; Thu, 2 Oct 2003 13:55:26 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 13:55:27 -0400 Message-ID: From: "Hamid Ould-Brahim" To: tnadeau@cisco.com, "'Ross Callon'" , l3vpn@ietf.org, l2vpn@ietf.org Subject: RE: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] Date: Thu, 2 Oct 2003 13:55:20 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Tom, [clipped]... > > I too supported the document, as it is a good idea > to keep track of the termonolgy. However, it seems more > appropriate to push these into the framework rather > than being stand-alone. If we come up with more acronyms > after the framework is published we can always push out a > supplemental document, or define them in their respective > drafts which seems to be how things have been done in the > past in other WGs. > That would be a good option as well to consider. Hamid. From exim@www1.ietf.org Thu Oct 2 16:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24140 for ; Thu, 2 Oct 2003 16:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5A2W-0008Vc-1a for l3vpn-archive@odin.ietf.org; Thu, 02 Oct 2003 16:27:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92KR8T4032702 for l3vpn-archive@odin.ietf.org; Thu, 2 Oct 2003 16:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5A2V-0008VN-SK for l3vpn-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 16:27:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24117 for ; Thu, 2 Oct 2003 16:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5A2U-0006GP-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 16:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5A2T-0006GM-00 for l3vpn-web-archive@ietf.org; Thu, 02 Oct 2003 16:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5A2P-0008U6-MH; Thu, 02 Oct 2003 16:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5A1U-0008TP-PL for l3vpn@optimus.ietf.org; Thu, 02 Oct 2003 16:26:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24062; Thu, 2 Oct 2003 16:25:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5A1R-0006Ey-00; Thu, 02 Oct 2003 16:26:01 -0400 Received: from smtp4.hy.skanova.net ([195.67.199.133]) by ietf-mx with esmtp (Exim 4.12) id 1A5A1Q-0006Ev-00; Thu, 02 Oct 2003 16:26:00 -0400 Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with ESMTP id h92KPqJg017716; Thu, 2 Oct 2003 22:25:52 +0200 (CEST) Message-ID: <3F7C89D3.9010808@pi.se> Date: Thu, 02 Oct 2003 22:25:55 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tnadeau@cisco.com CC: "'Ross Callon'" , l3vpn@ietf.org, l2vpn@ietf.org Subject: Re: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] References: <03e601c3890c$4be222f0$6701a8c0@amer.cisco.com> In-Reply-To: <03e601c3890c$4be222f0$6701a8c0@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom, this was one aspect in the "pondering", we found it was a good thing in itself to have a common place for the terminology, as some drafts use slight non-overlaping terminology and this is the only place where this is captured. Note that the terminology draft covers more than the l2 framework and it wouldn't make sense to take all of into the framework. /Loa Thomas D. Nadeau wrote: > I too supported the document, as it is a good idea > to keep track of the termonolgy. However, it seems more > appropriate to push these into the framework rather > than being stand-alone. If we come up with more acronyms > after the framework is published we can always push out a > supplemental document, or define them in their respective > drafts which seems to be how things have been done in the > past in other WGs. > > --Tom -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Thu Oct 2 17:02:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25641 for ; Thu, 2 Oct 2003 17:02:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Aam-0002N5-IA for l3vpn-archive@odin.ietf.org; Thu, 02 Oct 2003 17:02:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92L2WZD009109 for l3vpn-archive@odin.ietf.org; Thu, 2 Oct 2003 17:02:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Aam-0002Mk-Am for l3vpn-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 17:02:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25617 for ; Thu, 2 Oct 2003 17:02:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5AaG-0002G3-MY; Thu, 02 Oct 2003 17:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5AZX-0002FK-Lf for l3vpn@optimus.ietf.org; Thu, 02 Oct 2003 17:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25605; Thu, 2 Oct 2003 17:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5AZU-0006kX-00; Thu, 02 Oct 2003 17:01:12 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A5AZU-0006ju-00; Thu, 02 Oct 2003 17:01:12 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h92L0awn021806; Thu, 2 Oct 2003 14:00:36 -0700 (PDT) Received: from tnadeauw2k02 (che-vpn-cluster-2-80.cisco.com [10.86.242.80]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACW02923; Thu, 2 Oct 2003 17:00:33 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Loa Andersson'" Cc: "'Ross Callon'" , , Subject: RE: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] Date: Thu, 2 Oct 2003 17:00:33 -0400 Organization: Cisco Systems, inc. Message-ID: <044101c38928$39386440$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <3F7C89D3.9010808@pi.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >-----Original Message----- >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On >Behalf Of Loa Andersson >Sent: Thursday, October 02, 2003 4:26 PM >To: tnadeau@cisco.com >Cc: 'Ross Callon'; l3vpn@ietf.org; l2vpn@ietf.org >Subject: Re: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] > > >Tom, > >this was one aspect in the "pondering", we found it was a good >thing in itself to have a common place for the terminology, >as some drafts use slight non-overlaping terminology and this >is the only place where this is captured. > >Note that the terminology draft covers more than the l2 framework >and it wouldn't make sense to take all of into the framework. Agreed; just the stuff that applies to L2VPN should go into its charter. --Tom > > >/Loa > >Thomas D. Nadeau wrote: > > >> I too supported the document, as it is a good idea >> to keep track of the termonolgy. However, it seems more >> appropriate to push these into the framework rather >> than being stand-alone. If we come up with more acronyms >> after the framework is published we can always push out a >> supplemental document, or define them in their respective >> drafts which seems to be how things have been done in the >> past in other WGs. >> >> --Tom > > >-- >Loa Andersson > >Mobile +46 739 81 21 64 >Email loa@pi.se > > > From exim@www1.ietf.org Sun Oct 5 11:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18075 for ; Sun, 5 Oct 2003 11:21:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Agy-0004S0-Qd for l3vpn-archive@odin.ietf.org; Sun, 05 Oct 2003 11:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h95FL4F1017102 for l3vpn-archive@odin.ietf.org; Sun, 5 Oct 2003 11:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Agy-0004Rl-Kp for l3vpn-web-archive@optimus.ietf.org; Sun, 05 Oct 2003 11:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18063 for ; Sun, 5 Oct 2003 11:20:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Agx-0002gq-00 for l3vpn-web-archive@ietf.org; Sun, 05 Oct 2003 11:21:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6Agx-0002gm-00 for l3vpn-web-archive@ietf.org; Sun, 05 Oct 2003 11:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Agv-0004QZ-9i; Sun, 05 Oct 2003 11:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6AgK-0004Ob-3A for l3vpn@optimus.ietf.org; Sun, 05 Oct 2003 11:20:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18050; Sun, 5 Oct 2003 11:20:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6AgI-0002gU-00; Sun, 05 Oct 2003 11:20:22 -0400 Received: from smtp1.fre.skanova.net ([195.67.227.94]) by ietf-mx with esmtp (Exim 4.12) id 1A6AgI-0002gQ-00; Sun, 05 Oct 2003 11:20:22 -0400 Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with ESMTP id h95FKFTS007678; Sun, 5 Oct 2003 17:20:15 +0200 (CEST) Message-ID: <3F8036B2.70903@pi.se> Date: Sun, 05 Oct 2003 17:20:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tnadeau@cisco.com CC: "'Ross Callon'" , l3vpn@ietf.org, l2vpn@ietf.org Subject: Re: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] References: <044101c38928$39386440$6701a8c0@amer.cisco.com> In-Reply-To: <044101c38928$39386440$6701a8c0@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I feel like I'm runnig around in circles thre are twio aspects - we want more terminolgoy in one place than reltes to just l2 or l3 vpns, for obvious reasons - we want frameworks and solutions selfcontained terminologywise the fist aspect we could only bu a joint document, the second is (a bit less than percfect) done by referencing the joint document if we say that the firts aspect is unnecessary/unimportant/futile, then we include the appropriate parts in each doc my gutfeeling here (from the number if mail I've recieved on the terminology draft) is that it has filled a need. /Loa Thomas D. Nadeau wrote: > >>-----Original Message----- >>Note that the terminology draft covers more than the l2 framework >>and it wouldn't make sense to take all of into the framework. > > > Agreed; just the stuff that applies to L2VPN should > go into its charter. > > --Tom > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From exim@www1.ietf.org Mon Oct 6 08:25:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27162 for ; Mon, 6 Oct 2003 08:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UQE-000362-V3 for l3vpn-archive@odin.ietf.org; Mon, 06 Oct 2003 08:25:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96CP6ZO011896 for l3vpn-archive@odin.ietf.org; Mon, 6 Oct 2003 08:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UQE-00035n-Qx for l3vpn-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 08:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27143 for ; Mon, 6 Oct 2003 08:24:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UQD-0004Um-00 for l3vpn-web-archive@ietf.org; Mon, 06 Oct 2003 08:25:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6UQD-0004Uj-00 for l3vpn-web-archive@ietf.org; Mon, 06 Oct 2003 08:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UQA-00034L-DC; Mon, 06 Oct 2003 08:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UPO-00033X-Lr for l3vpn@optimus.ietf.org; Mon, 06 Oct 2003 08:24:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27123; Mon, 6 Oct 2003 08:24:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UPN-0004UE-00; Mon, 06 Oct 2003 08:24:13 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1A6UPN-0004U9-00; Mon, 06 Oct 2003 08:24:13 -0400 Received: from il06exr02.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h96COBpx025994; Mon, 6 Oct 2003 05:24:11 -0700 (MST) Received: from zin01exm01.corp.mot.com (zin01exm01.corp.mot.com [217.1.122.3]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h96CO5Vo009241; Mon, 6 Oct 2003 07:24:07 -0500 Received: by zin01exm01.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Mon, 6 Oct 2003 17:53:45 +0530 Message-ID: From: Nagarajan Ananth-Q3241C To: Ross Callon , l3vpn@ietf.org, l2vpn@ietf.org Subject: RE: [Fwd: I-D ACTION:draft-andersson-ppvpn-terminology-04.txt] Date: Mon, 6 Oct 2003 17:53:35 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > > We would like to solicit comments on accepting > draft-andersson-ppvpn-terminology-04.txt as an l3vpn working > group document. Note that the terminology in this draft covers > both L2 and L3 vpns, and that the document is referenced in > the l2vpn framework. > It is also referenced in the generic requirements draft. > The draft was presented to the ppvpn wg twice, both times with > quite a bit of support. In part the reason that this wasn't made a > working group draft was because Loa and others pondered what > to do with it. Since it is now referenced in the l2-framework we > need to either progress the terminology draft (presumably in the > direction of an informational draft), or do considerable editing to > the l2vpn framework. I am told that it is this terminology draft that > holds the l2-framework at the moment. > I guess this applies to the generic requirements draft as well. AS such, i support making this a WG document. Ananth > From exim@www1.ietf.org Thu Oct 9 12:20:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26657 for ; Thu, 9 Oct 2003 12:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dWM-0005yG-3a for l3vpn-archive@odin.ietf.org; Thu, 09 Oct 2003 12:20:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99GK9C3022944 for l3vpn-archive@odin.ietf.org; Thu, 9 Oct 2003 12:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dWL-0005xz-3B for l3vpn-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 12:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26619 for ; Thu, 9 Oct 2003 12:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7dWJ-0000aK-00 for l3vpn-web-archive@ietf.org; Thu, 09 Oct 2003 12:20:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7dWJ-0000aG-00 for l3vpn-web-archive@ietf.org; Thu, 09 Oct 2003 12:20:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dWE-0005xA-Kg; Thu, 09 Oct 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dVP-0005w0-Ep for l3vpn@optimus.ietf.org; Thu, 09 Oct 2003 12:19:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26517; Thu, 9 Oct 2003 12:19:02 -0400 (EDT) Message-Id: <200310091619.MAA26517@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-as2547-03.txt Date: Thu, 09 Oct 2003 12:19:01 -0400 Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Applicability Statement for BGP/MPLS IP VPNs Author(s) : E. Rosen Filename : draft-ietf-l3vpn-as2547-03.txt Pages : 27 Date : 2003-10-9 This document provides an Applicability Statement for the VPN solution described in [2547bis] and other documents listed in the References section. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as2547-03.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-l3vpn-as2547-03.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-l3vpn-as2547-03.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-10-9122549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-as2547-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-as2547-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9122549.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Oct 9 12:54:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29122 for ; Thu, 9 Oct 2003 12:54:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e3d-0008Gy-FN for l3vpn-archive@odin.ietf.org; Thu, 09 Oct 2003 12:54:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99GsX2i031794 for l3vpn-archive@odin.ietf.org; Thu, 9 Oct 2003 12:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e3d-0008Gj-AZ for l3vpn-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 12:54:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29055 for ; Thu, 9 Oct 2003 12:54:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e36-0008CT-DH; Thu, 09 Oct 2003 12:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e2d-0008BW-1g for l3vpn@optimus.ietf.org; Thu, 09 Oct 2003 12:53:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28901 for ; Thu, 9 Oct 2003 12:53:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7e2b-0001Ec-00 for l3vpn@ietf.org; Thu, 09 Oct 2003 12:53:29 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1A7e2a-0001Du-00 for l3vpn@ietf.org; Thu, 09 Oct 2003 12:53:28 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HMI00B691I5AM@firewall.wcom.com> for l3vpn@ietf.org; Thu, 09 Oct 2003 16:51:41 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HMI00H011I4EL@pmismtp05.wcomnet.com> for l3vpn@ietf.org; Thu, 09 Oct 2003 16:51:40 +0000 (GMT) Received: from rbonica ([166.32.199.163]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HMI00FHL1I4IO@pmismtp05.wcomnet.com> for l3vpn@ietf.org; Thu, 09 Oct 2003 16:51:40 +0000 (GMT) Date: Thu, 09 Oct 2003 12:52:19 -0400 From: Ron Bonica Subject: WG Last Call To: l3vpn@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, This begins a WG last call on the following documents: draft-ietf-l3vpn-rfc2547bis-01 draft-ietf-l3vpn-as2547-03 Last call will end on 10/23. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "An eye for an eye only ends up making the whole world blind." -- Gandhi From exim@www1.ietf.org Thu Oct 9 16:15:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09252 for ; Thu, 9 Oct 2003 16:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hBj-0005FQ-6f for l3vpn-archive@odin.ietf.org; Thu, 09 Oct 2003 16:15:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99KF7jx020169 for l3vpn-archive@odin.ietf.org; Thu, 9 Oct 2003 16:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hBi-0005FE-V5 for l3vpn-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 16:15:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09233 for ; Thu, 9 Oct 2003 16:14:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hBh-00045H-00 for l3vpn-web-archive@ietf.org; Thu, 09 Oct 2003 16:15:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7hBg-00045E-00 for l3vpn-web-archive@ietf.org; Thu, 09 Oct 2003 16:15:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hBe-0005Ec-Oy; Thu, 09 Oct 2003 16:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hB5-0005DW-Pl for l3vpn@optimus.ietf.org; Thu, 09 Oct 2003 16:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09223 for ; Thu, 9 Oct 2003 16:14:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hB3-000456-00 for l3vpn@ietf.org; Thu, 09 Oct 2003 16:14:26 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 1A7hB3-000452-00 for l3vpn@ietf.org; Thu, 09 Oct 2003 16:14:25 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h99LEI105599 for ; Fri, 10 Oct 2003 02:44:18 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h99LEIg05593 for ; Fri, 10 Oct 2003 02:44:18 +0530 Received: from 219.65.136.213 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Fri, 10 Oct 2003 02:44:18 +0530 (IST) Message-ID: <1600.219.65.136.213.1065734058.squirrel@mail.apara.com> Date: Fri, 10 Oct 2003 02:44:18 +0530 (IST) Subject: Route Reflectors versus Route-servers From: "Alok Dube" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal 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 Content-Transfer-Encoding: 8bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit hi, I would like to understand the difference in using either one on a L3VPN topology. (route reflectors versus route servers). I read some threads which said that the RR may not need a "VRF" as it will not have an "interface" in the VPN associated with the VRF. But the RR will make the "best path decisions as seen by itself locally". Which implies that for an RR to operate effectively, the RR has to be in the forwarding path of the traffic. In that case, would it not need a VRF for those VPNs? In 1 case , the decision making algorithm (incase it is not in the forwarding path) may lead to suboptimal routing, and in the 2nd case, it would be in the path anyways, so why not the VRF? if it was a sort of "route server", it would never run the decision process and pass on all routes learnt from client peers to the each and every non client peer and client peer , and those from non client peers to client peers. In this case it may not even be in the forwarding path. is my interpretation correct? -thanks Alok From exim@www1.ietf.org Thu Oct 9 16:42:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10157 for ; Thu, 9 Oct 2003 16:42:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hbr-0006YB-DN for l3vpn-archive@odin.ietf.org; Thu, 09 Oct 2003 16:42:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Kg7sM025173 for l3vpn-archive@odin.ietf.org; Thu, 9 Oct 2003 16:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hbr-0006Xw-8z for l3vpn-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 16:42:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10133 for ; Thu, 9 Oct 2003 16:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hbp-0004HZ-00 for l3vpn-web-archive@ietf.org; Thu, 09 Oct 2003 16:42:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7hbo-0004HW-00 for l3vpn-web-archive@ietf.org; Thu, 09 Oct 2003 16:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hbl-0006XK-6Z; Thu, 09 Oct 2003 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7hbF-0006RP-U6 for l3vpn@optimus.ietf.org; Thu, 09 Oct 2003 16:41:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10084 for ; Thu, 9 Oct 2003 16:41:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7hbD-0004HK-00 for l3vpn@ietf.org; Thu, 09 Oct 2003 16:41:27 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7hbB-0004H3-00 for l3vpn@ietf.org; Thu, 09 Oct 2003 16:41:26 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 13:41:56 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h99KercZ005000; Thu, 9 Oct 2003 13:40:53 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMJ49810; Thu, 9 Oct 2003 13:36:42 -0700 (PDT) Message-ID: <3F85C7D1.3050906@cisco.com> Date: Thu, 09 Oct 2003 22:40:49 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: alok.dube@apara.com CC: l3vpn@ietf.org Subject: Re: Route Reflectors versus Route-servers References: <1600.219.65.136.213.1065734058.squirrel@mail.apara.com> In-Reply-To: <1600.219.65.136.213.1065734058.squirrel@mail.apara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alok, Yes I think your observations are correct. But please observe that if you follow a principle of different RD per each vrf your RR's best path selection would turn into a pure formality as each path will be unique and best path selection will always be running there essentially over a single path. If your RDs are the same on any set of vrfs it seems indeed that falling down to IGP cost to next hop especially in the case when you run LDP and RRs are not in the forwarding path or that don't set next hop to self is questionable. I should not break anything connectivity wise. Only in the cases of multihomed sites it could make the path less optimal. Cheers, R. > Alok Dube wrote: > > hi, > > I would like to understand the difference in using either one on a L3VPN > topology. (route reflectors versus route servers). > I read some threads which said that the RR may not need a "VRF" as it will > not have an "interface" in the VPN associated with the VRF. > But the RR will make the "best path decisions as seen by itself locally". > > Which implies that for an RR to operate effectively, the RR has to be in > the forwarding path of the traffic. > In that case, would it not need a VRF for those VPNs? > > In 1 case , the decision making algorithm (incase it is not in the > forwarding path) may lead to suboptimal routing, and in the 2nd case, it > would be in the path anyways, so why not the VRF? > > if it was a sort of "route server", it would never run the decision > process and pass on all routes learnt from client peers to the each and > every non client peer and client peer , and those from non client peers to > client peers. In this case it may not even be in the forwarding path. > > is my interpretation correct? > > -thanks > Alok > > > > From exim@www1.ietf.org Fri Oct 10 05:33:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15218 for ; Fri, 10 Oct 2003 05:33:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7te0-0001py-8r for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 05:33:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A9X8EL007063 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 05:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7te0-0001pq-2H for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 05:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15211 for ; Fri, 10 Oct 2003 05:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7tdw-0004N7-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 05:33:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7tdw-0004N4-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 05:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7tdt-0001p3-SY; Fri, 10 Oct 2003 05:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7tdM-0001oI-Nb for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 05:32:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15182 for ; Fri, 10 Oct 2003 05:32:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7tdJ-0004M8-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 05:32:25 -0400 Received: from web86205.mail.ukl.yahoo.com ([217.12.12.80]) by ietf-mx with smtp (Exim 4.12) id 1A7tdI-0004LZ-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 05:32:24 -0400 Message-ID: <20031010093154.91806.qmail@web86205.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web86205.mail.ukl.yahoo.com via HTTP; Fri, 10 Oct 2003 10:31:54 BST Date: Fri, 10 Oct 2003 10:31:54 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: RE: Route Reflectors versus Route-servers To: alok.dube@apara.com Cc: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Alok, > Which implies that for an RR to operate effectively, the RR has to be in > the forwarding path of the traffic. > In that case, would it not need a VRF for those VPNs? Even if the RR falls in the forwarding path, it does not need to configure VRFs. Consider this scenario. A -- RR -- B where both A and B are RR Clients. Suppose B advertises some BGP Labels to RR which in turn are advertised to A by the RR. The information that A receives is (i) The BGP label associated with some prefix (some FEC) (ii) the BGP NEXT_HOP which happens to be the loopback IP address of B in most of the cases. A searches for the IGP Tunnel label associated with the bgp NEXT_HOP. The tunnel could have been set up using LDP, etc. So what A simply needs to do is to push the BGP label (the one which it received from the RR) and then push the tunnel IGP label and send this MPLS packet towards RR. RR upon recieving this packet simply swaps the top most label and pushes a new label and sends it off to B. B recives the MPLS packet with the tunnel label (if PHB is not supported) or the BGP label. It looks at its ILM and forwards the packet based on the entries it has. In this case, the RR falls in the forwarding path, but it still does not need to configure any VRF. I think the golden rule to remember is: Use VRFs only when connecting to customers! > In 1 case , the decision making algorithm (incase it is not in the > forwarding path) may lead to suboptimal routing, and in the 2nd case, it I think its well known that using RR can sometimes lead to suboptimal routing if its not in the forwarding path. > would be in the path anyways, so why not the VRF? > Cheers! ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk From exim@www1.ietf.org Fri Oct 10 08:33:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24485 for ; Fri, 10 Oct 2003 08:33:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wSC-0007oP-Dr for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 08:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ACX8A1030028 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 08:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wSC-0007oF-8D for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 08:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24458 for ; Fri, 10 Oct 2003 08:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wSB-0002RL-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 08:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7wSA-0002RI-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 08:33:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wS6-0007mH-C3; Fri, 10 Oct 2003 08:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wRw-0007lV-OO for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 08:32:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24444 for ; Fri, 10 Oct 2003 08:32:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wRv-0002Qw-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 08:32:51 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 1A7wRu-0002Qn-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 08:32:51 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h9ADX3106435 for ; Fri, 10 Oct 2003 19:03:03 +0530 Received: from ALOK ([203.124.140.97]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h9ADX0g06426; Fri, 10 Oct 2003 19:03:01 +0530 Message-ID: <00a501c38f2a$3bf24f40$fb01a8c0@aparabgl.com> From: "Alok Dube" To: "John Smith" Cc: References: <20031010093154.91806.qmail@web86205.mail.ukl.yahoo.com> Subject: Re: Route Reflectors versus Route-servers Date: Fri, 10 Oct 2003 17:59:52 +0530 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, some things I would appreciate if you could clarify.. ----- Original Message ----- From: "John Smith" To: Cc: Sent: Friday, October 10, 2003 3:01 PM Subject: RE: Route Reflectors versus Route-servers > Alok, > > > Which implies that for an RR to operate effectively, the RR has to be in > > the forwarding path of the traffic. > > In that case, would it not need a VRF for those VPNs? > > Even if the RR falls in the forwarding path, it does not need to configure VRFs. > > Consider this scenario. > > A -- RR -- B > > where both A and B are RR Clients. Suppose B advertises some BGP Labels to RR which in > turn are advertised to A by the RR. The information that A receives is (i) The BGP label > associated with some prefix (some FEC) (ii) the BGP NEXT_HOP which happens to be the > loopback IP address of B in most of the cases. for the part below, I assume you saying we do not have LSPs from A to B. > > A searches for the IGP Tunnel label associated with the bgp NEXT_HOP. The tunnel could > have been set up using LDP, etc. So what A simply needs to do is to push the BGP label > (the one which it received from the RR) and then push the tunnel IGP label and send this > MPLS packet towards RR. RR upon recieving this packet simply swaps the top most label and > pushes a new label and sends it off to B. > > B recives the MPLS packet with the tunnel label (if PHB is not supported) or the BGP > label. It looks at its ILM and forwards the packet based on the entries it has. > > In this case, the RR falls in the forwarding path, but it still does not need to > configure any VRF. I think the golden rule to remember is: Use VRFs only when connecting > to customers! My point is not VRF....I may not use the right word, but it seems to be more like a "table/seperate database" to me. What i see is something like this: Incoming Routes from clients----->export RT matched--->table based on export RT (RT is unique to the VPN)---->BGP decision algorithm "per table"--->send out the best routes to peers. if this means that there is seperate decision making algorithm "thread" running in this case for each table (depending on how you plan to implement it), what is the exact overhead you see in doing so? I am calling it a "table" and not a VRF and as you can see, there are no interfaces here too. I am also not asking for multiple instances of OSPF etc on this device. All I am pointing out is "seperate tables/database seperation on the device per VPN" About the multihoming case, I see that the draft seems to suggest -use the same RD for the VPN if its on the same router, use the same RD for the VPN if its on different routers- and as Robert pointed out, the fact that RDs are the same implies they are the same route in a correctly configured network..which also implies that the RR still sees them as 2 different routes and propogates them both. Now if the RR is to anyway propogate them both, the only outcome is that the RR is avoiding the full mesh. The same could be done by simply passing on everything the RR learns. > > > In 1 case , the decision making algorithm (incase it is not in the > > forwarding path) may lead to suboptimal routing, and in the 2nd case, it > > I think its well known that using RR can sometimes lead to suboptimal routing if its not > in the forwarding path. How would using a forwarding device like a route server cause a problem here? this is what is confusing me. thanks for your clarifications though, -rgds Alok > > > would be in the path anyways, so why not the VRF? > > > > Cheers! > > ________________________________________________________________________ > Want to chat instantly with your online friends? Get the FREE Yahoo! > Messenger http://mail.messenger.yahoo.co.uk > From exim@www1.ietf.org Fri Oct 10 08:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25524 for ; Fri, 10 Oct 2003 08:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wei-0000Po-LD for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 08:46:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ACk4t3001590 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 08:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wei-0000PZ-Gb for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 08:46:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25506 for ; Fri, 10 Oct 2003 08:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7weh-0002pK-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 08:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7weg-0002pH-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 08:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wef-0000Ou-Qc; Fri, 10 Oct 2003 08:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7weQ-0000Lu-Pl for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 08:45:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25500 for ; Fri, 10 Oct 2003 08:45:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7weP-0002p4-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 08:45:45 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 1A7weO-0002p1-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 08:45:45 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h9ADjv106906 for ; Fri, 10 Oct 2003 19:15:57 +0530 Received: from ALOK ([203.124.140.97]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h9ADjtg06897; Fri, 10 Oct 2003 19:15:55 +0530 Message-ID: <00c801c38f2c$0975e480$fb01a8c0@aparabgl.com> From: "Alok Dube" To: "John Smith" Cc: Subject: Re: Route Reflectors versus Route-servers Date: Fri, 10 Oct 2003 18:12:50 +0530 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, an errata on my part : >which also implies that the RR still sees them as 2 >different routes and propogates them both. should be "which implies on an incorrectly configured network the RR still sees them as 2 different routes and propogates them both." apologies. -Alok ----- Original Message ----- From: "Alok Dube" To: "John Smith" Cc: Sent: Friday, October 10, 2003 5:59 PM Subject: Re: Route Reflectors versus Route-servers > John, > > some things I would appreciate if you could clarify.. > > ----- Original Message ----- > From: "John Smith" > To: > Cc: > Sent: Friday, October 10, 2003 3:01 PM > Subject: RE: Route Reflectors versus Route-servers > > > > Alok, > > > > > Which implies that for an RR to operate effectively, the RR has to be in > > > the forwarding path of the traffic. > > > In that case, would it not need a VRF for those VPNs? > > > > Even if the RR falls in the forwarding path, it does not need to configure > VRFs. > > > > Consider this scenario. > > > > A -- RR -- B > > > > where both A and B are RR Clients. Suppose B advertises some BGP Labels to > RR which in > > turn are advertised to A by the RR. The information that A receives is (i) > The BGP label > > associated with some prefix (some FEC) (ii) the BGP NEXT_HOP which happens > to be the > > loopback IP address of B in most of the cases. > > > for the part below, I assume you saying we do not have LSPs from A to B. > > > > A searches for the IGP Tunnel label associated with the bgp NEXT_HOP. The > tunnel could > > have been set up using LDP, etc. So what A simply needs to do is to push > the BGP label > > (the one which it received from the RR) and then push the tunnel IGP label > and send this > > MPLS packet towards RR. RR upon recieving this packet simply swaps the top > most label and > > pushes a new label and sends it off to B. > > > > B recives the MPLS packet with the tunnel label (if PHB is not supported) > or the BGP > > label. It looks at its ILM and forwards the packet based on the entries it > has. > > > > In this case, the RR falls in the forwarding path, but it still does not > need to > > configure any VRF. I think the golden rule to remember is: Use VRFs only > when connecting > > to customers! > > > My point is not VRF....I may not use the right word, but it seems to be more > like a "table/seperate database" to me. > > What i see is something like this: > > Incoming Routes from clients----->export RT matched--->table based on export > RT (RT is unique to the VPN)---->BGP decision algorithm "per table"--->send > out the best routes to peers. > > if this means that there is seperate decision making algorithm "thread" > running in this case for each table (depending on how you plan to implement > it), what is the exact overhead you see in doing so? I am calling it a > "table" and not a VRF and as you can see, there are no interfaces here too. > > I am also not asking for multiple instances of OSPF etc on this device. All > I am pointing out is "seperate tables/database seperation on the device per > VPN" > > About the multihoming case, I see that the draft seems to suggest -use the > same RD for the VPN if its on the same router, use the same RD for the VPN > if its on different routers- and as Robert pointed out, the fact that RDs > are the same implies they are the same route in a correctly configured > network..which also implies that the RR still sees them as 2 different > routes and propogates them both. > > Now if the RR is to anyway propogate them both, the only outcome is that the > RR is avoiding the full mesh. > > The same could be done by simply passing on everything the RR learns. > > > > > > > In 1 case , the decision making algorithm (incase it is not in the > > > forwarding path) may lead to suboptimal routing, and in the 2nd case, it > > > > I think its well known that using RR can sometimes lead to suboptimal > routing if its not > > in the forwarding path. > > How would using a forwarding device like a route server cause a problem > here? this is what is confusing me. > > thanks for your clarifications though, > > -rgds > Alok > > > > > > would be in the path anyways, so why not the VRF? > > > > > > > Cheers! > > > > ________________________________________________________________________ > > Want to chat instantly with your online friends? Get the FREE Yahoo! > > Messenger http://mail.messenger.yahoo.co.uk > > > From exim@www1.ietf.org Fri Oct 10 10:23:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00148 for ; Fri, 10 Oct 2003 10:23:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yAh-00066d-2B for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AENBKZ023465 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yAg-00066O-Tn for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00103 for ; Fri, 10 Oct 2003 10:23:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yAe-00042T-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 10:23:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yAe-00042Q-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 10:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yAX-00065m-7v; Fri, 10 Oct 2003 10:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yAR-00065W-4b for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 10:22:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00091 for ; Fri, 10 Oct 2003 10:22:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yAC-000427-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 10:22:40 -0400 Received: from web14107.mail.yahoo.com ([216.136.172.137]) by ietf-mx with smtp (Exim 4.12) id 1A7yAB-000424-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 10:22:40 -0400 Message-ID: <20031010142238.33202.qmail@web14107.mail.yahoo.com> Received: from [47.234.0.51] by web14107.mail.yahoo.com via HTTP; Fri, 10 Oct 2003 07:22:38 PDT Date: Fri, 10 Oct 2003 07:22:38 -0700 (PDT) From: PamSri Subject: Re: Route Reflectors versus Route-servers To: raszuk@cisco.com, alok.dube@apara.com Cc: l3vpn@ietf.org In-Reply-To: <3F85C7D1.3050906@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Alok, Sub-optimal routing is just one of the consequence. It could lead to blackholes should the RR start making the routing decisions on the received VPN routes. Here's the reason: Since the RR does'nt have VRF it cannot really use the RTs for the policies. So if RR were to choose a best route (ofcourse as Bob said, using RD to uniquely identify the VPN routes) which its client were to discard due to non-match of RT for the VRF then that VRF never gets any more routes for that. sri --- Robert Raszuk wrote: > Hi Alok, > > Yes I think your observations are correct. But > please observe that if > you follow a principle of different RD per each vrf > your RR's best path > selection would turn into a pure formality as each > path will be unique > and best path selection will always be running there > essentially over a > single path. > > If your RDs are the same on any set of vrfs it seems > indeed that falling > down to IGP cost to next hop especially in the case > when you run LDP and > RRs are not in the forwarding path or that don't set > next hop to self is > questionable. I should not break anything > connectivity wise. Only in the > cases of multihomed sites it could make the path > less optimal. > > Cheers, > R. > > > Alok Dube wrote: > > > > hi, > > > > I would like to understand the difference in using > either one on a L3VPN > > topology. (route reflectors versus route servers). > > I read some threads which said that the RR may not > need a "VRF" as it will > > not have an "interface" in the VPN associated with > the VRF. > > But the RR will make the "best path decisions as > seen by itself locally". > > > > Which implies that for an RR to operate > effectively, the RR has to be in > > the forwarding path of the traffic. > > In that case, would it not need a VRF for those > VPNs? > > > > In 1 case , the decision making algorithm (incase > it is not in the > > forwarding path) may lead to suboptimal routing, > and in the 2nd case, it > > would be in the path anyways, so why not the VRF? > > > > if it was a sort of "route server", it would never > run the decision > > process and pass on all routes learnt from client > peers to the each and > > every non client peer and client peer , and those > from non client peers to > > client peers. In this case it may not even be in > the forwarding path. > > > > is my interpretation correct? > > > > -thanks > > Alok > > > > > > > > > > __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From exim@www1.ietf.org Fri Oct 10 10:35:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00631 for ; Fri, 10 Oct 2003 10:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yMC-0006ax-2m for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEZ4uJ025350 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 10:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yMB-0006an-Qk for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00597 for ; Fri, 10 Oct 2003 10:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yM9-00049O-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 10:35:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yM9-00049L-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 10:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yM9-0006a9-1Z; Fri, 10 Oct 2003 10:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yLk-0006X9-1k for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 10:34:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00564 for ; Fri, 10 Oct 2003 10:34:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yLh-00048c-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 10:34:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A7yLh-00047w-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 10:34:33 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2003 16:32:15 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9AEXsIQ008744; Fri, 10 Oct 2003 16:33:54 +0200 (MET DST) Received: from JGUICHARW2K (dhcp-10-86-162-41.cisco.com [10.86.162.41]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA00235; Fri, 10 Oct 2003 16:33:57 +0200 (MET DST) From: "Jim Guichard" To: "PamSri" , , Cc: Subject: RE: Route Reflectors versus Route-servers Date: Fri, 10 Oct 2003 10:27:48 -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.4927.1200 In-reply-to: <20031010142238.33202.qmail@web14107.mail.yahoo.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't think the possibility for blackholes exists unless you misconfigure the import/export policy. The RTs have nothing to do with route selection. If you happen to send two routes with same RD:IP-address pair, and these two routes do not carry the right RT values (or one does and the other does not), then the PEs that were supposed to receive the routes might lose connectivity to that specific prefix. Jim > >-----Original Message----- > >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > >PamSri > >Sent: Friday, October 10, 2003 10:23 AM > >To: raszuk@cisco.com; alok.dube@apara.com > >Cc: l3vpn@ietf.org > >Subject: Re: Route Reflectors versus Route-servers > > > > > >Hi Alok, > > Sub-optimal routing is just one of the > >consequence. It could lead to blackholes should the RR > >start making the routing decisions on the received VPN > >routes. Here's the reason: > >Since the RR does'nt have VRF it cannot really use the > >RTs for the policies. So if RR were to choose a best > >route (ofcourse as Bob said, using RD to uniquely > >identify the VPN routes) which its client were to > >discard due to non-match of RT for the VRF then that > >VRF never gets any more routes for that. > > > >sri > > > >--- Robert Raszuk wrote: > >> Hi Alok, > >> > >> Yes I think your observations are correct. But > >> please observe that if > >> you follow a principle of different RD per each vrf > >> your RR's best path > >> selection would turn into a pure formality as each > >> path will be unique > >> and best path selection will always be running there > >> essentially over a > >> single path. > >> > >> If your RDs are the same on any set of vrfs it seems > >> indeed that falling > >> down to IGP cost to next hop especially in the case > >> when you run LDP and > >> RRs are not in the forwarding path or that don't set > >> next hop to self is > >> questionable. I should not break anything > >> connectivity wise. Only in the > >> cases of multihomed sites it could make the path > >> less optimal. > >> > >> Cheers, > >> R. > >> > >> > Alok Dube wrote: > >> > > >> > hi, > >> > > >> > I would like to understand the difference in using > >> either one on a L3VPN > >> > topology. (route reflectors versus route servers). > >> > I read some threads which said that the RR may not > >> need a "VRF" as it will > >> > not have an "interface" in the VPN associated with > >> the VRF. > >> > But the RR will make the "best path decisions as > >> seen by itself locally". > >> > > >> > Which implies that for an RR to operate > >> effectively, the RR has to be in > >> > the forwarding path of the traffic. > >> > In that case, would it not need a VRF for those > >> VPNs? > >> > > >> > In 1 case , the decision making algorithm (incase > >> it is not in the > >> > forwarding path) may lead to suboptimal routing, > >> and in the 2nd case, it > >> > would be in the path anyways, so why not the VRF? > >> > > >> > if it was a sort of "route server", it would never > >> run the decision > >> > process and pass on all routes learnt from client > >> peers to the each and > >> > every non client peer and client peer , and those > >> from non client peers to > >> > client peers. In this case it may not even be in > >> the forwarding path. > >> > > >> > is my interpretation correct? > >> > > >> > -thanks > >> > Alok > >> > > >> > > >> > > >> > > >> > >> > > > > > >__________________________________ > >Do you Yahoo!? > >The New Yahoo! Shopping - with improved product search > >http://shopping.yahoo.com From exim@www1.ietf.org Fri Oct 10 11:36:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03813 for ; Fri, 10 Oct 2003 11:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zJH-0002pv-JB for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 11:36:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AFa7Ee010903 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 11:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zJH-0002pl-ES for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 11:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03781 for ; Fri, 10 Oct 2003 11:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zJG-0005BF-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 11:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7zJF-0005BC-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 11:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zJC-0002oO-BX; Fri, 10 Oct 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7zIX-0002mQ-OK for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 11:35:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03755 for ; Fri, 10 Oct 2003 11:35:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zIW-0005AS-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 11:35:20 -0400 Received: from web14105.mail.yahoo.com ([216.136.172.135]) by ietf-mx with smtp (Exim 4.12) id 1A7zIV-0005AP-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 11:35:20 -0400 Message-ID: <20031010153518.44389.qmail@web14105.mail.yahoo.com> Received: from [47.234.0.51] by web14105.mail.yahoo.com via HTTP; Fri, 10 Oct 2003 08:35:18 PDT Date: Fri, 10 Oct 2003 08:35:18 -0700 (PDT) From: PamSri Subject: RE: Route Reflectors versus Route-servers To: Jim Guichard , alok.dube@apara.com Cc: l3vpn@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Blackholing is a subset of suboptimality and the former is a condition arising out of the latter. Whole idea of RRs usage in this scenario is prevent meshes and to not cause suboptimality. Does it mean that this condition is seen in every scenario ? I dont think so but there are cases where this is prone to this condition. IMO, its oversimplifying to rule out this condition. BTW, RTs have everything to do with route selection as they remain the prime criterion to be even considered for route selection. sri --- Jim Guichard wrote: > I don't think the possibility for blackholes exists > unless you misconfigure > the import/export policy. The RTs have nothing to do > with route selection. > If you happen to send two routes with same > RD:IP-address pair, and these two > routes do not carry the right RT values (or one does > and the other does > not), then the PEs that were supposed to receive the > routes might lose > connectivity to that specific prefix. Jim > > > >-----Original Message----- > > >From: l3vpn-admin@ietf.org > [mailto:l3vpn-admin@ietf.org]On Behalf Of > > >PamSri > > >Sent: Friday, October 10, 2003 10:23 AM > > >To: raszuk@cisco.com; alok.dube@apara.com > > >Cc: l3vpn@ietf.org > > >Subject: Re: Route Reflectors versus > Route-servers > > > > > > > > >Hi Alok, > > > Sub-optimal routing is just one of the > > >consequence. It could lead to blackholes should > the RR > > >start making the routing decisions on the > received VPN > > >routes. Here's the reason: > > >Since the RR does'nt have VRF it cannot really > use the > > >RTs for the policies. So if RR were to choose a > best > > >route (ofcourse as Bob said, using RD to uniquely > > >identify the VPN routes) which its client were to > > >discard due to non-match of RT for the VRF then > that > > >VRF never gets any more routes for that. > > > > > >sri > > > > > >--- Robert Raszuk wrote: > > >> Hi Alok, > > >> > > >> Yes I think your observations are correct. But > > >> please observe that if > > >> you follow a principle of different RD per each > vrf > > >> your RR's best path > > >> selection would turn into a pure formality as > each > > >> path will be unique > > >> and best path selection will always be running > there > > >> essentially over a > > >> single path. > > >> > > >> If your RDs are the same on any set of vrfs it > seems > > >> indeed that falling > > >> down to IGP cost to next hop especially in the > case > > >> when you run LDP and > > >> RRs are not in the forwarding path or that > don't set > > >> next hop to self is > > >> questionable. I should not break anything > > >> connectivity wise. Only in the > > >> cases of multihomed sites it could make the > path > > >> less optimal. > > >> > > >> Cheers, > > >> R. > > >> > > >> > Alok Dube wrote: > > >> > > > >> > hi, > > >> > > > >> > I would like to understand the difference in > using > > >> either one on a L3VPN > > >> > topology. (route reflectors versus route > servers). > > >> > I read some threads which said that the RR > may not > > >> need a "VRF" as it will > > >> > not have an "interface" in the VPN associated > with > > >> the VRF. > > >> > But the RR will make the "best path decisions > as > > >> seen by itself locally". > > >> > > > >> > Which implies that for an RR to operate > > >> effectively, the RR has to be in > > >> > the forwarding path of the traffic. > > >> > In that case, would it not need a VRF for > those > > >> VPNs? > > >> > > > >> > In 1 case , the decision making algorithm > (incase > > >> it is not in the > > >> > forwarding path) may lead to suboptimal > routing, > > >> and in the 2nd case, it > > >> > would be in the path anyways, so why not the > VRF? > > >> > > > >> > if it was a sort of "route server", it would > never > > >> run the decision > > >> > process and pass on all routes learnt from > client > > >> peers to the each and > > >> > every non client peer and client peer , and > those > > >> from non client peers to > > >> > client peers. In this case it may not even be > in > > >> the forwarding path. > > >> > > > >> > is my interpretation correct? > > >> > > > >> > -thanks > > >> > Alok > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > > > > > > > >__________________________________ > > >Do you Yahoo!? > > >The New Yahoo! Shopping - with improved product > search > > >http://shopping.yahoo.com > > __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From exim@www1.ietf.org Fri Oct 10 12:22:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05624 for ; Fri, 10 Oct 2003 12:22:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A801l-0006wP-Au for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 12:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGM5mX026680 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 12:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A801l-0006wF-6G for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:22:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05591 for ; Fri, 10 Oct 2003 12:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A801j-0005nl-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 12:22:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A801j-0005nh-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 12:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A801h-0006vf-Lb; Fri, 10 Oct 2003 12:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A801c-0006v9-RW for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 12:21:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05585; Fri, 10 Oct 2003 12:21:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A801b-0005ne-00; Fri, 10 Oct 2003 12:21:55 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1A801a-0005nM-00; Fri, 10 Oct 2003 12:21:54 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HMJ00M62UOG3Q@firewall.wcom.com>; Fri, 10 Oct 2003 16:19:28 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HMJ00201UOE2U@dgismtp06.wcomnet.com>; Fri, 10 Oct 2003 16:19:28 +0000 (GMT) Received: from dmcdysan ([166.32.199.64]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HMJ00MMIUOF6D@dgismtp06.wcomnet.com>; Fri, 10 Oct 2003 16:19:27 +0000 (GMT) Date: Fri, 10 Oct 2003 12:19:28 -0400 From: Dave McDysan Subject: MPLS 2003 Conference To: Ccamp , Pwe3 , Mpls , l2vpn@ietf.org, l3vpn@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (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 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit MPLS 2003 International Conference Omni Shoreham Hotel, Washington D.C. October 26-28, 2003 ==================================== http://www.mpls2003.com ==================================== You are cordially invited to attend the MPLS 2003 International Conference to be held in Washington D.C. October 26-28, 2003. The 3-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. You can register for the conference at: http://www.mpls2003.com/registration.htm A limited number of rooms are available at the Omni Shoreham Hotel at special rates for conference attendees. These discounted rooms are available for only a few more days - make your reservation as soon as possible. Please MAKE SURE THAT YOU IDENTIFY YOURSELVES AS CONFERENCE ATTENDEES TO RECEIVE THE REDUCED RATES. Important Dates: --------------------- - Tutorials: October 26, 9:00am - 5:30 pm - Conference sessions: October 27-28, 8:45am-6:30pm - Exhibits: October 27-28, 8:45am-6:30pm Program: --------------------- Visit http://www.mpls2003.com/sessions.htm for abstracts and speaker bios We look forward to seeing you at the Conference. From exim@www1.ietf.org Fri Oct 10 12:30:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05997 for ; Fri, 10 Oct 2003 12:30:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A809T-0007m8-Ox for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 12:30:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGU3XS029877 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 12:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A809T-0007ln-6I for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05974 for ; Fri, 10 Oct 2003 12:29:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A809R-0005u5-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 12:30:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A809R-0005u2-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 12:30:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A809R-0007kO-6x; Fri, 10 Oct 2003 12:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A809E-0007jg-UA for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 12:29:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05964 for ; Fri, 10 Oct 2003 12:29:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A809D-0005tg-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 12:29:47 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A809C-0005tO-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 12:29:46 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2003 18:27:27 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9AGT6qT006554; Fri, 10 Oct 2003 18:29:06 +0200 (MET DST) Received: from JGUICHARW2K (che-vpn-cluster-1-4.cisco.com [10.86.240.4]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id SAA14630; Fri, 10 Oct 2003 18:29:09 +0200 (MET DST) From: "Jim Guichard" To: "PamSri" , Cc: Subject: RE: Route Reflectors versus Route-servers Date: Fri, 10 Oct 2003 12:23:00 -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.4927.1200 In-Reply-To: <20031010153518.44389.qmail@web14105.mail.yahoo.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >-----Original Message----- > >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > >PamSri > >Sent: Friday, October 10, 2003 11:35 AM > >To: Jim Guichard; alok.dube@apara.com > >Cc: l3vpn@ietf.org > >Subject: RE: Route Reflectors versus Route-servers > > > > > >Blackholing is a subset of suboptimality and the > >former is a condition arising out of the latter. not in the case of a 2547 network - if there is a specific scenario you have in mind that details a blackholing event then I would be interested to see it .. apart from misconfiguration I cannot think of a single case. Whole > >idea of RRs usage in this scenario is prevent meshes > >and to not cause suboptimality. Does it mean that this > >condition is seen in every scenario ? I dont think so > >but there are cases where this is prone to this > >condition. IMO, its oversimplifying to rule out this > >condition. > > > >BTW, RTs have everything to do with route selection as > >they remain the prime criterion to be even considered > >for route selection. not at the RRs - they could not care less about RTs - RTs are used for import/export policy at the PE-routers - note that RTs have no place within the BGP selection criteria. If you misconfigure the RTs then they may not pass the ARF check but then this is a misconfiguration rather than a flaw in the architecture. Jim > > > >sri > > > >--- Jim Guichard wrote: > >> I don't think the possibility for blackholes exists > >> unless you misconfigure > >> the import/export policy. The RTs have nothing to do > >> with route selection. > >> If you happen to send two routes with same > >> RD:IP-address pair, and these two > >> routes do not carry the right RT values (or one does > >> and the other does > >> not), then the PEs that were supposed to receive the > >> routes might lose > >> connectivity to that specific prefix. Jim > >> > >> > >-----Original Message----- > >> > >From: l3vpn-admin@ietf.org > >> [mailto:l3vpn-admin@ietf.org]On Behalf Of > >> > >PamSri > >> > >Sent: Friday, October 10, 2003 10:23 AM > >> > >To: raszuk@cisco.com; alok.dube@apara.com > >> > >Cc: l3vpn@ietf.org > >> > >Subject: Re: Route Reflectors versus > >> Route-servers > >> > > > >> > > > >> > >Hi Alok, > >> > > Sub-optimal routing is just one of the > >> > >consequence. It could lead to blackholes should > >> the RR > >> > >start making the routing decisions on the > >> received VPN > >> > >routes. Here's the reason: > >> > >Since the RR does'nt have VRF it cannot really > >> use the > >> > >RTs for the policies. So if RR were to choose a > >> best > >> > >route (ofcourse as Bob said, using RD to uniquely > >> > >identify the VPN routes) which its client were to > >> > >discard due to non-match of RT for the VRF then > >> that > >> > >VRF never gets any more routes for that. > >> > > > >> > >sri > >> > > > >> > >--- Robert Raszuk wrote: > >> > >> Hi Alok, > >> > >> > >> > >> Yes I think your observations are correct. But > >> > >> please observe that if > >> > >> you follow a principle of different RD per each > >> vrf > >> > >> your RR's best path > >> > >> selection would turn into a pure formality as > >> each > >> > >> path will be unique > >> > >> and best path selection will always be running > >> there > >> > >> essentially over a > >> > >> single path. > >> > >> > >> > >> If your RDs are the same on any set of vrfs it > >> seems > >> > >> indeed that falling > >> > >> down to IGP cost to next hop especially in the > >> case > >> > >> when you run LDP and > >> > >> RRs are not in the forwarding path or that > >> don't set > >> > >> next hop to self is > >> > >> questionable. I should not break anything > >> > >> connectivity wise. Only in the > >> > >> cases of multihomed sites it could make the > >> path > >> > >> less optimal. > >> > >> > >> > >> Cheers, > >> > >> R. > >> > >> > >> > >> > Alok Dube wrote: > >> > >> > > >> > >> > hi, > >> > >> > > >> > >> > I would like to understand the difference in > >> using > >> > >> either one on a L3VPN > >> > >> > topology. (route reflectors versus route > >> servers). > >> > >> > I read some threads which said that the RR > >> may not > >> > >> need a "VRF" as it will > >> > >> > not have an "interface" in the VPN associated > >> with > >> > >> the VRF. > >> > >> > But the RR will make the "best path decisions > >> as > >> > >> seen by itself locally". > >> > >> > > >> > >> > Which implies that for an RR to operate > >> > >> effectively, the RR has to be in > >> > >> > the forwarding path of the traffic. > >> > >> > In that case, would it not need a VRF for > >> those > >> > >> VPNs? > >> > >> > > >> > >> > In 1 case , the decision making algorithm > >> (incase > >> > >> it is not in the > >> > >> > forwarding path) may lead to suboptimal > >> routing, > >> > >> and in the 2nd case, it > >> > >> > would be in the path anyways, so why not the > >> VRF? > >> > >> > > >> > >> > if it was a sort of "route server", it would > >> never > >> > >> run the decision > >> > >> > process and pass on all routes learnt from > >> client > >> > >> peers to the each and > >> > >> > every non client peer and client peer , and > >> those > >> > >> from non client peers to > >> > >> > client peers. In this case it may not even be > >> in > >> > >> the forwarding path. > >> > >> > > >> > >> > is my interpretation correct? > >> > >> > > >> > >> > -thanks > >> > >> > Alok > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> > >> > > > >> > > > >> > >__________________________________ > >> > >Do you Yahoo!? > >> > >The New Yahoo! Shopping - with improved product > >> search > >> > >http://shopping.yahoo.com > >> > >> > > > > > >__________________________________ > >Do you Yahoo!? > >The New Yahoo! Shopping - with improved product search > >http://shopping.yahoo.com From exim@www1.ietf.org Fri Oct 10 14:01:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09903 for ; Fri, 10 Oct 2003 14:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Zc-0005ik-T1 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 14:01:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AI18hn021990 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 14:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Zc-0005ib-Oo for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:01:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09871 for ; Fri, 10 Oct 2003 14:01:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81Za-000702-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 14:01:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A81ZZ-0006zz-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 14:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81ZV-0005hl-Ck; Fri, 10 Oct 2003 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81Yo-0005bc-EW for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 14:00:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09861 for ; Fri, 10 Oct 2003 14:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81Yl-0006zf-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 14:00:15 -0400 Received: from web14104.mail.yahoo.com ([216.136.172.134]) by ietf-mx with smtp (Exim 4.12) id 1A81Yl-0006zb-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 14:00:15 -0400 Message-ID: <20031010180008.4432.qmail@web14104.mail.yahoo.com> Received: from [47.234.0.51] by web14104.mail.yahoo.com via HTTP; Fri, 10 Oct 2003 11:00:08 PDT Date: Fri, 10 Oct 2003 11:00:08 -0700 (PDT) From: PamSri Subject: RE: Route Reflectors versus Route-servers To: Jim Guichard Cc: l3vpn@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Did i ever refer to the fact that the RRs were using RTs ? Was'nt the whole issue that the RRs did'nt need to store the VRF info inclusive of the RTs was resulting in sub-optimal routing ? Before we get offtrack let me re-iterate my concern for the sake of clarity. My concern is about the RRs running the route selection on the VPN prefixes by comparing routes with the same RD heading to different VRFs. In this case the best route selected and propagted by the RR will get populated in only some VRFs (ofcourse this is conditional). Thus resulting in black holes. sri --- Jim Guichard wrote: > > > > >-----Original Message----- > > >From: l3vpn-admin@ietf.org > [mailto:l3vpn-admin@ietf.org]On Behalf Of > > >PamSri > > >Sent: Friday, October 10, 2003 11:35 AM > > >To: Jim Guichard; alok.dube@apara.com > > >Cc: l3vpn@ietf.org > > >Subject: RE: Route Reflectors versus > Route-servers > > > > > > > > >Blackholing is a subset of suboptimality and the > > >former is a condition arising out of the latter. > > not in the case of a 2547 network - if there is a > specific scenario you have > in mind that details a blackholing event then I > would be interested to see > it .. apart from misconfiguration I cannot think of > a single case. > > Whole > > >idea of RRs usage in this scenario is prevent > meshes > > >and to not cause suboptimality. Does it mean that > this > > >condition is seen in every scenario ? I dont > think so > > >but there are cases where this is prone to this > > >condition. IMO, its oversimplifying to rule out > this > > >condition. > > > > > >BTW, RTs have everything to do with route > selection as > > >they remain the prime criterion to be even > considered > > >for route selection. > > not at the RRs - they could not care less about RTs > - RTs are used for > import/export policy at the PE-routers - note that > RTs have no place within > the BGP selection criteria. If you misconfigure the > RTs then they may not > pass the ARF check but then this is a > misconfiguration rather than a flaw in > the architecture. > > Jim > > > > > > >sri > > > > > >--- Jim Guichard wrote: > > >> I don't think the possibility for blackholes > exists > > >> unless you misconfigure > > >> the import/export policy. The RTs have nothing > to do > > >> with route selection. > > >> If you happen to send two routes with same > > >> RD:IP-address pair, and these two > > >> routes do not carry the right RT values (or one > does > > >> and the other does > > >> not), then the PEs that were supposed to > receive the > > >> routes might lose > > >> connectivity to that specific prefix. Jim > > >> > > >> > >-----Original Message----- > > >> > >From: l3vpn-admin@ietf.org > > >> [mailto:l3vpn-admin@ietf.org]On Behalf Of > > >> > >PamSri > > >> > >Sent: Friday, October 10, 2003 10:23 AM > > >> > >To: raszuk@cisco.com; alok.dube@apara.com > > >> > >Cc: l3vpn@ietf.org > > >> > >Subject: Re: Route Reflectors versus > > >> Route-servers > > >> > > > > >> > > > > >> > >Hi Alok, > > >> > > Sub-optimal routing is just one of > the > > >> > >consequence. It could lead to blackholes > should > > >> the RR > > >> > >start making the routing decisions on the > > >> received VPN > > >> > >routes. Here's the reason: > > >> > >Since the RR does'nt have VRF it cannot > really > > >> use the > > >> > >RTs for the policies. So if RR were to > choose a > > >> best > > >> > >route (ofcourse as Bob said, using RD to > uniquely > > >> > >identify the VPN routes) which its client > were to > > >> > >discard due to non-match of RT for the VRF > then > > >> that > > >> > >VRF never gets any more routes for that. > > >> > > > > >> > >sri > > >> > > > > >> > >--- Robert Raszuk wrote: > > >> > >> Hi Alok, > > >> > >> > > >> > >> Yes I think your observations are correct. > But > > >> > >> please observe that if > > >> > >> you follow a principle of different RD per > each > > >> vrf > > >> > >> your RR's best path > > >> > >> selection would turn into a pure formality > as > > >> each > > >> > >> path will be unique > > >> > >> and best path selection will always be > running > > >> there > > >> > >> essentially over a > > >> > >> single path. > > >> > >> > > >> > >> If your RDs are the same on any set of > vrfs it > > >> seems > > >> > >> indeed that falling > > >> > >> down to IGP cost to next hop especially in > the > > >> case > > >> > >> when you run LDP and > > >> > >> RRs are not in the forwarding path or that > > >> don't set > > >> > >> next hop to self is > > >> > >> questionable. I should not break anything > > >> > >> connectivity wise. Only in the > > >> > >> cases of multihomed sites it could make > the > > >> path > > >> > >> less optimal. > > >> > >> > > >> > >> Cheers, > > >> > >> R. > > >> > >> > > >> > >> > Alok Dube wrote: > > >> > >> > > > >> > >> > hi, > > >> > >> > > > >> > >> > I would like to understand the > difference in > > >> using > > >> > >> either one on a L3VPN > > >> > >> > topology. (route reflectors versus route > > >> servers). > > >> > >> > I read some threads which said that the > RR > > >> may not > > >> > >> need a "VRF" as it will > > >> > >> > not have an "interface" in the VPN > associated > > >> with > > >> > >> the VRF. > > >> > >> > But the RR will make the "best path > decisions > > >> as > > >> > >> seen by itself locally". > > >> > >> > > > >> > >> > Which implies that for an RR to operate > > >> > >> effectively, the RR has to be in > > >> > >> > the forwarding path of the traffic. > > >> > >> > In that case, would it not need a VRF > for > > >> those > > >> > >> VPNs? > > >> > >> > > > >> > >> > In 1 case , the decision making > algorithm > > >> (incase > > >> > >> it is not in the > > >> > >> > forwarding path) may lead to suboptimal > > >> routing, > > >> > >> and in the 2nd case, it > > >> > >> > would be in the path anyways, so why not > the > > >> VRF? > > >> > >> > > > >> > >> > if it was a sort of "route server", it > would > > >> never > > >> > >> run the decision > > >> > >> > process and pass on all routes learnt > from > > >> client > > >> > >> peers to the each and > === message truncated === __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From exim@www1.ietf.org Fri Oct 10 14:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10941 for ; Fri, 10 Oct 2003 14:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81xl-00088D-5d for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 14:26:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIQ5w0031257 for l3vpn-archive@odin.ietf.org; Fri, 10 Oct 2003 14:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81xk-000884-W6 for l3vpn-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10932 for ; Fri, 10 Oct 2003 14:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81xi-0007J9-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 14:26:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A81xi-0007J6-00 for l3vpn-web-archive@ietf.org; Fri, 10 Oct 2003 14:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81xh-00087N-Ke; Fri, 10 Oct 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81xQ-00086i-VX for l3vpn@optimus.ietf.org; Fri, 10 Oct 2003 14:25:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10902 for ; Fri, 10 Oct 2003 14:25:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81xO-0007IZ-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 14:25:42 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A81xN-0007Hr-00 for l3vpn@ietf.org; Fri, 10 Oct 2003 14:25:41 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2003 20:23:25 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9AIP4nf005942; Fri, 10 Oct 2003 20:25:05 +0200 (MET DST) Received: from JGUICHARW2K (che-vpn-cluster-1-4.cisco.com [10.86.240.4]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id UAA02356; Fri, 10 Oct 2003 20:25:07 +0200 (MET DST) From: "Jim Guichard" To: "PamSri" Cc: Subject: RE: Route Reflectors versus Route-servers Date: Fri, 10 Oct 2003 14:18:57 -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.4927.1200 In-Reply-To: <20031010180008.4432.qmail@web14104.mail.yahoo.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >-----Original Message----- > >From: PamSri [mailto:pamsri01@yahoo.com] > >Sent: Friday, October 10, 2003 2:00 PM > >To: Jim Guichard > >Cc: l3vpn@ietf.org > >Subject: RE: Route Reflectors versus Route-servers > > > > > >Did i ever refer to the fact that the RRs were using > >RTs ? Was'nt the whole issue that the RRs did'nt need > >to store the VRF info inclusive of the RTs was > >resulting in sub-optimal routing ? Before we get > >offtrack let me re-iterate my concern for the sake of > >clarity. > > > >My concern is about the RRs running the route > >selection on the VPN prefixes by comparing routes with > >the same RD heading to different VRFs. In this case > >the best route selected and propagted by the RR will > >get populated in only some VRFs (ofcourse this is > >conditional). Thus resulting in black holes. once again, this is a misconfiguration. If two routes with the same RD arrive at the RRs then they must be equal to be compared e.g. RD:1:10.1.1.1/32 is not comparable with RD:1:10.1.1.2/32. The best path is selected and advertised to the PEs. If the RT has been configured correctly on the exporting PEs then there is no problem. Also, note that we recommend using separate RDs per VRF per PE and therefore this situation should not even arise. Jim > > > >sri > > > >--- Jim Guichard wrote: > >> > >> > >> > >-----Original Message----- > >> > >From: l3vpn-admin@ietf.org > >> [mailto:l3vpn-admin@ietf.org]On Behalf Of > >> > >PamSri > >> > >Sent: Friday, October 10, 2003 11:35 AM > >> > >To: Jim Guichard; alok.dube@apara.com > >> > >Cc: l3vpn@ietf.org > >> > >Subject: RE: Route Reflectors versus > >> Route-servers > >> > > > >> > > > >> > >Blackholing is a subset of suboptimality and the > >> > >former is a condition arising out of the latter. > >> > >> not in the case of a 2547 network - if there is a > >> specific scenario you have > >> in mind that details a blackholing event then I > >> would be interested to see > >> it .. apart from misconfiguration I cannot think of > >> a single case. > >> > >> Whole > >> > >idea of RRs usage in this scenario is prevent > >> meshes > >> > >and to not cause suboptimality. Does it mean that > >> this > >> > >condition is seen in every scenario ? I dont > >> think so > >> > >but there are cases where this is prone to this > >> > >condition. IMO, its oversimplifying to rule out > >> this > >> > >condition. > >> > > > >> > >BTW, RTs have everything to do with route > >> selection as > >> > >they remain the prime criterion to be even > >> considered > >> > >for route selection. > >> > >> not at the RRs - they could not care less about RTs > >> - RTs are used for > >> import/export policy at the PE-routers - note that > >> RTs have no place within > >> the BGP selection criteria. If you misconfigure the > >> RTs then they may not > >> pass the ARF check but then this is a > >> misconfiguration rather than a flaw in > >> the architecture. > >> > >> Jim > >> > >> > > > >> > >sri > >> > > > >> > >--- Jim Guichard wrote: > >> > >> I don't think the possibility for blackholes > >> exists > >> > >> unless you misconfigure > >> > >> the import/export policy. The RTs have nothing > >> to do > >> > >> with route selection. > >> > >> If you happen to send two routes with same > >> > >> RD:IP-address pair, and these two > >> > >> routes do not carry the right RT values (or one > >> does > >> > >> and the other does > >> > >> not), then the PEs that were supposed to > >> receive the > >> > >> routes might lose > >> > >> connectivity to that specific prefix. Jim > >> > >> > >> > >> > >-----Original Message----- > >> > >> > >From: l3vpn-admin@ietf.org > >> > >> [mailto:l3vpn-admin@ietf.org]On Behalf Of > >> > >> > >PamSri > >> > >> > >Sent: Friday, October 10, 2003 10:23 AM > >> > >> > >To: raszuk@cisco.com; alok.dube@apara.com > >> > >> > >Cc: l3vpn@ietf.org > >> > >> > >Subject: Re: Route Reflectors versus > >> > >> Route-servers > >> > >> > > > >> > >> > > > >> > >> > >Hi Alok, > >> > >> > > Sub-optimal routing is just one of > >> the > >> > >> > >consequence. It could lead to blackholes > >> should > >> > >> the RR > >> > >> > >start making the routing decisions on the > >> > >> received VPN > >> > >> > >routes. Here's the reason: > >> > >> > >Since the RR does'nt have VRF it cannot > >> really > >> > >> use the > >> > >> > >RTs for the policies. So if RR were to > >> choose a > >> > >> best > >> > >> > >route (ofcourse as Bob said, using RD to > >> uniquely > >> > >> > >identify the VPN routes) which its client > >> were to > >> > >> > >discard due to non-match of RT for the VRF > >> then > >> > >> that > >> > >> > >VRF never gets any more routes for that. > >> > >> > > > >> > >> > >sri > >> > >> > > > >> > >> > >--- Robert Raszuk wrote: > >> > >> > >> Hi Alok, > >> > >> > >> > >> > >> > >> Yes I think your observations are correct. > >> But > >> > >> > >> please observe that if > >> > >> > >> you follow a principle of different RD per > >> each > >> > >> vrf > >> > >> > >> your RR's best path > >> > >> > >> selection would turn into a pure formality > >> as > >> > >> each > >> > >> > >> path will be unique > >> > >> > >> and best path selection will always be > >> running > >> > >> there > >> > >> > >> essentially over a > >> > >> > >> single path. > >> > >> > >> > >> > >> > >> If your RDs are the same on any set of > >> vrfs it > >> > >> seems > >> > >> > >> indeed that falling > >> > >> > >> down to IGP cost to next hop especially in > >> the > >> > >> case > >> > >> > >> when you run LDP and > >> > >> > >> RRs are not in the forwarding path or that > >> > >> don't set > >> > >> > >> next hop to self is > >> > >> > >> questionable. I should not break anything > >> > >> > >> connectivity wise. Only in the > >> > >> > >> cases of multihomed sites it could make > >> the > >> > >> path > >> > >> > >> less optimal. > >> > >> > >> > >> > >> > >> Cheers, > >> > >> > >> R. > >> > >> > >> > >> > >> > >> > Alok Dube wrote: > >> > >> > >> > > >> > >> > >> > hi, > >> > >> > >> > > >> > >> > >> > I would like to understand the > >> difference in > >> > >> using > >> > >> > >> either one on a L3VPN > >> > >> > >> > topology. (route reflectors versus route > >> > >> servers). > >> > >> > >> > I read some threads which said that the > >> RR > >> > >> may not > >> > >> > >> need a "VRF" as it will > >> > >> > >> > not have an "interface" in the VPN > >> associated > >> > >> with > >> > >> > >> the VRF. > >> > >> > >> > But the RR will make the "best path > >> decisions > >> > >> as > >> > >> > >> seen by itself locally". > >> > >> > >> > > >> > >> > >> > Which implies that for an RR to operate > >> > >> > >> effectively, the RR has to be in > >> > >> > >> > the forwarding path of the traffic. > >> > >> > >> > In that case, would it not need a VRF > >> for > >> > >> those > >> > >> > >> VPNs? > >> > >> > >> > > >> > >> > >> > In 1 case , the decision making > >> algorithm > >> > >> (incase > >> > >> > >> it is not in the > >> > >> > >> > forwarding path) may lead to suboptimal > >> > >> routing, > >> > >> > >> and in the 2nd case, it > >> > >> > >> > would be in the path anyways, so why not > >> the > >> > >> VRF? > >> > >> > >> > > >> > >> > >> > if it was a sort of "route server", it > >> would > >> > >> never > >> > >> > >> run the decision > >> > >> > >> > process and pass on all routes learnt > >> from > >> > >> client > >> > >> > >> peers to the each and > >> > >=== message truncated === > > > > > > > >__________________________________ > >Do you Yahoo!? > >The New Yahoo! Shopping - with improved product search > >http://shopping.yahoo.com From exim@www1.ietf.org Mon Oct 13 03:35:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25610 for ; Mon, 13 Oct 2003 03:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8xEU-0002pR-Mg for l3vpn-archive@odin.ietf.org; Mon, 13 Oct 2003 03:35:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D7ZAGK010874 for l3vpn-archive@odin.ietf.org; Mon, 13 Oct 2003 03:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8xEU-0002pJ-36 for l3vpn-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 03:35:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25603 for ; Mon, 13 Oct 2003 03:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8xER-0007le-00 for l3vpn-web-archive@ietf.org; Mon, 13 Oct 2003 03:35:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8xER-0007la-00 for l3vpn-web-archive@ietf.org; Mon, 13 Oct 2003 03:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8xEN-0002oj-Nx; Mon, 13 Oct 2003 03:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8xEA-0002o8-6E for l3vpn@optimus.ietf.org; Mon, 13 Oct 2003 03:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25597 for ; Mon, 13 Oct 2003 03:34:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8xE7-0007lW-00 for l3vpn@ietf.org; Mon, 13 Oct 2003 03:34:47 -0400 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A8xE6-0007l8-00 for l3vpn@ietf.org; Mon, 13 Oct 2003 03:34:46 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Mon, 13 Oct 2003 12:46:53 +0530 Received: from sakthivss (sakthivss.future.futsoft.com [10.6.4.130]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h9D7BxT10125 for ; Mon, 13 Oct 2003 12:41:59 +0530 Reply-To: From: "Sakthivadivu.S.S" To: Subject: Route Reflector Date: Mon, 13 Oct 2003 12:43:38 +0530 Message-ID: <001201c39159$87056360$8204060a@future.futsoft.com> 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Section 4.3.3 of 2547 draft says in 2'nd method of Route Reflector "Note that this technique will not work properly if some client PE has a VRF with an import Route Target that is not one of its export Route Target" Can you please tell me why does this method not work? Thanks, Sakthi *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From exim@www1.ietf.org Mon Oct 13 07:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00417 for ; Mon, 13 Oct 2003 07:21:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A90l6-00048B-Od for l3vpn-archive@odin.ietf.org; Mon, 13 Oct 2003 07:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DBL4C9015873 for l3vpn-archive@odin.ietf.org; Mon, 13 Oct 2003 07:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A90l6-00047w-JF for l3vpn-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 07:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00412 for ; Mon, 13 Oct 2003 07:20:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A90l6-0001cY-00 for l3vpn-web-archive@ietf.org; Mon, 13 Oct 2003 07:21:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A90l5-0001cV-00 for l3vpn-web-archive@ietf.org; Mon, 13 Oct 2003 07:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A90l3-00047I-OG; Mon, 13 Oct 2003 07:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A90kD-00046R-EB for l3vpn@optimus.ietf.org; Mon, 13 Oct 2003 07:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00405 for ; Mon, 13 Oct 2003 07:20:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A90kC-0001cK-00 for l3vpn@ietf.org; Mon, 13 Oct 2003 07:20:08 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A90kC-0001c6-00 for l3vpn@ietf.org; Mon, 13 Oct 2003 07:20:08 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9DBJYlR019209; Mon, 13 Oct 2003 04:19:34 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AML52700; Mon, 13 Oct 2003 04:14:51 -0700 (PDT) Message-ID: <3F8A8A42.7000706@cisco.com> Date: Mon, 13 Oct 2003 13:19:30 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sakthivss@future.futsoft.com CC: l3vpn@ietf.org Subject: Re: Route Reflector References: <001201c39159$87056360$8204060a@future.futsoft.com> In-Reply-To: <001201c39159$87056360$8204060a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sakthi, Reflector partitioning as described in 4.3.3 point 2 It will not work when on any PE your import RTs and not part of the export RTs attached to vpnv4 routes. Reason is very simple. 4.3.3/2 relies on PEs connected to a subset of RRs not all of them ! Therefor RRs build dynamically a list of "interested" RTs for all PEs connected to them. On the other hand in vpnv4 updates only exported RTs are carried. So RRs have no way of finding out what other RTs may be configured on PEs for import to include them in the list. This list is used to filter routes coming from other RRs. So if not all import RTs are advertised with vpnv4 routes (are exported) it is likely that some of the interesting vpnv4 routes will be dropped by such a RR hence not propagated to PEs. I hope this is clear now. Also pls note that 4.3.3/2 could very well work when PE would "out of band" of vpnv4 routes signal his imported RT list to RR. That could be done by the use of ext community ORF or by rt-constrain idea: draft-marques-ppvpn-rt-constrain-01.txt Rgs, R. > Sakthivadivu.S.S wrote: > > Hi, > > Section 4.3.3 of 2547 draft says in 2'nd method of Route Reflector > "Note that this technique will not work properly if some client PE > has a VRF with an import Route Target that is not one of its > export Route Target" > > Can you please tell me why does this method not work? > > Thanks, > Sakthi > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > > From exim@www1.ietf.org Sun Oct 19 10:34:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09801 for ; Sun, 19 Oct 2003 10:34:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABEdD-0007ud-IG for l3vpn-archive@odin.ietf.org; Sun, 19 Oct 2003 10:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JEY7Ir030412 for l3vpn-archive@odin.ietf.org; Sun, 19 Oct 2003 10:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABEdD-0007uO-8k for l3vpn-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 10:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09783 for ; Sun, 19 Oct 2003 10:33:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABEdA-0005lO-00 for l3vpn-web-archive@ietf.org; Sun, 19 Oct 2003 10:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABEdA-0005lK-00 for l3vpn-web-archive@ietf.org; Sun, 19 Oct 2003 10:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABEd7-0007sg-HB; Sun, 19 Oct 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABEcl-0007qF-Uj for l3vpn@optimus.ietf.org; Sun, 19 Oct 2003 10:33:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09757 for ; Sun, 19 Oct 2003 10:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABEcj-0005kc-00 for L3vpn@ietf.org; Sun, 19 Oct 2003 10:33:37 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ABEci-0005kZ-00 for L3vpn@ietf.org; Sun, 19 Oct 2003 10:33:37 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9JEXZSs026118 for ; Sun, 19 Oct 2003 16:33:36 +0200 (MEST) Received: from emyklnt163.ao.ericsson.se ([150.236.89.100]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JZ20HZ; Sun, 19 Oct 2003 16:37:22 +0200 Received: by emyklnt163.ao.ericsson.se with Internet Mail Service (5.5.2653.19) id <47FPGD5G>; Sun, 19 Oct 2003 22:33:57 +0800 Message-ID: <0C5B2CD01E65B6458822496C215E8F07035940F1@ecnbjnt512.itc.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Junwen Guo (BJ/ETC)" To: "'L3vpn@ietf.org'" Subject: L3VPN deployment help Date: Sun, 19 Oct 2003 22:33:36 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello Who would like to tell me what is the popular l3vpn deployment model now? VPN+LDP, VPN+RSVP, or VPN+LDP+RSVP? Or others? The network which I will deploy , includes more than 60 PEs (Juniper router); And each VPN will cover more than 30 PEs. IGP is OSPF. Which l3vpn model is better? Thanks Guo Junwen From exim@www1.ietf.org Tue Oct 21 15:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03483 for ; Tue, 21 Oct 2003 15:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2SH-0005FG-EY for l3vpn-archive@odin.ietf.org; Tue, 21 Oct 2003 15:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LJk9bB020156 for l3vpn-archive@odin.ietf.org; Tue, 21 Oct 2003 15:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2SH-0005F1-Af for l3vpn-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 15:46:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03459 for ; Tue, 21 Oct 2003 15:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2SF-0000Lk-00 for l3vpn-web-archive@ietf.org; Tue, 21 Oct 2003 15:46:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC2SF-0000Lg-00 for l3vpn-web-archive@ietf.org; Tue, 21 Oct 2003 15:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2S9-0005Cn-JF; Tue, 21 Oct 2003 15:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2RS-0004vx-9M for l3vpn@optimus.ietf.org; Tue, 21 Oct 2003 15:45:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03434 for ; Tue, 21 Oct 2003 15:45:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2RQ-0000LA-00 for l3vpn@ietf.org; Tue, 21 Oct 2003 15:45:16 -0400 Received: from web20513.mail.yahoo.com ([216.136.174.44]) by ietf-mx with smtp (Exim 4.12) id 1AC2RP-0000L7-00 for l3vpn@ietf.org; Tue, 21 Oct 2003 15:45:16 -0400 Message-ID: <20031021194515.55888.qmail@web20513.mail.yahoo.com> Received: from [64.221.212.131] by web20513.mail.yahoo.com via HTTP; Tue, 21 Oct 2003 12:45:15 PDT Date: Tue, 21 Oct 2003 12:45:15 -0700 (PDT) From: Jim T Subject: Question regarding draft-rosen-vpn-mcast-05.txt To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-863596386-1066765515=:55249" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --0-863596386-1066765515=:55249 Content-Type: text/plain; charset=us-ascii I have a couple of questions regarding this draft related to multicast in BGP/MPLS VPNs. a) In section 2.7, it is mentioned that if a PIM RP-tree is used instead of a bidir tree, the GRE header would have to be used for all tunneled VPN multicast packets. I am not clear about this and would appreciate very much if someone clarifies. b) The draft refers to draft-farinacci-mpls-multicast-03.txt but I am unable to find this on the IETF site. Has this been issued as an IETF draft? Could someone point me to it? I apologize If I've posted these questions on the wrong mailing list. If so, I hope someone will direct me to the correct mailing list. Jim --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-863596386-1066765515=:55249 Content-Type: text/html; charset=us-ascii
I have a couple of questions regarding this draft related to multicast in BGP/MPLS VPNs.
 
a) In section 2.7, it is mentioned that if a PIM RP-tree is used instead of a bidir tree, the GRE header would have to be used for all tunneled VPN multicast packets. I am not clear about this and would appreciate very much if someone clarifies.
 
b) The draft refers to draft-farinacci-mpls-multicast-03.txt but I am unable to find this on the IETF site. Has this been issued as an IETF draft? Could someone point me to it?
 
I apologize If I've posted these questions on the wrong mailing list. If so, I hope someone will direct me to the correct mailing list.
 
Jim
 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-863596386-1066765515=:55249-- From exim@www1.ietf.org Tue Oct 21 16:36:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06462 for ; Tue, 21 Oct 2003 16:36:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3Eb-0001Ut-IY for l3vpn-archive@odin.ietf.org; Tue, 21 Oct 2003 16:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LKa53J005749 for l3vpn-archive@odin.ietf.org; Tue, 21 Oct 2003 16:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3Eb-0001Ue-Dn for l3vpn-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 16:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06445 for ; Tue, 21 Oct 2003 16:35:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC3EZ-0001CX-00 for l3vpn-web-archive@ietf.org; Tue, 21 Oct 2003 16:36:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC3EZ-0001CU-00 for l3vpn-web-archive@ietf.org; Tue, 21 Oct 2003 16:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3EY-0001Sz-IS; Tue, 21 Oct 2003 16:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3EP-0001RK-8A for l3vpn@optimus.ietf.org; Tue, 21 Oct 2003 16:35:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06402; Tue, 21 Oct 2003 16:35:36 -0400 (EDT) Message-Id: <200310212035.QAA06402@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tpext@ietf.org, mpls@uu.net, l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-townsley-l2tpv3-mpls-00.txt Date: Tue, 21 Oct 2003 16:35:36 -0400 Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS over Layer 2 Tunneling Protocol (Version 3) Author(s) : M. Townsley Filename : draft-townsley-l2tpv3-mpls-00.txt Pages : 9 Date : 2003-10-20 The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label or label stack and its payload over L2TPv3. This enables an application which traditionally requires an MPLS-enabled core network to utilize an L2TPv3 encapsulation over an IP network instead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-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-townsley-l2tpv3-mpls-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-townsley-l2tpv3-mpls-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-10-21163835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-townsley-l2tpv3-mpls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-townsley-l2tpv3-mpls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21163835.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Oct 22 08:54:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06642 for ; Wed, 22 Oct 2003 08:54:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIV5-00081e-0s for l3vpn-archive@odin.ietf.org; Wed, 22 Oct 2003 08:54:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCs6gU030844 for l3vpn-archive@odin.ietf.org; Wed, 22 Oct 2003 08:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIV4-00081P-SE for l3vpn-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:54:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06597 for ; Wed, 22 Oct 2003 08:53:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIV3-0004j6-00 for l3vpn-web-archive@ietf.org; Wed, 22 Oct 2003 08:54:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACIV3-0004j3-00 for l3vpn-web-archive@ietf.org; Wed, 22 Oct 2003 08:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIUz-0007zb-Cr; Wed, 22 Oct 2003 08:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIUs-0007xr-Sy for l3vpn@optimus.ietf.org; Wed, 22 Oct 2003 08:53:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06589 for ; Wed, 22 Oct 2003 08:53:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIUr-0004iq-00 for l3vpn@ietf.org; Wed, 22 Oct 2003 08:53:53 -0400 Received: from [203.199.93.15] (helo=WS0005.indiatimes.com) by ietf-mx with esmtp (Exim 4.12) id 1ACIUp-0004iN-00 for l3vpn@ietf.org; Wed, 22 Oct 2003 08:53:52 -0400 Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA13154 for ; Wed, 22 Oct 2003 17:54:03 +0530 From: "Rohit Gupta" Message-Id: <200310221224.RAA13154@WS0005.indiatimes.com> To: Reply-To: "Rohit Gupta" Subject: Aggregate Label and Interface Labels Date: Wed, 22 Oct 2003 18:11:57 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I have a doubt and would really appreciate if someone could clarify that. AFAIK a unique label is generally associated whenever an interface is bound to a VRF. Say, we call this a "CE Label". Thus if i have two interfaces bound to a VRF (same or different) then i will have 2 labels for all the routes that i originate via these 2 interfaces. The other option is to configure an Aggregate Label. This will be associated with a VRF. Thus if an MPLS packet comes with the Aggregate label then the PE router will do an IPv4 lookup to determine the outgoing interface for the data packet. Now suppose i bind some interfaces to this VRF (for which i already have an aggregate label). Is it possible for an admin to specify that he wants to use a "CE Label" for all the routes learnt over this interface and the Aggregate Label for all others learnt form other interfaces (tied to the same VRF)? And if its possible then is there any reason why somebody would want to do that? Policy Reasons? Any clues anybody. Regards, Rohit Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now ! From exim@www1.ietf.org Thu Oct 23 09:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17338 for ; Thu, 23 Oct 2003 09:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfH2-0006Zc-08 for l3vpn-archive@odin.ietf.org; Thu, 23 Oct 2003 09:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDD7dP025260 for l3vpn-archive@odin.ietf.org; Thu, 23 Oct 2003 09:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfH1-0006ZL-KY for l3vpn-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 09:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17297 for ; Thu, 23 Oct 2003 09:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfH0-000708-00 for l3vpn-web-archive@ietf.org; Thu, 23 Oct 2003 09:13:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACfGz-000704-00 for l3vpn-web-archive@ietf.org; Thu, 23 Oct 2003 09:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfGu-0006Qv-JL; Thu, 23 Oct 2003 09:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfGc-0006NM-2p for l3vpn@optimus.ietf.org; Thu, 23 Oct 2003 09:12:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17245 for ; Thu, 23 Oct 2003 09:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfGa-0006yv-00 for l3vpn@ietf.org; Thu, 23 Oct 2003 09:12:40 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 1ACfGa-0006yo-00 for l3vpn@ietf.org; Thu, 23 Oct 2003 09:12:40 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HN7002L1OKQJL@firewall.wcom.com> for l3vpn@ietf.org; Thu, 23 Oct 2003 13:10:02 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HN700G01OKFO0@dgismtp04.wcomnet.com> for l3vpn@ietf.org; Thu, 23 Oct 2003 13:10:02 +0000 (GMT) Received: from rbonica ([166.32.199.163]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HN700FKBOKPBG@dgismtp04.wcomnet.com> for l3vpn@ietf.org; Thu, 23 Oct 2003 13:10:02 +0000 (GMT) Date: Thu, 23 Oct 2003 09:10:41 -0400 From: Ron Bonica Subject: RE: WG Last Call In-reply-to: To: l3vpn@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, This email ends the last call. I will forward these documents to the IESG for consideration. Ron > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > Sent: Thursday, October 09, 2003 12:52 PM > To: l3vpn@ietf.org > Subject: WG Last Call > > > Folks, > > This begins a WG last call on the following documents: > > draft-ietf-l3vpn-rfc2547bis-01 > draft-ietf-l3vpn-as2547-03 > > Last call will end on 10/23. > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "An eye for an eye only ends up making > the whole world blind." > -- Gandhi From exim@www1.ietf.org Fri Oct 24 11:45:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10957 for ; Fri, 24 Oct 2003 11:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD47d-0006Pr-K4 for l3vpn-archive@odin.ietf.org; Fri, 24 Oct 2003 11:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OFj5M3024657 for l3vpn-archive@odin.ietf.org; Fri, 24 Oct 2003 11:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD47d-0006Pc-En for l3vpn-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 11:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10912 for ; Fri, 24 Oct 2003 11:44:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD47c-0006FQ-00 for l3vpn-web-archive@ietf.org; Fri, 24 Oct 2003 11:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD47b-0006FM-00 for l3vpn-web-archive@ietf.org; Fri, 24 Oct 2003 11:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD47a-0006O7-En; Fri, 24 Oct 2003 11:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD46o-0006H8-Rg for l3vpn@optimus.ietf.org; Fri, 24 Oct 2003 11:44:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10790; Fri, 24 Oct 2003 11:44:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD46n-0006BN-00; Fri, 24 Oct 2003 11:44:13 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AD46m-00069s-00; Fri, 24 Oct 2003 11:44:13 -0400 Received: from rcallon-lt.juniper.net (securepptp032.static.jnpr.net [172.24.253.32]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h9OFhfi94039; Fri, 24 Oct 2003 08:43:41 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20031024113949.02b3ee10@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 24 Oct 2003 11:42:08 -0400 To: l3vpn@ietf.org, l2vpn@ietf.org From: Ross Callon Subject: draft-andersson-ppvpn-terminology-04.txt as working group draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , There appears to be broad consensus on the *content* of this draft (there were no objections to any of the content). We don't have any clear direction from the working group on the preferred distribution of text between documents. This is however an editorial issue. Some distribution of the content between documents is necessary in order to make progress on other documents in a timely fashion. Given agreement on content, and in the absence of any clear direction from the working group on the editorial distribution of text between documents, the chairs would prefer to go with the editorial distribution recommended by the document authors. Therefore, we will accept draft-andersson-ppvpn-terminology-04.txt as an l3vpn working group document. Ross, Ron, and Rick From exim@www1.ietf.org Mon Oct 27 16:58:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17144 for ; Mon, 27 Oct 2003 16:58:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFNG-00063s-8D for l3vpn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:58:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RLw6Hl023297 for l3vpn-archive@odin.ietf.org; Mon, 27 Oct 2003 16:58:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFNG-00063g-4S for l3vpn-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 16:58:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17083 for ; Mon, 27 Oct 2003 16:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEFND-0006US-00 for l3vpn-web-archive@ietf.org; Mon, 27 Oct 2003 16:58:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEFND-0006UO-00 for l3vpn-web-archive@ietf.org; Mon, 27 Oct 2003 16:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFNB-00062y-FO; Mon, 27 Oct 2003 16:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFML-0005yk-5c for l3vpn@optimus.ietf.org; Mon, 27 Oct 2003 16:57:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16931 for ; Mon, 27 Oct 2003 16:56:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEFMI-0006Rx-00 for l3vpn@ietf.org; Mon, 27 Oct 2003 16:57:06 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AEFMI-0006QN-00 for l3vpn@ietf.org; Mon, 27 Oct 2003 16:57:06 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9RLuQA18420 for ; Mon, 27 Oct 2003 16:56:26 -0500 (EST) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Oct 2003 16:56:25 -0500 Message-ID: <8B888AAAAB0FD31189590008C791844310DE9957@zbl6c002.corpeast.baynetworks.com> From: "Rajesh Potti" To: "'l3vpn@ietf.org'" Subject: Route Reflector and VRFs Date: Mon, 27 Oct 2003 16:56:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39CD5.2A1D3E34" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39CD5.2A1D3E34 Content-Type: text/plain Hi, Route Reflectors reflect routes only if it is inserted into the Forwarding Table. In that case, we need to have the VRFs activated, and routes inserted into the VRF, before it can be advertised to the clients? Is an exception to this rule done, before reflecting vpnv4 routes? Thanks, Rajesh ------_=_NextPart_001_01C39CD5.2A1D3E34 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Route Reflector and VRFs

Hi,

 Route Reflectors reflect routes = only if it is inserted into the Forwarding Table.
  In that case, we need to have = the VRFs activated, and routes inserted into the VRF,  before it = can be advertised to the clients?

 Is an exception to this rule = done, before reflecting vpnv4 routes?

Thanks,
Rajesh

------_=_NextPart_001_01C39CD5.2A1D3E34-- From exim@www1.ietf.org Mon Oct 27 18:42:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28723 for ; Mon, 27 Oct 2003 18:42:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGzr-00015A-Lu for l3vpn-archive@odin.ietf.org; Mon, 27 Oct 2003 18:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RNg3MN004154 for l3vpn-archive@odin.ietf.org; Mon, 27 Oct 2003 18:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGzr-00014v-HA for l3vpn-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 18:42:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28709 for ; Mon, 27 Oct 2003 18:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGzo-00021J-00 for l3vpn-web-archive@ietf.org; Mon, 27 Oct 2003 18:42:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEGzo-00021G-00 for l3vpn-web-archive@ietf.org; Mon, 27 Oct 2003 18:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGzp-00013N-8z; Mon, 27 Oct 2003 18:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEGzT-00011w-L3 for l3vpn@optimus.ietf.org; Mon, 27 Oct 2003 18:41:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28692 for ; Mon, 27 Oct 2003 18:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGzQ-00020i-00 for l3vpn@ietf.org; Mon, 27 Oct 2003 18:41:36 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AEGzP-00020D-00 for l3vpn@ietf.org; Mon, 27 Oct 2003 18:41:35 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9RNeoc12314; Mon, 27 Oct 2003 18:40:50 -0500 (EST) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Oct 2003 18:40:49 -0500 Message-ID: <8B888AAAAB0FD31189590008C791844310DE9958@zbl6c002.corpeast.baynetworks.com> From: "Rajesh Potti" To: "'nanur@avici.com'" Cc: "'l3vpn@ietf.org'" Subject: RE: Route Reflector and VRFs Date: Mon, 27 Oct 2003 18:40:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39CE3.BFAFBAE0" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39CE3.BFAFBAE0 Content-Type: text/plain Nagananda, For ipv4 routes, do Route Reflectors reflect routes even if it is not inserted into the FIB? RFC 2796 does not states this explicitly. Since the nexthop is unaltered by the RR, i think it would be sufficient if the RR clients have inserted the routes into its FIB. Since the RR selects the best route for reflecting, from its view point, this could result in suboptimality, as the RFC points out. For vpnv4 routes, routes should be in the FIB, as well as an LSP should be established between the clients. RR does not sound like a good way to handle this case, since it only sends the clients, only the best route for it. Suppose, 1. RRC A and RRC B sends a route to the RR, 2. RR picks the route from RRC A, as the best, and sends it to RRC C. 3. RRC C might have an LSP to RRC B, and not to RRC A --> In this case, RRC C would have preferred the route from RRC B, while it gets the route from RRC A, which results in loss of connectivity, when there is an alternate path. Rajesh -----Original Message----- From: Nagananda Anur [mailto:nanur@avici.com] Sent: Monday, October 27, 2003 6:16 PM To: Potti, Rajesh [BL60:SF40:EXCH] Subject: RE: Route Reflector and VRFs Rajesh, One doesn't need to have VRF to reflect VPN routes. You don't install MBGP routes into you FIB but you still reflect right - it's the same way. It's the resposibility of PEs to make sure that LSP is been established before opening up for directing traffic. Also, RR may not be in VPN traffic forwarding path...hence it's not necessary to have VRFs to reflect. Nagananda -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh Potti Sent: Monday, October 27, 2003 4:56 PM To: 'l3vpn@ietf.org' Subject: Route Reflector and VRFs Hi, Route Reflectors reflect routes only if it is inserted into the Forwarding Table. In that case, we need to have the VRFs activated, and routes inserted into the VRF, before it can be advertised to the clients? Is an exception to this rule done, before reflecting vpnv4 routes? Thanks, Rajesh ------_=_NextPart_001_01C39CE3.BFAFBAE0 Content-Type: text/html Message
Nagananda,
 
 For ipv4 routes, do Route Reflectors reflect routes even if it is not inserted into the FIB? RFC 2796 does not states
 this explicitly. Since the nexthop is unaltered by the RR, i think it would be sufficient if the RR clients have inserted the
 routes into its FIB.
 
Since the RR selects the best route for reflecting, from its view point, this could result in suboptimality, as the RFC
points out. For vpnv4 routes, routes should be in the FIB, as well as an LSP should be established between the
clients.
 
RR does not sound like a good way to handle this case, since it only sends the clients, only the best route for it.
Suppose,
1. RRC A and RRC B sends a route to the RR,
2. RR picks the route from RRC A, as the best, and sends it to RRC C.
3. RRC C might have an LSP to RRC B, and not to RRC A --> In this case, RRC C would have preferred the route
from RRC B, while it gets the route from RRC A, which results in loss of connectivity, when there is an alternate
path.
 
Rajesh
-----Original Message-----
From: Nagananda Anur [mailto:nanur@avici.com]
Sent: Monday, October 27, 2003 6:16 PM
To: Potti, Rajesh [BL60:SF40:EXCH]
Subject: RE: Route Reflector and VRFs

Rajesh,
 
One doesn't need to have VRF to reflect VPN routes.
You don't install MBGP routes into you FIB but you still reflect right - it's the same way.
 
It's the resposibility of PEs to make sure that LSP is been established before opening up for directing traffic. Also, RR may not be in VPN traffic forwarding path...hence it's not necessary to have VRFs to reflect.
 
Nagananda
-----Original Message-----
From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh Potti
Sent: Monday, October 27, 2003 4:56 PM
To: 'l3vpn@ietf.org'
Subject: Route Reflector and VRFs


Hi,

 Route Reflectors reflect routes only if it is inserted into the Forwarding Table.
  In that case, we need to have the VRFs activated, and routes inserted into the VRF,  before it can be advertised to the clients?

 Is an exception to this rule done, before reflecting vpnv4 routes?

Thanks,
Rajesh

------_=_NextPart_001_01C39CE3.BFAFBAE0-- From exim@www1.ietf.org Mon Oct 27 20:22:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02553 for ; Mon, 27 Oct 2003 20:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEIYe-0000Wx-Cc for l3vpn-archive@odin.ietf.org; Mon, 27 Oct 2003 20:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S1M4ld002034 for l3vpn-archive@odin.ietf.org; Mon, 27 Oct 2003 20:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEIYe-0000Wj-6R for l3vpn-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 20:22:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02547 for ; Mon, 27 Oct 2003 20:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEIYc-0003Xe-00 for l3vpn-web-archive@ietf.org; Mon, 27 Oct 2003 20:22:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEIYb-0003Xb-00 for l3vpn-web-archive@ietf.org; Mon, 27 Oct 2003 20:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEIYc-0000WA-1O; Mon, 27 Oct 2003 20:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEIYZ-0000VX-6Y for l3vpn@optimus.ietf.org; Mon, 27 Oct 2003 20:21:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02544 for ; Mon, 27 Oct 2003 20:21:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEIYX-0003XY-00 for l3vpn@ietf.org; Mon, 27 Oct 2003 20:21:57 -0500 Received: from web14101.mail.yahoo.com ([216.136.172.131]) by ietf-mx with smtp (Exim 4.12) id 1AEIYW-0003XU-00 for l3vpn@ietf.org; Mon, 27 Oct 2003 20:21:56 -0500 Message-ID: <20031028012156.189.qmail@web14101.mail.yahoo.com> Received: from [151.203.73.15] by web14101.mail.yahoo.com via HTTP; Mon, 27 Oct 2003 17:21:56 PST Date: Mon, 27 Oct 2003 17:21:56 -0800 (PST) From: PamSri Subject: RE: Route Reflector and VRFs To: Rajesh Potti , "'nanur@avici.com'" Cc: "'l3vpn@ietf.org'" In-Reply-To: <8B888AAAAB0FD31189590008C791844310DE9958@zbl6c002.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Rajesh, refer to the Route Reflector v/s Router Server email thread. ORFs are used to get the specific routes by the PE from the RR. According to 2547 a RR need'nt store the VRF info if it does'nt interface any VRF site. sri --- Rajesh Potti wrote: > Nagananda, > > For ipv4 routes, do Route Reflectors reflect routes > even if it is not > inserted into the FIB? RFC 2796 does not states > this explicitly. Since the nexthop is unaltered by > the RR, i think it would > be sufficient if the RR clients have inserted the > routes into its FIB. > > Since the RR selects the best route for reflecting, > from its view point, > this could result in suboptimality, as the RFC > points out. For vpnv4 routes, routes should be in > the FIB, as well as an LSP > should be established between the > clients. > > RR does not sound like a good way to handle this > case, since it only sends > the clients, only the best route for it. > Suppose, > 1. RRC A and RRC B sends a route to the RR, > 2. RR picks the route from RRC A, as the best, and > sends it to RRC C. > 3. RRC C might have an LSP to RRC B, and not to RRC > A --> In this case, RRC > C would have preferred the route > from RRC B, while it gets the route from RRC A, > which results in loss of > connectivity, when there is an alternate > path. > > Rajesh > > -----Original Message----- > From: Nagananda Anur [mailto:nanur@avici.com] > Sent: Monday, October 27, 2003 6:16 PM > To: Potti, Rajesh [BL60:SF40:EXCH] > Subject: RE: Route Reflector and VRFs > > > Rajesh, > > One doesn't need to have VRF to reflect VPN routes. > You don't install MBGP routes into you FIB but you > still reflect right - > it's the same way. > > It's the resposibility of PEs to make sure that LSP > is been established > before opening up for directing traffic. Also, RR > may not be in VPN traffic > forwarding path...hence it's not necessary to have > VRFs to reflect. > > Nagananda > > -----Original Message----- > From: l3vpn-admin@ietf.org > [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh > Potti > Sent: Monday, October 27, 2003 4:56 PM > To: 'l3vpn@ietf.org' > Subject: Route Reflector and VRFs > > > > > Hi, > > Route Reflectors reflect routes only if it is > inserted into the Forwarding > Table. > In that case, we need to have the VRFs activated, > and routes inserted into > the VRF, before it can be advertised to the > clients? > > Is an exception to this rule done, before > reflecting vpnv4 routes? > > Thanks, > Rajesh > > __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ From exim@www1.ietf.org Tue Oct 28 02:55:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05848 for ; Tue, 28 Oct 2003 02:55:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOh2-0002M2-AM for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 02:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S7t8WT009044 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 02:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOh1-0002Ll-MP for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 02:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05831 for ; Tue, 28 Oct 2003 02:54:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEOgx-0003zH-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 02:55:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEOgx-0003zE-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 02:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOgw-0002L3-Ch; Tue, 28 Oct 2003 02:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOgj-0002Hd-VL for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 02:54:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05791 for ; Tue, 28 Oct 2003 02:54:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEOgd-0003y9-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 02:54:43 -0500 Received: from law9-oe31.law9.hotmail.com ([64.4.8.88] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AEOgc-0003xW-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 02:54:42 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Oct 2003 23:54:12 -0800 Received: from 203.124.140.97 by law9-oe31.law9.hotmail.com with DAV; Tue, 28 Oct 2003 07:54:12 +0000 X-Originating-IP: [203.124.140.97] X-Originating-Email: [johnsmith0302@hotmail.com] From: "John Smith" To: "PamSri" , "Rajesh Potti" , Cc: References: <20031028012156.189.qmail@web14101.mail.yahoo.com> Subject: Re: Route Reflector and VRFs Date: Tue, 28 Oct 2003 13:21:36 +0530 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 Message-ID: X-OriginalArrivalTime: 28 Oct 2003 07:54:12.0613 (UTC) FILETIME=[AD2C7350:01C39D28] Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit just a clarification, 1. is there anything in the RFC which prevents from treating the RT:ipv4 and not RD:ipv4 as the bases of the decision making algorithim 2. even if #1 is there, is there anything in the RFC which prevents the following: filter routes based on RT, tag each route with an RD=RT, run BGP decision on the whole set of RD:ipv4 routes, put routes in RIBs_OUT tagged with their export target attributes etc, and strip RD before sending out the route? i believe both 1 and 2 are not possible based on the RFC, though it does say one can make RD=RT. please correct me if I am wrong. -Smith ----- Original Message ----- From: "PamSri" To: "Rajesh Potti" ; Cc: Sent: Tuesday, October 28, 2003 6:51 AM Subject: RE: Route Reflector and VRFs > Rajesh, refer to the Route Reflector v/s Router Server > email thread. ORFs are used to get the specific routes > by the PE from the RR. According to 2547 a RR need'nt > store the VRF info if it does'nt interface any VRF > site. > > sri > > --- Rajesh Potti wrote: > > Nagananda, > > > > For ipv4 routes, do Route Reflectors reflect routes > > even if it is not > > inserted into the FIB? RFC 2796 does not states > > this explicitly. Since the nexthop is unaltered by > > the RR, i think it would > > be sufficient if the RR clients have inserted the > > routes into its FIB. > > > > Since the RR selects the best route for reflecting, > > from its view point, > > this could result in suboptimality, as the RFC > > points out. For vpnv4 routes, routes should be in > > the FIB, as well as an LSP > > should be established between the > > clients. > > > > RR does not sound like a good way to handle this > > case, since it only sends > > the clients, only the best route for it. > > Suppose, > > 1. RRC A and RRC B sends a route to the RR, > > 2. RR picks the route from RRC A, as the best, and > > sends it to RRC C. > > 3. RRC C might have an LSP to RRC B, and not to RRC > > A --> In this case, RRC > > C would have preferred the route > > from RRC B, while it gets the route from RRC A, > > which results in loss of > > connectivity, when there is an alternate > > path. > > > > Rajesh > > > > -----Original Message----- > > From: Nagananda Anur [mailto:nanur@avici.com] > > Sent: Monday, October 27, 2003 6:16 PM > > To: Potti, Rajesh [BL60:SF40:EXCH] > > Subject: RE: Route Reflector and VRFs > > > > > > Rajesh, > > > > One doesn't need to have VRF to reflect VPN routes. > > You don't install MBGP routes into you FIB but you > > still reflect right - > > it's the same way. > > > > It's the resposibility of PEs to make sure that LSP > > is been established > > before opening up for directing traffic. Also, RR > > may not be in VPN traffic > > forwarding path...hence it's not necessary to have > > VRFs to reflect. > > > > Nagananda > > > > -----Original Message----- > > From: l3vpn-admin@ietf.org > > [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh > > Potti > > Sent: Monday, October 27, 2003 4:56 PM > > To: 'l3vpn@ietf.org' > > Subject: Route Reflector and VRFs > > > > > > > > > > Hi, > > > > Route Reflectors reflect routes only if it is > > inserted into the Forwarding > > Table. > > In that case, we need to have the VRFs activated, > > and routes inserted into > > the VRF, before it can be advertised to the > > clients? > > > > Is an exception to this rule done, before > > reflecting vpnv4 routes? > > > > Thanks, > > Rajesh > > > > > > > __________________________________ > Do you Yahoo!? > Exclusive Video Premiere - Britney Spears > http://launch.yahoo.com/promos/britneyspears/ > From exim@www1.ietf.org Tue Oct 28 02:57:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05981 for ; Tue, 28 Oct 2003 02:57:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOit-0002Xq-2J for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 02:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S7v34f009776 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 02:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOis-0002Xb-RZ for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 02:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05966 for ; Tue, 28 Oct 2003 02:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEOio-00042G-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 02:56:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEOio-00042D-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 02:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOir-0002WD-MA; Tue, 28 Oct 2003 02:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOiJ-0002Uf-CI for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 02:56:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05932 for ; Tue, 28 Oct 2003 02:56:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEOiF-00041W-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 02:56:23 -0500 Received: from bay0-hmr04.bay0.hotmail.com ([65.54.241.203] helo=BAY0-HMR04.adinternal.hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AEOiE-00040W-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 02:56:23 -0500 Received: from hotmail.com ([64.4.8.21]) by BAY0-HMR04.adinternal.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 27 Oct 2003 23:55:53 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Oct 2003 23:55:53 -0800 Received: from 203.124.140.97 by law9-oe49.law9.hotmail.com with DAV; Tue, 28 Oct 2003 07:55:53 +0000 X-Originating-IP: [203.124.140.97] X-Originating-Email: [johnsmith0302@hotmail.com] From: "John Smith" To: Date: Tue, 28 Oct 2003 13:23:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C39D56.A8681E90" 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 Message-ID: X-OriginalArrivalTime: 28 Oct 2003 07:55:53.0415 (UTC) FILETIME=[E9419D70:01C39D28] Subject: (no subject) Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C39D56.A8681E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe ------=_NextPart_000_0060_01C39D56.A8681E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe
------=_NextPart_000_0060_01C39D56.A8681E90-- From exim@www1.ietf.org Tue Oct 28 03:57:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10067 for ; Tue, 28 Oct 2003 03:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPf1-0007qu-3R for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 03:57:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S8v6no030178 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 03:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPf0-0007qd-LG for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 03:57:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09977 for ; Tue, 28 Oct 2003 03:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPex-0005dI-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 03:57:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEPex-0005dF-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 03:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPex-0007pu-5D; Tue, 28 Oct 2003 03:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPdz-0007dH-VW for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 03:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09936 for ; Tue, 28 Oct 2003 03:55:52 -0500 (EST) From: Juerg.Fankhauser@swisscom.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPdx-0005c1-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 03:56:01 -0500 Received: from outmail5.swisscom.com ([138.190.3.48] helo=sbe3777.swissptt.ch) by ietf-mx with esmtp (Exim 4.12) id 1AEPdw-0005bx-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 03:56:00 -0500 Received: from sxmcmp01.corproot.net (138.190.70.99) by sbe3778.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Tue, 28 Oct 2003 09:55:59 +0100 Received: from sxmbx01.corproot.net ([138.190.70.160]) by sxsmtp02.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Oct 2003 09:55:40 +0100 Received: from sxmbx04.corproot.net ([138.190.70.163]) by sxmbx01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Oct 2003 09:55:39 +0100 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: Route Reflector and VRFs Date: Tue, 28 Oct 2003 09:55:39 +0100 Message-ID: <026B34976F51A64A8D52114441599CA8016BD3EC@sxmbx04.corproot.net> Thread-Topic: Route Reflector and VRFs Thread-Index: AcOdKO21F2Ij5HQAR2WNkwCwqzybSgAB+JDg To: CC: X-OriginalArrivalTime: 28 Oct 2003 08:55:39.0770 (UTC) FILETIME=[42E3F5A0:01C39D31] Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi there, I'm not sure what you are trying to do, but as soon as you go beyond the = basic architectures you may have multiple RTs for one route (still = exactly one RD), and then neither #1 nor #2 make sense. Cheers, Juerg Fankhauser www.swisscom.com -----Original Message----- From: John Smith [mailto:johnsmith0302@hotmail.com]=20 Sent: Tuesday, October 28, 2003 8:52 AM To: PamSri; Rajesh Potti; nanur@avici.com Cc: l3vpn@ietf.org Subject: Re: Route Reflector and VRFs just a clarification, 1. is there anything in the RFC which prevents from treating the RT:ipv4 = and not RD:ipv4 as the bases of the decision making algorithim 2. even if #1 is there, is there anything in the RFC which prevents the following: filter routes based on RT, tag each route with an RD=3DRT, run BGP = decision on the whole set of RD:ipv4 routes, put routes in RIBs_OUT tagged with = their export target attributes etc, and strip RD before sending out the route? i believe both 1 and 2 are not possible based on the RFC, though it does = say one can make RD=3DRT. please correct me if I am wrong. -Smith ----- Original Message ----- From: "PamSri" To: "Rajesh Potti" ; Cc: Sent: Tuesday, October 28, 2003 6:51 AM Subject: RE: Route Reflector and VRFs > Rajesh, refer to the Route Reflector v/s Router Server > email thread. ORFs are used to get the specific routes > by the PE from the RR. According to 2547 a RR need'nt > store the VRF info if it does'nt interface any VRF > site. > > sri > > --- Rajesh Potti wrote: > > Nagananda, > > > > For ipv4 routes, do Route Reflectors reflect routes > > even if it is not > > inserted into the FIB? RFC 2796 does not states > > this explicitly. Since the nexthop is unaltered by > > the RR, i think it would > > be sufficient if the RR clients have inserted the > > routes into its FIB. > > > > Since the RR selects the best route for reflecting, > > from its view point, > > this could result in suboptimality, as the RFC > > points out. For vpnv4 routes, routes should be in > > the FIB, as well as an LSP > > should be established between the > > clients. > > > > RR does not sound like a good way to handle this > > case, since it only sends > > the clients, only the best route for it. > > Suppose, > > 1. RRC A and RRC B sends a route to the RR, > > 2. RR picks the route from RRC A, as the best, and > > sends it to RRC C. > > 3. RRC C might have an LSP to RRC B, and not to RRC > > A --> In this case, RRC > > C would have preferred the route > > from RRC B, while it gets the route from RRC A, > > which results in loss of > > connectivity, when there is an alternate > > path. > > > > Rajesh > > > > -----Original Message----- > > From: Nagananda Anur [mailto:nanur@avici.com] > > Sent: Monday, October 27, 2003 6:16 PM > > To: Potti, Rajesh [BL60:SF40:EXCH] > > Subject: RE: Route Reflector and VRFs > > > > > > Rajesh, > > > > One doesn't need to have VRF to reflect VPN routes. > > You don't install MBGP routes into you FIB but you > > still reflect right - > > it's the same way. > > > > It's the resposibility of PEs to make sure that LSP > > is been established > > before opening up for directing traffic. Also, RR > > may not be in VPN traffic > > forwarding path...hence it's not necessary to have > > VRFs to reflect. > > > > Nagananda > > > > -----Original Message----- > > From: l3vpn-admin@ietf.org > > [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh > > Potti > > Sent: Monday, October 27, 2003 4:56 PM > > To: 'l3vpn@ietf.org' > > Subject: Route Reflector and VRFs > > > > > > > > > > Hi, > > > > Route Reflectors reflect routes only if it is > > inserted into the Forwarding > > Table. > > In that case, we need to have the VRFs activated, > > and routes inserted into > > the VRF, before it can be advertised to the > > clients? > > > > Is an exception to this rule done, before > > reflecting vpnv4 routes? > > > > Thanks, > > Rajesh > > > > > > > __________________________________ > Do you Yahoo!? > Exclusive Video Premiere - Britney Spears > http://launch.yahoo.com/promos/britneyspears/ > From exim@www1.ietf.org Tue Oct 28 04:16:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11109 for ; Tue, 28 Oct 2003 04:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPxS-0001f2-CP for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 04:16:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9GAtL006378 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 04:16:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPxS-0001ee-5Q for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 04:16:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11088 for ; Tue, 28 Oct 2003 04:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPxN-00063J-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 04:16:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEPxN-00063G-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 04:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPxM-0001dj-PM; Tue, 28 Oct 2003 04:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPwu-0001bd-1c for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 04:15:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11070 for ; Tue, 28 Oct 2003 04:15:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPwr-00062t-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 04:15:33 -0500 Received: from law9-oe41.law9.hotmail.com ([64.4.8.98] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AEPwq-00062i-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 04:15:32 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 28 Oct 2003 01:14:59 -0800 Received: from 203.124.140.97 by law9-oe41.law9.hotmail.com with DAV; Tue, 28 Oct 2003 09:14:59 +0000 X-Originating-IP: [203.124.140.97] X-Originating-Email: [johnsmith0302@hotmail.com] From: "John Smith" To: Cc: References: <026B34976F51A64A8D52114441599CA8016BD3EC@sxmbx04.corproot.net> Subject: Re: Route Reflector and VRFs Date: Tue, 28 Oct 2003 14:42:27 +0530 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 Message-ID: X-OriginalArrivalTime: 28 Oct 2003 09:14:59.0934 (UTC) FILETIME=[F666EFE0:01C39D33] Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In that case, would they not be the same customer V4 route destined to different VPNs. so one could still say : #1 if there are multiple RTs, make multiple routes for the decision process: for (loop=1;loop<=count(RT);loop++) { newroute_for_decision(RT:prefix);/*makes a new route for decision in the incoming_routes_base*/ } and while trasmitting routes, sort for RT and send all routes with the same RT under one set of NLRI with the same attribute. #2. if there are multiple RTs, and one still wishes to use the RD, make multiple routes for the decision process: for (loop=1;loop<=count(RT);loop++) { RD=RT[loop]; newroute_for_decision(RD:prefix);/*makes a new route for decision in the incoming_routes_base*/ } Then run BGP decison process on the routes, and then strip the RD before propogation etc, and retain the attributes. eitherways, I believe that the next-hop may have to be the RR, but I was referring to a case where one may not want to make multiple VRFs or have multiple decision making instances. -Smith ----- Original Message ----- From: To: Cc: Sent: Tuesday, October 28, 2003 2:25 PM Subject: RE: Route Reflector and VRFs Hi there, I'm not sure what you are trying to do, but as soon as you go beyond the basic architectures you may have multiple RTs for one route (still exactly one RD), and then neither #1 nor #2 make sense. Cheers, Juerg Fankhauser www.swisscom.com -----Original Message----- From: John Smith [mailto:johnsmith0302@hotmail.com] Sent: Tuesday, October 28, 2003 8:52 AM To: PamSri; Rajesh Potti; nanur@avici.com Cc: l3vpn@ietf.org Subject: Re: Route Reflector and VRFs just a clarification, 1. is there anything in the RFC which prevents from treating the RT:ipv4 and not RD:ipv4 as the bases of the decision making algorithim 2. even if #1 is there, is there anything in the RFC which prevents the following: filter routes based on RT, tag each route with an RD=RT, run BGP decision on the whole set of RD:ipv4 routes, put routes in RIBs_OUT tagged with their export target attributes etc, and strip RD before sending out the route? i believe both 1 and 2 are not possible based on the RFC, though it does say one can make RD=RT. please correct me if I am wrong. -Smith ----- Original Message ----- From: "PamSri" To: "Rajesh Potti" ; Cc: Sent: Tuesday, October 28, 2003 6:51 AM Subject: RE: Route Reflector and VRFs > Rajesh, refer to the Route Reflector v/s Router Server > email thread. ORFs are used to get the specific routes > by the PE from the RR. According to 2547 a RR need'nt > store the VRF info if it does'nt interface any VRF > site. > > sri > > --- Rajesh Potti wrote: > > Nagananda, > > > > For ipv4 routes, do Route Reflectors reflect routes > > even if it is not > > inserted into the FIB? RFC 2796 does not states > > this explicitly. Since the nexthop is unaltered by > > the RR, i think it would > > be sufficient if the RR clients have inserted the > > routes into its FIB. > > > > Since the RR selects the best route for reflecting, > > from its view point, > > this could result in suboptimality, as the RFC > > points out. For vpnv4 routes, routes should be in > > the FIB, as well as an LSP > > should be established between the > > clients. > > > > RR does not sound like a good way to handle this > > case, since it only sends > > the clients, only the best route for it. > > Suppose, > > 1. RRC A and RRC B sends a route to the RR, > > 2. RR picks the route from RRC A, as the best, and > > sends it to RRC C. > > 3. RRC C might have an LSP to RRC B, and not to RRC > > A --> In this case, RRC > > C would have preferred the route > > from RRC B, while it gets the route from RRC A, > > which results in loss of > > connectivity, when there is an alternate > > path. > > > > Rajesh > > > > -----Original Message----- > > From: Nagananda Anur [mailto:nanur@avici.com] > > Sent: Monday, October 27, 2003 6:16 PM > > To: Potti, Rajesh [BL60:SF40:EXCH] > > Subject: RE: Route Reflector and VRFs > > > > > > Rajesh, > > > > One doesn't need to have VRF to reflect VPN routes. > > You don't install MBGP routes into you FIB but you > > still reflect right - > > it's the same way. > > > > It's the resposibility of PEs to make sure that LSP > > is been established > > before opening up for directing traffic. Also, RR > > may not be in VPN traffic > > forwarding path...hence it's not necessary to have > > VRFs to reflect. > > > > Nagananda > > > > -----Original Message----- > > From: l3vpn-admin@ietf.org > > [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh > > Potti > > Sent: Monday, October 27, 2003 4:56 PM > > To: 'l3vpn@ietf.org' > > Subject: Route Reflector and VRFs > > > > > > > > > > Hi, > > > > Route Reflectors reflect routes only if it is > > inserted into the Forwarding > > Table. > > In that case, we need to have the VRFs activated, > > and routes inserted into > > the VRF, before it can be advertised to the > > clients? > > > > Is an exception to this rule done, before > > reflecting vpnv4 routes? > > > > Thanks, > > Rajesh > > > > > > > __________________________________ > Do you Yahoo!? > Exclusive Video Premiere - Britney Spears > http://launch.yahoo.com/promos/britneyspears/ > From exim@www1.ietf.org Tue Oct 28 05:53:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15519 for ; Tue, 28 Oct 2003 05:53:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERTE-0002nN-5q for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 05:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SAr4pJ010739 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 05:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERTE-0002n8-1R for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 05:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15512 for ; Tue, 28 Oct 2003 05:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AERTA-0000Fx-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 05:53:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AERT9-0000Fu-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 05:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERTB-0002mN-FJ; Tue, 28 Oct 2003 05:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERSw-0002lk-Fl for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 05:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15496 for ; Tue, 28 Oct 2003 05:52:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AERSs-0000FF-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 05:52:42 -0500 Received: from law9-oe53.law9.hotmail.com ([64.4.8.46] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AERSs-0000DH-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 05:52:42 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 28 Oct 2003 02:51:16 -0800 Received: from 203.124.140.97 by law9-oe53.law9.hotmail.com with DAV; Tue, 28 Oct 2003 10:51:16 +0000 X-Originating-IP: [203.124.140.97] X-Originating-Email: [johnsmith0302@hotmail.com] From: "John Smith" To: "John Smith" , Cc: Subject: Re: Route Reflector and VRFs Date: Tue, 28 Oct 2003 16:18:43 +0530 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 Message-ID: X-OriginalArrivalTime: 28 Oct 2003 10:51:16.0819 (UTC) FILETIME=[69B1A230:01C39D41] Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, just a clarification, are you saying that we now transmit RT:v4 as the route? -thanks Alok ----- Original Message ----- From: "John Smith" To: Cc: Sent: Tuesday, October 28, 2003 2:42 PM Subject: Re: Route Reflector and VRFs > > In that case, would they not be the same customer V4 route destined to > different VPNs. > > so one could still say : > > #1 if there are multiple RTs, make multiple routes for the decision process: > for (loop=1;loop<=count(RT);loop++) > { > newroute_for_decision(RT:prefix);/*makes a new route for decision in the > incoming_routes_base*/ > } > > and while trasmitting routes, sort for RT and send all routes with the same > RT under one set of NLRI with the same attribute. > > > #2. if there are multiple RTs, and one still wishes to use the RD, make > multiple routes for the decision process: > for (loop=1;loop<=count(RT);loop++) > { > RD=RT[loop]; > newroute_for_decision(RD:prefix);/*makes a new route for decision in the > incoming_routes_base*/ > } > > Then run BGP decison process on the routes, and then strip the RD before > propogation etc, and retain the attributes. > > eitherways, I believe that the next-hop may have to be the RR, but I was > referring to a case where one may not want to make multiple VRFs or have > multiple decision making instances. > > -Smith > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, October 28, 2003 2:25 PM > Subject: RE: Route Reflector and VRFs > > > Hi there, > > I'm not sure what you are trying to do, but as soon as you go beyond the > basic architectures you may have multiple RTs for one route (still exactly > one RD), and then neither #1 nor #2 make sense. > > Cheers, > > Juerg Fankhauser > www.swisscom.com > > > > -----Original Message----- > From: John Smith [mailto:johnsmith0302@hotmail.com] > Sent: Tuesday, October 28, 2003 8:52 AM > To: PamSri; Rajesh Potti; nanur@avici.com > Cc: l3vpn@ietf.org > Subject: Re: Route Reflector and VRFs > > > just a clarification, > > 1. is there anything in the RFC which prevents from treating the RT:ipv4 and > not RD:ipv4 as the bases of the decision making algorithim > 2. even if #1 is there, is there anything in the RFC which prevents the > following: > filter routes based on RT, tag each route with an RD=RT, run BGP decision on > the whole set of RD:ipv4 routes, put routes in RIBs_OUT tagged with their > export target attributes etc, and strip RD before sending out the route? > > i believe both 1 and 2 are not possible based on the RFC, though it does say > one can make RD=RT. > > please correct me if I am wrong. > > -Smith > > > ----- Original Message ----- > From: "PamSri" > To: "Rajesh Potti" ; > Cc: > Sent: Tuesday, October 28, 2003 6:51 AM > Subject: RE: Route Reflector and VRFs > > > > Rajesh, refer to the Route Reflector v/s Router Server > > email thread. ORFs are used to get the specific routes > > by the PE from the RR. According to 2547 a RR need'nt > > store the VRF info if it does'nt interface any VRF > > site. > > > > sri > > > > --- Rajesh Potti wrote: > > > Nagananda, > > > > > > For ipv4 routes, do Route Reflectors reflect routes > > > even if it is not > > > inserted into the FIB? RFC 2796 does not states > > > this explicitly. Since the nexthop is unaltered by > > > the RR, i think it would > > > be sufficient if the RR clients have inserted the > > > routes into its FIB. > > > > > > Since the RR selects the best route for reflecting, > > > from its view point, > > > this could result in suboptimality, as the RFC > > > points out. For vpnv4 routes, routes should be in > > > the FIB, as well as an LSP > > > should be established between the > > > clients. > > > > > > RR does not sound like a good way to handle this > > > case, since it only sends > > > the clients, only the best route for it. > > > Suppose, > > > 1. RRC A and RRC B sends a route to the RR, > > > 2. RR picks the route from RRC A, as the best, and > > > sends it to RRC C. > > > 3. RRC C might have an LSP to RRC B, and not to RRC > > > A --> In this case, RRC > > > C would have preferred the route > > > from RRC B, while it gets the route from RRC A, > > > which results in loss of > > > connectivity, when there is an alternate > > > path. > > > > > > Rajesh > > > > > > -----Original Message----- > > > From: Nagananda Anur [mailto:nanur@avici.com] > > > Sent: Monday, October 27, 2003 6:16 PM > > > To: Potti, Rajesh [BL60:SF40:EXCH] > > > Subject: RE: Route Reflector and VRFs > > > > > > > > > Rajesh, > > > > > > One doesn't need to have VRF to reflect VPN routes. > > > You don't install MBGP routes into you FIB but you > > > still reflect right - > > > it's the same way. > > > > > > It's the resposibility of PEs to make sure that LSP > > > is been established > > > before opening up for directing traffic. Also, RR > > > may not be in VPN traffic > > > forwarding path...hence it's not necessary to have > > > VRFs to reflect. > > > > > > Nagananda > > > > > > -----Original Message----- > > > From: l3vpn-admin@ietf.org > > > [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh > > > Potti > > > Sent: Monday, October 27, 2003 4:56 PM > > > To: 'l3vpn@ietf.org' > > > Subject: Route Reflector and VRFs > > > > > > > > > > > > > > > Hi, > > > > > > Route Reflectors reflect routes only if it is > > > inserted into the Forwarding > > > Table. > > > In that case, we need to have the VRFs activated, > > > and routes inserted into > > > the VRF, before it can be advertised to the > > > clients? > > > > > > Is an exception to this rule done, before > > > reflecting vpnv4 routes? > > > > > > Thanks, > > > Rajesh > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Exclusive Video Premiere - Britney Spears > > http://launch.yahoo.com/promos/britneyspears/ > > > > From exim@www1.ietf.org Tue Oct 28 08:59:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20402 for ; Tue, 28 Oct 2003 08:59:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUND-0006km-6x for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 08:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SDx3r1025954 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 08:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUND-0006kU-1S for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 08:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20395 for ; Tue, 28 Oct 2003 08:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUNB-00033Y-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 08:59:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUNB-00033V-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 08:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUNB-0006jY-91; Tue, 28 Oct 2003 08:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUMf-0006gS-S5 for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 08:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20376 for ; Tue, 28 Oct 2003 08:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUMe-00033D-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 08:58:28 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AEUMd-000336-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 08:58:27 -0500 Received: from rcallon-lt.juniper.net (securepptp105.static.jnpr.net [172.24.253.105]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h9SDvsi27426; Tue, 28 Oct 2003 05:57:55 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20031028085202.02dd5eb8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 28 Oct 2003 08:57:53 -0500 To: l3vpn@ietf.org, ospf@peach.ease.lsoft.com From: Ross Callon Subject: last call draft-ietf-l3vpn-ospf-2547-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This begins the working group last call on: OSPF as the PE/CE Protocol in BGP/MPLS VPNs draft-ietf-l3vpn-ospf-2547-00.txt While this document is an l3vpn working group document, the last call will take place on both the l3vpn and ospf working group mailing lists. The last call will terminate at the end of the day on Friday November 14th. Thanks, Ross From exim@www1.ietf.org Tue Oct 28 09:56:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26776 for ; Tue, 28 Oct 2003 09:56:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVGO-0007yG-Uj for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 09:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEu4p9030634 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 09:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVGO-0007y1-QW for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26715 for ; Tue, 28 Oct 2003 09:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVGM-0004t7-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 09:56:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEVGM-0004t4-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 09:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVGM-0007wD-EI; Tue, 28 Oct 2003 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVGA-0007us-I7 for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 09:55:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26690 for ; Tue, 28 Oct 2003 09:55:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVG8-0004sM-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 09:55:48 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AEVG7-0004qQ-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 09:55:47 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9SEt2c03751; Tue, 28 Oct 2003 09:55:02 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VRKRAYQZ; Tue, 28 Oct 2003 09:55:00 -0500 Received: from nortelnetworks.com (potti.engeast.baynetworks.com [47.17.140.52]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VYDJKRH5; Tue, 28 Oct 2003 09:55:00 -0500 Message-ID: <3F9E8345.75C3FBB6@nortelnetworks.com> Date: Tue, 28 Oct 2003 09:55:01 -0500 From: Rajesh Potti Organization: Nortel Networks X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: "Rajesh Potti" , "'nanur@avici.com'" , "'l3vpn@ietf.org'" Subject: Re: Route Reflector and VRFs References: <20031028012156.189.qmail@web14101.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------056A90BF0F6583143D0C5EC6" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --------------056A90BF0F6583143D0C5EC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree VRFs need not be activated for RR to reflect the VRF routes. The question was :- Is this an exception to RFC 2796 on RRs? Or does Route Reflectors generally reflect routes, even if they are not inserted into the FIB? Rajesh PamSri wrote: > Rajesh, refer to the Route Reflector v/s Router Server > email thread. ORFs are used to get the specific routes > by the PE from the RR. According to 2547 a RR need'nt > store the VRF info if it does'nt interface any VRF > site. > > sri > > --- Rajesh Potti wrote: > > Nagananda, > > > > For ipv4 routes, do Route Reflectors reflect routes > > even if it is not > > inserted into the FIB? RFC 2796 does not states > > this explicitly. Since the nexthop is unaltered by > > the RR, i think it would > > be sufficient if the RR clients have inserted the > > routes into its FIB. > > > > Since the RR selects the best route for reflecting, > > from its view point, > > this could result in suboptimality, as the RFC > > points out. For vpnv4 routes, routes should be in > > the FIB, as well as an LSP > > should be established between the > > clients. > > > > RR does not sound like a good way to handle this > > case, since it only sends > > the clients, only the best route for it. > > Suppose, > > 1. RRC A and RRC B sends a route to the RR, > > 2. RR picks the route from RRC A, as the best, and > > sends it to RRC C. > > 3. RRC C might have an LSP to RRC B, and not to RRC > > A --> In this case, RRC > > C would have preferred the route > > from RRC B, while it gets the route from RRC A, > > which results in loss of > > connectivity, when there is an alternate > > path. > > > > Rajesh > > > > -----Original Message----- > > From: Nagananda Anur [mailto:nanur@avici.com] > > Sent: Monday, October 27, 2003 6:16 PM > > To: Potti, Rajesh [BL60:SF40:EXCH] > > Subject: RE: Route Reflector and VRFs > > > > > > Rajesh, > > > > One doesn't need to have VRF to reflect VPN routes. > > You don't install MBGP routes into you FIB but you > > still reflect right - > > it's the same way. > > > > It's the resposibility of PEs to make sure that LSP > > is been established > > before opening up for directing traffic. Also, RR > > may not be in VPN traffic > > forwarding path...hence it's not necessary to have > > VRFs to reflect. > > > > Nagananda > > > > -----Original Message----- > > From: l3vpn-admin@ietf.org > > [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh > > Potti > > Sent: Monday, October 27, 2003 4:56 PM > > To: 'l3vpn@ietf.org' > > Subject: Route Reflector and VRFs > > > > > > > > > > Hi, > > > > Route Reflectors reflect routes only if it is > > inserted into the Forwarding > > Table. > > In that case, we need to have the VRFs activated, > > and routes inserted into > > the VRF, before it can be advertised to the > > clients? > > > > Is an exception to this rule done, before > > reflecting vpnv4 routes? > > > > Thanks, > > Rajesh > > > > > > __________________________________ > Do you Yahoo!? > Exclusive Video Premiere - Britney Spears > http://launch.yahoo.com/promos/britneyspears/ -- Rajesh Potti. --------------056A90BF0F6583143D0C5EC6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I agree VRFs need not be activated for RR to reflect the VRF routes.
 The question was :- Is this an exception to RFC 2796 on RRs?  Or does Route Reflectors generally
 reflect routes, even if they are not inserted into the FIB?

Rajesh

PamSri wrote:

Rajesh, refer to the Route Reflector v/s Router Server
email thread. ORFs are used to get the specific routes
by the PE from the RR. According to 2547 a RR need'nt
store the VRF info if it does'nt interface any VRF
site.

sri

--- Rajesh Potti <rpotti@nortelnetworks.com> wrote:
> Nagananda,
>
>  For ipv4 routes, do Route Reflectors reflect routes
> even if it is not
> inserted into the FIB? RFC 2796 does not states
>  this explicitly. Since the nexthop is unaltered by
> the RR, i think it would
> be sufficient if the RR clients have inserted the
>  routes into its FIB.
>
> Since the RR selects the best route for reflecting,
> from its view point,
> this could result in suboptimality, as the RFC
> points out. For vpnv4 routes, routes should be in
> the FIB, as well as an LSP
> should be established between the
> clients.
>
> RR does not sound like a good way to handle this
> case, since it only sends
> the clients, only the best route for it.
> Suppose,
> 1. RRC A and RRC B sends a route to the RR,
> 2. RR picks the route from RRC A, as the best, and
> sends it to RRC C.
> 3. RRC C might have an LSP to RRC B, and not to RRC
> A --> In this case, RRC
> C would have preferred the route
> from RRC B, while it gets the route from RRC A,
> which results in loss of
> connectivity, when there is an alternate
> path.
>
> Rajesh
>
> -----Original Message-----
> From: Nagananda Anur [mailto:nanur@avici.com]
> Sent: Monday, October 27, 2003 6:16 PM
> To: Potti, Rajesh [BL60:SF40:EXCH]
> Subject: RE: Route Reflector and VRFs
>
>
> Rajesh,
>
> One doesn't need to have VRF to reflect VPN routes.
> You don't install MBGP routes into you FIB but you
> still reflect right -
> it's the same way.
>
> It's the resposibility of PEs to make sure that LSP
> is been established
> before opening up for directing traffic. Also, RR
> may not be in VPN traffic
> forwarding path...hence it's not necessary to have
> VRFs to reflect.
>
> Nagananda
>
> -----Original Message-----
> From: l3vpn-admin@ietf.org
> [mailto:l3vpn-admin@ietf.org]On Behalf Of Rajesh
> Potti
> Sent: Monday, October 27, 2003 4:56 PM
> To: 'l3vpn@ietf.org'
> Subject: Route Reflector and VRFs
>
>
>
>
> Hi,
>
>  Route Reflectors reflect routes only if it is
> inserted into the Forwarding
> Table.
>   In that case, we need to have the VRFs activated,
> and routes inserted into
> the VRF,  before it can be advertised to the
> clients?
>
>  Is an exception to this rule done, before
> reflecting vpnv4 routes?
>
> Thanks,
> Rajesh
>
>

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

-- 
Rajesh Potti.
  --------------056A90BF0F6583143D0C5EC6-- From exim@www1.ietf.org Tue Oct 28 14:36:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18543 for ; Tue, 28 Oct 2003 14:36:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZdN-0006aL-FV for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 14:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJa5Gi025307 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 14:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZdN-0006a6-9t for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 14:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18525 for ; Tue, 28 Oct 2003 14:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZdK-00056p-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 14:36:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEZdK-00056m-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 14:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZdJ-0006Z7-QB; Tue, 28 Oct 2003 14:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEZdH-0006Yj-PT for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 14:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18522 for ; Tue, 28 Oct 2003 14:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZdE-00056i-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 14:35:56 -0500 Received: from web14101.mail.yahoo.com ([216.136.172.131]) by ietf-mx with smtp (Exim 4.12) id 1AEZdE-00056f-00 for l3vpn@ietf.org; Tue, 28 Oct 2003 14:35:56 -0500 Message-ID: <20031028193552.21926.qmail@web14101.mail.yahoo.com> Received: from [47.234.0.51] by web14101.mail.yahoo.com via HTTP; Tue, 28 Oct 2003 11:35:52 PST Date: Tue, 28 Oct 2003 11:35:52 -0800 (PST) From: PamSri Subject: Re: Route Reflector and VRFs To: Rajesh Potti Cc: Rajesh Potti , "'nanur@avici.com'" , "'l3vpn@ietf.org'" In-Reply-To: <3F9E8345.75C3FBB6@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Rajesh Potti wrote: > > I agree VRFs need not be activated for RR to reflect > the VRF routes. > The question was :- Is this an exception to RFC > 2796 on RRs? Or does > Route Reflectors generally > reflect routes, even if they are not inserted into > the FIB? Yes. From a VRF residing on a ingress LER's perspective the egress LER for the LSP is the p2p interface and the RR does'nt do a VRF route forwarding. The only thing that RR would do is a transport label switching. sri __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ From exim@www1.ietf.org Tue Oct 28 15:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25194 for ; Tue, 28 Oct 2003 15:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagI-0000DJ-Ma for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 15:43:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKhAg3000814 for l3vpn-archive@odin.ietf.org; Tue, 28 Oct 2003 15:43:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagI-0000D3-Ix for l3vpn-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:43:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25078 for ; Tue, 28 Oct 2003 15:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEagH-0006fD-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 15:43:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEagG-0006fA-00 for l3vpn-web-archive@ietf.org; Tue, 28 Oct 2003 15:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagA-00005b-OU; Tue, 28 Oct 2003 15:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEafi-0008TG-No for l3vpn@optimus.ietf.org; Tue, 28 Oct 2003 15:42:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24963; Tue, 28 Oct 2003 15:42:23 -0500 (EST) Message-Id: <200310282042.PAA24963@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-ce-based-01.txt Date: Tue, 28 Oct 2003 15:42:22 -0500 Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec Author(s) : J. De Clercq Filename : draft-ietf-l3vpn-ce-based-01.txt Pages : 26 Date : 2003-10-28 This document describes the procedures for a Service Provider to offer Virtual Private Network Services to its customers by provisioning the CE devices on behalf of the customer. The IPsec technology is used to protect the customer traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ce-based-01.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-l3vpn-ce-based-01.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-l3vpn-ce-based-01.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-10-28155552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-ce-based-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-ce-based-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155552.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Oct 29 15:43:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05095 for ; Wed, 29 Oct 2003 15:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx9k-00021Y-Jr for l3vpn-archive@odin.ietf.org; Wed, 29 Oct 2003 15:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TKh4no007774 for l3vpn-archive@odin.ietf.org; Wed, 29 Oct 2003 15:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx9k-00021H-EP for l3vpn-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 15:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05078 for ; Wed, 29 Oct 2003 15:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEx9j-0002xx-00 for l3vpn-web-archive@ietf.org; Wed, 29 Oct 2003 15:43:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEx9i-0002xp-00 for l3vpn-web-archive@ietf.org; Wed, 29 Oct 2003 15:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx9h-0001zv-EI; Wed, 29 Oct 2003 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx8w-0001xi-Mg for l3vpn@optimus.ietf.org; Wed, 29 Oct 2003 15:42:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05052 for ; Wed, 29 Oct 2003 15:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEx8u-0002x8-00 for l3vpn@ietf.org; Wed, 29 Oct 2003 15:42:12 -0500 Received: from smtp015.mail.yahoo.com ([216.136.173.59]) by ietf-mx with smtp (Exim 4.12) id 1AEx8u-0002x0-00 for l3vpn@ietf.org; Wed, 29 Oct 2003 15:42:12 -0500 Received: from adsl-63-206-88-169.dsl.snfc21.pacbell.net (HELO METANOIA) (vsharma87@63.206.88.169 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Oct 2003 20:42:11 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" , "MPLS" , "L2PPVPN" , "L3PPVPN" , "PWE3" , Cc: "Monique J. Morrow" , "Tom Nadeau" Subject: Update: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Date: Wed, 29 Oct 2003 12:39:42 -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.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, The deadline for this FT issue is fast approaching, and this is for those who may have either missed the earlier announcements or have been in "thinking about it" mode. :-) We really appreciate the interest the issue has received, and are excited to have already received titles and abstracts from several contributors. If you have been thinking about contributing, please send us, the title and abstract for your contribution at the earliest. The thoughts and insights of the community are what make the issues such as this valuable, and so far we seem to be making very good progress on that front. Again, thanks to those who are already contributing, and we look forward to additional participation! Regards, -Vishal, Monique, Tom PS: The submission process is automated and very easy. Pl. check instructions below. ==================================================================== CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "OAM in MPLS-Based Networks" ********************************************** As carriers and service providers converge multiple services and associated networks on to an MPLS-based infrastructure, OAM functionality becomes pivotal for enabling them to provide service level agreement (SLA) guarantees, service assurance, quality of service (QoS) assurance and overall interworking service management. The advent of new applications of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs) also means the emergence of added OAM requirements from operators deploying those networks. As a result, providers today require more efficient means of monitoring network health, performance, and robustness, and of quickly identifying and resolving performance problems. This is leading to the emergence of improved or novel tools and techniques, whose goal is to improve security and billing/accounting, aid in verifying QoS commitments, and reduce operating costs. Standards organizations such as the IETF and the ITU have in the recent past done significant work in this area, and this subject is also being investigated by the IEEE and the Metro Ethernet Forum. This feature topic issue of the IEEE Communications Magazine has a dual focus: to highlight operator requirements and deployment experiences with OAM in MPLS-based networks, and to present a survey of the current engineering and research developments in this area. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but not limited to) the following: * Operational consequences of inadequate OAM capabilities * Service provider requirements for efficient OAM - current operational needs and future demands * Deployment experiences with OAM over MPLS-based networks * Overview or comparative analysis of different approaches/philosophies for OAM * Standards activities o Emerging architectures o New mechanisms for OAM in development (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit connection verification (VCCV)) * Platform support for OAM * OAM impact on edge services (such as metro Ethernet) using MPLS transport * Interoperability issues, interworking with other technologies (e.g. ATM) * Review of current research in the area - E.g. setting parameters for connectivity verification and their impact on LSP recovery, trade-offs between bandwidth usage by OAM traffic and efficiency of failure/anomaly detection, and results from testbed deployments or simulations On-line CFP with submission instructions can be found at: http://www.comsoc.org/pubs/commag/cfpcommag1004.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at: http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no later than November 30, 2003. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Schedule: Manuscript Due: November 30, 2003 Acceptance Notification: February 28, 2004 Final Manuscript Due: April 15, 2004 Publication Date: October 2004 Guest Editors: Monique J. Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Tom Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824, USA. Email: tnadeau@cisco.com Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA. Email: v.sharma@ieee.org About the IEEE Communications Magazine: The IEEE Comm. Mag. is the official technical publication of conferences such as Supercomm, and has the unique distinction of being the most widely read IEEE journal, with its over 50,000 paid subscribers representing key communications engineers and technical managers in our industry. More information on the IEEE Comm. Mag., may be found here: www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt From exim@www1.ietf.org Thu Oct 30 15:22:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09700 for ; Thu, 30 Oct 2003 15:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJIx-00078Z-9D for l3vpn-archive@odin.ietf.org; Thu, 30 Oct 2003 15:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UKM3ra027432 for l3vpn-archive@odin.ietf.org; Thu, 30 Oct 2003 15:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJIx-00078N-18 for l3vpn-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 15:22:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09683 for ; Thu, 30 Oct 2003 15:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJIv-0001Xb-00 for l3vpn-web-archive@ietf.org; Thu, 30 Oct 2003 15:22:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFJIv-0001XY-00 for l3vpn-web-archive@ietf.org; Thu, 30 Oct 2003 15:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJIu-00077V-LG; Thu, 30 Oct 2003 15:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFI6u-0005zH-Ku for l3vpn@optimus.ietf.org; Thu, 30 Oct 2003 14:05:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05125 for ; Thu, 30 Oct 2003 14:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFI6s-0000HT-00 for l3vpn@ietf.org; Thu, 30 Oct 2003 14:05:30 -0500 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 1AFI6r-0000HG-00 for l3vpn@ietf.org; Thu, 30 Oct 2003 14:05:29 -0500 Received: (qmail 24341 invoked by uid 404); 30 Oct 2003 19:04:59 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.594589 secs); 30 Oct 2003 19:04:59 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 30 Oct 2003 19:04:58 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id OAA27687; Thu, 30 Oct 2003 14:04:57 -0500 Message-Id: <200310301904.OAA27687@bigbird.nj.us.utstar.com> To: l3vpn@ietf.org cc: rohit@utstar.com Subject: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt Date: Thu, 30 Oct 2003 14:04:57 -0500 From: Rohit Dube Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This a joint OSPF and L3VPN WG last call for draft-ietf-ospf-2547-dnbit-01.txt Details below, --rohit. (OSPF WG Co-chair) ------- Forwarded Message Date: Tue, 28 Oct 2003 20:31:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Working Group Last Call for draft-ietf-ospf-2547-dnbit-01.txt to both lists Comments: cc: ronald.p.bonica@mci.com, rick@rhwilder.net, rcallon@juniper.net, erosen@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM This is the start of a Working Group last call for "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs" (draft-ietf-ospf-2547-dnbit-01.txt) All comments should be received by 5PM (US Eastern), 11/21/2003. Please send your comments to the OSPF list. The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ospf-2547-dnbit-01.txt This is a companion document to draft-ietf-l3vpn-ospf-2547-00.txt which is also in Last Call. Both of these documents are being Last Called in OSPF WG as well as the L3VPN WG. --rohit. ------- End of Forwarded Message