From l3vpn-bounces@ietf.org Mon Jan 3 15:00:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04313 for ; Mon, 3 Jan 2005 15:00:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClYa5-0005Pk-Ho for l3vpn-web-archive@ietf.org; Mon, 03 Jan 2005 15:13:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClYMj-0004WO-UM; Mon, 03 Jan 2005 14:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClYKS-0003Da-GC for l3vpn@megatron.ietf.org; Mon, 03 Jan 2005 14:57:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04106 for ; Mon, 3 Jan 2005 14:57:22 -0500 (EST) Received: from mailgate1b.savvis.net ([216.91.182.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClYWf-0005Lx-IY for l3vpn@ietf.org; Mon, 03 Jan 2005 15:10:02 -0500 Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (8.12.10/8.12.1) with ESMTP id j03JvKwn010210; Mon, 3 Jan 2005 13:57:20 -0600 Received: from s228130hz1ew08.apptix-01.savvis.net ([10.146.4.8]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jan 2005 13:57:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2005 13:57:07 -0600 Message-ID: Thread-Topic: draft-ietf-l3vpn-vr-mib-03.txt Thread-Index: AcTiKxggm0W2oQHARwCAlLFu7NyK1gKwOvPAATM35QA= From: "Schliesser, Benson" To: "Ronald Bonica" , "Joseph Laria" , X-OriginalArrivalTime: 03 Jan 2005 19:57:09.0801 (UTC) FILETIME=[68DBD190:01C4F1CE] X-ECS-MailScanner: No virus is found X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-vr-mib-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Ron- Thanks for these comments/questions. I hope the other contributors will comment with any of their own thoughts, but here are mine. > 1) The draft is based upon the premise that a single SNMP=20 > agent should represent every virtual router on a physical=20 > router. An alternative approach would be to deploy a separate=20 > SNMP agent for each virtual router. Have you explored that=20 > option? If so, why did you reject it? Had you chosen that=20 > option, would a vr-mib be required at all? >=20 > (I honestly don't know which alternative is better. I'm just=20 > checking to see that the alternative was explored.) Creating multiple agents for use by the administrator (SP) could be done, for instance by binding to different ports or addresses on the P-node. But from a resource perspective, it is more efficient to use a single agent and multiplex based on the community/context as described in the draft. In either case, though, a VR-MIB is needed to map each VR to its respective agent or context. There is one case that I'd like to point out, where a separate agent per VR is useful, though not as a replacement for the VR-MIB. If the platform supports instantiation of an agent *within* the VR then the VPN user could query stats, etc., from that agent. This isn't a replacement for the VR-MIB because (in addition to the above points) the SP may very well not have reachability/connectivity (not to mention uniqueness in addressing) into the VPN. I.e., the SP may not have management-network access to the customers' networks. > 2) The vr-mib goes to some length the support configuration=20 > using SNMP. > Other MIBs tend to be for monitoring purposes, with an=20 > occasional read-write variable. Do you see this MIB being=20 > used much for configuration? I, speaking as one SP, intend to use it only for monitoring. This is largely because I have other mechanisms available for configuration of my platforms, such as Corba or XML interfaces, that I find more valuable for this function. However, I see value in having configuration capabilities in the MIB. The VR-MIB fills in a gap, allowing for creation of the VR, while the VR context MIBs allow for configuration of the VR itself. This might prove useful, perhaps even allowing for interoperable management tools. Is there perhaps a precedent for better stating the requirement levels such that configuration functionality is not a MUST? This might satisfy both perspectives. > 3) The document has a few formatting problems (e.g., section=20 > numbering). > Please see http://www.ietf.org/ID-Checklist.html We'll clean things up. We should also include some text relating to the above discussion. Thanks, -Benson From WSNFBBYEXNNGR@yahoo.com Wed Jan 5 06:35:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23836; Wed, 5 Jan 2005 06:35:04 -0500 (EST) Received: from roc-69-202-144-6.rochester.rr.com ([69.202.144.6]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cm9do-0001av-10; Wed, 05 Jan 2005 06:48:04 -0500 Received: from [20.80.106.212] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 675LFL-0048PT-89 Message-ID: <57920093144732.R37431@.noc..gr> Sender: freeradius-devel-WSNFBBYEXNNGR@yahoo.com X-Mailman-Version: 2.0.1 Date: Wed, 05 Jan 2005 16:25:12 +0500 From: "Marva Sullivan" To: l2tpext@ietf.org Subject: House of Viicodin L2tpext X-Spam-Score: 2.7 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year OzVERTwZZqrZNyVck0x1VibAZppyrp From l3vpn-bounces@ietf.org Thu Jan 6 06:52:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00897 for ; Thu, 6 Jan 2005 06:52:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmWON-0003WP-Ua for l3vpn-web-archive@ietf.org; Thu, 06 Jan 2005 07:05:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmW5R-0001BC-QU; Thu, 06 Jan 2005 06:45:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmW1v-0000Qu-Kr for l3vpn@megatron.ietf.org; Thu, 06 Jan 2005 06:42:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00258 for ; Thu, 6 Jan 2005 06:42:12 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmWEe-0007fK-4h for l3vpn@ietf.org; Thu, 06 Jan 2005 06:55:27 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j06Bfdc7008724 for ; Thu, 6 Jan 2005 05:41:39 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 12:41:38 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155061B6883@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Schliesser, Benson" , Ronald Bonica , Joseph Laria , l3vpn@ietf.org Date: Thu, 6 Jan 2005 12:41:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: RE: draft-ietf-l3vpn-vr-mib-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 W.r.t. > > > 2) The vr-mib goes to some length the support configuration > > using SNMP. > > Other MIBs tend to be for monitoring purposes, with an > > occasional read-write variable. Do you see this MIB being > > used much for configuration? > > I, speaking as one SP, intend to use it only for monitoring. This is > largely because I have other mechanisms available for configuration of > my platforms, such as Corba or XML interfaces, that I find > more valuable > for this function. > > However, I see value in having configuration capabilities in the MIB. > The VR-MIB fills in a gap, allowing for creation of the VR, while the VR > context MIBs allow for configuration of the VR itself. This might prove > useful, perhaps even allowing for interoperable management tools. > > Is there perhaps a precedent for better stating the requirement levels > such that configuration functionality is not a MUST? This might satisfy > both perspectives. > I have been advising/suggesting to people to define 2 MODULE-COMPLIANCE statement, one for monitoring and one for (what I call) FULL compliance (so that includes configuration). A good example is the MODULE-COMPLIANCE statements in RFC3289. See also section 4.8 of draft-ietf-ops-mib-review-guidelines-03.txt Hope this helps, Bert From l3vpn-bounces@ietf.org Mon Jan 10 16:32:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02433 for ; Mon, 10 Jan 2005 16:32:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co7NH-0002SX-HR for l3vpn-web-archive@ietf.org; Mon, 10 Jan 2005 16:46:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co6YH-0006mB-3v; Mon, 10 Jan 2005 15:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co6UQ-0004eM-FO; Mon, 10 Jan 2005 15:50:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23662; Mon, 10 Jan 2005 15:50:12 -0500 (EST) Message-Id: <200501102050.PAA23662@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 10 Jan 2005 15:50:12 -0500 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-l3vpn-auth-01.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --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 : CE-to-CE Member Verification for Layer 3 VPNs Author(s) : R. Bonica, et al. Filename : draft-ietf-l3vpn-l3vpn-auth-01.txt Pages : 16 Date : 2005-1-10 This document describes a CE-based verification mechanism that VPN customers can use to detect security breaches caused by misconfiguration of the provider network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-l3vpn-auth-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-l3vpn-auth-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-l3vpn-auth-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: <2005-1-10153247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-l3vpn-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-l3vpn-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-10153247.I-D@ietf.org> --OtherAccess-- --NextPart-- From ALHDMFZNYGJZY@hotmail.com Wed Jan 12 02:08:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22508; Wed, 12 Jan 2005 02:08:10 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cocpp-00058X-NB; Wed, 12 Jan 2005 02:22:35 -0500 Received: from pool-68-239-152-94.nwrk.east.verizon.net ([68.239.152.94]) by mx2.foretec.com with smtp (Exim 4.24) id 1CocbS-0002q9-5R; Wed, 12 Jan 2005 02:07:39 -0500 Received: from [240.89.192.134] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 911LFL-0084PT-65 Message-ID: <17949683144732.R37404@.noc..gr> Sender: freeradius-devel-ALHDMFZNYGJZY@hotmail.com X-Mailman-Version: 2.0.1 Date: Wed, 12 Jan 2005 10:07:01 +0300 From: "Deirdre Broussard" To: l2vpn-admin@ietf.org Cc: l2vpn-web-archive@ietf.org, l3vpn@ietf.org, l3vpn-admin@ietf.org, l3vpn-web-archive@ietf.org, ldap-dir@ietf.org, ldap-dir-admin@ietf.org, ldap-dir-web-archive@ietf.org, ldapext@ietf.org, ldapext-admin@ietf.org, ldapext-archive@ietf.org, lemonade@ietf.org Subject: Everyone Need This L2vpn-admin X-Spam-Score: 3.5 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year HlBZQ8uT8Apuv0MjdtmQmWLdCficdiIqVJEPywSQgT6b From l3vpn-bounces@ietf.org Fri Jan 14 07:47:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04467 for ; Fri, 14 Jan 2005 07:47:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpR6M-0001Fr-FV for l3vpn-web-archive@ietf.org; Fri, 14 Jan 2005 08:02:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpQq7-0006DY-WC; Fri, 14 Jan 2005 07:46:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpQkg-0005Gr-Bk for l3vpn@megatron.ietf.org; Fri, 14 Jan 2005 07:40:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03430 for ; Fri, 14 Jan 2005 07:40:29 -0500 (EST) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpQz5-0000pq-TB for l3vpn@ietf.org; Fri, 14 Jan 2005 07:55:25 -0500 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for l3vpn@ietf.org; Fri, 14 Jan 2005 13:39:51 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jan 2005 13:39:51 +0100 Message-Id: From: "Leymann, Nicolai" To: l3vpn@ietf.org Date: Fri, 14 Jan 2005 13:39:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: TTL Handling in draft-rosen / mVPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Dear all, according to draft-rosen-vpn-mcast-07.txt the following applies to the TTL values when a payload packet is encapsulated. "The ingress PE should not copy the TTL field from the payload IP header received from a CE router to the delivery IP header. The setting the TTL of the deliver IP header is determined by the local policy of the ingress PE router." So it's up to the implementation of the ingress PE which TTL value is used. How is this handled in existing implementations? Is there a commonly used TTL-Value (like 255) and/or is this value configurable? best regards Nic -- Nicolai Leymann EMail: nicolai.leymann@t-systems.com T-Systems System Integration, Berlin Tel/Fax: ++49-30-3497-3570/-3571 Abteilung ET52 Mobil: ++49-170-2275345 Senior Experte IP-Technologien Goslarer Ufer 35, 10589 Berlin, Germany From l3vpn-bounces@ietf.org Fri Jan 14 11:16:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24852 for ; Fri, 14 Jan 2005 11:16:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpULp-0006Fa-W4 for l3vpn-web-archive@ietf.org; Fri, 14 Jan 2005 11:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpU0I-0006UC-9U; Fri, 14 Jan 2005 11:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpTvB-0005Qg-9W for l3vpn@megatron.ietf.org; Fri, 14 Jan 2005 11:03:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24258 for ; Fri, 14 Jan 2005 11:03:31 -0500 (EST) From: jeremy.de_clercq@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpU9c-00062F-Ux for l3vpn@ietf.org; Fri, 14 Jan 2005 11:18:30 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j0EG3SG8015284; Fri, 14 Jan 2005 17:03:28 +0100 Received: from alcatel.be ([138.203.67.106]) by bemail04.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2005011417032688:6116 ; Fri, 14 Jan 2005 17:03:26 +0100 Message-ID: <41E7ED4C.2000204@alcatel.be> Date: Fri, 14 Jan 2005 17:03:24 +0100 Organization: Alcatel User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/14/2005 17:03:26, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/14/2005 17:03:28, Serialize complete at 01/14/2005 17:03:28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ross callon , Francois Le Faucheur , rick@rhwilder.net Subject: draft-ietf-l3vpn-bgp-ipv6-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi, we just posted draft-ietf-l3vpn-bgp-ipv6-04.txt (it will appear in the directory any time soon). The changes that we incorporated since the previous version are the following: - the draft now explicitly mentions that inter-working between an IPv4 site and an IPv6 site is out if its scope, as was agreed during the last IETF meeting. - a paragraph was added to allow the use of unique local addresses (inline with draft-ietf-ipv6-unique-local-addr) - extended the inter-AS section. It is now inline with 2547bis. - added a small section on carriers' carrier vpn (referring to 2547bis) - added an IANA considerations section We now believe that the document is ready for working group last call. Jeremy. From l3vpn-bounces@ietf.org Fri Jan 14 16:13:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20175 for ; Fri, 14 Jan 2005 16:13:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZ07-0005bo-UR for l3vpn-web-archive@ietf.org; Fri, 14 Jan 2005 16:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpYGE-0002Lz-Eo; Fri, 14 Jan 2005 15:41:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpY8H-00045m-4u; Fri, 14 Jan 2005 15:33:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14387; Fri, 14 Jan 2005 15:33:19 -0500 (EST) Message-Id: <200501142033.PAA14387@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 14 Jan 2005 15:33:19 -0500 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --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 : BGP-MPLS VPN extension for IPv6 VPN Author(s) : J. De Clercq, et al. Filename : draft-ietf-l3vpn-bgp-ipv6-04.txt Pages : 17 Date : 2005-1-14 This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method [2547bis] for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP". This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunnelling techniques over the core including MPLS, IP-in-IP, GRE and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-bgp-ipv6-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-bgp-ipv6-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-14153317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgp-ipv6-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgp-ipv6-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-14153317.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Jan 14 21:54:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19467 for ; Fri, 14 Jan 2005 21:54:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpeJn-0005l7-Ap for l3vpn-web-archive@ietf.org; Fri, 14 Jan 2005 22:09:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cpe0a-0001I2-JP; Fri, 14 Jan 2005 21:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpdtA-0007Uz-Mf for l3vpn@megatron.ietf.org; Fri, 14 Jan 2005 21:42:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18639 for ; Fri, 14 Jan 2005 21:42:06 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cpe7h-0005Rg-W1 for l3vpn@ietf.org; Fri, 14 Jan 2005 21:57:11 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Jan 2005 19:48:17 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0F2fVvl021339; Fri, 14 Jan 2005 18:41:31 -0800 (PST) Received: (from ycai@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA21540; Fri, 14 Jan 2005 18:41:33 -0800 (PST) Date: Fri, 14 Jan 2005 18:41:33 -0800 (PST) Message-Id: <200501150241.SAA21540@cisco.com> X-Authentication-Warning: cypher.cisco.com: ycai set sender to ycai@cypher.cisco.com using -f From: Yiqun Cai To: Nicolai.Leymann@t-systems.com In-reply-to: (Nicolai.Leymann@t-systems.com) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: l3vpn@ietf.org Subject: Re: TTL Handling in draft-rosen / mVPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ycai@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 > > Dear all, > > according to draft-rosen-vpn-mcast-07.txt the following applies to the > TTL values when a payload packet is encapsulated. > > "The ingress PE should not copy the TTL field from the payload IP > header received from a CE router to the delivery IP header. The > setting the TTL of the deliver IP header is determined by the local > policy of the ingress PE router." > > So it's up to the implementation of the ingress PE which TTL value > is used. How is this handled in existing implementations? Yes. That was the idea. > Is there > a commonly used TTL-Value (like 255) and/or is this value configurable? > Cisco IOS uses 255 by default. -- Yiqun From l3vpn-bounces@ietf.org Mon Jan 17 10:51:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17328 for ; Mon, 17 Jan 2005 10:51:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZPN-0007lI-2Y for l3vpn-web-archive@ietf.org; Mon, 17 Jan 2005 11:07:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZ20-0005ra-Ci; Mon, 17 Jan 2005 10:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZ0G-0005MZ-Q8 for l3vpn@megatron.ietf.org; Mon, 17 Jan 2005 10:41:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16296 for ; Mon, 17 Jan 2005 10:41:13 -0500 (EST) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZFJ-0007TZ-Ud for l3vpn@ietf.org; Mon, 17 Jan 2005 10:56:51 -0500 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Jan 2005 15:40:42 +0000 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Jan 2005 10:40:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2005 10:40:39 -0500 Message-ID: <1E8ACF422ADD1A458AAFFAD2E6FF70C80192A281@proton.jnpr.net> Thread-Topic: LAST CALL: draft-ietf-l3vpn-bgp-ipv6-04 Thread-Index: AcT8quVTNHfBR3bBSceNyCIml6ut1w== From: "Ronald Bonica" To: X-OriginalArrivalTime: 17 Jan 2005 15:40:41.0391 (UTC) FILETIME=[E66F4BF0:01C4FCAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: LAST CALL: draft-ietf-l3vpn-bgp-ipv6-04 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Folks, This message begins a last call on draft-ietf-l3vpn-bgp-ipv6-04. Last call ends on Feb 1 at midnight UTC. Ron From RRUVL@hotmail.com Sat Jan 22 04:47:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21387; Sat, 22 Jan 2005 04:47:17 -0500 (EST) Received: from [220.86.98.30] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CsI7X-0001Hg-0F; Sat, 22 Jan 2005 05:03:55 -0500 Received: from [92.50.234.23] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 689LFL-0078PT-10 Message-ID: <14955893144732.R37444@.noc..gr> Sender: freeradius-devel-RRUVL@hotmail.com X-Mailman-Version: 2.0.1 Date: Sat, 22 Jan 2005 05:42:53 -0400 From: "Melissa Vargas" To: l2vpn-web-archive@ietf.org Cc: l3vpn@ietf.org, l3vpn-admin@ietf.org, l3vpn-web-archive@ietf.org, ldap-dir@ietf.org, ldap-dir-admin@ietf.org, ldap-dir-web-archive@ietf.org, ldapext@ietf.org, ldapext-admin@ietf.org, ldapext-archive@ietf.org, lemonade@ietf.org, lemonade-request@ietf.org Subject: Viic0din and Hydr0c0done Heere ToE X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Offers of the month... Viaggra $139.95 Ciallis $129.95 Vallium $179.95 Xanaax $160.95 Ambient $114.95 Visitt us today for irresistable offerss.. http://expedited2u.biz/2/?wid=200007 This is 1 -time mailing. N0-re m0val are re'qui-red wDa0vw4d3jx0FFh8X5BcSAmWn3GxuBRhJsJM44kHYgD5MlLBfOU6ede4f From l3vpn-bounces@ietf.org Wed Jan 26 07:14:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16370 for ; Wed, 26 Jan 2005 07:14:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtmL4-0003Nv-JE for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 07:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctlz0-0006G4-66; Wed, 26 Jan 2005 07:09:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctlvg-0005lV-54 for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 07:05:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15556 for ; Wed, 26 Jan 2005 07:05:44 -0500 (EST) Received: from mail.si.fr.atosorigin.com ([195.68.44.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtmCY-00038x-TP for L3vpn@ietf.org; Wed, 26 Jan 2005 07:23:16 -0500 Received: from mailmir.si.fr.atosorigin.com (mailmir.si.fr.atosorigin.com [55.2.7.165]) by mail.si.fr.atosorigin.com (8.13.1/8.13.1) with ESMTP id j0QC56Rt014284 for ; Wed, 26 Jan 2005 13:05:16 +0100 Received: from AOFR06585 ([55.3.96.70]) by mailmir.si.fr.atosorigin.com (8.13.0/8.13.0) with SMTP id j0QC56Z3018965 for ; Wed, 26 Jan 2005 13:05:06 +0100 Message-ID: <00d201c5039f$0b9e3c10$46600337@AOFR06585> From: "Fabien Verhaeghe" To: Date: Wed, 26 Jan 2005 13:03:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01C503A7.6D51DB30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-uvscan-category: small X-RelayAddrIn-Show: (55.3.96.70) X-RelayAddrIn-Local: Yes X-Scanned-By: MIMEDefang 2.48 on 55.2.7.5 X-Spam-Score: 0.8 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C503A7.6D51DB30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target." If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned = from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). So how can systems in site B communicate with systems in site C? I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. Can someone explain to me please? Thanks Fabien ------=_NextPart_000_00CF_01C503A7.6D51DB30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of  = draft-ietf-l3vpn-rfc2547bis-03.txt=20 states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be done = by the use=20 of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is the = Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to the=20 spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A will = actually=20 advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------=_NextPart_000_00CF_01C503A7.6D51DB30-- From l3vpn-bounces@ietf.org Wed Jan 26 07:39:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18436 for ; Wed, 26 Jan 2005 07:39:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtmjV-0004AV-El for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 07:57:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtmKP-0001r6-4D; Wed, 26 Jan 2005 07:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtmIl-0001PH-6T for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 07:29:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17777 for ; Wed, 26 Jan 2005 07:29:37 -0500 (EST) From: TYushkov@microtest.ru Received: from relay2.moscow.microtest.ru ([194.154.88.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtmZf-0003q0-C8 for L3vpn@ietf.org; Wed, 26 Jan 2005 07:47:07 -0500 Received: from nike.msk.mt ([10.240.28.6]) by relay2.moscow.microtest.ru with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Jan 2005 15:29:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C503A2.9FBAFD48" Date: Wed, 26 Jan 2005 15:29:03 +0300 Message-ID: <715A34CD104ED041859430F0A63C3797691F51@nike.msk.mt> Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDoPXPPiOb/qoHTPOPMWRrJhuIiwAAKQVg To: , X-OriginalArrivalTime: 26 Jan 2005 12:29:03.0751 (UTC) FILETIME=[9F066970:01C503A2] X-Spam-Score: 0.9 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 This is a multi-part message in MIME format. ------_=_NextPart_001_01C503A2.9FBAFD48 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi, The main idea of Hub&spoke is the following: spokes may communicate with = hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, = and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN Hi, =20 I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: =20 "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target." =20 If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke =20 In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned = from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). =20 So how can systems in site B communicate with systems in site C? =20 I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. =20 Can someone explain to me please? =20 Thanks Fabien =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C503A2.9FBAFD48 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, = and sites=20 B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and=20 CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 = PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of  = draft-ietf-l3vpn-rfc2547bis-03.txt=20 states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be done = by the use=20 of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is the = Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to the=20 spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A will = actually=20 advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------_=_NextPart_001_01C503A2.9FBAFD48-- From l3vpn-bounces@ietf.org Wed Jan 26 08:27:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22735 for ; Wed, 26 Jan 2005 08:27:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtnTP-0005yO-Pa for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 08:44:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctn9k-0005aY-V2; Wed, 26 Jan 2005 08:24:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctn2g-00043z-74 for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 08:17:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21736 for ; Wed, 26 Jan 2005 08:17:04 -0500 (EST) Received: from mail.si.fr.atosorigin.com ([195.68.44.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtnJa-0005c6-Nq for L3vpn@ietf.org; Wed, 26 Jan 2005 08:34:35 -0500 Received: from mailmir.si.fr.atosorigin.com (mailmir.si.fr.atosorigin.com [55.2.7.165]) by mail.si.fr.atosorigin.com (8.13.1/8.13.1) with ESMTP id j0QDGPOv024251 for ; Wed, 26 Jan 2005 14:16:35 +0100 Received: from AOFR06585 ([55.3.96.70]) by mailmir.si.fr.atosorigin.com (8.13.0/8.13.0) with SMTP id j0QDGROI021197 for ; Wed, 26 Jan 2005 14:16:27 +0100 Message-ID: <011d01c503a9$02b26810$46600337@AOFR06585> From: "Fabien Verhaeghe" To: References: <715A34CD104ED041859430F0A63C3797691F51@nike.msk.mt> Date: Wed, 26 Jan 2005 14:14:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011A_01C503B1.64745F10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-uvscan-category: small X-RelayAddrIn-Show: (55.3.96.70) X-RelayAddrIn-Local: Yes X-Scanned-By: MIMEDefang 2.48 on 55.2.7.5 X-Spam-Score: 0.6 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Subject: Re: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 This is a multi-part message in MIME format. ------=_NextPart_000_011A_01C503B1.64745F10 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Thanks for your answer Taras , What I understood is that Spoke can not communicate DIRECTLY with each = other. They have to go through the Hub. But if a packet is received at PE C (from the CE) for a destination = address which is in site B he won't have any route that says to go through the Hub. I'm talking about the routing between PEs when I make a reference to = RFC1771 9.2.1. Not between CE and PE. Fabien ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate with = hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, = and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras -------------------------------------------------------------------------= ------- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN Hi, I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target." If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned = from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). So how can systems in site B communicate with systems in site C? I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. Can someone explain to me please? Thanks Fabien ------=_NextPart_000_011A_01C503B1.64745F10 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Thanks for your answer Taras = ,
 
What I understood is that Spoke can not = communicate=20 DIRECTLY with each other. They have
to go through the Hub.
But if a packet is received at PE C = (from the=20 CE) for a destination address which is in site B he = won't
have any route that says to go through = the=20 Hub.
 
I'm talking about the routing between = PEs when I=20 make a reference to RFC1771 9.2.1. Not between CE and PE.
 
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 1:29 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, = and sites=20 B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and=20 CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 = PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of  = draft-ietf-l3vpn-rfc2547bis-03.txt=20 states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be done = by the use=20 of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is the = Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to the=20 spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A will = actually=20 advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------=_NextPart_000_011A_01C503B1.64745F10-- From l3vpn-bounces@ietf.org Wed Jan 26 08:54:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25089 for ; Wed, 26 Jan 2005 08:54:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctnta-0006uN-US for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 09:11:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctnab-00034c-O4; Wed, 26 Jan 2005 08:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtnRv-0001Ae-GD for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 08:43:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24205 for ; Wed, 26 Jan 2005 08:43:09 -0500 (EST) From: TYushkov@microtest.ru Received: from relay2.moscow.microtest.ru ([194.154.88.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctniq-0006W9-DG for L3vpn@ietf.org; Wed, 26 Jan 2005 09:00:41 -0500 Received: from nike.msk.mt ([10.240.28.6]) by relay2.moscow.microtest.ru with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Jan 2005 16:42:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C503AC.E5D229AA" Date: Wed, 26 Jan 2005 16:42:36 +0300 Message-ID: <715A34CD104ED041859430F0A63C3797691FE2@nike.msk.mt> Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDquyISpZSCEHlTummY7dfRLk6GQAAEZfA To: , X-OriginalArrivalTime: 26 Jan 2005 13:42:34.0665 (UTC) FILETIME=[E4227990:01C503AC] X-Spam-Score: 0.9 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc This is a multi-part message in MIME format. ------_=_NextPart_001_01C503AC.E5D229AA Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Fabien: "What I understood is that Spoke can not communicate DIRECTLY = with each other. They have to go through the Hub." Taras: No, spokes can not communicate with each other even through hub. That is = idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. Suppose, you have a large data center and some clients of data center. = Clients want to reach data center, but they don't want have ANY = connectivity with other clients due security reasons, for example. =20 As to BGP routing, I may say, that PE router on site B (spoke Site) may = receive all routes, including routes from site C. But it does not = install routes to site C in its VRF routing table. Route Target of route = from site C do not mach VRF "import" set of route target attributes. =20 Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 4:15 PM To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN Thanks for your answer Taras , =20 What I understood is that Spoke can not communicate DIRECTLY with each = other. They have to go through the Hub.=20 =20 But if a packet is received at PE C (from the CE) for a destination = address which is in site B he won't have any route that says to go through the Hub. =20 I'm talking about the routing between PEs when I make a reference to = RFC1771 9.2.1. Not between CE and PE. =20 Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate with = hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, = and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN Hi, =20 I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: =20 "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target." =20 If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke =20 In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned = from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). =20 So how can systems in site B communicate with systems in site C? =20 I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. =20 Can someone explain to me please? =20 Thanks Fabien =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C503AC.E5D229AA Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Fabien: = "What I=20 understood is that Spoke can not communicate DIRECTLY with each other. = They=20 have
to go = through the=20 Hub."
Taras:
No, spokes can not communicate with each other = even through=20 hub. That is idea of hub&spoke VPN - it is VPN with PARTIAL=20 connectivity.
Suppose, you have a large data center and some = clients of=20 data center. Clients want to reach data center, but they don't want have = ANY=20 connectivity with other clients due security reasons, for=20 example.
 
As to BGP routing, I may say, that PE router on = site B=20 (spoke Site) may receive all routes, including routes from site C. = But it=20 does not install routes to site C in its VRF routing table. Route Target = of=20 route from site C do not mach VRF "import" set of route target=20 attributes.
 
Taras

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 4:15 = PM
To:=20 L3vpn@ietf.org
Subject: Re: Route Target in BGP/MPLS IP=20 VPN

Thanks for your answer Taras = ,
 
What I understood is that Spoke can not = communicate=20 DIRECTLY with each other. They have
to go through the Hub. 
 
But if a packet is received at PE C = (from the=20 CE) for a destination address which is in site B he = won't
have any route that says to go through = the=20 Hub.
 
I'm talking about the routing between = PEs when I=20 make a reference to RFC1771 9.2.1. Not between CE and PE.
 
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 1:29 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, = and sites=20 B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and=20 CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 = PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of  = draft-ietf-l3vpn-rfc2547bis-03.txt=20 states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be done = by the use=20 of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is the = Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to the=20 spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A will = actually=20 advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------_=_NextPart_001_01C503AC.E5D229AA-- From l3vpn-bounces@ietf.org Wed Jan 26 09:31:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28746 for ; Wed, 26 Jan 2005 09:31:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtoTY-0007vp-HP for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 09:48:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cto2b-0001s6-PA; Wed, 26 Jan 2005 09:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctnst-0007p8-OG for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 09:11:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26440 for ; Wed, 26 Jan 2005 09:11:01 -0500 (EST) Received: from mx.tellabs.fi ([193.65.253.34] helo=mx2-priv.tellabs.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cto9o-0007OA-Hj for l3vpn@ietf.org; Wed, 26 Jan 2005 09:28:33 -0500 Received: from fies1wms01b.tellabs.fi (HELO FIESEX1.tellabs-east.tellabsinc.net) (172.19.6.62) by mx2-priv.tellabs.fi with ESMTP; 26 Jan 2005 08:10:29 -0600 X-SBRS: None X-IronPort-AV: i="3.88,154,1102312800"; d="scan'208,217"; a="570601:sNHT31116396" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C503B0.D80D617B" Date: Wed, 26 Jan 2005 16:10:26 +0200 Message-ID: <4EE011314003124CA4389D37DC21940F011C6FC4@FIESEX1.tellabs-east.tellabsinc.net> Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDquyISpZSCEHlTummY7dfRLk6GQAAEZfAAAEQgRA= From: "Kulmala, Marko" To: , , X-Spam-Score: 0.6 (/) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C503B0.D80D617B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 It seems that many times people mean different thing when they talk about hub and spoke VPN. This is my opinion: - When spokes have connectivity through hub site then it is real hub and spoke VPN. - If spokes have no connectivity at all between each other then they do not belong to same VPN from IP connectivity point of view. The topology that Taras described (no connectivity between spokes) is in my mind collection of overlapping VPNs. Hub site and each spoke site form separate VPN. So, there are so many VPNs as there are spokes and hub site belongs to all those VPNs. =20 Marko =20 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of TYushkov@microtest.ru Sent: 26. tammikuuta 2005 15:43 To: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN =09 =09 =09 Fabien: "What I understood is that Spoke can not communicate DIRECTLY with each other. They have to go through the Hub." Taras: No, spokes can not communicate with each other even through hub. That is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. Suppose, you have a large data center and some clients of data center. Clients want to reach data center, but they don't want have ANY connectivity with other clients due security reasons, for example. =20 As to BGP routing, I may say, that PE router on site B (spoke Site) may receive all routes, including routes from site C. But it does not install routes to site C in its VRF routing table. Route Target of route from site C do not mach VRF "import" set of route target attributes. =20 Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 4:15 PM To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN =09 =09 Thanks for your answer Taras , =20 What I understood is that Spoke can not communicate DIRECTLY with each other. They have to go through the Hub.=20 =20 But if a packet is received at PE C (from the CE) for a destination address which is in site B he won't have any route that says to go through the Hub. =20 I'm talking about the routing between PEs when I make a reference to RFC1771 9.2.1. Not between CE and PE. =20 Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate with hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN =09 =09 =09 Hi, =20 I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: =20 "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At =09 the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke =09 site, "Hub" is the Import Target and "Spoke" is the Export Target." =20 If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per CE/PE. Site A is the hub Site B,C are spoke =20 In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). =20 So how can systems in site B communicate with systems in site C? =20 I guess I misunderstood something, and PE connected to site A will actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. =20 Can someone explain to me please? =20 Thanks Fabien =20 =20 =20 =20 =20 =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C503B0.D80D617B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
It seems that many times people mean different thi= ng when=20 they talk about hub and spoke VPN.
This is my opinion:
- When spokes have connectivity through hub site t= hen it is=20 real hub and spoke VPN.
- If= spokes have=20 no connectivity at all between each other then they do not belong to same V= PN=20 from IP connectivity point of view.
The=20 topology that Taras described (no connectivity between spokes) is in m= y=20 mind collection of overlapping VPNs.
Hub=20 site and each spoke site form separate VPN. So, there are so many VPNs= as=20 there are spokes and hub site belongs to all those=20 VPNs.
 
Marko
 

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of=20 TYushkov@microtest.ru
Sent: 26. tammikuuta 2005=20 15:43
To: fabien.verhaeghe@atosorigin.com;=20 L3vpn@ietf.org
Subject: RE: Route Target in BGP/MPLS IP=20 VPN

Fabien: "W= hat I=20 understood is that Spoke can not communicate DIRECTLY with each other. Th= ey=20 have
to go throug= h the=20 Hub."
Taras:
No, spokes can not communicate with each other e= ven=20 through hub. That is idea of hub&spoke VPN - it is VPN with PART= IAL=20 connectivity.
Suppose, you have a large data center and some c= lients of=20 data center. Clients want to reach data center, but they don't want have = ANY=20 connectivity with other clients due security reasons, for=20 example.
 
As to BGP routing, I may say, that PE router on = site B=20 (spoke Site) may receive all routes, including routes from site C. B= ut it=20 does not install routes to site C in its VRF routing table. Route Target = of=20 route from site C do not mach VRF "import" set of route target=20 attributes.
 
Taras

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 4:15 PM
To:=20 L3vpn@ietf.org
Subject: Re: Route Target in BGP/MPLS IP=20 VPN

Thanks for your answer Taras ,
 
What I understood is that Spoke can not=20 communicate DIRECTLY with each other. They have
to go through the Hub. 
 
But if a packet is received at PE C (fro= m the=20 CE) for a destination address which is in site B he won't
have any route that says to go through t= he=20 Hub.
 
I'm talking about the routing between PE= s when I=20 make a reference to RFC1771 9.2.1. Not between CE and PE.
 
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 1:29 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

<= SPAN=20 class=3D661452112-26012005>

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, an= d=20 sites B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing between= PE=20 and CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route Targe= t" in=20 BGP/MPLS IP VPN
Section 4.3.5 of =20 draft-ietf-l3vpn-rfc2547bis-03.txt states:
 
"Alternatively, suppose= one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be done b= y the=20 use of two
Route Target values, one meaning "Hub" and one me= aning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is the = Export=20 Target and
"Spoke" is the Import Target. At the VRFs attache= d to=20 the spoke
site, "Hub" is the Import Target and "Spoke" is the Export Target."<= /DIV>
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF pe= r=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site C?
 
I guess I misunderstood something, and PE connected to site A will=20 actually advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C503B0.D80D617B-- From l3vpn-bounces@ietf.org Wed Jan 26 09:32:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28863 for ; Wed, 26 Jan 2005 09:32:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtoUY-0007xr-Kq for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 09:49:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cto2c-0001sv-N2; Wed, 26 Jan 2005 09:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctnt0-0007s6-51 for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 09:11:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26458 for ; Wed, 26 Jan 2005 09:11:08 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cto9v-0007OF-AA for l3vpn@ietf.org; Wed, 26 Jan 2005 09:28:40 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2005 15:21:17 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from amsterdam.cisco.com (amsterdam.cisco.com [144.254.224.160]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0QEAZW6005473; Wed, 26 Jan 2005 15:10:35 +0100 (MET) Received: from jguicharw2k01 (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by amsterdam.cisco.com (8.12.10/8.12.6) with ESMTP id j0QEAWDw004251; Wed, 26 Jan 2005 15:10:32 +0100 (MET) Message-Id: <200501261410.j0QEAWDw004251@amsterdam.cisco.com> From: "jguichar" To: , , Date: Wed, 26 Jan 2005 09:10:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E6_01C50386.E407BAE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <715A34CD104ED041859430F0A63C3797691FE2@nike.msk.mt> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUDquyISpZSCEHlTummY7dfRLk6GQAAEZfAAAFVCJA= X-Spam-Score: 0.6 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c This is a multi-part message in MIME format. ------=_NextPart_000_00E6_01C50386.E407BAE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not exactly. It is actually both of these things and connectivity between spokes is driven by configuration. In one model spokes cannot communicate, in another they can (preferably via a firewall at the hub). Jim Guichard CCIE# 2069 System Architect - MPLS Technologies ITD Boxborough DD: 978-936-1586 Cell: 978-302-0481 _____ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of TYushkov@microtest.ru Sent: Wednesday, January 26, 2005 8:43 AM To: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN Fabien: "What I understood is that Spoke can not communicate DIRECTLY with each other. They have to go through the Hub." Taras: No, spokes can not communicate with each other even through hub. That is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. Suppose, you have a large data center and some clients of data center. Clients want to reach data center, but they don't want have ANY connectivity with other clients due security reasons, for example. As to BGP routing, I may say, that PE router on site B (spoke Site) may receive all routes, including routes from site C. But it does not install routes to site C in its VRF routing table. Route Target of route from site C do not mach VRF "import" set of route target attributes. Taras _____ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 4:15 PM To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN Thanks for your answer Taras , What I understood is that Spoke can not communicate DIRECTLY with each other. They have to go through the Hub. But if a packet is received at PE C (from the CE) for a destination address which is in site B he won't have any route that says to go through the Hub. I'm talking about the routing between PEs when I make a reference to RFC1771 9.2.1. Not between CE and PE. Fabien ----- Original Message ----- From: TYushkov@microtest.ru To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate with hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing between PE and CE. So RFC1771 9.2.1 it's not our case. Cheers. Taras _____ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN Hi, I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target." If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per CE/PE. Site A is the hub Site B,C are spoke In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). So how can systems in site B communicate with systems in site C? I guess I misunderstood something, and PE connected to site A will actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. Can someone explain to me please? Thanks Fabien ------=_NextPart_000_00E6_01C50386.E407BAE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not exactly. It is actually both of these = things and=20 connectivity between spokes is driven by configuration. In one model = spokes=20 cannot communicate, in another they can (preferably via a firewall at = the hub).=20
 

Jim Guichard CCIE# 2069
System = Architect -=20 MPLS Technologies

ITD Boxborough
DD: 978-936-1586
Cell:=20 978-302-0481

 

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of=20 TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 = 8:43=20 AM
To: fabien.verhaeghe@atosorigin.com;=20 L3vpn@ietf.org
Subject: RE: Route Target in BGP/MPLS IP=20 VPN

Fabien: = "What I=20 understood is that Spoke can not communicate DIRECTLY with each other. = They=20 have
to go = through the=20 Hub."
Taras:
No, spokes can not communicate with each = other even=20 through hub. That is idea of hub&spoke VPN - it is VPN = with PARTIAL=20 connectivity.
Suppose, you have a large data center and = some clients of=20 data center. Clients want to reach data center, but they don't want = have ANY=20 connectivity with other clients due security reasons, for=20 example.
 
As to BGP routing, I may say, that PE router = on site B=20 (spoke Site) may receive all routes, including routes from site = C. But it=20 does not install routes to site C in its VRF routing table. Route = Target of=20 route from site C do not mach VRF "import" set of route target=20 attributes.
 
Taras

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 4:15 = PM
To:=20 L3vpn@ietf.org
Subject: Re: Route Target in BGP/MPLS IP=20 VPN

Thanks for your answer Taras = ,
 
What I understood is that Spoke can = not=20 communicate DIRECTLY with each other. They have
to go through the Hub. 
 
But if a packet is received at PE C = (from the=20 CE) for a destination address which is in site B he = won't
have any route that says to go = through the=20 Hub.
 
I'm talking about the routing between = PEs when I=20 make a reference to RFC1771 9.2.1. Not between CE and PE.
 
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 1:29 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, = and=20 sites B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE=20 and CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 = PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of =20 draft-ietf-l3vpn-rfc2547bis-03.txt states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be = done by the=20 use of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is = the Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to=20 the spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A = will=20 actually advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------=_NextPart_000_00E6_01C50386.E407BAE0-- From l3vpn-bounces@ietf.org Wed Jan 26 09:44:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00834 for ; Wed, 26 Jan 2005 09:44:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctofk-0008Ul-Az for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 10:01:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtoGS-0005J5-Eo; Wed, 26 Jan 2005 09:35:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cto5e-0002Sy-6y for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 09:24:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28017 for ; Wed, 26 Jan 2005 09:24:12 -0500 (EST) From: E.T.Metz@telecom.tno.nl Received: from ds04.tnoase.telecom.tno.nl ([139.63.192.204] helo=ds04.telecom.tno.nl) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtoMW-0007mJ-0e for L3vpn@ietf.org; Wed, 26 Jan 2005 09:41:44 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 26 Jan 2005 15:24:07 +0100 Message-ID: Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDqtbDIQUu4QRbRPSdNmGW8XjR5wABqDqg To: X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable =20 In a hub-and-spoke VPN, spoke-sites (assuming these do not share a VRF when connected to the same PE) cannot communicate with eachother directly, i.e. spoke-PE to spoke-PE. If spoke-sites need to communicate with eachother the communication path indeed goes (must go) through the hub-CE, the underlying requirement could e.g. be that traffic between B and C needs to pass a firewall at A. Note that the hub-PE never acts as a 'transit' node in this case. To achieve spoke-spoke communication you either need to advertise an aggregate (covering the spoke-subnets or entire VPN) or a default from the hub-site (CE), and ensure that the hub-CE has specific routes to the spoke-CEs pointing to the hub-PE. This will result in traffic from CE-B to CE-C to go like this CE-B -> PE-B -> PE-A -> CE-A -> PE-A -> PE-C -> CE-C. Hope this helps. cheers, Eduard ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe Sent: woensdag 26 januari 2005 14:15 To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN =09 =09 Thanks for your answer Taras , =20 What I understood is that Spoke can not communicate DIRECTLY with each other. They have to go through the Hub. But if a packet is received at PE C (from the CE) for a destination address which is in site B he won't have any route that says to go through the Hub. =20 I'm talking about the routing between PEs when I make a reference to RFC1771 9.2.1. Not between CE and PE. =20 Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate with hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras =09 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN =09 =09 Hi, =20 I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: =20 "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target." =20 If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per CE/PE. Site A is the hub Site B,C are spoke =20 In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). =20 So how can systems in site B communicate with systems in site C? =20 I guess I misunderstood something, and PE connected to site A will actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. =20 Can someone explain to me please? =20 Thanks Fabien =20 =20 =20 =20 =20 =20 =20 =09 From l3vpn-bounces@ietf.org Wed Jan 26 09:55:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01972 for ; Wed, 26 Jan 2005 09:55:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtorI-0000QT-KJ for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 10:13:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtoOE-0008EV-Bn; Wed, 26 Jan 2005 09:43:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtoGA-0005C6-7X for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 09:35:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29276 for ; Wed, 26 Jan 2005 09:35:04 -0500 (EST) From: TYushkov@microtest.ru Received: from ns2.moscow.microtest.ru ([194.154.88.10] helo=relay2.moscow.microtest.ru) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtoX5-00082e-EZ for L3vpn@ietf.org; Wed, 26 Jan 2005 09:52:36 -0500 Received: from nike.msk.mt ([10.240.28.6]) by relay2.moscow.microtest.ru with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Jan 2005 17:34:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C503B4.299EEA38" Date: Wed, 26 Jan 2005 17:34:37 +0300 Message-ID: <715A34CD104ED041859430F0A63C3797692041@nike.msk.mt> Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDquyISpZSCEHlTummY7dfRLk6GQAAEZfAAAFVCJAAAFHfIA== To: , X-OriginalArrivalTime: 26 Jan 2005 14:34:24.0640 (UTC) FILETIME=[21D30000:01C503B4] X-Spam-Score: 0.9 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e This is a multi-part message in MIME format. ------_=_NextPart_001_01C503B4.299EEA38 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Jim, Fabien asked us about example in draft-ietf-l3vpn-rfc2547bis-03.txt = (4.3.5). In this examples authors show us how to build hub&spoke VPN = without any connectivity between spokes. Btw, I agree with you. There is another kind of VPN called hub&spoke, = where traffic between spokes goes through hub. But it is not the case of = 4.3.5. =20 Marko, As I can understand if you want to build hub&spoke VPN with connectivity = between spokes through hub, you have to organize one VPN per spoke. Each = VPN must be "point-to-point" (including one spoke site and separate = (sub)interface on hub site). Than you must organize routing between = these VPN on CE on hub Site. So, we have as many different VPNs as spoke sites, you want to connect = to hub. =20 Cheers Taras ________________________________ From: jguichar [mailto:jguichar@cisco.com]=20 Sent: Wednesday, January 26, 2005 5:11 PM To: =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1; fabien.verhaeghe@atosorigin.com; = L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN Not exactly. It is actually both of these things and connectivity = between spokes is driven by configuration. In one model spokes cannot = communicate, in another they can (preferably via a firewall at the hub). = =20 Jim Guichard CCIE# 2069 System Architect - MPLS Technologies ITD Boxborough DD: 978-936-1586 Cell: 978-302-0481=20 =20 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of TYushkov@microtest.ru Sent: Wednesday, January 26, 2005 8:43 AM To: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN =09 =09 =09 Fabien: "What I understood is that Spoke can not communicate DIRECTLY = with each other. They have to go through the Hub." Taras: No, spokes can not communicate with each other even through hub. That = is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. Suppose, you have a large data center and some clients of data center. = Clients want to reach data center, but they don't want have ANY = connectivity with other clients due security reasons, for example. =20 As to BGP routing, I may say, that PE router on site B (spoke Site) may = receive all routes, including routes from site C. But it does not = install routes to site C in its VRF routing table. Route Target of route = from site C do not mach VRF "import" set of route target attributes. =20 Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 4:15 PM To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN =09 =09 Thanks for your answer Taras , =20 What I understood is that Spoke can not communicate DIRECTLY with each = other. They have to go through the Hub.=20 =20 But if a packet is received at PE C (from the CE) for a destination = address which is in site B he won't have any route that says to go through the Hub. =20 I'm talking about the routing between PEs when I make a reference to = RFC1771 9.2.1. Not between CE and PE. =20 Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate = with hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, = and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN =09 =09 =09 Hi, =20 I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: =20 "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At =09 the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke =09 site, "Hub" is the Import Target and "Spoke" is the Export Target." =20 If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke =20 In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned = from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). =20 So how can systems in site B communicate with systems in site C? =20 I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. =20 Can someone explain to me please? =20 Thanks Fabien =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C503B4.299EEA38 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Jim,
Fabien asked us about example in = draft-ietf-l3vpn-rfc2547bis-03.txt=20 (4.3.5). In this examples authors show us how to build hub&spoke VPN = without=20 any connectivity between spokes.
Btw, I agree with you. There is another kind of VPN called = hub&spoke,=20 where traffic between spokes goes through hub. But it is not the case=20 of 4.3.5.
 
Marko,
As I can understand if you want to build hub&spoke VPN with = connectivity between spokes through hub, you have to organize one VPN = per spoke.=20 Each VPN must be "point-to-point" (including one spoke site and separate = (sub)interface on hub site). Than you must organize routing between = these=20 VPN on CE on hub Site.
So, we have as many different VPNs as spoke sites, you want to = connect to=20 hub.
 
Cheers
Taras

From: jguichar = [mailto:jguichar@cisco.com]=20
Sent: Wednesday, January 26, 2005 5:11 PM
To: = =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1;=20 fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org
Subject: RE: = Route=20 Target in BGP/MPLS IP VPN

Not exactly. It is actually both of these = things and=20 connectivity between spokes is driven by configuration. In one model = spokes=20 cannot communicate, in another they can (preferably via a firewall at = the hub).=20
 

Jim Guichard CCIE# 2069
System = Architect -=20 MPLS Technologies

ITD Boxborough
DD: 978-936-1586
Cell:=20 978-302-0481

 

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of=20 TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 = 8:43=20 AM
To: fabien.verhaeghe@atosorigin.com;=20 L3vpn@ietf.org
Subject: RE: Route Target in BGP/MPLS IP=20 VPN

Fabien: = "What I=20 understood is that Spoke can not communicate DIRECTLY with each other. = They=20 have
to go = through the=20 Hub."
Taras:
No, spokes can not communicate with each = other even=20 through hub. That is idea of hub&spoke VPN - it is VPN = with PARTIAL=20 connectivity.
Suppose, you have a large data center and = some clients of=20 data center. Clients want to reach data center, but they don't want = have ANY=20 connectivity with other clients due security reasons, for=20 example.
 
As to BGP routing, I may say, that PE router = on site B=20 (spoke Site) may receive all routes, including routes from site = C. But it=20 does not install routes to site C in its VRF routing table. Route = Target of=20 route from site C do not mach VRF "import" set of route target=20 attributes.
 
Taras

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 4:15 = PM
To:=20 L3vpn@ietf.org
Subject: Re: Route Target in BGP/MPLS IP=20 VPN

Thanks for your answer Taras = ,
 
What I understood is that Spoke can = not=20 communicate DIRECTLY with each other. They have
to go through the Hub. 
 
But if a packet is received at PE C = (from the=20 CE) for a destination address which is in site B he = won't
have any route that says to go = through the=20 Hub.
 
I'm talking about the routing between = PEs when I=20 make a reference to RFC1771 9.2.1. Not between CE and PE.
 
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 1:29 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, = and=20 sites B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE=20 and CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 = PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of =20 draft-ietf-l3vpn-rfc2547bis-03.txt states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be = done by the=20 use of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is = the Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to=20 the spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A = will=20 actually advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------_=_NextPart_001_01C503B4.299EEA38-- From l3vpn-bounces@ietf.org Wed Jan 26 11:01:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09933 for ; Wed, 26 Jan 2005 11:01:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctpsf-0002I8-Tm for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 11:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtpYk-0003bU-Q4; Wed, 26 Jan 2005 10:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtpRJ-0000Nr-0n for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 10:50:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08981 for ; Wed, 26 Jan 2005 10:50:37 -0500 (EST) Received: from mail.si.fr.atosorigin.com ([195.68.44.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtpiE-00021i-1W for L3vpn@ietf.org; Wed, 26 Jan 2005 11:08:11 -0500 Received: from mailmir.si.fr.atosorigin.com (mailmir.si.fr.atosorigin.com [55.2.7.165]) by mail.si.fr.atosorigin.com (8.13.1/8.13.1) with ESMTP id j0QFnuX8029522; Wed, 26 Jan 2005 16:50:06 +0100 Received: from AOFR06585 ([55.3.96.70]) by mailmir.si.fr.atosorigin.com (8.13.0/8.13.0) with SMTP id j0QFnuda026823; Wed, 26 Jan 2005 16:49:56 +0100 Message-ID: <01d501c503be$765c7ed0$46600337@AOFR06585> From: "Fabien Verhaeghe" To: , , References: <715A34CD104ED041859430F0A63C3797692041@nike.msk.mt> Date: Wed, 26 Jan 2005 16:48:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D2_01C503C6.D81C2BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-uvscan-category: small X-RelayAddrIn-Show: (55.3.96.70) X-RelayAddrIn-Local: Yes X-Scanned-By: MIMEDefang 2.48 on 55.2.7.5 X-Spam-Score: 0.6 (/) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Cc: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: b7b1e91f6d312d4248b994050b22d659 This is a multi-part message in MIME format. ------=_NextPart_000_01D2_01C503C6.D81C2BE0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Seems clear to me now. Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it should explicitly be said = that the spoke and hub here does not offer connectivity=20 between the spoke. Thanks all Fabien ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: jguichar@cisco.com ; marko.kulmala@tellabs.com=20 Cc: L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 3:34 PM Subject: RE: Route Target in BGP/MPLS IP VPN Jim, Fabien asked us about example in draft-ietf-l3vpn-rfc2547bis-03.txt = (4.3.5). In this examples authors show us how to build hub&spoke VPN = without any connectivity between spokes. Btw, I agree with you. There is another kind of VPN called hub&spoke, = where traffic between spokes goes through hub. But it is not the case of = 4.3.5. Marko, As I can understand if you want to build hub&spoke VPN with connectivity = between spokes through hub, you have to organize one VPN per spoke. Each = VPN must be "point-to-point" (including one spoke site and separate = (sub)interface on hub site). Than you must organize routing between = these VPN on CE on hub Site. So, we have as many different VPNs as spoke sites, you want to connect = to hub. Cheers Taras -------------------------------------------------------------------------= ------- From: jguichar [mailto:jguichar@cisco.com]=20 Sent: Wednesday, January 26, 2005 5:11 PM To: =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1; fabien.verhaeghe@atosorigin.com; = L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN Not exactly. It is actually both of these things and connectivity = between spokes is driven by configuration. In one model spokes cannot = communicate, in another they can (preferably via a firewall at the hub). = Jim Guichard CCIE# 2069 System Architect - MPLS Technologies ITD Boxborough DD: 978-936-1586 Cell: 978-302-0481=20 -------------------------------------------------------------------------= ----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of TYushkov@microtest.ru Sent: Wednesday, January 26, 2005 8:43 AM To: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN Fabien: "What I understood is that Spoke can not communicate DIRECTLY = with each other. They have to go through the Hub." Taras: No, spokes can not communicate with each other even through hub. That = is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. Suppose, you have a large data center and some clients of data center. = Clients want to reach data center, but they don't want have ANY = connectivity with other clients due security reasons, for example. As to BGP routing, I may say, that PE router on site B (spoke Site) = may receive all routes, including routes from site C. But it does not = install routes to site C in its VRF routing table. Route Target of route = from site C do not mach VRF "import" set of route target attributes. Taras -------------------------------------------------------------------------= ----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 4:15 PM To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN Thanks for your answer Taras , What I understood is that Spoke can not communicate DIRECTLY with each = other. They have to go through the Hub.=20 But if a packet is received at PE C (from the CE) for a destination = address which is in site B he won't have any route that says to go through the Hub. I'm talking about the routing between PEs when I make a reference to = RFC1771 9.2.1. Not between CE and PE. Fabien ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate = with hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, = and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras -------------------------------------------------------------------------= ----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN Hi, I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target." If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned = from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). So how can systems in site B communicate with systems in site C? I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. Can someone explain to me please? Thanks Fabien ------=_NextPart_000_01D2_01C503C6.D81C2BE0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Seems clear to me now.
 
Maybe in = draft-ietf-l3vpn-rfc2547bis-03.txt it=20 should explicitly be said that the spoke and hub here does not offer=20 connectivity
between the spoke.
 
Thanks all
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
To: jguichar@cisco.com ; marko.kulmala@tellabs.com =
Sent: Wednesday, January 26, 2005 3:34 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Jim,
Fabien asked us about example in = draft-ietf-l3vpn-rfc2547bis-03.txt=20 (4.3.5). In this examples authors show us how to build hub&spoke VPN = without=20 any connectivity between spokes.
Btw, I agree with you. There is another kind of VPN called = hub&spoke,=20 where traffic between spokes goes through hub. But it is not the case=20 of 4.3.5.
 
Marko,
As I can understand if you want to build hub&spoke VPN with = connectivity between spokes through hub, you have to organize one VPN = per spoke.=20 Each VPN must be "point-to-point" (including one spoke site and separate = (sub)interface on hub site). Than you must organize routing between = these=20 VPN on CE on hub Site.
So, we have as many different VPNs as spoke sites, you want to = connect to=20 hub.
 
Cheers
Taras

From: jguichar = [mailto:jguichar@cisco.com]=20
Sent: Wednesday, January 26, 2005 5:11 PM
To: = =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1;=20 fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org
Subject: RE: = Route=20 Target in BGP/MPLS IP VPN

Not exactly. It is actually both of these = things and=20 connectivity between spokes is driven by configuration. In one model = spokes=20 cannot communicate, in another they can (preferably via a firewall at = the hub).=20
 

Jim Guichard CCIE# 2069
System = Architect -=20 MPLS Technologies

ITD Boxborough
DD: 978-936-1586
Cell:=20 978-302-0481

 

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of=20 TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 = 8:43=20 AM
To: fabien.verhaeghe@atosorigin.com;=20 L3vpn@ietf.org
Subject: RE: Route Target in BGP/MPLS IP=20 VPN

Fabien: = "What I=20 understood is that Spoke can not communicate DIRECTLY with each other. = They=20 have
to go = through the=20 Hub."
Taras:
No, spokes can not communicate with each = other even=20 through hub. That is idea of hub&spoke VPN - it is VPN = with PARTIAL=20 connectivity.
Suppose, you have a large data center and = some clients of=20 data center. Clients want to reach data center, but they don't want = have ANY=20 connectivity with other clients due security reasons, for=20 example.
 
As to BGP routing, I may say, that PE router = on site B=20 (spoke Site) may receive all routes, including routes from site = C. But it=20 does not install routes to site C in its VRF routing table. Route = Target of=20 route from site C do not mach VRF "import" set of route target=20 attributes.
 
Taras

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 4:15 = PM
To:=20 L3vpn@ietf.org
Subject: Re: Route Target in BGP/MPLS IP=20 VPN

Thanks for your answer Taras = ,
 
What I understood is that Spoke can = not=20 communicate DIRECTLY with each other. They have
to go through the Hub. 
 
But if a packet is received at PE C = (from the=20 CE) for a destination address which is in site B he = won't
have any route that says to go = through the=20 Hub.
 
I'm talking about the routing between = PEs when I=20 make a reference to RFC1771 9.2.1. Not between CE and PE.
 
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 1:29 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, = and=20 sites B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE=20 and CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 = PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of =20 draft-ietf-l3vpn-rfc2547bis-03.txt states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be = done by the=20 use of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is = the Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to=20 the spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A = will=20 actually advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------=_NextPart_000_01D2_01C503C6.D81C2BE0-- From l3vpn-bounces@ietf.org Wed Jan 26 11:31:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13075 for ; Wed, 26 Jan 2005 11:31:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtqM5-0003Ez-Sy for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 11:49:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctq1l-0007BO-Rw; Wed, 26 Jan 2005 11:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtplD-0001fQ-8j for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 11:11:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11102 for ; Wed, 26 Jan 2005 11:11:12 -0500 (EST) From: TYushkov@microtest.ru Received: from janus.moscow.microtest.ru ([194.154.88.17] helo=relay2.moscow.microtest.ru) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctq27-0002bB-2P for L3vpn@ietf.org; Wed, 26 Jan 2005 11:28:46 -0500 Received: from nike.msk.mt ([10.240.28.6]) by relay2.moscow.microtest.ru with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Jan 2005 19:11:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C503C1.93A6AB74" Date: Wed, 26 Jan 2005 19:10:38 +0300 Message-ID: <715A34CD104ED041859430F0A63C37976920D5@nike.msk.mt> Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDvtkaPlcTB/23TyCOYW/Y3uTj1AAAXohA To: X-OriginalArrivalTime: 26 Jan 2005 16:11:02.0766 (UTC) FILETIME=[A1C6D0E0:01C503C1] X-Spam-Score: 0.9 (/) X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 8a7d7b1ff9fdb39b8762b25bc5367e56 This is a multi-part message in MIME format. ------_=_NextPart_001_01C503C1.93A6AB74 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable I agree with you! Btw, in RFC 2547 hub&spoke VPN was described not so deep. Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Target Attribute values, one meaning "Hub" and one meaning "Spoke". Then routes from the spokes could be distributed to the hub, without causing routes from the hub to be distributed to the spokes. =20 Who knows, may be authors of draft-ietf-l3vpn-rfc2547bis-03.txt will = describe h&s VPN more deeply. =20 Taras ________________________________ From: Fabien Verhaeghe [mailto:fabien.verhaeghe@atosorigin.com]=20 Sent: Wednesday, January 26, 2005 6:48 PM To: =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1; jguichar@cisco.com; = marko.kulmala@tellabs.com Cc: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN Seems clear to me now. =20 Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it should explicitly be said = that the spoke and hub here does not offer connectivity=20 between the spoke. =20 Thanks all Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: jguichar@cisco.com ; marko.kulmala@tellabs.com=20 Cc: L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 3:34 PM Subject: RE: Route Target in BGP/MPLS IP VPN Jim, Fabien asked us about example in draft-ietf-l3vpn-rfc2547bis-03.txt = (4.3.5). In this examples authors show us how to build hub&spoke VPN = without any connectivity between spokes. Btw, I agree with you. There is another kind of VPN called hub&spoke, = where traffic between spokes goes through hub. But it is not the case of = 4.3.5. =20 Marko, As I can understand if you want to build hub&spoke VPN with connectivity = between spokes through hub, you have to organize one VPN per spoke. Each = VPN must be "point-to-point" (including one spoke site and separate = (sub)interface on hub site). Than you must organize routing between = these VPN on CE on hub Site. So, we have as many different VPNs as spoke sites, you want to connect = to hub. =20 Cheers Taras ________________________________ From: jguichar [mailto:jguichar@cisco.com]=20 Sent: Wednesday, January 26, 2005 5:11 PM To: =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1; fabien.verhaeghe@atosorigin.com; = L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN Not exactly. It is actually both of these things and connectivity = between spokes is driven by configuration. In one model spokes cannot = communicate, in another they can (preferably via a firewall at the hub). = =20 Jim Guichard CCIE# 2069 System Architect - MPLS Technologies ITD Boxborough DD: 978-936-1586 Cell: 978-302-0481=20 =20 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of TYushkov@microtest.ru Sent: Wednesday, January 26, 2005 8:43 AM To: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN =09 =09 =09 Fabien: "What I understood is that Spoke can not communicate DIRECTLY = with each other. They have to go through the Hub." Taras: No, spokes can not communicate with each other even through hub. That = is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. Suppose, you have a large data center and some clients of data center. = Clients want to reach data center, but they don't want have ANY = connectivity with other clients due security reasons, for example. =20 As to BGP routing, I may say, that PE router on site B (spoke Site) may = receive all routes, including routes from site C. But it does not = install routes to site C in its VRF routing table. Route Target of route = from site C do not mach VRF "import" set of route target attributes. =20 Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 4:15 PM To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN =09 =09 Thanks for your answer Taras , =20 What I understood is that Spoke can not communicate DIRECTLY with each = other. They have to go through the Hub.=20 =20 But if a packet is received at PE C (from the CE) for a destination = address which is in site B he won't have any route that says to go through the Hub. =20 I'm talking about the routing between PEs when I make a reference to = RFC1771 9.2.1. Not between CE and PE. =20 Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate = with hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & C, = and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN =09 =09 =09 Hi, =20 I've got a question about the use of "Route Target" in BGP/MPLS IP VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: =20 "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At =09 the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke =09 site, "Hub" is the Import Target and "Spoke" is the Export Target." =20 If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke =20 In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes learned = from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). =20 So how can systems in site B communicate with systems in site C? =20 I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. =20 Can someone explain to me please? =20 Thanks Fabien =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C503C1.93A6AB74 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
I agree with you!
Btw, in RFC 2547 hub&spoke VPN was = described not so=20 deep.
Alternatively, suppose=20 one desired, for whatever reason, to create a
"hub and spoke" kind of = VPN.  This could be done by the use of two
Target Attribute = values, one=20 meaning "Hub" and one meaning "Spoke".
Then routes from the spokes = could be=20 distributed to the hub, without
causing routes from the hub to be = distributed=20 to the spokes.
 
Who knows, may be = authors of=20 draft-ietf-l3vpn-rfc2547bis-03.txt will describe h&s VPN more=20 deeply.
 
Taras

From: Fabien Verhaeghe=20 [mailto:fabien.verhaeghe@atosorigin.com]
Sent: Wednesday, = January 26,=20 2005 6:48 PM
To: =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1; = jguichar@cisco.com;=20 marko.kulmala@tellabs.com
Cc: = L3vpn@ietf.org
Subject: Re:=20 Route Target in BGP/MPLS IP VPN

Seems clear to me now.
 
Maybe in = draft-ietf-l3vpn-rfc2547bis-03.txt it=20 should explicitly be said that the spoke and hub here does not offer=20 connectivity
between the spoke.
 
Thanks all
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
To: jguichar@cisco.com ; marko.kulmala@tellabs.com =
Sent: Wednesday, January 26, 2005 3:34 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Jim,
Fabien asked us about example in = draft-ietf-l3vpn-rfc2547bis-03.txt=20 (4.3.5). In this examples authors show us how to build hub&spoke VPN = without=20 any connectivity between spokes.
Btw, I agree with you. There is another kind of VPN called = hub&spoke,=20 where traffic between spokes goes through hub. But it is not the case=20 of 4.3.5.
 
Marko,
As I can understand if you want to build hub&spoke VPN with = connectivity between spokes through hub, you have to organize one VPN = per spoke.=20 Each VPN must be "point-to-point" (including one spoke site and separate = (sub)interface on hub site). Than you must organize routing between = these=20 VPN on CE on hub Site.
So, we have as many different VPNs as spoke sites, you want to = connect to=20 hub.
 
Cheers
Taras

From: jguichar = [mailto:jguichar@cisco.com]=20
Sent: Wednesday, January 26, 2005 5:11 PM
To: = =DE=F8=EA=EE=E2 =D2=E0=F0=E0=F1;=20 fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org
Subject: RE: = Route=20 Target in BGP/MPLS IP VPN

Not exactly. It is actually both of these = things and=20 connectivity between spokes is driven by configuration. In one model = spokes=20 cannot communicate, in another they can (preferably via a firewall at = the hub).=20
 

Jim Guichard CCIE# 2069
System = Architect -=20 MPLS Technologies

ITD Boxborough
DD: 978-936-1586
Cell:=20 978-302-0481

 

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of=20 TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 = 8:43=20 AM
To: fabien.verhaeghe@atosorigin.com;=20 L3vpn@ietf.org
Subject: RE: Route Target in BGP/MPLS IP=20 VPN

Fabien: = "What I=20 understood is that Spoke can not communicate DIRECTLY with each other. = They=20 have
to go = through the=20 Hub."
Taras:
No, spokes can not communicate with each = other even=20 through hub. That is idea of hub&spoke VPN - it is VPN = with PARTIAL=20 connectivity.
Suppose, you have a large data center and = some clients of=20 data center. Clients want to reach data center, but they don't want = have ANY=20 connectivity with other clients due security reasons, for=20 example.
 
As to BGP routing, I may say, that PE router = on site B=20 (spoke Site) may receive all routes, including routes from site = C. But it=20 does not install routes to site C in its VRF routing table. Route = Target of=20 route from site C do not mach VRF "import" set of route target=20 attributes.
 
Taras

From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 4:15 = PM
To:=20 L3vpn@ietf.org
Subject: Re: Route Target in BGP/MPLS IP=20 VPN

Thanks for your answer Taras = ,
 
What I understood is that Spoke can = not=20 communicate DIRECTLY with each other. They have
to go through the Hub. 
 
But if a packet is received at PE C = (from the=20 CE) for a destination address which is in site B he = won't
have any route that says to go = through the=20 Hub.
 
I'm talking about the routing between = PEs when I=20 make a reference to RFC1771 9.2.1. Not between CE and PE.
 
Fabien
 
----- Original Message -----=20
From: TYushkov@microtest.ru
Sent: Wednesday, January 26, 2005 1:29 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Hi,

The=20 main idea of Hub&spoke is the=20 following: spokes may communicate with hub, but spokes can NOT=20 communicate with each other.

So,=20 everything seems to be ok. Site A can communicate with site B & C, = and=20 sites B & C can't communicate with each other.

As=20 I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE=20 and CE. So RFC1771 9.2.1 it's not our case.

 

Cheers.

Taras


From: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien=20 Verhaeghe
Sent: Wednesday, January 26, 2005 3:03 = PM
To:=20 L3vpn@ietf.org
Subject: Route Target in BGP/MPLS IP=20 VPN

Hi,
 
I've got a question about the use of "Route = Target" in=20 BGP/MPLS IP VPN
Section 4.3.5 of =20 draft-ietf-l3vpn-rfc2547bis-03.txt states:
 
"Alternatively, = suppose one=20 desired, for whatever reason, to create a
"hub and spoke" kind of VPN. This could be = done by the=20 use of two
Route Target values, one meaning "Hub" and one = meaning=20 "Spoke". At
the VRFs attached to the hub sites, "Hub" is = the Export=20 Target and
"Spoke" is the Import Target. At the VRFs = attached to=20 the spoke
site, "Hub" is the Import Target and "Spoke" is the Export = Target."
 
If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF = per=20 CE/PE.
Site A is the hub
Site B,C are spoke
 
In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes=20 learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).
 
So how can systems in site B communicate with systems in site = C?
 
I guess I misunderstood something, and PE connected to site A = will=20 actually advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.
 
Can someone explain to me please?
 
Thanks
Fabien
 
 
 
 
 
 
 
 
------_=_NextPart_001_01C503C1.93A6AB74-- From l3vpn-bounces@ietf.org Wed Jan 26 11:33:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13226 for ; Wed, 26 Jan 2005 11:33:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtqO6-0003IA-LT for l3vpn-web-archive@ietf.org; Wed, 26 Jan 2005 11:51:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctq2Q-0007MM-PE; Wed, 26 Jan 2005 11:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctppf-0003UE-8p for l3vpn@megatron.ietf.org; Wed, 26 Jan 2005 11:15:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11504 for ; Wed, 26 Jan 2005 11:15:48 -0500 (EST) Received: from mailgate1b.savvis.net ([216.91.182.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctq6a-0002jl-JI for L3vpn@ietf.org; Wed, 26 Jan 2005 11:33:22 -0500 Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (8.12.10/8.12.1) with ESMTP id j0QGEbIU028135; Wed, 26 Jan 2005 10:14:37 -0600 Received: from s228130hz1ew08.apptix-01.savvis.net ([10.146.4.8]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jan 2005 10:14:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2005 10:14:21 -0600 Message-ID: Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDwF7mKrLYQUKTTw+maCILBrAZHwAADzAgAABVgzA= From: "Schliesser, Benson" To: "Fabien Verhaeghe" , , , X-OriginalArrivalTime: 26 Jan 2005 16:14:42.0144 (UTC) FILETIME=[24893E00:01C503C2] X-ECS-MailScanner: No virus is found X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable If the Hub advertises an aggregate prefix (0/0, 10/8, etc.) then it = should support spoke-spoke traffic, per the draft. (section 5 refers = back to 4.3.2, which explains this) Cheers, -Benson =20 =09 =09 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf = Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:48 PM To: TYushkov@microtest.ru; jguichar@cisco.com; = marko.kulmala@tellabs.com Cc: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN =09 =09 Seems clear to me now. =20 Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it should explicitly be = said that the spoke and hub here does not offer connectivity=20 between the spoke. =20 Thanks all Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: jguichar@cisco.com ; marko.kulmala@tellabs.com=20 Cc: L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 3:34 PM Subject: RE: Route Target in BGP/MPLS IP VPN Jim, Fabien asked us about example in draft-ietf-l3vpn-rfc2547bis-03.txt = (4.3.5). In this examples authors show us how to build hub&spoke VPN = without any connectivity between spokes. Btw, I agree with you. There is another kind of VPN called hub&spoke, = where traffic between spokes goes through hub. But it is not the case of = 4.3.5. =20 Marko, As I can understand if you want to build hub&spoke VPN with = connectivity between spokes through hub, you have to organize one VPN = per spoke. Each VPN must be "point-to-point" (including one spoke site = and separate (sub)interface on hub site). Than you must organize routing = between these VPN on CE on hub Site. So, we have as many different VPNs as spoke sites, you want to connect = to hub. =20 Cheers Taras ________________________________ From: jguichar [mailto:jguichar@cisco.com]=20 Sent: Wednesday, January 26, 2005 5:11 PM To: =E0=DB=CB=CF=D7 =F4=C1=D2=C1=D3; fabien.verhaeghe@atosorigin.com; = L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN =09 =09 Not exactly. It is actually both of these things and connectivity = between spokes is driven by configuration. In one model spokes cannot = communicate, in another they can (preferably via a firewall at the hub). = =20 Jim Guichard CCIE# 2069 System Architect - MPLS Technologies =09 ITD Boxborough DD: 978-936-1586 Cell: 978-302-0481=20 =20 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On = Behalf Of TYushkov@microtest.ru Sent: Wednesday, January 26, 2005 8:43 AM To: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN =09 =09 Fabien: "What I understood is that Spoke can not communicate = DIRECTLY with each other. They have to go through the Hub." Taras: No, spokes can not communicate with each other even through hub. = That is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. Suppose, you have a large data center and some clients of data = center. Clients want to reach data center, but they don't want have ANY = connectivity with other clients due security reasons, for example. =20 As to BGP routing, I may say, that PE router on site B (spoke Site) = may receive all routes, including routes from site C. But it does not = install routes to site C in its VRF routing table. Route Target of route = from site C do not mach VRF "import" set of route target attributes. =20 Taras ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On = Behalf Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 4:15 PM To: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN =09 =09 Thanks for your answer Taras , =20 What I understood is that Spoke can not communicate DIRECTLY with = each other. They have to go through the Hub.=20 =20 But if a packet is received at PE C (from the CE) for a destination = address which is in site B he won't have any route that says to go through the Hub. =20 I'm talking about the routing between PEs when I make a reference to = RFC1771 9.2.1. Not between CE and PE. =20 Fabien =20 ----- Original Message -----=20 From: TYushkov@microtest.ru=20 To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 Sent: Wednesday, January 26, 2005 1:29 PM Subject: RE: Route Target in BGP/MPLS IP VPN Hi, The main idea of Hub&spoke is the following: spokes may communicate = with hub, but spokes can NOT communicate with each other. So, everything seems to be ok. Site A can communicate with site B & = C, and sites B & C can't communicate with each other. As I can understand we may use: RIPv2, OSPF and EBGP to make routing = between PE and CE. So RFC1771 9.2.1 it's not our case. =20 Cheers. Taras =09 ________________________________ From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On = Behalf Of Fabien Verhaeghe Sent: Wednesday, January 26, 2005 3:03 PM To: L3vpn@ietf.org Subject: Route Target in BGP/MPLS IP VPN =09 =09 Hi, =20 I've got a question about the use of "Route Target" in BGP/MPLS IP = VPN Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: =20 "Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Route Target values, one meaning "Hub" and one meaning "Spoke". At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target. At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export = Target." =20 If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per = CE/PE. Site A is the hub Site B,C are spoke =20 In A VRF I would have the routes to both sites B and C In B,C VRF I would only have routes to A since with BGP routes = learned from IBGP are not advertised to BGP peer in the same AS (RFC 1771 9.2.1). =20 So how can systems in site B communicate with systems in site C? =20 I guess I misunderstood something, and PE connected to site A will = actually advertised routes received from site C to site B. But it seems inconsistent with RFC 1771 9.2.1. =20 Can someone explain to me please? =20 Thanks Fabien =20 =20 =20 =20 =20 =20 =20 =09 From l3vpn-bounces@ietf.org Thu Jan 27 01:34:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07301 for ; Thu, 27 Jan 2005 01:34:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu3VM-0000fU-39 for l3vpn-web-archive@ietf.org; Thu, 27 Jan 2005 01:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu37b-00009r-K0; Thu, 27 Jan 2005 01:27:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu36d-0008MX-OL for l3vpn@megatron.ietf.org; Thu, 27 Jan 2005 01:26:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06886 for ; Thu, 27 Jan 2005 01:26:14 -0500 (EST) Received: from mx.tellabs.fi ([193.65.253.34] helo=mx2-priv.tellabs.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu3NL-0000VI-3d for l3vpn@ietf.org; Thu, 27 Jan 2005 01:43:48 -0500 Received: from fies1wms01b.tellabs.fi (HELO FIESEX1.tellabs-east.tellabsinc.net) (172.19.6.62) by mx2-priv.tellabs.fi with ESMTP; 27 Jan 2005 00:25:09 -0600 X-SBRS: None X-IronPort-AV: i="3.88,156,1102312800"; d="scan'208"; a="586532:sNHT24425788" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2005 08:25:04 +0200 Message-ID: <4EE011314003124CA4389D37DC21940F011C71A6@FIESEX1.tellabs-east.tellabsinc.net> Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDwF7mKrLYQUKTTw+maCILBrAZHwAADzAgAABVgzAAHXIpIA== From: "Kulmala, Marko" To: "Schliesser, Benson" , "Fabien Verhaeghe" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: quoted-printable Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Content-Transfer-Encoding: quoted-printable Benson, Yes, it does support spoke-spoke traffic in that way but spoke-spoke traffi= c does not go through customer hub site instead it would only through hub P= E=2E This is because VRF (import RT=3Dhub, export RT=3Dspoke) in hub PE has also= those more specific routes to the spokes. Thus, from customer point of view, this is full mesh VPN. To make the spoke-spoke traffic go through customer hub site a bit more com= plex implementation is needed.=20 Marko > -----Original Message----- > From: Schliesser, Benson [mailto:benson.schliesser@savvis.net]=20 > Sent: 26. tammikuuta 2005 18:14 > To: Fabien Verhaeghe; TYushkov@microtest.ru;=20 > jguichar@cisco.com; Kulmala, Marko > Cc: L3vpn@ietf.org > Subject: RE: Route Target in BGP/MPLS IP VPN >=20 >=20 > If the Hub advertises an aggregate prefix (0/0, 10/8, etc.)=20 > then it should support spoke-spoke traffic, per the draft.=20 > (section 5 refers back to 4.3.2, which explains this) >=20 > Cheers, > -Benson > =20 > =09 > =09 >=20 > ________________________________ >=20 > From: l3vpn-bounces@ietf.org=20 > [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe > Sent: Wednesday, January 26, 2005 3:48 PM > To: TYushkov@microtest.ru; jguichar@cisco.com;=20 > marko.kulmala@tellabs.com > Cc: L3vpn@ietf.org > Subject: Re: Route Target in BGP/MPLS IP VPN > =09 > =09 > Seems clear to me now. > =20 > Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it=20 > should explicitly be said that the spoke and hub here does=20 > not offer connectivity=20 > between the spoke. > =20 > Thanks all > Fabien > =20 > ----- Original Message -----=20 > From: TYushkov@microtest.ru=20 > To: jguichar@cisco.com ; marko.kulmala@tellabs.com=20 > Cc: L3vpn@ietf.org=20 > Sent: Wednesday, January 26, 2005 3:34 PM > Subject: RE: Route Target in BGP/MPLS IP VPN >=20 > Jim, > Fabien asked us about example in=20 > draft-ietf-l3vpn-rfc2547bis-03.txt (4.3.5). In this examples=20 > authors show us how to build hub&spoke VPN without any=20 > connectivity between spokes. > Btw, I agree with you. There is another kind of=20 > VPN called hub&spoke, where traffic between spokes goes=20 > through hub. But it is not the case of 4.3.5. > =20 > Marko, > As I can understand if you want to build=20 > hub&spoke VPN with connectivity between spokes through hub,=20 > you have to organize one VPN per spoke. Each VPN must be=20 > "point-to-point" (including one spoke site and separate=20 > (sub)interface on hub site). Than you must organize routing=20 > between these VPN on CE on hub Site. > So, we have as many different VPNs as spoke=20 > sites, you want to connect to hub. > =20 > Cheers > Taras >=20 > ________________________________ >=20 > From: jguichar [mailto:jguichar@cisco.com]=20 > Sent: Wednesday, January 26, 2005 5:11 PM > To: =E0=DB=CB=CF=D7 =F4=C1=D2=C1=D3;=20 > fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org > Subject: RE: Route Target in BGP/MPLS IP VPN > =09 > =09 > Not exactly. It is actually both of these=20 > things and connectivity between spokes is driven by=20 > configuration. In one model spokes cannot communicate, in=20 > another they can (preferably via a firewall at the hub).=20 > =20 >=20 > Jim Guichard CCIE# 2069 > System Architect - MPLS Technologies > =09 > ITD Boxborough > DD: 978-936-1586 > Cell: 978-302-0481=20 >=20 > =20 >=20 >=20 > ________________________________ >=20 > From: l3vpn-bounces@ietf.org=20 > [mailto:l3vpn-bounces@ietf.org] On Behalf Of TYushkov@microtest.ru > Sent: Wednesday, January 26, 2005 8:43 AM > To: fabien.verhaeghe@atosorigin.com;=20 > L3vpn@ietf.org > Subject: RE: Route Target in BGP/MPLS IP VPN > =09 > =09 > Fabien: "What I=20 > understood is that Spoke can not communicate DIRECTLY with=20 > each other. They have > to go through the Hub." > Taras: > No, spokes can=20 > not communicate with each other even through hub. That is=20 > idea of hub&spoke VPN - it is VPN with PARTIAL connectivity. > Suppose, you have a large data center=20 > and some clients of data center. Clients want to reach data=20 > center, but they don't want have ANY connectivity with other=20 > clients due security reasons, for example. > =20 > As to BGP routing, I may say, that PE=20 > router on site B (spoke Site) may receive all routes,=20 > including routes from site C. But it does not install routes=20 > to site C in its VRF routing table. Route Target of route=20 > from site C do not mach VRF "import" set of route target attributes. > =20 > Taras >=20 > ________________________________ >=20 > From: l3vpn-bounces@ietf.org=20 > [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe > Sent: Wednesday, January 26, 2005 4:15 PM > To: L3vpn@ietf.org > Subject: Re: Route Target in BGP/MPLS IP VPN > =09 > =09 > Thanks for your answer Taras , > =20 > What I understood is that Spoke can not=20 > communicate DIRECTLY with each other. They have > to go through the Hub.=20 > =20 > But if a packet is received at PE C=20 > (from the CE) for a destination address which is in site B he won't > have any route that says to go through the Hub. > =20 > I'm talking about the routing between=20 > PEs when I make a reference to RFC1771 9.2.1. Not between CE and PE. > =20 > Fabien > =20 > ----- Original Message -----=20 > From: TYushkov@microtest.ru=20 > To: fabien.verhaeghe@atosorigin.com ;=20 > L3vpn@ietf.org=20 > Sent: Wednesday, January 26, 2005 1:29 PM > Subject: RE: Route Target in BGP/MPLS IP VPN >=20 > Hi, >=20 > The main idea of Hub&spoke is the=20 > following: spokes may communicate with hub, but spokes can=20 > NOT communicate with each other. >=20 > So, everything seems to be ok. Site A=20 > can communicate with site B & C, and sites B & C can't=20 > communicate with each other. >=20 > As I can understand we may use: RIPv2,=20 > OSPF and EBGP to make routing between PE and CE. So RFC1771=20 > 9.2.1 it's not our case. >=20 > =20 >=20 > Cheers. >=20 > Taras >=20 > =09 > ________________________________ >=20 > From: l3vpn-bounces@ietf.org=20 > [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe > Sent: Wednesday, January 26, 2005 3:03 PM > To: L3vpn@ietf.org > Subject: Route Target in BGP/MPLS IP VPN > =09 > =09 > Hi, > =20 > I've got a question about the use of=20 > "Route Target" in BGP/MPLS IP VPN > Section 4.3.5 of =20 > draft-ietf-l3vpn-rfc2547bis-03.txt states: > =20 > "Alternatively, suppose one desired,=20 > for whatever reason, to create a > "hub and spoke" kind of VPN. This could=20 > be done by the use of two > Route Target values, one meaning "Hub"=20 > and one meaning "Spoke". At > the VRFs=20 > attached to the hub sites, "Hub" is the Export Target and > "Spoke" is the Import Target. At the=20 > VRFs attached to the spoke > site, "Hub" is=20 > the Import Target and "Spoke" is the Export Target." > =20 > If I have 3 sites A,B,C. one CE/PE pair=20 > for each site and one VRF per CE/PE. > Site A is the hub > Site B,C are spoke > =20 > In A VRF I would have the routes to=20 > both sites B and C > In B,C VRF I would only have routes to=20 > A since with BGP routes learned from IBGP are not > advertised to BGP peer in the same AS=20 > (RFC 1771 9.2.1). > =20 > So how can systems in site B=20 > communicate with systems in site C? > =20 > I guess I misunderstood something, and=20 > PE connected to site A will actually advertised routes=20 > received from site C > to site B. But it seems inconsistent=20 > with RFC 1771 9.2.1. > =20 > Can someone explain to me please? > =20 > Thanks > Fabien > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =09 >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From l3vpn-bounces@ietf.org Thu Jan 27 06:30:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18396 for ; Thu, 27 Jan 2005 06:30:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu88L-0007nd-Av for l3vpn-web-archive@ietf.org; Thu, 27 Jan 2005 06:48:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu7oi-0002Ys-PE; Thu, 27 Jan 2005 06:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu7ef-00080Z-DU for l3vpn@megatron.ietf.org; Thu, 27 Jan 2005 06:17:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17076 for ; Thu, 27 Jan 2005 06:17:38 -0500 (EST) Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu7vm-0007Tq-19 for L3vpn@ietf.org; Thu, 27 Jan 2005 06:35:22 -0500 Received: from balavenkata@netscape.net by imo-d01.mx.aol.com (mail_out_v37_r3.8.) id f.e9.103b0771 (16239); Thu, 27 Jan 2005 06:16:59 -0500 (EST) Received: from [192.168.3.2] (210.211.187.92.vsnl.net.in [210.211.187.92]) by air-in03.mx.aol.com (v104.17) with ESMTP id MAILININ33-3f6f41f8cda425d; Thu, 27 Jan 2005 06:16:58 -0500 Message-ID: <41F8AEDD.9020509@netscape.net> Date: Thu, 27 Jan 2005 14:35:33 +0530 From: Bala Venkata User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: E.T.Metz@telecom.tno.nl References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 210.211.187.92 X-Mailer: Unknown (No Version) X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: L3vpn@ietf.org Subject: Re: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Eduard- When you say "This will result in traffic from CE-B to CE-C to go like this CE-B -> PE-B -> PE-A -> CE-A -> PE-A -> PE-C -> CE-C." are you assuming that PE-A has two VRF's ? One to import the routes from the spokes and the other two export its (CE-A's) routes to them ? Just wanted to be clear on your "PE-A -> CE-A -> PE-A" portion. (btw, it is confusing to call everything "hub and spoke" - I vaguely remember coming across the phrase "Central Services" must be in Guichard's book...?) Thanks ! E.T.Metz@telecom.tno.nl wrote: > > In a hub-and-spoke VPN, spoke-sites (assuming these do not share a VRF > when connected to the same PE) cannot communicate with eachother > directly, i.e. spoke-PE to spoke-PE. If spoke-sites need to communicate > with eachother the communication path indeed goes (must go) through the > hub-CE, the underlying requirement could e.g. be that traffic between B > and C needs to pass a firewall at A. Note that the hub-PE never acts as > a 'transit' node in this case. To achieve spoke-spoke communication you > either need to advertise an aggregate (covering the spoke-subnets or > entire VPN) or a default from the hub-site (CE), and ensure that the > hub-CE has specific routes to the spoke-CEs pointing to the hub-PE. This > will result in traffic from CE-B to CE-C to go like this CE-B -> PE-B -> > PE-A -> CE-A -> PE-A -> PE-C -> CE-C. > > Hope this helps. > > cheers, > Eduard > > ________________________________ > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > Behalf Of Fabien Verhaeghe > Sent: woensdag 26 januari 2005 14:15 > To: L3vpn@ietf.org > Subject: Re: Route Target in BGP/MPLS IP VPN > > > Thanks for your answer Taras , > > What I understood is that Spoke can not communicate DIRECTLY > with each other. They have > to go through the Hub. > But if a packet is received at PE C (from the CE) for a > destination address which is in site B he won't > have any route that says to go through the Hub. > > I'm talking about the routing between PEs when I make a > reference to RFC1771 9.2.1. Not between CE and PE. > > Fabien > > ----- Original Message ----- > From: TYushkov@microtest.ru > To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org > Sent: Wednesday, January 26, 2005 1:29 PM > Subject: RE: Route Target in BGP/MPLS IP VPN > > Hi, > > The main idea of Hub&spoke is the following: spokes may > communicate with hub, but spokes can NOT communicate with each other. > > So, everything seems to be ok. Site A can communicate with site > B & C, and sites B & C can't communicate with each other. > > As I can understand we may use: RIPv2, OSPF and EBGP to make > routing between PE and CE. So RFC1771 9.2.1 it's not our case. > > > > Cheers. > > Taras > > > ________________________________ > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > Behalf Of Fabien Verhaeghe > Sent: Wednesday, January 26, 2005 3:03 PM > To: L3vpn@ietf.org > Subject: Route Target in BGP/MPLS IP VPN > > > Hi, > > I've got a question about the use of "Route Target" in BGP/MPLS > IP VPN > Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: > > "Alternatively, suppose one desired, for whatever reason, to > create a > "hub and spoke" kind of VPN. This could be done by the use of > two > Route Target values, one meaning "Hub" and one meaning "Spoke". > At > the VRFs attached to the hub sites, "Hub" is the Export > Target and > "Spoke" is the Import Target. At the VRFs attached to the spoke > site, "Hub" is the Import Target and "Spoke" is the > Export Target." > > If I have 3 sites A,B,C. one CE/PE pair for each site and one > VRF per CE/PE. > Site A is the hub > Site B,C are spoke > > In A VRF I would have the routes to both sites B and C > In B,C VRF I would only have routes to A since with BGP routes > learned from IBGP are not > advertised to BGP peer in the same AS (RFC 1771 9.2.1). > > So how can systems in site B communicate with systems in site C? > > I guess I misunderstood something, and PE connected to site A > will actually advertised routes received from site C > to site B. But it seems inconsistent with RFC 1771 9.2.1. > > Can someone explain to me please? > > Thanks > Fabien > From l3vpn-bounces@ietf.org Thu Jan 27 07:06:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23431 for ; Thu, 27 Jan 2005 07:06:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu8gs-0000Jh-E2 for l3vpn-web-archive@ietf.org; Thu, 27 Jan 2005 07:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu8ML-0002nF-I3; Thu, 27 Jan 2005 07:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu8Io-0001sK-4B for l3vpn@megatron.ietf.org; Thu, 27 Jan 2005 06:59:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22414 for ; Thu, 27 Jan 2005 06:59:06 -0500 (EST) From: E.T.Metz@telecom.tno.nl Received: from ds04.tnoase.telecom.tno.nl ([139.63.192.204] helo=ds04.telecom.tno.nl) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu8Zv-00009d-3L for L3vpn@ietf.org; Thu, 27 Jan 2005 07:16:51 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 27 Jan 2005 12:59:02 +0100 Message-ID: Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUEYb6ncvBCR6u8TWGIPx8qEcAWuAAA7MYw To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable You could do this using two VRFs.=20 I don't think it is required though (but this could be implementation dependent). As far as I understand this, a PE never passes on VPN traffic received from one PE to another PE (i.e. PE has no transit function). Thus even though the VRF on PE A has more specific entries for let's say site C in the example below, these would not be valid for traffic received from another PE -e.g. PE B (because the next-hop is a PE as well) and the PE would/should only consider 'CE' next-hops as valid. cheers, Eduard > -----Original Message----- > From: Bala Venkata [mailto:balavenkata@netscape.net]=20 > Sent: donderdag 27 januari 2005 10:06 > To: Metz, E.T. > Cc: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org > Subject: Re: Route Target in BGP/MPLS IP VPN >=20 > Eduard- >=20 > When you say >=20 > "This will result in traffic from CE-B to CE-C to go like=20 > this CE-B ->=20 > PE-B -> PE-A -> CE-A -> PE-A -> PE-C -> CE-C." >=20 > are you assuming that PE-A has two VRF's ? One to import the routes > from the spokes and the other two export its (CE-A's) routes to them ? > Just wanted to be clear on your "PE-A -> CE-A -> PE-A" portion. >=20 > (btw, it is confusing to call everything "hub and spoke" - I vaguely > remember coming across the phrase "Central Services" must be in=20 > Guichard's book...?) >=20 >=20 > Thanks ! >=20 >=20 > E.T.Metz@telecom.tno.nl wrote: > > =20 > > In a hub-and-spoke VPN, spoke-sites (assuming these do not=20 > share a VRF > > when connected to the same PE) cannot communicate with eachother > > directly, i.e. spoke-PE to spoke-PE. If spoke-sites need to=20 > communicate > > with eachother the communication path indeed goes (must go)=20 > through the > > hub-CE, the underlying requirement could e.g. be that=20 > traffic between B > > and C needs to pass a firewall at A. Note that the hub-PE=20 > never acts as > > a 'transit' node in this case. To achieve spoke-spoke=20 > communication you > > either need to advertise an aggregate (covering the spoke-subnets or > > entire VPN) or a default from the hub-site (CE), and ensure that the > > hub-CE has specific routes to the spoke-CEs pointing to the=20 > hub-PE. This > > will result in traffic from CE-B to CE-C to go like this=20 > CE-B -> PE-B -> > > PE-A -> CE-A -> PE-A -> PE-C -> CE-C. > >=20 > > Hope this helps. > >=20 > > cheers, > > Eduard > >=20 > > ________________________________ > >=20 > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > > Behalf Of Fabien Verhaeghe > > Sent: woensdag 26 januari 2005 14:15 > > To: L3vpn@ietf.org > > Subject: Re: Route Target in BGP/MPLS IP VPN > > =20 > > =20 > > Thanks for your answer Taras , > > =20 > > What I understood is that Spoke can not communicate DIRECTLY > > with each other. They have > > to go through the Hub. > > But if a packet is received at PE C (from the CE) for a > > destination address which is in site B he won't > > have any route that says to go through the Hub. > > =20 > > I'm talking about the routing between PEs when I make a > > reference to RFC1771 9.2.1. Not between CE and PE. > > =20 > > Fabien > > =20 > > ----- Original Message -----=20 > > From: TYushkov@microtest.ru=20 > > To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 > > Sent: Wednesday, January 26, 2005 1:29 PM > > Subject: RE: Route Target in BGP/MPLS IP VPN > >=20 > > Hi, > >=20 > > The main idea of Hub&spoke is the following: spokes may > > communicate with hub, but spokes can NOT communicate with=20 > each other. > >=20 > > So, everything seems to be ok. Site A can communicate with site > > B & C, and sites B & C can't communicate with each other. > >=20 > > As I can understand we may use: RIPv2, OSPF and EBGP to make > > routing between PE and CE. So RFC1771 9.2.1 it's not our case. > >=20 > > =20 > >=20 > > Cheers. > >=20 > > Taras > >=20 > > =20 > > ________________________________ > >=20 > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > > Behalf Of Fabien Verhaeghe > > Sent: Wednesday, January 26, 2005 3:03 PM > > To: L3vpn@ietf.org > > Subject: Route Target in BGP/MPLS IP VPN > > =20 > > =20 > > Hi, > > =20 > > I've got a question about the use of "Route Target" in BGP/MPLS > > IP VPN > > Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: > > =20 > > "Alternatively, suppose one desired, for whatever reason, to > > create a > > "hub and spoke" kind of VPN. This could be done by the use of > > two > > Route Target values, one meaning "Hub" and one meaning "Spoke". > > At > > the VRFs attached to the hub sites, "Hub" is the Export > > Target and > > "Spoke" is the Import Target. At the VRFs attached to the spoke > > site, "Hub" is the Import Target and "Spoke" is the > > Export Target." > > =20 > > If I have 3 sites A,B,C. one CE/PE pair for each site and one > > VRF per CE/PE. > > Site A is the hub > > Site B,C are spoke > > =20 > > In A VRF I would have the routes to both sites B and C > > In B,C VRF I would only have routes to A since with BGP routes > > learned from IBGP are not > > advertised to BGP peer in the same AS (RFC 1771 9.2.1). > > =20 > > So how can systems in site B communicate with systems in site C? > > =20 > > I guess I misunderstood something, and PE connected to site A > > will actually advertised routes received from site C > > to site B. But it seems inconsistent with RFC 1771 9.2.1. > > =20 > > Can someone explain to me please? > > =20 > > Thanks > > Fabien > > =20 >=20 >=20 From l3vpn-bounces@ietf.org Thu Jan 27 08:21:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01437 for ; Thu, 27 Jan 2005 08:21:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu9rs-0002J3-15 for l3vpn-web-archive@ietf.org; Thu, 27 Jan 2005 08:39:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu9ZF-00074C-LY; Thu, 27 Jan 2005 08:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu9Qa-00053E-JQ for l3vpn@megatron.ietf.org; Thu, 27 Jan 2005 08:11:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00112 for ; Thu, 27 Jan 2005 08:11:14 -0500 (EST) Received: from mailgate1b.savvis.net ([216.91.182.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu9hi-000224-03 for L3vpn@ietf.org; Thu, 27 Jan 2005 08:28:58 -0500 Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44]) by mailgate1b.savvis.net (8.12.10/8.12.1) with ESMTP id j0RDAeUE031930; Thu, 27 Jan 2005 07:10:40 -0600 Received: from s228130hz1ew08.apptix-01.savvis.net ([10.146.4.8]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 07:10:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2005 07:10:17 -0600 Message-ID: Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUDwF7mKrLYQUKTTw+maCILBrAZHwAADzAgAABVgzAAHXIpIAANtWxA From: "Schliesser, Benson" To: "Kulmala, Marko" , "Fabien Verhaeghe" , , X-OriginalArrivalTime: 27 Jan 2005 13:10:44.0672 (UTC) FILETIME=[9C1A6C00:01C50471] X-ECS-MailScanner: No virus is found X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Content-Transfer-Encoding: quoted-printable Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Content-Transfer-Encoding: quoted-printable Marko- Yes, from a customer perspective there is complete reachability between = all sites in the VPN. Though, complete reachability and full-mesh = connectivity are different things. The rationale I had in mind, from a SP perspective, for creating a = sub-full-mesh topology while maintaining complete reachability in the = VPN, is so that the Hub PE node could be used to provide some layered = services, that might be unique to it amongst PEs. (Firewall, IDS, = content caching or filtering, QOS policy, etc.) I agree though, that making spoke-spoke traffic traverse a "Hub" CE is a = bit more difficult. A customer who wants this sort of topology is just = as well off with CE-CE tunnels (i.e. GRE) or a pt-pt L2 network (i.e. FR = PW/PVC). Cheers, -Benson > -----Original Message----- > From: Kulmala, Marko [mailto:marko.kulmala@tellabs.com]=20 > Sent: Thursday, January 27, 2005 6:25 AM > To: Schliesser, Benson; Fabien Verhaeghe;=20 > TYushkov@microtest.ru; jguichar@cisco.com > Cc: L3vpn@ietf.org > Subject: RE: Route Target in BGP/MPLS IP VPN >=20 > Benson, >=20 > Yes, it does support spoke-spoke traffic in that way but=20 > spoke-spoke traffic does not go through customer hub site=20 > instead it would only through hub PE. > This is because VRF (import RT=3Dhub, export RT=3Dspoke) in hub=20 > PE has also those more specific routes to the spokes. > Thus, from customer point of view, this is full mesh VPN. >=20 > To make the spoke-spoke traffic go through customer hub site=20 > a bit more complex implementation is needed.=20 >=20 > Marko >=20 > > -----Original Message----- > > From: Schliesser, Benson [mailto:benson.schliesser@savvis.net] > > Sent: 26. tammikuuta 2005 18:14 > > To: Fabien Verhaeghe; TYushkov@microtest.ru; jguichar@cisco.com;=20 > > Kulmala, Marko > > Cc: L3vpn@ietf.org > > Subject: RE: Route Target in BGP/MPLS IP VPN > >=20 > >=20 > > If the Hub advertises an aggregate prefix (0/0, 10/8, etc.) then it=20 > > should support spoke-spoke traffic, per the draft. > > (section 5 refers back to 4.3.2, which explains this) > >=20 > > Cheers, > > -Benson > > =20 > > =09 > > =09 > >=20 > > ________________________________ > >=20 > > From: l3vpn-bounces@ietf.org > > [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe > > Sent: Wednesday, January 26, 2005 3:48 PM > > To: TYushkov@microtest.ru; jguichar@cisco.com;=20 > > marko.kulmala@tellabs.com > > Cc: L3vpn@ietf.org > > Subject: Re: Route Target in BGP/MPLS IP VPN > > =09 > > =09 > > Seems clear to me now. > > =20 > > Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it=20 > should explicitly be=20 > > said that the spoke and hub here does not offer connectivity > > between the spoke. > > =20 > > Thanks all > > Fabien > > =20 > > ----- Original Message -----=20 > > From: TYushkov@microtest.ru=20 > > To: jguichar@cisco.com ; marko.kulmala@tellabs.com=20 > > Cc: L3vpn@ietf.org=20 > > Sent: Wednesday, January 26, 2005 3:34 PM > > Subject: RE: Route Target in BGP/MPLS IP VPN > >=20 > > Jim, > > Fabien asked us about example in > > draft-ietf-l3vpn-rfc2547bis-03.txt (4.3.5). In this=20 > examples authors=20 > > show us how to build hub&spoke VPN without any connectivity between=20 > > spokes. > > Btw, I agree with you. There is another kind of=20 > VPN called=20 > > hub&spoke, where traffic between spokes goes through hub. But it is=20 > > not the case of 4.3.5. > > =20 > > Marko, > > As I can understand if you want to build=20 > hub&spoke VPN with=20 > > connectivity between spokes through hub, you have to=20 > organize one VPN=20 > > per spoke. Each VPN must be "point-to-point" (including one=20 > spoke site=20 > > and separate (sub)interface on hub site). Than you must organize=20 > > routing between these VPN on CE on hub Site. > > So, we have as many different VPNs as spoke=20 > sites, you want to=20 > > connect to hub. > > =20 > > Cheers > > Taras > >=20 > > ________________________________ > >=20 > > From: jguichar [mailto:jguichar@cisco.com]=20 > > Sent: Wednesday, January 26, 2005 5:11 PM > > To: =E0=DB=CB=CF=D7 =F4=C1=D2=C1=D3; > > fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org > > Subject: RE: Route Target in BGP/MPLS IP VPN > > =09 > > =09 > > Not exactly. It is actually both of these=20 > things and connectivity=20 > > between spokes is driven by configuration. In one model=20 > spokes cannot=20 > > communicate, in another they can (preferably via a firewall at the=20 > > hub). > > =20 > >=20 > > Jim Guichard CCIE# 2069 > > System Architect - MPLS Technologies > > =09 > > ITD Boxborough > > DD: 978-936-1586 > > Cell: 978-302-0481 > >=20 > > =20 > >=20 > >=20 > > ________________________________ > >=20 > > From: l3vpn-bounces@ietf.org > > [mailto:l3vpn-bounces@ietf.org] On Behalf Of TYushkov@microtest.ru > > Sent: Wednesday, January 26, 2005 8:43 AM > > To: fabien.verhaeghe@atosorigin.com;=20 > L3vpn@ietf.org > > Subject: RE: Route Target in BGP/MPLS IP VPN > > =09 > > =09 > > Fabien: "What I > > understood is that Spoke can not communicate DIRECTLY with=20 > each other.=20 > > They have > > to go through the Hub." > > Taras: > > No, spokes can > > not communicate with each other even through hub. That is idea of=20 > > hub&spoke VPN - it is VPN with PARTIAL connectivity. > > Suppose, you have a large data center=20 > and some clients of data=20 > > center. Clients want to reach data center, but they don't want have=20 > > ANY connectivity with other clients due security reasons,=20 > for example. > > =20 > > As to BGP routing, I may say, that PE=20 > router on site B (spoke Site)=20 > > may receive all routes, including routes from site C. But=20 > it does not=20 > > install routes to site C in its VRF routing table. Route Target of=20 > > route from site C do not mach VRF "import" set of route target=20 > > attributes. > > =20 > > Taras > >=20 > > ________________________________ > >=20 > > From: l3vpn-bounces@ietf.org > > [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe > > Sent: Wednesday, January 26, 2005 4:15 PM > > To: L3vpn@ietf.org > > Subject: Re: Route Target in BGP/MPLS IP VPN > > =09 > > =09 > > Thanks for your answer Taras , > > =20 > > What I understood is that Spoke can not=20 > communicate DIRECTLY with=20 > > each other. They have > > to go through the Hub.=20 > > =20 > > But if a packet is received at PE C=20 > (from the CE) for a destination=20 > > address which is in site B he won't > > have any route that says to go through the Hub. > > =20 > > I'm talking about the routing between=20 > PEs when I make a reference=20 > > to RFC1771 9.2.1. Not between CE and PE. > > =20 > > Fabien > > =20 > > ----- Original Message -----=20 > > From: TYushkov@microtest.ru=20 > > To: fabien.verhaeghe@atosorigin.com ;=20 > L3vpn@ietf.org > > Sent: Wednesday, January 26, 2005 1:29 PM > > Subject: RE: Route Target in BGP/MPLS IP VPN > >=20 > > Hi, > >=20 > > The main idea of Hub&spoke is the > > following: spokes may communicate with hub, but spokes can NOT=20 > > communicate with each other. > >=20 > > So, everything seems to be ok. Site A=20 > can communicate with site B &=20 > > C, and sites B & C can't communicate with each other. > >=20 > > As I can understand we may use: RIPv2,=20 > OSPF and EBGP to make=20 > > routing between PE and CE. So RFC1771 > > 9.2.1 it's not our case. > >=20 > > =20 > >=20 > > Cheers. > >=20 > > Taras > >=20 > > =09 > > ________________________________ > >=20 > > From: l3vpn-bounces@ietf.org > > [mailto:l3vpn-bounces@ietf.org] On Behalf Of Fabien Verhaeghe > > Sent: Wednesday, January 26, 2005 3:03 PM > > To: L3vpn@ietf.org > > Subject: Route Target in BGP/MPLS IP VPN > > =09 > > =09 > > Hi, > > =20 > > I've got a question about the use of=20 > "Route Target" in BGP/MPLS IP=20 > > VPN > > Section 4.3.5 of > > draft-ietf-l3vpn-rfc2547bis-03.txt states: > > =20 > > "Alternatively, suppose one desired,=20 > for whatever reason, to create=20 > > a > > "hub and spoke" kind of VPN. This could=20 > be done by the use of two > > Route Target values, one meaning "Hub"=20 > > and one meaning "Spoke". At > > the VRFs > > attached to the hub sites, "Hub" is the Export Target and > > "Spoke" is the Import Target. At the=20 > VRFs attached to the spoke > > site, "Hub" is > > the Import Target and "Spoke" is the Export Target." > > =20 > > If I have 3 sites A,B,C. one CE/PE pair=20 > for each site and one VRF=20 > > per CE/PE. > > Site A is the hub > > Site B,C are spoke > > =20 > > In A VRF I would have the routes to=20 > both sites B and C > > In B,C VRF I would only have routes to=20 > A since with BGP routes=20 > > learned from IBGP are not > > advertised to BGP peer in the same AS=20 > (RFC 1771 9.2.1). > > =20 > > So how can systems in site B > > communicate with systems in site C? > > =20 > > I guess I misunderstood something, and=20 > PE connected to site A will=20 > > actually advertised routes received from site C > > to site B. But it seems inconsistent=20 > with RFC 1771 9.2.1. > > =20 > > Can someone explain to me please? > > =20 > > Thanks > > Fabien > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =09 > >=20 > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The information contained in this message may be privileged=20 > and confidential and protected from disclosure. If the reader=20 > of this message is not the intended recipient, or an employee=20 > or agent responsible for delivering this message to the=20 > intended recipient, you are hereby notified that any=20 > reproduction, dissemination or distribution of this=20 > communication is strictly prohibited. If you have received=20 > this communication in error, please notify us immediately by=20 > replying to the message and deleting it from your computer.=20 > Thank you. Tellabs=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From l3vpn-bounces@ietf.org Thu Jan 27 08:43:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04367 for ; Thu, 27 Jan 2005 08:43:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuACm-0002xR-EF for l3vpn-web-archive@ietf.org; Thu, 27 Jan 2005 09:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu9ui-0003aY-GQ; Thu, 27 Jan 2005 08:42:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu9kn-0001NX-P4 for l3vpn@megatron.ietf.org; Thu, 27 Jan 2005 08:32:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02564 for ; Thu, 27 Jan 2005 08:32:07 -0500 (EST) Received: from mailgate1b.savvis.net ([216.91.182.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuA1u-0002Yo-KJ for L3vpn@ietf.org; Thu, 27 Jan 2005 08:49:52 -0500 Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (8.12.10/8.12.1) with ESMTP id j0RDVhUE000390; Thu, 27 Jan 2005 07:31:43 -0600 Received: from s228130hz1ew08.apptix-01.savvis.net ([10.146.4.8]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 07:31:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2005 07:31:22 -0600 Message-ID: Thread-Topic: Route Target in BGP/MPLS IP VPN Thread-Index: AcUEYb6ncvBCR6u8TWGIPx8qEcAWuAAA7MYwAAMODkA= From: "Schliesser, Benson" To: , X-OriginalArrivalTime: 27 Jan 2005 13:31:34.0614 (UTC) FILETIME=[85206F60:01C50474] X-ECS-MailScanner: No virus is found X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Cc: L3vpn@ietf.org Subject: RE: Route Target in BGP/MPLS IP VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: quoted-printable E.T.Metz@telecom.tno.nl: > As far as I understand this, a PE never passes on VPN > traffic received from one PE to another PE (i.e. PE has > no transit function).=20 > [...] > (because the next-hop is a PE as well) and the PE > would/should only consider 'CE' next-hops as valid. While this is true for certain types of L2 VPNs, it's not forbidden in 2547bis. Per section 5 and 4.3.2, there are times when a VRF lookup is performed on traffic incoming from a PE-PE link. Presumably, that traffic could then be forwarded via a different PE-PE link. I'll grant that it might be an implementation specific behavior. Perhaps the I-D could be more specific. Cheers, -Benson =20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]=20 > On Behalf Of E.T.Metz@telecom.tno.nl > Sent: Thursday, January 27, 2005 11:59 AM > To: balavenkata@netscape.net > Cc: L3vpn@ietf.org > Subject: RE: Route Target in BGP/MPLS IP VPN >=20 > You could do this using two VRFs.=20 >=20 > I don't think it is required though (but this could be=20 > implementation dependent). As far as I understand this, a PE=20 > never passes on VPN traffic received from one PE to another=20 > PE (i.e. PE has no transit function). Thus even though the=20 > VRF on PE A has more specific entries for let's say site C in=20 > the example below, these would not be valid for traffic=20 > received from another PE -e.g. PE B (because the next-hop is=20 > a PE as well) and the PE would/should only consider 'CE'=20 > next-hops as valid. >=20 > cheers, > Eduard >=20 > > -----Original Message----- > > From: Bala Venkata [mailto:balavenkata@netscape.net] > > Sent: donderdag 27 januari 2005 10:06 > > To: Metz, E.T. > > Cc: fabien.verhaeghe@atosorigin.com; L3vpn@ietf.org > > Subject: Re: Route Target in BGP/MPLS IP VPN > >=20 > > Eduard- > >=20 > > When you say > >=20 > > "This will result in traffic from CE-B to CE-C to go like=20 > this CE-B ->=20 > > PE-B -> PE-A -> CE-A -> PE-A -> PE-C -> CE-C." > >=20 > > are you assuming that PE-A has two VRF's ? One to import the routes=20 > > from the spokes and the other two export its (CE-A's)=20 > routes to them ? > > Just wanted to be clear on your "PE-A -> CE-A -> PE-A" portion. > >=20 > > (btw, it is confusing to call everything "hub and spoke" -=20 > I vaguely=20 > > remember coming across the phrase "Central Services" must be in=20 > > Guichard's book...?) > >=20 > >=20 > > Thanks ! > >=20 > >=20 > > E.T.Metz@telecom.tno.nl wrote: > > > =20 > > > In a hub-and-spoke VPN, spoke-sites (assuming these do not > > share a VRF > > > when connected to the same PE) cannot communicate with eachother=20 > > > directly, i.e. spoke-PE to spoke-PE. If spoke-sites need to > > communicate > > > with eachother the communication path indeed goes (must go) > > through the > > > hub-CE, the underlying requirement could e.g. be that > > traffic between B > > > and C needs to pass a firewall at A. Note that the hub-PE > > never acts as > > > a 'transit' node in this case. To achieve spoke-spoke > > communication you > > > either need to advertise an aggregate (covering the=20 > spoke-subnets or=20 > > > entire VPN) or a default from the hub-site (CE), and=20 > ensure that the=20 > > > hub-CE has specific routes to the spoke-CEs pointing to the > > hub-PE. This > > > will result in traffic from CE-B to CE-C to go like this > > CE-B -> PE-B -> > > > PE-A -> CE-A -> PE-A -> PE-C -> CE-C. > > >=20 > > > Hope this helps. > > >=20 > > > cheers, > > > Eduard > > >=20 > > > ________________________________ > > >=20 > > > From: l3vpn-bounces@ietf.org=20 > [mailto:l3vpn-bounces@ietf.org] On=20 > > > Behalf Of Fabien Verhaeghe > > > Sent: woensdag 26 januari 2005 14:15 > > > To: L3vpn@ietf.org > > > Subject: Re: Route Target in BGP/MPLS IP VPN > > > =20 > > > =20 > > > Thanks for your answer Taras , > > > =20 > > > What I understood is that Spoke can not communicate DIRECTLY=20 > > > with each other. They have > > > to go through the Hub. > > > But if a packet is received at PE C (from the CE) for a=20 > > > destination address which is in site B he won't > > > have any route that says to go through the Hub. > > > =20 > > > I'm talking about the routing between PEs when I make a=20 > > > reference to RFC1771 9.2.1. Not between CE and PE. > > > =20 > > > Fabien > > > =20 > > > ----- Original Message -----=20 > > > From: TYushkov@microtest.ru=20 > > > To: fabien.verhaeghe@atosorigin.com ; L3vpn@ietf.org=20 > > > Sent: Wednesday, January 26, 2005 1:29 PM > > > Subject: RE: Route Target in BGP/MPLS IP VPN > > >=20 > > > Hi, > > >=20 > > > The main idea of Hub&spoke is the following: spokes may=20 > > > communicate with hub, but spokes can NOT communicate with > > each other. > > >=20 > > > So, everything seems to be ok. Site A can communicate=20 > with site=20 > > > B & C, and sites B & C can't communicate with each other. > > >=20 > > > As I can understand we may use: RIPv2, OSPF and EBGP to make=20 > > > routing between PE and CE. So RFC1771 9.2.1 it's not our case. > > >=20 > > > =20 > > >=20 > > > Cheers. > > >=20 > > > Taras > > >=20 > > > =20 > > > ________________________________ > > >=20 > > > From: l3vpn-bounces@ietf.org=20 > [mailto:l3vpn-bounces@ietf.org] On=20 > > > Behalf Of Fabien Verhaeghe > > > Sent: Wednesday, January 26, 2005 3:03 PM > > > To: L3vpn@ietf.org > > > Subject: Route Target in BGP/MPLS IP VPN > > > =20 > > > =20 > > > Hi, > > > =20 > > > I've got a question about the use of "Route Target"=20 > in BGP/MPLS=20 > > > IP VPN > > > Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states: > > > =20 > > > "Alternatively, suppose one desired, for whatever reason, to=20 > > > create a > > > "hub and spoke" kind of VPN. This could be done by the use of=20 > > > two > > > Route Target values, one meaning "Hub" and one=20 > meaning "Spoke". > > > At > > > the VRFs attached to the hub sites, "Hub" is the Export=20 > > > Target and > > > "Spoke" is the Import Target. At the VRFs attached to=20 > the spoke > > > site, "Hub" is the Import Target and "Spoke" is=20 > the Export=20 > > > Target." > > > =20 > > > If I have 3 sites A,B,C. one CE/PE pair for each site and one=20 > > > VRF per CE/PE. > > > Site A is the hub > > > Site B,C are spoke > > > =20 > > > In A VRF I would have the routes to both sites B and C > > > In B,C VRF I would only have routes to A since with=20 > BGP routes=20 > > > learned from IBGP are not > > > advertised to BGP peer in the same AS (RFC 1771 9.2.1). > > > =20 > > > So how can systems in site B communicate with systems=20 > in site C? > > > =20 > > > I guess I misunderstood something, and PE connected to site A=20 > > > will actually advertised routes received from site C > > > to site B. But it seems inconsistent with RFC 1771 9.2.1. > > > =20 > > > Can someone explain to me please? > > > =20 > > > Thanks > > > Fabien > > > =20 > >=20 > >=20 >=20 >=20