Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA06873 for ; Sat, 30 Sep 2000 08:45:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FA7F5DDE3; Sat, 30 Sep 2000 08:44:29 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 031005DDE2; Sat, 30 Sep 2000 08:44:28 -0400 (EDT) Received: from rcsnet.rcs.fr (rcsnet.rcs.fr [62.161.167.10]) by segue.merit.edu (Postfix) with SMTP id CD0FB5DDDB for ; Sat, 30 Sep 2000 08:44:23 -0400 (EDT) Received: from myhost.free.fr (c716 [172.17.7.16]) by rcsnet.rcs.fr (8.9.3 (PHNE_18979)/8.9.3) with SMTP id OAA10198; Sat, 30 Sep 2000 14:41:57 +0200 (METDST) Message-Id: <3.0.32.20000930130751.00874c90@172.17.0.30> X-Sender: sauer@172.17.0.30 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 30 Sep 2000 14:43:04 +0200 To: Tony Li , Yakov Rekhter From: Stephen Sauer Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 Cc: idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk Hi Tony, Really yes, many customers use confederation, and for design, really, if we have just Route-reflectors ... Confederation is really funny to design and configure, not simple to deploy, or migrate in an existing network. With extension of Pan European Network, each country like to administrate its own network, confederation is the best solution in this case, for me. Now, could you tell me if we have confederation in an MPLS/VPN network. Actually, we can use Route Reflector. I think confed, in this case, is similar to MP-eBGP. Someone has some info concerning this ? Stephen At 00:31 28/09/00 -0700, Tony Li wrote: > > >Are folks still enamored of this solution? Many other people seem to be >more interested in route reflectors. If no one is using confederations, we >should let this die. > >Tony > > >Yakov Rekhter writes: > | Folks, > | > | In response to the attached request I'd like to start > | IDR WG Last Call on the document. The Last Call will > | be closed in two weeks (oct 10). > | > | Yakov. > | ------- Forwarded Message > | > | Date: Mon, 25 Sep 2000 10:22:08 -0600 > | From: Danny McPherson > | To: idr@merit.edu > | Subject: BGP Confeds > | > | > | Folks, we'd like to move this to Proposed Standard: > | > | draft-ietf-idr-bgp-confed-rfc1965bis-00.txt > | > | Comments? > | > | - -danny > | > | > | ------- End of Forwarded Message > | > | > | > | _______________________________________________ > | Idr-external mailing list > | Idr-external@mailist.procket.com > | http://mailist.procket.com/mailman/listinfo/idr-external > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA06862 for ; Sat, 30 Sep 2000 08:45:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B5185DD91; Sat, 30 Sep 2000 08:44:19 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8625B5DDB0; Sat, 30 Sep 2000 08:44:19 -0400 (EDT) Received: from rcsnet.rcs.fr (rcsnet.rcs.fr [62.161.167.10]) by segue.merit.edu (Postfix) with SMTP id D24955DD91 for ; Sat, 30 Sep 2000 08:44:16 -0400 (EDT) Received: from myhost.free.fr (c716 [172.17.7.16]) by rcsnet.rcs.fr (8.9.3 (PHNE_18979)/8.9.3) with SMTP id OAA10201; Sat, 30 Sep 2000 14:42:17 +0200 (METDST) Message-Id: <3.0.32.20000930141856.0087f8d0@172.17.0.30> X-Sender: sauer@172.17.0.30 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 30 Sep 2000 14:43:20 +0200 To: "ben abarbanel" , "Venu V." , From: Stephen Sauer Subject: Re: Updation of Routing tables by BGP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk Hello Ben, FIB is generated, for a part, by routing table. If routing table is updated, so, FIB will be updated with this new informations. 1. In this case, no, you just have the redistribution in the BGP table. If you look at BGP table, you will find an entry with the IGP networks. normally, it's a network entry with ORIGIN internal. When you loose a network learned by IGP, you can have a problem. Indeed, if the network disappears, IGP will suppress this network from the routing table. If it's not suppressed from BGP table at the same time ( redistribution done later, you can have an entry to this network in your BGP table ). And this entry can be added to the routing table, if in your bgp config, you have disabled synchronisation. Well, for this router, this network is always reachable. While you dont have a withdraw for this network, this network is "reachable" via this router. 2. This update received from an iBGP peer is stored in your BGP table. Now, if it's a new network, routing table will be updated. If it's an existing network, BGP scans if this new entry is better than existing. If this path is better, routing table is updated, else no. Stephen > >> Hello Everyone, >> >> I have a doubt regarding updating of Routing tables or FIB(Forwading >> information base) by BGP in the following scenarios >> >> 1. When IGP routes are injected into BGP, does BGP updates the Routing >> tables? Because IGP must have already updated the Routing table. >> >> 2. Similarly when BGP receives a Update message from an internal BGP peer >> does it needs to update its routing table. >> >> Any input on this queries is welcome!!! >> >> Thanks, >> Venu >> Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06470 for ; Thu, 28 Sep 2000 13:05:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 27FDD5DE53; Thu, 28 Sep 2000 13:04:42 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 143605DE55; Thu, 28 Sep 2000 13:04:42 -0400 (EDT) Received: from redd248.procket.com (flowpoint.procket.com [205.253.146.41]) by segue.merit.edu (Postfix) with ESMTP id 494295DE53 for ; Thu, 28 Sep 2000 13:04:40 -0400 (EDT) Received: (from tli@localhost) by redd248.procket.com (8.9.3/8.9.3) id KAA03976; Thu, 28 Sep 2000 10:04:38 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd248.procket.com: tli set sender to tli@redd248.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14803.31270.676289.372264@redd248.procket.com> Date: Thu, 28 Sep 2000 10:04:38 -0700 (PDT) To: Erik Sherk Cc: Tony Li , Yakov Rekhter , idr@merit.edu Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 In-Reply-To: References: <14802.62394.531963.32603@redd248.procket.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-idr@merit.edu Precedence: bulk | UUNET uses BGP confederations extensively. We have three | confederations, one per each of our operational areas. They really | help solve some scaling issues that are not strictly technical. | We would appreciate moving forward with this. Thanks... Erik, That's fine thanks. Just as long as someone still wants 'em. Tony Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA05992 for ; Thu, 28 Sep 2000 12:21:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E78B15DDF7; Thu, 28 Sep 2000 12:21:13 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D554D5DE1C; Thu, 28 Sep 2000 12:21:13 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id C82E05DDF7 for ; Thu, 28 Sep 2000 12:21:11 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA17284 for ; Thu, 28 Sep 2000 10:21:24 -0600 Message-Id: <200009281621.KAA17284@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 10:21:24 -0600 Sender: owner-idr@merit.edu Precedence: bulk Agreed. I know of a number of networks (new & old) that are using confederations. -danny > Both confederations and route reflectors are still useful. Some > providers use confederations to provide a sepatation between regions > and core and then use RR within the regions. In some situations > community based policiy is provided between confederations (affecting > preference and in some cases aggregation). We still have customer > requests for confederations so it is clearly not dead. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA05969 for ; Thu, 28 Sep 2000 12:18:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C0335DE22; Thu, 28 Sep 2000 12:16:18 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0B58E5DE20; Thu, 28 Sep 2000 12:16:18 -0400 (EDT) Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230]) by segue.merit.edu (Postfix) with ESMTP id 0C9355DE19 for ; Thu, 28 Sep 2000 12:16:14 -0400 (EDT) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA31323; Thu, 28 Sep 2000 12:14:51 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200009281614.MAA31323@workhorse.fictitious.org> To: Tony Li Cc: Yakov Rekhter , idr@merit.edu Reply-To: curtis@avici.com Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 In-reply-to: Your message of "Thu, 28 Sep 2000 00:31:06 PDT." <14802.62394.531963.32603@redd248.procket.com> Date: Thu, 28 Sep 2000 12:14:51 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <14802.62394.531963.32603@redd248.procket.com>, Tony Li writes: > > Are folks still enamored of this solution? Many other people seem to be > more interested in route reflectors. If no one is using confederations, we > should let this die. > > Tony Tony, Both confederations and route reflectors are still useful. Some providers use confederations to provide a sepatation between regions and core and then use RR within the regions. In some situations community based policiy is provided between confederations (affecting preference and in some cases aggregation). We still have customer requests for confederations so it is clearly not dead. Curtis Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05403 for ; Thu, 28 Sep 2000 11:36:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA6C35DE13; Thu, 28 Sep 2000 11:36:17 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D898C5DE15; Thu, 28 Sep 2000 11:36:17 -0400 (EDT) Received: from hotmail.com (f333.law10.hotmail.com [64.4.14.208]) by segue.merit.edu (Postfix) with ESMTP id 3AE045DE13 for ; Thu, 28 Sep 2000 11:36:16 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Sep 2000 08:36:12 -0700 Received: from 209.58.11.227 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 28 Sep 2000 15:36:12 GMT X-Originating-IP: [209.58.11.227] From: "vikram idrp" To: jtsillas@tenornetworks.com, idr@merit.edu Subject: Re: imports to IBGP peers Date: Thu, 28 Sep 2000 15:36:12 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Sep 2000 15:36:12.0985 (UTC) FILETIME=[D514CA90:01C02961] Sender: owner-idr@merit.edu Precedence: bulk >From: "James Tsillas" >Reply-To: >To: "IDR" >Subject: imports to IBGP peers >Date: Wed, 27 Sep 2000 14:06:32 -0400 > >Should imported routes (via cisco "network" cmd) be >redistributed to internal peers? by default? by switch? By default, if the "networked" prefix is also present in the FIB, it is announced to the internal peers. -Vikram >WDCD? (What Does Cisco Do?) > >It seems that one can either rely on IGP to import local >routes (via redistribution) or use manual "network" cmd >and rely on IBGP. > >-Jim. > > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA02291 for ; Thu, 28 Sep 2000 08:53:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 257525DE10; Thu, 28 Sep 2000 08:53:01 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 165C55DDFE; Thu, 28 Sep 2000 08:53:01 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 034A05DDF7 for ; Thu, 28 Sep 2000 08:53:00 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13edBH-0001HI-00; Thu, 28 Sep 2000 05:52:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tony Li Cc: idr@merit.edu Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 References: <200009261509.IAA05023@omega.cisco.com> <14802.62394.531963.32603@redd248.procket.com> Message-Id: Date: Thu, 28 Sep 2000 05:52:55 -0700 Sender: owner-idr@merit.edu Precedence: bulk > Are folks still enamored of this solution? yes, very much so. randy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA29949 for ; Thu, 28 Sep 2000 05:28:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D83A5DE0B; Thu, 28 Sep 2000 05:28:02 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F276F5DE04; Thu, 28 Sep 2000 05:28:01 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by segue.merit.edu (Postfix) with ESMTP id C1AA15DDF7 for ; Thu, 28 Sep 2000 05:27:59 -0400 (EDT) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e8S9SdP22139 for ; Thu, 28 Sep 2000 11:28:39 +0200 (MET DST) Received: from alcatel.be ([138.203.66.5]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C1256968.0033F883; Thu, 28 Sep 2000 11:27:39 +0200 Message-ID: <39D30EE0.BA5C06EF@alcatel.be> Date: Thu, 28 Sep 2000 11:26:57 +0200 From: Geoffrey CRISTALLO X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: idr@merit.edu Subject: Use of BGP-4 multiprotocol extensions for IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Hi, Paragraph 1 of RFC 2858 (Multiprotocol extensions for BGP-4) says "This document assumes that any BGP speaker has to have an IPv4 address". How can this be achieved in an IPv6 network where the BGP speakers do not have an IPv4 address ??? RFC 2545 explains how to use BGP-4 multiprotocol extensions for ipv6 inter-domain routing, but does not treat this "problem". Many thanks in advance Geoffrey Cristallo Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA28528 for ; Thu, 28 Sep 2000 03:32:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DC325DDB8; Thu, 28 Sep 2000 03:31:10 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 04ACA5DE13; Thu, 28 Sep 2000 03:31:09 -0400 (EDT) Received: from redd248.procket.com (flowpoint.procket.com [205.253.146.41]) by segue.merit.edu (Postfix) with ESMTP id BA1835DDB8 for ; Thu, 28 Sep 2000 03:31:07 -0400 (EDT) Received: (from tli@localhost) by redd248.procket.com (8.9.3/8.9.3) id AAA03538; Thu, 28 Sep 2000 00:31:06 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd248.procket.com: tli set sender to tli@redd248.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14802.62394.531963.32603@redd248.procket.com> Date: Thu, 28 Sep 2000 00:31:06 -0700 (PDT) To: Yakov Rekhter Cc: idr@merit.edu Subject: WG last call on -bgp-confed-rfc1965bis-00 In-Reply-To: <200009261509.IAA05023@omega.cisco.com> References: <200009261509.IAA05023@omega.cisco.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-idr@merit.edu Precedence: bulk Are folks still enamored of this solution? Many other people seem to be more interested in route reflectors. If no one is using confederations, we should let this die. Tony Yakov Rekhter writes: | Folks, | | In response to the attached request I'd like to start | IDR WG Last Call on the document. The Last Call will | be closed in two weeks (oct 10). | | Yakov. | ------- Forwarded Message | | Date: Mon, 25 Sep 2000 10:22:08 -0600 | From: Danny McPherson | To: idr@merit.edu | Subject: BGP Confeds | | | Folks, we'd like to move this to Proposed Standard: | | draft-ietf-idr-bgp-confed-rfc1965bis-00.txt | | Comments? | | - -danny | | | ------- End of Forwarded Message | | | | _______________________________________________ | Idr-external mailing list | Idr-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/idr-external Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA18685 for ; Wed, 27 Sep 2000 14:08:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F0555DE01; Wed, 27 Sep 2000 14:08:04 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1D4495DE00; Wed, 27 Sep 2000 14:08:04 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 4E0FE5DDDD for ; Wed, 27 Sep 2000 14:08:02 -0400 (EDT) Received: from tsillas (tsillas [192.168.0.133]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id OAA15370 for ; Wed, 27 Sep 2000 14:08:01 -0400 (EDT) Reply-To: From: "James Tsillas" To: "IDR" Subject: imports to IBGP peers Date: Wed, 27 Sep 2000 14:06:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idr@merit.edu Precedence: bulk Should imported routes (via cisco "network" cmd) be redistributed to internal peers? by default? by switch? WDCD? (What Does Cisco Do?) It seems that one can either rely on IGP to import local routes (via redistribution) or use manual "network" cmd and rely on IBGP. -Jim. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15382 for ; Wed, 27 Sep 2000 10:25:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FB205DDEA; Wed, 27 Sep 2000 10:24:39 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F1835DDD6; Wed, 27 Sep 2000 10:24:39 -0400 (EDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by segue.merit.edu (Postfix) with ESMTP id CAE7D5DD9C for ; Wed, 27 Sep 2000 10:24:37 -0400 (EDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13eI8S-0001ND-00; Wed, 27 Sep 2000 10:24:36 -0400 Message-ID: <002201c0288f$59c9b6c0$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: "Venu V." , References: Subject: Re: Updation of Routing tables by BGP Date: Wed, 27 Sep 2000 10:29:31 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idr@merit.edu Precedence: bulk Venu: To answer your question in a more global sense. You should look at the preference test between routing protocols when updating the FDB. Clearly BGP has lower preference than IGP, thus it will not overwrite IGP routes with BGP routes for the same prefix. There are other relationship between the type of routes, so I suggest you look at the specification on how Cisco and Juniper work. Regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Venu V." To: Sent: Wednesday, September 27, 2000 7:03 AM Subject: Updation of Routing tables by BGP > Hello Everyone, > > I have a doubt regarding updating of Routing tables or FIB(Forwading > information base) by BGP in the following scenarios > > 1. When IGP routes are injected into BGP, does BGP updates the Routing > tables? Because IGP must have already updated the Routing table. > > 2. Similarly when BGP receives a Update message from an internal BGP peer > does it needs to update its routing table. > > Any input on this queries is welcome!!! > > Thanks, > Venu > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA14423 for ; Wed, 27 Sep 2000 09:00:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B48C5DD92; Wed, 27 Sep 2000 08:59:33 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 144C65DDB8; Wed, 27 Sep 2000 08:59:33 -0400 (EDT) Received: from nsa-mail.us.newbridge.com (unknown [209.58.11.226]) by segue.merit.edu (Postfix) with ESMTP id 3E04C5DD92 for ; Wed, 27 Sep 2000 08:59:31 -0400 (EDT) Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id IAA20635; Wed, 27 Sep 2000 08:51:06 -0400 (EDT) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdAAAa0052P; Wed Sep 27 08:51:01 2000 Received: from okemo.northc.com by herndon-mh1.us.newbridge.com with ESMTP; Wed, 27 Sep 2000 08:58:37 -0400 Received: by okemo.northc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 27 Sep 2000 09:01:12 -0400 Message-Id: From: "Natale, Jonathan" To: "'Venu V.'" , idr@merit.edu Subject: RE: Updation of Routing tables by BGP Date: Wed, 27 Sep 2000 08:48:53 -0400 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-idr@merit.edu Precedence: bulk imo: 1. no 2. not if same route is learned by ebgp or igp -----Original Message----- From: Venu V. [mailto:venuv@netplane.com] Sent: Wednesday, September 27, 2000 7:03 AM To: idr@merit.edu Subject: Updation of Routing tables by BGP Hello Everyone, I have a doubt regarding updating of Routing tables or FIB(Forwading information base) by BGP in the following scenarios 1. When IGP routes are injected into BGP, does BGP updates the Routing tables? Because IGP must have already updated the Routing table. 2. Similarly when BGP receives a Update message from an internal BGP peer does it needs to update its routing table. Any input on this queries is welcome!!! Thanks, Venu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA13102 for ; Wed, 27 Sep 2000 07:03:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E81C5DD90; Wed, 27 Sep 2000 07:02:47 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6569D5DD92; Wed, 27 Sep 2000 07:02:47 -0400 (EDT) Received: from xover.hjinc.com (unknown [38.160.241.130]) by segue.merit.edu (Postfix) with ESMTP id DE9135DD90 for ; Wed, 27 Sep 2000 07:02:45 -0400 (EDT) Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Sep 2000 07:02:06 -0400 Message-ID: From: "Venu V." To: idr@merit.edu Subject: Updation of Routing tables by BGP Date: Wed, 27 Sep 2000 07:03:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk Hello Everyone, I have a doubt regarding updating of Routing tables or FIB(Forwading information base) by BGP in the following scenarios 1. When IGP routes are injected into BGP, does BGP updates the Routing tables? Because IGP must have already updated the Routing table. 2. Similarly when BGP receives a Update message from an internal BGP peer does it needs to update its routing table. Any input on this queries is welcome!!! Thanks, Venu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27509 for ; Tue, 26 Sep 2000 11:10:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BE2A5DDA3; Tue, 26 Sep 2000 11:09:35 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8A36C5DDBB; Tue, 26 Sep 2000 11:09:35 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 350F05DDA3 for ; Tue, 26 Sep 2000 11:09:34 -0400 (EDT) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA05023 for ; Tue, 26 Sep 2000 08:09:33 -0700 (PDT) Message-Id: <200009261509.IAA05023@omega.cisco.com> To: idr@merit.edu Subject: WG last call on -bgp-confed-rfc1965bis-00 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5021.969980973.1@cisco.com> Date: Tue, 26 Sep 2000 08:09:33 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, In response to the attached request I'd like to start IDR WG Last Call on the document. The Last Call will be closed in two weeks (oct 10). Yakov. ------- Forwarded Message Date: Mon, 25 Sep 2000 10:22:08 -0600 From: Danny McPherson To: idr@merit.edu Subject: BGP Confeds Folks, we'd like to move this to Proposed Standard: draft-ietf-idr-bgp-confed-rfc1965bis-00.txt Comments? - -danny ------- End of Forwarded Message Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA09591 for ; Mon, 25 Sep 2000 12:22:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B70CF5DDE1; Mon, 25 Sep 2000 12:21:56 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A19765DDD6; Mon, 25 Sep 2000 12:21:56 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id AA62E5DDCE for ; Mon, 25 Sep 2000 12:21:54 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA09340 for ; Mon, 25 Sep 2000 10:22:08 -0600 Message-Id: <200009251622.KAA09340@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: BGP Confeds Date: Mon, 25 Sep 2000 10:22:08 -0600 Sender: owner-idr@merit.edu Precedence: bulk Folks, we'd like to move this to Proposed Standard: draft-ietf-idr-bgp-confed-rfc1965bis-00.txt Comments? -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA23546 for ; Sun, 24 Sep 2000 18:09:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 584425DE72; Sun, 24 Sep 2000 18:05:10 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4163A5DE8F; Sun, 24 Sep 2000 18:05:10 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 00AEA5DE72 for ; Sun, 24 Sep 2000 18:05:08 -0400 (EDT) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA23254 for ; Sun, 24 Sep 2000 15:05:08 -0700 (PDT) Message-Id: <200009242205.PAA23254@omega.cisco.com> To: idr@merit.edu Subject: draft-chen-bgp-prefix-orf-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23251.969833108.1@cisco.com> Date: Sun, 24 Sep 2000 15:05:08 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, If there are any objections to the attached request, please send them to this list within next two week. Yakov. ------- Forwarded Message Date: Sun, 24 Sep 2000 11:59:30 -0700 From: Enke Chen To: yakov@cisco.com, skh@merit.edu cc: enke@redback.com Subject: draft-chen-bgp-prefix-orf-00.txt Hi, Yakov and Sue: I would like to request that the draft be considered as an IDR WG document. Thank you in advance for your consideration. - -- Enke ------- End of Forwarded Message Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26587 for ; Fri, 22 Sep 2000 19:58:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAFA35DE54; Fri, 22 Sep 2000 19:57:35 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9DA295DE3D; Fri, 22 Sep 2000 19:57:35 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by segue.merit.edu (Postfix) with ESMTP id 68A8F5DE54 for ; Fri, 22 Sep 2000 19:57:30 -0400 (EDT) Received: from qhars002.nortel.com (zhars00t [47.101.112.102]) by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id e8MNvPT08887 for ; Fri, 22 Sep 2000 19:57:25 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Thu, 21 Sep 2000 22:03:23 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id S90LAG5G; Thu, 21 Sep 2000 22:03:22 +0100 Received: from hmdhp0nw (hmdhp0nw.europe.nortel.com [47.160.91.114]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id STBVP9PB; Thu, 21 Sep 2000 23:03:19 +0200 Message-Id: <4.2.2.20000921215458.02be76b0@zvb1c002.corpemea.baynetworks.com > X-Sender: mdt@zvb1c002.corpemea.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 21 Sep 2000 21:55:32 -0400 To: ming lu From: "Mark Thompson" Subject: Re: BGP routes generator (freeware) Cc: IDR In-Reply-To: <39CA6956.B7A16279@cw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk Take a look @ http://www.mrtd.net/ in particular BGPsim. At 16:02 21/09/00 -0400, ming lu wrote: >Hi: > >Is there any BGP routes generator out there? I am looking for freeware, >since smartbits is just too expensive ... > >TIA > >_ming Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA10904 for ; Fri, 22 Sep 2000 00:48:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC0CD5DDF9; Fri, 22 Sep 2000 00:46:36 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9BDAA5DDF6; Fri, 22 Sep 2000 00:46:36 -0400 (EDT) Received: from mail.krioukov.net (cj114416-a.reston1.va.home.com [24.15.191.36]) by segue.merit.edu (Postfix) with ESMTP id 436385DD99 for ; Fri, 22 Sep 2000 00:46:34 -0400 (EDT) Received: from DIMA1 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id AAA21698; Fri, 22 Sep 2000 00:41:41 -0400 From: "Dmitri Krioukov" To: "truename" Cc: Subject: RE: Question about ISP interconnection Date: Fri, 22 Sep 2000 01:00:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39CABEE7.07856@ms2> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-idr@merit.edu Precedence: bulk > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of > truename > Sent: Thursday, September 21, 2000 10:08 PM > To: idr@merit.edu > Subject: Question about ISP interconnection > > > Hi, > > I am planning a ISP network. But something bothers me. :))) > It's known that there're two way to interconnect multiple ISP > networks: one is public > peering through NAP or IXP,another is private peering via direct > connection. Which one > is better? > In common, NAP(IXP) provides a Routing Arbiter service. What is > Routing Arbiter and how > does it work? > Are trere some prefernece about these? All these questions are more appropriate for the NANOG mailing list. You may start with http://www.nanog.org. Good luck. > Thanks in advance > > Regards > WenJian > > 欢迎使用网易新一代搜索引擎 > http://search.163.com > 网易引擎--网聚资讯动力！ -- dima. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA08886 for ; Thu, 21 Sep 2000 22:04:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 82C075DE1A; Thu, 21 Sep 2000 22:04:15 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 70DB55DE22; Thu, 21 Sep 2000 22:04:15 -0400 (EDT) Received: from ms1.yeah.net (unknown [202.106.185.103]) by segue.merit.edu (Postfix) with ESMTP id B587C5DE1A for ; Thu, 21 Sep 2000 22:04:13 -0400 (EDT) Received: by ms1.yeah.net (Postfix, from userid 60001) id E69361C9AFEF3; Fri, 22 Sep 2000 10:07:35 +0800 (CST) MIME-Version: 1.0 Message-Id: <39CABEE7.07856@ms2> Date: Fri, 22 Sep 2000 10:07:35 +0800 (CST) From: "truename" To: idr@merit.edu Subject: Question about ISP interconnection X-Priority: 3 X-Originating-IP: [211.99.226.210] Sender: owner-idr@merit.edu Precedence: bulk Hi, I am planning a ISP network. But something bothers me. It's known that there're two way to interconnect multiple ISP networks: one is public peering through NAP or IXP,another is private peering via direct connection. Which one is better? In common, NAP(IXP) provides a Routing Arbiter service. What is Routing Arbiter and how does it work? Are trere some prefernece about these? Thanks in advance Regards WenJian 欢迎使用网易新一代搜索引擎 http://search.163.com 网易引擎--网聚资讯动力！ Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA05465 for ; Thu, 21 Sep 2000 17:37:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E93A75E250; Thu, 21 Sep 2000 17:29:15 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 03B275E10B; Thu, 21 Sep 2000 17:23:49 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id B17705DF48 for ; Thu, 21 Sep 2000 17:05:38 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 14:04:38 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A2911C1E92C@exchsrv1.cosinecom.com> From: Ganesan Ramu To: "'ming lu'" , IDR Subject: RE: BGP routes generator (freeware) Date: Thu, 21 Sep 2000 14:04:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0240F.8D144880" Sender: owner-idr@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0240F.8D144880 Content-Type: text/plain; charset="iso-8859-1" bgpsim, which is part of MRT from http://www.merit.edu/~mrt/ is a good simulator. -----Original Message----- From: ming lu [mailto:mlu@cw.net] Sent: Thursday, September 21, 2000 1:03 PM To: IDR Subject: BGP routes generator (freeware) Hi: Is there any BGP routes generator out there? I am looking for freeware, since smartbits is just too expensive ... TIA _ming ------_=_NextPart_001_01C0240F.8D144880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BGP routes generator (freeware)

bgpsim, which is part of MRT from http://www.merit.edu/~mrt/ is a good = simulator.

-----Original Message-----
From: ming lu [mailto:mlu@cw.net]
Sent: Thursday, September 21, 2000 1:03 PM
To: IDR
Subject: BGP routes generator (freeware)


Hi:

Is there any BGP routes generator out there? I am = looking for freeware,
since smartbits is just too expensive ...

TIA

_ming

------_=_NextPart_001_01C0240F.8D144880-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04503 for ; Thu, 21 Sep 2000 16:44:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F9545E02E; Thu, 21 Sep 2000 16:39:01 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4BF0C5E03A; Thu, 21 Sep 2000 16:25:59 -0400 (EDT) Received: from fulcrum (unknown [204.70.128.22]) by segue.merit.edu (Postfix) with ESMTP id 46EBC5E12D for ; Thu, 21 Sep 2000 16:02:41 -0400 (EDT) Received: from cw.net ([204.71.43.32]) by cw.net (PMDF V5.2-33 #43876) with ESMTPA id <0G19004886C6L9@cw.net> for idr@merit.edu; Thu, 21 Sep 2000 16:02:30 -0400 (EDT) Date: Thu, 21 Sep 2000 16:02:30 -0400 From: ming lu Subject: BGP routes generator (freeware) To: IDR Message-id: <39CA6956.B7A16279@cw.net> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en,zh,zh-CN,zh-TW Sender: owner-idr@merit.edu Precedence: bulk Hi: Is there any BGP routes generator out there? I am looking for freeware, since smartbits is just too expensive ... TIA _ming Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04212 for ; Thu, 21 Sep 2000 16:29:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CADEA5E1EE; Thu, 21 Sep 2000 16:13:47 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 821575E302; Thu, 21 Sep 2000 15:57:27 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 1839B5E0C3 for ; Thu, 21 Sep 2000 15:21:05 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id NAA16513 for ; Thu, 21 Sep 2000 13:21:20 -0600 Message-Id: <200009211921.NAA16513@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: 2260 multi-homing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 13:21:20 -0600 Sender: owner-idr@merit.edu Precedence: bulk There are other issues as well. For example, customers ("enterprises" or "service providers") frequently only have a few hosts that account for the bulk of the "Internet" bandwidth utilization, and as such, this model provides no mechanism to perform load-sharing (ingress to the customer domain) .. this is especially a problem for "lower tier" service providers. The most broken thing I see with this proposal relates to failure recovery. Not only is the customer down for N minutes while the new path is propagated across multiple routing domains (which is extremely undesirable, and reasonably unacceptable to anyone with half a clue), route oscillation could easily result in subsequent suppression by domains upstream from ISPs adjacent to the enterprise. Not to mention the impact of changes in policies, filters, etc.. by others ISPs that would likely result in non-deterministic behavior (and this often not working at all) when failures occur. And no way would ISPs want to deal with managing non-direct EBGP peering. Customers (and ISPs alike) have problems managing "normal" configurations, now they're expected to be able to manage and troubleshoot and provision these types of complex things? And w/the non-direct EBGP peering model I now potentially have to maintain a peering session (and associated policies) for each connection my customer has to other networks... And ISP-N the whole time has to employ prefix filtering that includes all these "might-be-advertised-at-some-point" routes .. and as such, [ideally] has to include ISP-M's IRR entries for the customer AS or AS-MACRO. There's a whole slew of other issues that could be considered here as well. I think the bottom line is that while this would theoretically decrease the number of BGP paths available to a given prefix, and as well result in a lower number of unique prefixes in the routing system (when in steady state), it's simply not worth the hassle. Buying more memory and not dealing with this is much more efficient. Of course, omitting some of the multi-protocol cruft from BGP (e.g. VPN gunk) would likely be just as beneficial -- if not more. As for it's relation to optimal routing, even MEDs are broken with aggregation. -danny > I think I finally put my finger on what bothers me about RFC 2260. > > The biggest operational issue is probably the BGP ease of use issue, or the > ISP-trust-of-edge-network issue, that I list below. > > But that all aside, I think RFC 2260 misses a case. It posits two cases, in > this picture (taken from the RFC): > > +-------+ +-------+ +-------+ +-------+ > ( ) ( ) ( ) ( ) > ( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B ) > ( ) ( ) ( ) ( ) > +-------+ +-------+ +-------+ +-------+ > | /\ | /\ | /\ | > | || | || | Pref-A (connection > | Pref-A | Pref-B | Pref-B broken) > | || | || | || | > +-----+ +-----+ +-----+ +-----+ > | BR-A|------|BR-B | | BR-A|------|BR-B | > +-----+ IBGP +-----+ +-----+ IBGP +-----+ > > non-empty intersection empty intersection > > Ultimately, the goal of the RFC is that a host within the multihomed edge > network has an address within Pref-A or an address within Pref-B, and that > it can use either type of address to communicate with a device in a remote > network, let's say within Pref-C: > > host-C > | > BR-C > | > ISP network C > | > (the Internet, who knows how it gets there) > | | > ISP Network A ISP Network B > | | > BR-A BR-B > /-------------------------/ > host-A host-B > > So we call these hosts host-A, host-B, and host-C for convenience; each is > using an address in whichever prefix is relevant, and each needs to be able > to talk with the other two all the time. > > But suppose that the issue is not that BR-B loses its link to ISP Network B, > but that ISP Network B stops being reachable from ISP Network C? Reasons > could include a backhoe event, a bad confluence of policy, etc; bottom line > is that the advertisement doesn't get into ISP Network C from ISP Network B. > In that case, we need for Pref-B to get advertised via ISP Network A (it > still may not arrive, if the issue is policy, but if it is a backhoe event, > it may very well), but BR-A has no visibility of that. Often, in an edge > network, BR-A and BR-B will not event have a direct route to Pref-C, they > will have default routes leading into the default-free zone. > > It seems to me - and if I have this wrong, please correct me and show me how > this works - that in such a case communication is lost between host-B and > host-C, and there is no way for BR-A to realize that it has to advertise > Pref-B to fix it, because everything looks fine from its perspective. > > >At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote: > >>What exactly is/are the reason(s) the mult-homed (to different > >>ISPs) routing strategies suggested by RFC 2260 is not widely > >>deployed (or not deployed at all)? > > > >Just a guess, but I would expect that > > > >(a) service providers generally prefer to decide for themselves what > >routes they will advertise with regard to a customer, and will do that > >unless given a good monetary reason not to, and > >(b) customers are generally not savvy enough about routing to ask for the > >ability to advertise a different prefix on demand to the service provider, > >or to set it up. > > > >This translates as "there is no obvious reason that this would not work, > >but you have to ask for it, and you have to set it up, and getting BGP > >configurations right is not easy". The routing exchange between edge > >networks and their service providers is generally a default route > >advertised in a common IGP, or simply configured in place, not a routing > >exchange in BGP. > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03149 for ; Thu, 21 Sep 2000 15:22:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28A675E0EA; Thu, 21 Sep 2000 15:11:04 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 24B565DFFC; Thu, 21 Sep 2000 15:02:30 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id E28345E3BA for ; Thu, 21 Sep 2000 14:52:00 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id OAA25039 for ; Thu, 21 Sep 2000 14:51:59 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id MAA16319 for ; Thu, 21 Sep 2000 12:52:10 -0600 Message-Id: <200009211852.MAA16319@tcb.net> X-Mailer: exmh version 2.0.3 To: BGP mailing list From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: 2260 multi-homing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 12:52:10 -0600 Sender: owner-idr@merit.edu Precedence: bulk There are other issues as well. For example, customers ("enterprises" or "service providers") frequently only have a few hosts that account for the bulk of the "Internet" bandwidth utilization, and as such, this model provides no mechanism to perform load-sharing (ingress to the customer domain) .. this is especially a problem for "lower tier" service providers. The most broken thing I see with this proposal relates to failure recovery. Not only is the customer down for N minutes while the new path is propagated across multiple routing domains (which is extremely undesirable, and would be reasonably unacceptable to anyone with half a clue), route oscillation could easily result in suppression by domains upstream from adjacent ISPs. Not to mention the impact of changes in policies, filters, etc.. by others ISPs that would likely result in this not working at all the greater majority of the time. And no way would ISPs want to deal with managing non-direct EBGP peering. Much less, customers (and ISPs alike) have problems managing "normal" configurations, now they're expected to be able to manage and troubleshoot and provision these types of complex things? And ISP-N the whole time has to employ prefix filtering that includes all these "might-be-advertised-at-some-point" routes .. and as such, [ideally] has to include ISP-M's IRR entries for the customer AS or AS-MACRO. There's a whole slew of other less significant issues that could be dicussed. I think the bottom line is that while this would theoretically decrease the number of BGP paths available to a given prefix, and as well result in a lower number of unique prefixes in the routing system, it's simply not worth the hassle. Buying more memory and not dealing with this is much more efficient. Of course, omitting some of the multi-protocol cruft from of BGP (e.g. VPN gunk) would likely be just as beneficial -- if not more. -danny > I think I finally put my finger on what bothers me about RFC 2260. > > The biggest operational issue is probably the BGP ease of use issue, or the > ISP-trust-of-edge-network issue, that I list below. > > But that all aside, I think RFC 2260 misses a case. It posits two cases, in > this picture (taken from the RFC): > > +-------+ +-------+ +-------+ +-------+ > ( ) ( ) ( ) ( ) > ( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B ) > ( ) ( ) ( ) ( ) > +-------+ +-------+ +-------+ +-------+ > | /\ | /\ | /\ | > | || | || | Pref-A (connection > | Pref-A | Pref-B | Pref-B broken) > | || | || | || | > +-----+ +-----+ +-----+ +-----+ > | BR-A|------|BR-B | | BR-A|------|BR-B | > +-----+ IBGP +-----+ +-----+ IBGP +-----+ > > non-empty intersection empty intersection > > Ultimately, the goal of the RFC is that a host within the multihomed edge > network has an address within Pref-A or an address within Pref-B, and that > it can use either type of address to communicate with a device in a remote > network, let's say within Pref-C: > > host-C > | > BR-C > | > ISP network C > | > (the Internet, who knows how it gets there) > | | > ISP Network A ISP Network B > | | > BR-A BR-B > /-------------------------/ > host-A host-B > > So we call these hosts host-A, host-B, and host-C for convenience; each is > using an address in whichever prefix is relevant, and each needs to be able > to talk with the other two all the time. > > But suppose that the issue is not that BR-B loses its link to ISP Network B, > but that ISP Network B stops being reachable from ISP Network C? Reasons > could include a backhoe event, a bad confluence of policy, etc; bottom line > is that the advertisement doesn't get into ISP Network C from ISP Network B. > In that case, we need for Pref-B to get advertised via ISP Network A (it > still may not arrive, if the issue is policy, but if it is a backhoe event, > it may very well), but BR-A has no visibility of that. Often, in an edge > network, BR-A and BR-B will not event have a direct route to Pref-C, they > will have default routes leading into the default-free zone. > > It seems to me - and if I have this wrong, please correct me and show me how > this works - that in such a case communication is lost between host-B and > host-C, and there is no way for BR-A to realize that it has to advertise > Pref-B to fix it, because everything looks fine from its perspective. > > >At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote: > >>What exactly is/are the reason(s) the mult-homed (to different > >>ISPs) routing strategies suggested by RFC 2260 is not widely > >>deployed (or not deployed at all)? > > > >Just a guess, but I would expect that > > > >(a) service providers generally prefer to decide for themselves what > >routes they will advertise with regard to a customer, and will do that > >unless given a good monetary reason not to, and > >(b) customers are generally not savvy enough about routing to ask for the > >ability to advertise a different prefix on demand to the service provider, > >or to set it up. > > > >This translates as "there is no obvious reason that this would not work, > >but you have to ask for it, and you have to set it up, and getting BGP > >configurations right is not easy". The routing exchange between edge > >networks and their service providers is generally a default route > >advertised in a common IGP, or simply configured in place, not a routing > >exchange in BGP. > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01423 for ; Thu, 21 Sep 2000 13:53:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C97AE5DE18; Thu, 21 Sep 2000 13:50:33 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A7C75DE34; Thu, 21 Sep 2000 13:50:33 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id 6334F5DE18 for ; Thu, 21 Sep 2000 13:50:28 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id NAA21180 for ; Thu, 21 Sep 2000 13:50:27 -0400 (EDT) Received: from p7020-img-nt.cisco.com (ssh.cisco.com [171.69.10.34]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA25145; Thu, 21 Sep 2000 10:49:24 -0700 (PDT) Message-Id: <5.0.0.25.2.20000921134404.02d59790@127.0.0.1> X-Sender: fred@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Sep 2000 13:49:19 -0400 To: "Dmitri Krioukov" From: Fred Baker Subject: RE: 2260 multi-homing Cc: "BGP mailing list" , , In-Reply-To: References: <5.0.0.25.2.20000921063554.0338f9a0@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk At 01:32 PM 9/21/00 -0400, Dmitri Krioukov wrote: >As you can see, the only way to solve this is that ISP-A always >advertises Pref-B to cover all possible default-free zone problems. >However, this is basically equivalent to customer's using a PI >block (Pref-Z) advertised by the both ISP. And this is what >RFC2260 is trying to mitigate (longer prefix injections). > >I think that multihoming (especially for longer prefixes) remains >an open question while getting more and more frequently asked >by the customers. very much agree on both points. I have to say that I am thinking about Metro Addressing models, and expect to put together a draft on that. I'm aware of the past debates along those lines. My observation is that while geography has no bearing on topology (for which reason I have historically discounted it as bunk), multihoming by definition is bypassing topological issues. The key point will be that the geographical region wants to be selected such that a large percentage of multihomed sites are in fact aggregated outside the region. If we are multihoming homes (recent conversation with Steve Deering), the geographical region probably can be something smaller than a country. If we are multihoming companies, it probably has to be on the order of countries to continents. I don't think that there is an obvious multihoming solution that aggregates for multinational companies, but that may be OK. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00891 for ; Thu, 21 Sep 2000 13:20:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A0E2D5DDFC; Thu, 21 Sep 2000 13:19:40 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 904675DDD5; Thu, 21 Sep 2000 13:19:40 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id B54E05DDB5 for ; Thu, 21 Sep 2000 13:19:38 -0400 (EDT) Received: from mail.krioukov.net (cj114416-a.reston1.va.home.com [24.15.191.36]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id NAA19212 for ; Thu, 21 Sep 2000 13:19:36 -0400 (EDT) Received: from DIMA1 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id NAA21373; Thu, 21 Sep 2000 13:13:28 -0400 From: "Dmitri Krioukov" To: "Fred Baker" , "BGP mailing list" Cc: , Subject: RE: 2260 multi-homing Date: Thu, 21 Sep 2000 13:32:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.0.25.2.20000921063554.0338f9a0@flipper.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-idr@merit.edu Precedence: bulk I've been trying to understand myself why RFC2260 scenarios are not widely deployed. As a result of this effort, I got to the conclusion that the major reason they are not widely deployed is that they are not widely known by the operators. This conclusion looks more like impression and it may be wrong. Also, section 5.2 in particular, involves some "non- standard" BGP configurations and providers are usually not willing to do that since this (even slightest) complication does not bring them any immediate revenue increase. I think you're right and RFC2260 addresses only local (provider- customer) failures (but it addresses them well!) and it does not address the backbone events, etc. In your example below, imagine there is also ISP-D where some other potential clients reside and, while ISP-C still does not have routes for ISP-B, ISP-D does. Why should ISP-A advertise anything from the ISP-B address space? As you can see, the only way to solve this is that ISP-A always advertises Pref-B to cover all possible default-free zone problems. However, this is basically equivalent to customer's using a PI block (Pref-Z) advertised by the both ISP. And this is what RFC2260 is trying to mitigate (longer prefix injections). I think that multihoming (especially for longer prefixes) remains an open question while getting more and more frequently asked by the customers. -- dima. > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Fred > Baker > Sent: Thursday, September 21, 2000 6:42 AM > To: BGP mailing list > Cc: yakov@cisco.com; tbates@cisco.com > Subject: Re: 2260 multi-homing > > > I think I finally put my finger on what bothers me about RFC 2260. > > The biggest operational issue is probably the BGP ease of use > issue, or the > ISP-trust-of-edge-network issue, that I list below. > > But that all aside, I think RFC 2260 misses a case. It posits two > cases, in > this picture (taken from the RFC): > > +-------+ +-------+ +-------+ +-------+ > ( ) ( ) ( ) ( ) > ( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B ) > ( ) ( ) ( ) ( ) > +-------+ +-------+ +-------+ +-------+ > | /\ | /\ | /\ | > | || | || | Pref-A (connection > | Pref-A | Pref-B | Pref-B broken) > | || | || | || | > +-----+ +-----+ +-----+ +-----+ > | BR-A|------|BR-B | | BR-A|------|BR-B | > +-----+ IBGP +-----+ +-----+ IBGP +-----+ > > non-empty intersection empty intersection > > Ultimately, the goal of the RFC is that a host within the multihomed edge > network has an address within Pref-A or an address within Pref-B, and that > it can use either type of address to communicate with a device in a remote > network, let's say within Pref-C: > > host-C > | > BR-C > | > ISP network C > | > (the Internet, who knows how it gets there) > | | > ISP Network A ISP Network B > | | > BR-A BR-B > /-------------------------/ > host-A host-B > > So we call these hosts host-A, host-B, and host-C for convenience; each is > using an address in whichever prefix is relevant, and each needs > to be able > to talk with the other two all the time. > > But suppose that the issue is not that BR-B loses its link to ISP > Network B, > but that ISP Network B stops being reachable from ISP Network C? Reasons > could include a backhoe event, a bad confluence of policy, etc; > bottom line > is that the advertisement doesn't get into ISP Network C from ISP > Network B. > In that case, we need for Pref-B to get advertised via ISP Network A (it > still may not arrive, if the issue is policy, but if it is a > backhoe event, > it may very well), but BR-A has no visibility of that. Often, in an edge > network, BR-A and BR-B will not event have a direct route to Pref-C, they > will have default routes leading into the default-free zone. > > It seems to me - and if I have this wrong, please correct me and > show me how > this works - that in such a case communication is lost between host-B and > host-C, and there is no way for BR-A to realize that it has to advertise > Pref-B to fix it, because everything looks fine from its perspective. > > >At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote: > >>What exactly is/are the reason(s) the mult-homed (to different > >>ISPs) routing strategies suggested by RFC 2260 is not widely > >>deployed (or not deployed at all)? > > > >Just a guess, but I would expect that > > > >(a) service providers generally prefer to decide for themselves what > >routes they will advertise with regard to a customer, and will do that > >unless given a good monetary reason not to, and > >(b) customers are generally not savvy enough about routing to > ask for the > >ability to advertise a different prefix on demand to the service > provider, > >or to set it up. > > > >This translates as "there is no obvious reason that this would not work, > >but you have to ask for it, and you have to set it up, and getting BGP > >configurations right is not easy". The routing exchange between edge > >networks and their service providers is generally a default route > >advertised in a common IGP, or simply configured in place, not a routing > >exchange in BGP. > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA26785 for ; Thu, 21 Sep 2000 09:44:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0AB555DE0A; Thu, 21 Sep 2000 09:44:21 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EB1C55DE09; Thu, 21 Sep 2000 09:44:20 -0400 (EDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by segue.merit.edu (Postfix) with ESMTP id 484915DE08 for ; Thu, 21 Sep 2000 09:44:19 -0400 (EDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13c6dd-00022S-00; Thu, 21 Sep 2000 09:43:45 -0400 Message-ID: <000401c023d2$9bdc8a40$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: , "James Tsillas" Cc: "IDR" References: <20000920163013.K8067@exodus.net> Subject: Re: question on route propagation Date: Wed, 20 Sep 2000 19:59:46 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idr@merit.edu Precedence: bulk IMO, An IBGP route must have a BGP Next-hop that has reachability in the IGP domain. Meaning there is an IGP next hop that can get to the BGP Next-hop. If not the route should be rejected by the adj-RIB-in processing and hence should not make it to the Loc-RIB or adj-RIB-out. Anybody that violates this rule and uses and/or propagates this route will most certainly be looking at routes that lead to black holes. Just another opinion on the matter, Regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: To: "James Tsillas" Cc: "IDR" Sent: Wednesday, September 20, 2000 5:30 PM Subject: Re: question on route propagation > Advertising a route with a NH differing from that installed > in the FIB creates some obvious potential loop situations > > according to 1771: > > > - Routes are stored in the Routing Information Bases (RIBs): > namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes > that will be advertised to other BGP speakers must be present in > the Adj-RIB-Out; routes that will be used by the local BGP speaker > must be present in the Loc-RIB, and the next hop for each of these > routes must be present in the local BGP speaker's forwarding > information base; and routes that are received from other BGP > speakers are present in the Adj-RIBs-In. > > > Many vendors seem to advertise only those bgp routes installed > in the rib as best - this can lead to problems when routes > exist in both the IGP and iBGP, even with the same NH. > I would consider this a bug - the bgp route should be advertised > as long as the NH's are congruent (in order to avoid loop > scenario). > > If anyone can think of a reason why this is broken, please > let me know. > > IMO: > > Implementations should have a switch for both behaviors. > > 1> BGP routes should be advertised as long as NH in Loc-RIB > and in IGP are congruent (for strict compliance) > > or > > 2> BGP routes that make it into Loc-RIB should be elligible > for insertion into Adj-RIB-Out regardless of NH in underlying > protocol (most people have networks designed around BGP > using this behavior at this point). > > my 2c. > > -ed > > > > --> James Tsillas [000920 15:25]: > > > What should a peer do when it receives an IBGP update > > which doesn't agree with the IGP next hop? Should it > > still propagate that update to its external peers? How > > about if the next hops agree but the IGP route is still > > preferred? > > > > -Jim. > > > > > > -- > Edward Crabbe > ============= > Sr. Network Architect > Backbone Group > Exodus Communications > ------------- > v0x: 408 346 1544 > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA24918 for ; Thu, 21 Sep 2000 06:43:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F9645DDFE; Thu, 21 Sep 2000 06:43:01 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1F2FC5DDFC; Thu, 21 Sep 2000 06:43:01 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id B2A865DDFA for ; Thu, 21 Sep 2000 06:42:59 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id GAA29555 for ; Thu, 21 Sep 2000 06:42:58 -0400 (EDT) Received: from p7020-img-nt.cisco.com (rtp-dial-1-4.cisco.com [10.83.97.4]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id DAA28324; Thu, 21 Sep 2000 03:42:25 -0700 (PDT) Message-Id: <5.0.0.25.2.20000921063554.0338f9a0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Sep 2000 06:42:20 -0400 To: BGP mailing list From: Fred Baker Subject: Re: 2260 multi-homing Cc: yakov@cisco.com, tbates@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk I think I finally put my finger on what bothers me about RFC 2260. The biggest operational issue is probably the BGP ease of use issue, or the ISP-trust-of-edge-network issue, that I list below. But that all aside, I think RFC 2260 misses a case. It posits two cases, in this picture (taken from the RFC): +-------+ +-------+ +-------+ +-------+ ( ) ( ) ( ) ( ) ( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B ) ( ) ( ) ( ) ( ) +-------+ +-------+ +-------+ +-------+ | /\ | /\ | /\ | | || | || | Pref-A (connection | Pref-A | Pref-B | Pref-B broken) | || | || | || | +-----+ +-----+ +-----+ +-----+ | BR-A|------|BR-B | | BR-A|------|BR-B | +-----+ IBGP +-----+ +-----+ IBGP +-----+ non-empty intersection empty intersection Ultimately, the goal of the RFC is that a host within the multihomed edge network has an address within Pref-A or an address within Pref-B, and that it can use either type of address to communicate with a device in a remote network, let's say within Pref-C: host-C | BR-C | ISP network C | (the Internet, who knows how it gets there) | | ISP Network A ISP Network B | | BR-A BR-B /-------------------------/ host-A host-B So we call these hosts host-A, host-B, and host-C for convenience; each is using an address in whichever prefix is relevant, and each needs to be able to talk with the other two all the time. But suppose that the issue is not that BR-B loses its link to ISP Network B, but that ISP Network B stops being reachable from ISP Network C? Reasons could include a backhoe event, a bad confluence of policy, etc; bottom line is that the advertisement doesn't get into ISP Network C from ISP Network B. In that case, we need for Pref-B to get advertised via ISP Network A (it still may not arrive, if the issue is policy, but if it is a backhoe event, it may very well), but BR-A has no visibility of that. Often, in an edge network, BR-A and BR-B will not event have a direct route to Pref-C, they will have default routes leading into the default-free zone. It seems to me - and if I have this wrong, please correct me and show me how this works - that in such a case communication is lost between host-B and host-C, and there is no way for BR-A to realize that it has to advertise Pref-B to fix it, because everything looks fine from its perspective. >At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote: >>What exactly is/are the reason(s) the mult-homed (to different >>ISPs) routing strategies suggested by RFC 2260 is not widely >>deployed (or not deployed at all)? > >Just a guess, but I would expect that > >(a) service providers generally prefer to decide for themselves what >routes they will advertise with regard to a customer, and will do that >unless given a good monetary reason not to, and >(b) customers are generally not savvy enough about routing to ask for the >ability to advertise a different prefix on demand to the service provider, >or to set it up. > >This translates as "there is no obvious reason that this would not work, >but you have to ask for it, and you have to set it up, and getting BGP >configurations right is not easy". The routing exchange between edge >networks and their service providers is generally a default route >advertised in a common IGP, or simply configured in place, not a routing >exchange in BGP. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA17115 for ; Wed, 20 Sep 2000 19:43:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE13E5DDEA; Wed, 20 Sep 2000 19:42:47 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9DBD15DDDF; Wed, 20 Sep 2000 19:42:47 -0400 (EDT) Received: from gevurah.exodus.net (unknown [216.32.171.180]) by segue.merit.edu (Postfix) with ESMTP id 084075DDD4 for ; Wed, 20 Sep 2000 19:42:46 -0400 (EDT) Received: (from edc@localhost) by gevurah.exodus.net (8.10.2/8.10.2) id e8KLUD209765; Wed, 20 Sep 2000 16:30:13 -0500 (CDT) Date: Wed, 20 Sep 2000 16:30:13 -0500 From: edc@exodus.net To: James Tsillas Cc: IDR Subject: Re: question on route propagation Message-ID: <20000920163013.K8067@exodus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-idr@merit.edu Precedence: bulk Advertising a route with a NH differing from that installed in the FIB creates some obvious potential loop situations according to 1771: - Routes are stored in the Routing Information Bases (RIBs): namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes that will be advertised to other BGP speakers must be present in the Adj-RIB-Out; routes that will be used by the local BGP speaker must be present in the Loc-RIB, and the next hop for each of these routes must be present in the local BGP speaker's forwarding information base; and routes that are received from other BGP speakers are present in the Adj-RIBs-In. Many vendors seem to advertise only those bgp routes installed in the rib as best - this can lead to problems when routes exist in both the IGP and iBGP, even with the same NH. I would consider this a bug - the bgp route should be advertised as long as the NH's are congruent (in order to avoid loop scenario). If anyone can think of a reason why this is broken, please let me know. IMO: Implementations should have a switch for both behaviors. 1> BGP routes should be advertised as long as NH in Loc-RIB and in IGP are congruent (for strict compliance) or 2> BGP routes that make it into Loc-RIB should be elligible for insertion into Adj-RIB-Out regardless of NH in underlying protocol (most people have networks designed around BGP using this behavior at this point). my 2c. -ed --> James Tsillas [000920 15:25]: > What should a peer do when it receives an IBGP update > which doesn't agree with the IGP next hop? Should it > still propagate that update to its external peers? How > about if the next hops agree but the IGP route is still > preferred? > > -Jim. > > -- Edward Crabbe ============= Sr. Network Architect Backbone Group Exodus Communications ------------- v0x: 408 346 1544 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16422 for ; Wed, 20 Sep 2000 18:38:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74E9A5DDAC; Wed, 20 Sep 2000 18:37:39 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5E5CE5DDDF; Wed, 20 Sep 2000 18:37:39 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id A3C3A5DDAC for ; Wed, 20 Sep 2000 18:37:37 -0400 (EDT) Received: from tsillas (tsillas [192.168.0.133]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id SAA01718 for ; Wed, 20 Sep 2000 18:37:36 -0400 (EDT) Reply-To: From: "James Tsillas" To: "IDR" Subject: question on route propagation Date: Wed, 20 Sep 2000 18:36:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idr@merit.edu Precedence: bulk What should a peer do when it receives an IBGP update which doesn't agree with the IGP next hop? Should it still propagate that update to its external peers? How about if the next hops agree but the IGP route is still preferred? -Jim. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA04257 for ; Wed, 20 Sep 2000 03:34:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B367F5DDD0; Wed, 20 Sep 2000 03:33:36 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A340D5DDCC; Wed, 20 Sep 2000 03:33:36 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id 4A3CA5DDBB for ; Wed, 20 Sep 2000 03:33:34 -0400 (EDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id DAA01164 for ; Wed, 20 Sep 2000 03:33:33 -0400 (EDT) Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Fri, 15 Sep 2000 01:20:09 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id S7XGXVCX; Fri, 15 Sep 2000 01:20:09 +0100 Received: from hmdhp0nw (hmdhp0nw.europe.nortel.com [47.160.91.114]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id STBVP6YT; Fri, 15 Sep 2000 02:20:07 +0200 Message-Id: <4.2.2.20000915011656.02a70190@zvb1c002.corpemea.baynetworks.com > X-Sender: mdt@zvb1c002.corpemea.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 15 Sep 2000 01:18:00 -0400 To: BGP mailing list From: "Mark Thompson" Subject: Re: Error Handling in BGP multiprotocol extensions In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk The speaker should ignore the NLRI associated with the attributes and not terminate the peer session. Mark At 14:17 14/09/00 -0700, Srinivasa Chaganti wrote: >Hi, >I have a question regarding Error handling when processing a BGP updates >with multiprotocol extensions attributes. What should BGP speaker do when it >receives an update message from a peer with MP_REACH_NLRI and/or >MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present >in it. Should the speaker ingnore the NLRI in the attributes or terminate >the connection. I haven't found an answer for this specific error in RFC >2858. Thanks in advance for any help. > >-Chaganti S. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA09053 for ; Mon, 18 Sep 2000 19:42:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FB7F5DD8D; Mon, 18 Sep 2000 19:42:01 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EF2E45DD90; Mon, 18 Sep 2000 19:42:00 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id EFD755DD8D for ; Mon, 18 Sep 2000 19:41:58 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id TAA12281 for ; Mon, 18 Sep 2000 19:41:57 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA28920 for ; Mon, 18 Sep 2000 16:41:56 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 16:41:56 -0700 Message-ID: From: Srinivasa Chaganti To: BGP mailing list Subject: SNPA fields in MP_REACH_NLRI attribute Date: Mon, 18 Sep 2000 16:41:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Hi, can anybody please explain me what for "Subnetwork Points of Attachment" (SNPA) fields are used carried in MP_REACH_NLRI attribute as given in RFC2858. For my understanding these fields carry alternative next-hop information. What these fields should carry in the case of IPv4 unicast/multicast address families. thanks Chaganti S. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA24713 for ; Mon, 18 Sep 2000 05:52:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 189A35E928; Sun, 17 Sep 2000 22:15:45 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 052915EAC1; Sun, 17 Sep 2000 17:20:11 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id E44365F0CF for ; Sun, 17 Sep 2000 13:40:15 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Sun, 17 Sep 2000 10:39:23 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29110BD90D@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'Danny McPherson '" , "'idr@merit.edu '" Subject: RE: Question on Capability Date: Sun, 17 Sep 2000 10:39:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C020CE.36A18240" Sender: owner-idr@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C020CE.36A18240 Content-Type: text/plain; charset="iso-8859-1" Just to add to Danny's response... There are also some cases where the NEXT_HOP self _must_ be used such as cases where the subnet that the NEXT_HOP is on is not reachable directly from within the AS. This can happen if, for instance, the subnet that the NEXT_HOP is on is not advertised into the IGP, or when using ATM/Frame Relay and only a partial mesh is implemented (i.e. no direct VC exists to the original NEXT_HOP). -Anoop -----Original Message----- From: Danny McPherson To: idr@merit.edu Sent: 9/16/2000 5:34 PM Subject: Re: Question on Capability > Thanks for the input. But I was wondering, why NEXT_HOP self at ingress is > used rather than proprogating the announced NEXT_HOP as-is? Several reasons, actually. Primarily (IMO) because providers are converned with convergence, and as such, rely of IGPs for this purpose (providing intra-domain BGP NEXT_HOP reachability) rather than BGP. That is, they set NEXT_HOP to self at the ingress BGP router, with 'self' usually representing a 'loopback' interface (which typically used as the 'local address' for internal peerings). This way, all the external networks need not be present in the IGP .. and external instability doesn't jeopardize internal network stability. It also enables an implementation to do other clever things, such as that proposed by Alvaro on this list early this year. There are many other reasons as well. For example, when external subnets are routed throughout the entire domain it's possible (and has actually been discovered) that the 'unethical types' have the capability to 'steal' transit services from a network (e.g. employ IP tunneling across the network between routers on external subnets). Of course, most folks still fully route the nertworks in order to provide diagnostic capabilities. Etc, etc... -danny ------_=_NextPart_001_01C020CE.36A18240 Content-Type: text/html; charset="iso-8859-1" RE: Question on Capability

Just to add to Danny's response...

There are also some cases where the NEXT_HOP self _must_
be used such as cases where the subnet that the NEXT_HOP
is on is not reachable directly from within the AS.
This can happen if, for instance, the subnet that the
NEXT_HOP is on is not advertised into the IGP, or
when using ATM/Frame Relay and only a partial mesh is
implemented (i.e. no direct VC exists to the original
NEXT_HOP).

-Anoop

-----Original Message-----
From: Danny McPherson
To: idr@merit.edu
Sent: 9/16/2000 5:34 PM
Subject: Re: Question on Capability


> Thanks for the input. But I was wondering, why NEXT_HOP self at
ingress is
> used rather than proprogating the announced NEXT_HOP as-is?

Several reasons, actually. 

Primarily (IMO) because providers are converned with convergence, and as
such, rely of IGPs for this purpose (providing intra-domain BGP NEXT_HOP
reachability) rather than BGP.  That is, they set NEXT_HOP to self at
the ingress BGP router, with 'self' usually representing a 'loopback'
interface (which typically used as the 'local address' for internal
peerings).  This way, all the external networks need not be present in
the IGP .. and external instability doesn't jeopardize internal network
stability. 

It also enables an implementation to do other clever things, such as
that proposed by Alvaro on this list early this year.

There are many other reasons as well.  For example, when external
subnets are routed throughout the entire domain it's possible (and has
actually been discovered) that the 'unethical types' have the capability
to 'steal' transit services from a network (e.g. employ IP tunneling
across the network between routers on external subnets).  Of course,
most folks still fully route the nertworks in order to provide
diagnostic capabilities.

Etc, etc...

-danny

------_=_NextPart_001_01C020CE.36A18240-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA08235 for ; Sun, 17 Sep 2000 03:33:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B9DE75DECA; Sun, 17 Sep 2000 00:33:53 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 10C4C5DED1; Sat, 16 Sep 2000 22:19:23 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 4BB5D5E1C4 for ; Sat, 16 Sep 2000 20:34:40 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id SAA06821 for ; Sat, 16 Sep 2000 18:34:57 -0600 Message-Id: <200009170034.SAA06821@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: Question on Capability Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Sep 2000 18:34:57 -0600 Sender: owner-idr@merit.edu Precedence: bulk > Thanks for the input. But I was wondering, why NEXT_HOP self at ingress is > used rather than proprogating the announced NEXT_HOP as-is? Several reasons, actually. Primarily (IMO) because providers are converned with convergence, and as such, rely of IGPs for this purpose (providing intra-domain BGP NEXT_HOP reachability) rather than BGP. That is, they set NEXT_HOP to self at the ingress BGP router, with 'self' usually representing a 'loopback' interface (which typically used as the 'local address' for internal peerings). This way, all the external networks need not be present in the IGP .. and external instability doesn't jeopardize internal network stability. It also enables an implementation to do other clever things, such as that proposed by Alvaro on this list early this year. There are many other reasons as well. For example, when external subnets are routed throughout the entire domain it's possible (and has actually been discovered) that the 'unethical types' have the capability to 'steal' transit services from a network (e.g. employ IP tunneling across the network between routers on external subnets). Of course, most folks still fully route the nertworks in order to provide diagnostic capabilities. Etc, etc... -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA05558 for ; Sat, 16 Sep 2000 23:19:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EB5F5E2B2; Sat, 16 Sep 2000 21:31:29 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3C52C5EC26; Sat, 16 Sep 2000 21:31:03 -0400 (EDT) Received: from hotmail.com (f73.law10.hotmail.com [64.4.15.73]) by segue.merit.edu (Postfix) with ESMTP id 012EC5E180 for ; Sat, 16 Sep 2000 20:14:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Sep 2000 17:14:11 -0700 Received: from 209.58.11.227 by lw10fd.law10.hotmail.msn.com with HTTP; Sun, 17 Sep 2000 00:14:11 GMT X-Originating-IP: [209.58.11.227] From: "vikram idrp" To: danny@tcb.net, idr@merit.edu Subject: Re: Question on Capability Date: Sun, 17 Sep 2000 00:14:11 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Sep 2000 00:14:11.0435 (UTC) FILETIME=[3452EBB0:01C0203C] Sender: owner-idr@merit.edu Precedence: bulk hello Danny, Thanks for the input. But I was wondering, why NEXT_HOP self at ingress is used rather than proprogating the announced NEXT_HOP as-is? Vikram >From: Danny McPherson >Reply-To: danny@tcb.net >To: idr@merit.edu >Subject: Re: Question on Capability >Date: Fri, 15 Sep 2000 16:58:10 -0600 > > >Though at first it does seem like a nice optimization, typical deployment >typically does involve employing 'NEXT_HOP self" at the ingress BGP speaker >within the routing domain. > >-danny > > > Hello everybody, > > I have a question about capabilities. > > Is there a need for having a capability to withdraw routes pertaining to >an > > EBGP peer by sending a withdraw message to all the IBGP peers with just >the > > Next Hop withdrawl. If all the routes associated with a given Next Hop >are > > chained, withdrawl of these routes can be done effectively with just a > > single entry in the message. However, it should be done, if and only if >the > > IBGP router peering with the EBGP router does not propogate some routes >with > > Next Hop Self. > > Any thoughts in this direction will be highly appreciated! > > > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA18914 for ; Fri, 15 Sep 2000 19:18:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AC675DE6F; Fri, 15 Sep 2000 19:15:57 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4DC215DE6E; Fri, 15 Sep 2000 19:15:57 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id 618A15DE64 for ; Fri, 15 Sep 2000 19:15:55 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id TAA08228 for ; Fri, 15 Sep 2000 19:15:53 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id RAA32202 for ; Fri, 15 Sep 2000 17:16:07 -0600 Message-Id: <200009152316.RAA32202@tcb.net> X-Mailer: exmh version 2.0.3 To: BGP mailing list From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: Error Handling in BGP multiprotocol extensions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Sep 2000 17:16:07 -0600 Sender: owner-idr@merit.edu Precedence: bulk Actually, this was a really good question. I guess it depends on your interpretation of the word "incorrect" in RFC 2858 [MBGP], which states the following: If a BGP speaker receives from a neighbor an Update message that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the speaker determines that the attribute is incorrect, the speaker must delete all the BGP routes received from that neighbor whose AFI/SAFI is the same as the one carried in the incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute. For the duration of the BGP session over which the Update message was received, the speaker then should ignore all the subsequent routes with that AFI/SAFI received over that session. As you should never receive MP_REACH_NLRI or MP_UNREACH_NLRI from a neighbor describing and AFI or SAFI that wasn't first advertised in Capabilities Optional Parameter (and subsequently [implicitly] accepted) by the peer, as defined in RFC 2842 [BGPCAP]: A BGP speaker that supports a particular capability may use this capability with its peer after the speaker determines (as described above) that the peer supports this capability. As such, it would seem to me that receipt of an UPDATE message that describes an AFI or SAFI that wasn't "agreed upon" when the session was established should result in NOTIFICATION message being sent to the peer with the Error Subcode set to "Unsupported Optional Parameter", as defined in RFC 2842. Perhaps clarifying the wording in RFC 2842 would be of benefit. Replacing the above with something like: A BGP speaker that supports a particular capability MUST NOT use this capability until the speaker determines (as described above) that the peer supports this capability. Perhaps codifying "incorrect" in RFC 2858 would be of benefit as well. HTH, -danny > The speaker should ignore the NLRI associated with the attributes and not > terminate the peer session. > > Mark > > At 14:17 14/09/00 -0700, Srinivasa Chaganti wrote: > >Hi, > >I have a question regarding Error handling when processing a BGP updates > >with multiprotocol extensions attributes. What should BGP speaker do when it > >receives an update message from a peer with MP_REACH_NLRI and/or > >MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present > >in it. Should the speaker ingnore the NLRI in the attributes or terminate > >the connection. I haven't found an answer for this specific error in RFC > >2858. Thanks in advance for any help. > > > >-Chaganti S. > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA18795 for ; Fri, 15 Sep 2000 19:06:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 227E85DE68; Fri, 15 Sep 2000 19:03:37 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D5B25DE5C; Fri, 15 Sep 2000 19:03:37 -0400 (EDT) Received: from redd207.procket.com (flowpoint.procket.com [205.253.146.41]) by segue.merit.edu (Postfix) with ESMTP id 659385DE54 for ; Fri, 15 Sep 2000 19:03:35 -0400 (EDT) Received: (from henk@localhost) by redd207.procket.com (8.9.3/8.9.3) id QAA15536; Fri, 15 Sep 2000 16:02:56 -0700 From: Henk Smit Message-Id: <200009152302.QAA15536@redd207.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: Question on Capability To: danny@tcb.net Date: Fri, 15 Sep 2000 16:02:56 -0700 (PDT) Cc: idr@merit.edu In-Reply-To: <200009152258.QAA32078@tcb.net> from "Danny McPherson" at Sep 15, 2000 04:58:10 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk You could make it a combination of the bgp next hop and the first ASN in the AS path. Although that would be less useful if an eBGP speaker is connected to two external peers in the same AS. Henk. > Though at first it does seem like a nice optimization, typical deployment > typically does involve employing 'NEXT_HOP self" at the ingress BGP speaker > within the routing domain. > > -danny > > > Hello everybody, > > I have a question about capabilities. > > Is there a need for having a capability to withdraw routes pertaining to an > > EBGP peer by sending a withdraw message to all the IBGP peers with just the > > Next Hop withdrawl. If all the routes associated with a given Next Hop are > > chained, withdrawl of these routes can be done effectively with just a > > single entry in the message. However, it should be done, if and only if the > > IBGP router peering with the EBGP router does not propogate some routes with > > Next Hop Self. > > Any thoughts in this direction will be highly appreciated! > > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA18689 for ; Fri, 15 Sep 2000 18:58:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 104F05DDE9; Fri, 15 Sep 2000 18:57:57 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F38665DE54; Fri, 15 Sep 2000 18:57:56 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 717035DDE9 for ; Fri, 15 Sep 2000 18:57:54 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id QAA32078 for ; Fri, 15 Sep 2000 16:58:10 -0600 Message-Id: <200009152258.QAA32078@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: Question on Capability Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Sep 2000 16:58:10 -0600 Sender: owner-idr@merit.edu Precedence: bulk Though at first it does seem like a nice optimization, typical deployment typically does involve employing 'NEXT_HOP self" at the ingress BGP speaker within the routing domain. -danny > Hello everybody, > I have a question about capabilities. > Is there a need for having a capability to withdraw routes pertaining to an > EBGP peer by sending a withdraw message to all the IBGP peers with just the > Next Hop withdrawl. If all the routes associated with a given Next Hop are > chained, withdrawl of these routes can be done effectively with just a > single entry in the message. However, it should be done, if and only if the > IBGP router peering with the EBGP router does not propogate some routes with > Next Hop Self. > Any thoughts in this direction will be highly appreciated! Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA18511 for ; Fri, 15 Sep 2000 18:45:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F9885DE35; Fri, 15 Sep 2000 18:44:32 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7E92C5DE6E; Fri, 15 Sep 2000 18:44:32 -0400 (EDT) Received: from hotmail.com (f227.law10.hotmail.com [64.4.15.227]) by segue.merit.edu (Postfix) with ESMTP id 80EC75DE35 for ; Fri, 15 Sep 2000 18:44:30 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Sep 2000 15:44:28 -0700 Received: from 209.58.11.227 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 15 Sep 2000 22:44:28 GMT X-Originating-IP: [209.58.11.227] From: "vikram idrp" To: idr@merit.edu Subject: Question on Capability Date: Fri, 15 Sep 2000 22:44:28 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Sep 2000 22:44:28.0755 (UTC) FILETIME=[81956230:01C01F66] Sender: owner-idr@merit.edu Precedence: bulk Hello everybody, I have a question about capabilities. Is there a need for having a capability to withdraw routes pertaining to an EBGP peer by sending a withdraw message to all the IBGP peers with just the Next Hop withdrawl. If all the routes associated with a given Next Hop are chained, withdrawl of these routes can be done effectively with just a single entry in the message. However, it should be done, if and only if the IBGP router peering with the EBGP router does not propogate some routes with Next Hop Self. Any thoughts in this direction will be highly appreciated! vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13259 for ; Fri, 15 Sep 2000 12:26:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B05CB5DE41; Fri, 15 Sep 2000 12:26:26 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A12895DE3F; Fri, 15 Sep 2000 12:26:26 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id D00995DDA6 for ; Fri, 15 Sep 2000 12:26:23 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id MAA06302 for ; Fri, 15 Sep 2000 12:26:20 -0400 (EDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA17263; Fri, 15 Sep 2000 09:25:15 -0700 (PDT) Message-Id: <5.0.0.25.2.20000915090015.01f833b0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 15 Sep 2000 09:05:43 -0700 To: Chandrasekar Ramachandran From: Fred Baker Subject: Re: 2260 multi-homing Cc: bgp@ans.net, chandra@ittc.ukans.edu In-Reply-To: <39C19D6E.444DF673@ittc.ukans.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote: >What exactly is/are the reason(s) the mult-homed (to different >ISPs) routing strategies suggested by RFC 2260 is not widely >deployed (or not deployed at all)? Just a guess, but I would expect that (a) service providers generally prefer to decide for themselves what routes they will advertise with regard to a customer, and will do that unless given a good monetary reason not to, and (b) customers are generally not savvy enough about routing to ask for the ability to advertise a different prefix on demand to the service provider, or to set it up. This translates as "there is no obvious reason that this would not work, but you have to ask for it, and you have to set it up, and getting BGP configurations right is not easy". The routing exchange between edge networks and their service providers is generally a default route advertised in a common IGP, or simply configured in place, not a routing exchange in BGP. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA03237 for ; Thu, 14 Sep 2000 23:55:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97B105DD91; Thu, 14 Sep 2000 23:54:35 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 70CE25DD9C; Thu, 14 Sep 2000 23:54:35 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id BF1765DD91 for ; Thu, 14 Sep 2000 23:54:33 -0400 (EDT) Received: from stephens.ittc.ukans.edu (stephens.ittc.ukans.edu [129.237.125.220]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id XAA19362 for ; Thu, 14 Sep 2000 23:54:32 -0400 (EDT) Received: from ittc.ukans.edu (brazil.ittc.ukans.edu [129.237.126.163]) by stephens.ittc.ukans.edu (8.9.3/8.9.3/ITTC-NOSPAM-1.0) with ESMTP id WAA08063; Thu, 14 Sep 2000 22:54:22 -0500 (CDT) Message-ID: <39C19D6E.444DF673@ittc.ukans.edu> Date: Thu, 14 Sep 2000 22:54:22 -0500 From: Chandrasekar Ramachandran Organization: ITTC, University of Kansas X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: bgp@ans.net Cc: chandra@ittc.ukans.edu Subject: 2260 multi-homing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk What exactly is/are the reason(s) the mult-homed (to different ISPs) routing strategies suggested by RFC 2260 is not widely deployed (or not deployed at all)? I think there may be some commercial reasons too for this. thanks, Chandra. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA01192 for ; Thu, 14 Sep 2000 20:59:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 829875DE23; Thu, 14 Sep 2000 20:58:49 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 70F9C5DE28; Thu, 14 Sep 2000 20:58:49 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id 8BF7C5DE23 for ; Thu, 14 Sep 2000 20:58:47 -0400 (EDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id UAA10066 for ; Thu, 14 Sep 2000 20:58:46 -0400 (EDT) Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Fri, 15 Sep 2000 01:58:32 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id S7XGXV7R; Fri, 15 Sep 2000 01:58:33 +0100 Received: from hmdhp0nw (hmdhp0nw.europe.nortel.com [47.160.91.114]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id STBVP6YX; Fri, 15 Sep 2000 02:58:29 +0200 Message-Id: <4.2.2.20000915015536.02a69420@zvb1c002.corpemea.baynetworks.com > X-Sender: mdt@zvb1c002.corpemea.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 15 Sep 2000 01:56:21 -0400 To: Srinivasa Chaganti From: "Mark Thompson" Subject: Re: Error Handling in BGP multiprotocol extensions Cc: BGP mailing list In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk The speaker should ignore the NLRI associated with the attributes and not terminate the peer session. Mark At 14:17 14/09/00 -0700, Srinivasa Chaganti wrote: >Hi, >I have a question regarding Error handling when processing a BGP updates >with multiprotocol extensions attributes. What should BGP speaker do when it >receives an update message from a peer with MP_REACH_NLRI and/or >MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present >in it. Should the speaker ingnore the NLRI in the attributes or terminate >the connection. I haven't found an answer for this specific error in RFC >2858. Thanks in advance for any help. > >-Chaganti S. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA00658 for ; Thu, 14 Sep 2000 20:12:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BD145DE24; Thu, 14 Sep 2000 20:11:37 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7A3C05DE1D; Thu, 14 Sep 2000 20:11:37 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id 02C8B5DE1B for ; Thu, 14 Sep 2000 20:11:35 -0400 (EDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id UAA07331 for ; Thu, 14 Sep 2000 20:11:34 -0400 (EDT) Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Fri, 15 Sep 2000 01:11:07 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id S7XGX4Y8; Fri, 15 Sep 2000 01:11:07 +0100 Received: from hmdhp0nw (hmdhp0nw.europe.nortel.com [47.160.91.114]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id STBVP6YP; Fri, 15 Sep 2000 02:11:03 +0200 Message-Id: <4.2.2.20000915005315.02a6f8c0@zvb1c002.corpemea.baynetworks.com > X-Sender: mdt@zvb1c002.corpemea.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 15 Sep 2000 01:08:56 -0400 To: "Natale, Jonathan" From: "Mark Thompson" Subject: Re: Split Horrizon Cc: "Bgp Mail List (E-mail)" , "Bgp Ietf Mail List (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk Jonathan The current spec (not including any multicast attributes) should not allow you to re-advertise routes back to the same logical peer (peer IP address). The reason being it would break the loop detection mechanism. For EBGP peers it is effectively a split horizon. For IBGP peers the rule is do not advertise routes learned from an iBGP peer onto a third iBGP peer. This rule forces the requirement for a logical full mesh of iBGP peers. You are able to peer back to and readvertise back to the same physical peer but you would require a secondary peer relationship with the router. Mark At 17:14 14/09/00 -0400, Natale, Jonathan wrote: >Is multicast peering supported? Is this what is refered to below? Is there >any reason why routes learned from a peer should not be advertised back to >the peer (other than the performance hit)? Is there any advantage to >advertising learned from a peer back at that peer? > >RFC 1771 sec 9.1.3 says: >For the benefit of future support of inter-AS multicast capabilities, a BGP >speaker that participates in inter-AS multicast routing shall advertise a >route it receives from one of its external peers and if it installs it in >its Loc-RIB, it shall advertise it back to the peer from which the route was >received. For a BGP speaker that does not participate in inter-AS multicast >routing such an advertisement is optional. When doing such an advertisement, >the NEXT_HOP attribute should be set to the address of the peer. An >implementation may also optimize such an advertisement by truncating >information in the AS_PATH attribute to include only its own AS number and >that of the peer that advertised the route (such truncation requires the >ORIGIN attribute to be set to INCOMPLETE). In addition an implementation is >not required to pass optional or discretionary path attributes with such an >advertisement. Mark Thompson - Nortel Networks EMEA IP Specialist Advanced Technical Solutions Tel :+44 (0)1628 437265 ESN : 560-7265 GSM :+44 (0)7710 876079 mailto:mdt@nortelnetworks.com Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA00466 for ; Thu, 14 Sep 2000 19:57:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E64745DE21; Thu, 14 Sep 2000 19:56:51 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D61C55DE1D; Thu, 14 Sep 2000 19:56:51 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id F07155DE1B for ; Thu, 14 Sep 2000 19:56:49 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id TAA06543 for ; Thu, 14 Sep 2000 19:56:48 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA11770 for ; Thu, 14 Sep 2000 16:56:45 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 16:56:44 -0700 Message-ID: From: Srinivasa Chaganti To: BGP mailing list Subject: RE: Error Handling in BGP multiprotocol extensions Date: Thu, 14 Sep 2000 16:56:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Please read ASI/ASFI as AFI/SAFI in my previous mail. Apologize for the typo error. thanks Chaganti S. -----Original Message----- From: Srinivasa Chaganti [mailto:chaganti@pluris.com] Sent: Thursday, September 14, 2000 2:18 PM To: BGP mailing list Subject: Error Handling in BGP multiprotocol extensions Hi, I have a question regarding Error handling when processing a BGP updates with multiprotocol extensions attributes. What should BGP speaker do when it receives an update message from a peer with MP_REACH_NLRI and/or MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present in it. Should the speaker ingnore the NLRI in the attributes or terminate the connection. I haven't found an answer for this specific error in RFC 2858. Thanks in advance for any help. -Chaganti S. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA28183 for ; Thu, 14 Sep 2000 17:25:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 119965DE3E; Thu, 14 Sep 2000 17:25:04 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 00BA75DE37; Thu, 14 Sep 2000 17:25:03 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id 371DC5DE33 for ; Thu, 14 Sep 2000 17:25:02 -0400 (EDT) Received: from nsa-mail.us.newbridge.com ([209.58.11.226]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id RAA27680 for ; Thu, 14 Sep 2000 17:25:01 -0400 (EDT) Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id RAA04712; Thu, 14 Sep 2000 17:16:01 -0400 (EDT) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdAAAa0019a; Thu Sep 14 17:15:59 2000 Received: from okemo.northc.com by herndon-mh1.us.newbridge.com with ESMTP; Thu, 14 Sep 2000 17:23:44 -0400 Received: by okemo.northc.com with Internet Mail Service (5.5.2448.0) id ; Thu, 14 Sep 2000 17:26:18 -0400 Message-Id: From: "Natale, Jonathan" To: "Bgp Mail List (E-mail)" , "Bgp Ietf Mail List (E-mail)" Subject: Split Horrizon Date: Thu, 14 Sep 2000 17:14:39 -0400 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-idr@merit.edu Precedence: bulk Is multicast peering supported? Is this what is refered to below? Is there any reason why routes learned from a peer should not be advertised back to the peer (other than the performance hit)? Is there any advantage to advertising learned from a peer back at that peer? RFC 1771 sec 9.1.3 says: For the benefit of future support of inter-AS multicast capabilities, a BGP speaker that participates in inter-AS multicast routing shall advertise a route it receives from one of its external peers and if it installs it in its Loc-RIB, it shall advertise it back to the peer from which the route was received. For a BGP speaker that does not participate in inter-AS multicast routing such an advertisement is optional. When doing such an advertisement, the NEXT_HOP attribute should be set to the address of the peer. An implementation may also optimize such an advertisement by truncating information in the AS_PATH attribute to include only its own AS number and that of the peer that advertised the route (such truncation requires the ORIGIN attribute to be set to INCOMPLETE). In addition an implementation is not required to pass optional or discretionary path attributes with such an advertisement. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA28150 for ; Thu, 14 Sep 2000 17:23:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBE7D5DE58; Thu, 14 Sep 2000 17:19:16 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CD2225DE59; Thu, 14 Sep 2000 17:19:16 -0400 (EDT) Received: from mailrelay00.aa.ops.us.uu.net (postal.aa.ops.us.uu.net [147.225.22.28]) by segue.merit.edu (Postfix) with ESMTP id B2C845DE58 for ; Thu, 14 Sep 2000 17:18:03 -0400 (EDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by mailrelay00.aa.ops.us.uu.net (8.9.3/8.9.3) with ESMTP id RAA27151 for ; Thu, 14 Sep 2000 17:18:02 -0400 (EDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA07520 for ; Thu, 14 Sep 2000 14:18:00 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 14:18:01 -0700 Message-ID: From: Srinivasa Chaganti To: BGP mailing list Subject: Error Handling in BGP multiprotocol extensions Date: Thu, 14 Sep 2000 14:17:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Hi, I have a question regarding Error handling when processing a BGP updates with multiprotocol extensions attributes. What should BGP speaker do when it receives an update message from a peer with MP_REACH_NLRI and/or MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present in it. Should the speaker ingnore the NLRI in the attributes or terminate the connection. I haven't found an answer for this specific error in RFC 2858. Thanks in advance for any help. -Chaganti S. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA17571 for ; Thu, 14 Sep 2000 05:13:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 431235DDCD; Thu, 14 Sep 2000 05:13:24 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 248955DDDC; Thu, 14 Sep 2000 05:13:24 -0400 (EDT) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by segue.merit.edu (Postfix) with ESMTP id 9EE215DDCD for ; Thu, 14 Sep 2000 05:13:22 -0400 (EDT) Received: from oleane (dyn-1-1-077.Vin.dialup.oleane.fr [195.25.4.77]) by smtp1.cluster.oleane.net with SMTP id LAA41777 for ; Thu, 14 Sep 2000 11:13:48 +0200 (CEST) Message-ID: <004d01c01e2b$efc70b00$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP over DWDM 2000 international conference Date: Thu, 14 Sep 2000 11:12:41 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C01E3C.B2C06C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C01E3C.B2C06C40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP over DWDM 2000 international conference, Paris 27-30 November : This event aims at presenting an up-to-date state of the art in the = design of new Internet network architectures. It will be a unique = opportunity for researchers, network operators and service providers = from both the IP world and the optical networking world to discuss the = potentialities of all these promising perspectives.=20 http://www.upperside.fr/badwdm.htm ------=_NextPart_000_004A_01C01E3C.B2C06C40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP over DWDM 2000 international conference, Paris 27-30 November = :
 
This event aims at presenting an up-to-date state of the art in the = design=20 of new Internet network architectures. It will be a unique opportunity = for=20 researchers, network operators and service providers from both the IP = world and=20 the optical networking world to discuss the potentialities of all these=20 promising perspectives.
 
http://www.upperside.fr/badwd= m.htm
 
------=_NextPart_000_004A_01C01E3C.B2C06C40-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA03160 for ; Tue, 12 Sep 2000 04:27:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 303F55DDAA; Tue, 12 Sep 2000 04:26:59 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 189935DDAE; Tue, 12 Sep 2000 04:26:59 -0400 (EDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by segue.merit.edu (Postfix) with ESMTP id 46CF25DDAA for ; Tue, 12 Sep 2000 04:26:57 -0400 (EDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Tue, 12 Sep 2000 09:26:44 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id S4ZNTLRL; Tue, 12 Sep 2000 09:26:44 +0100 Received: from hmdhp0nw (hmdhp0nw.europe.nortel.com [47.160.91.114]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id STBVP5B8; Tue, 12 Sep 2000 10:26:43 +0200 Message-Id: <4.2.2.20000912092424.029f2180@zvb1c002.corpemea.baynetworks.com > X-Sender: mdt@zvb1c002.corpemea.baynetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 12 Sep 2000 09:24:38 -0400 To: Anoop Ghanwani From: "Mark Thompson" Subject: Re: RFC 1772 Cc: "'idr@merit.edu'" In-Reply-To: <7EB7C6B62C4FD41196A80090279A29110BD8CB@exchsrv1.cosinecom. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1502617==_.ALT" Sender: owner-idr@merit.edu Precedence: bulk --=====================_1502617==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed No. Try ftp://ftp.isi.edu/in-notes/rfc1772.txt At 16:27 11/09/00 -0700, Anoop Ghanwani wrote: >Has RFC 1772 been obsoleted by something else? I couldn't >find it in the list of RFCs on the IDR WG page. -Anoop --=====================_1502617==_.ALT Content-Type: text/html; charset="us-ascii"
No.

Try ftp://ftp.isi.edu/in-notes/rfc1772.txt

At 16:27 11/09/00 -0700, Anoop Ghanwani wrote:

Has RFC 1772 been obsoleted by something else?  I couldn't
find it in the list of RFCs on the IDR WG page.  -Anoop
--=====================_1502617==_.ALT-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26507 for ; Mon, 11 Sep 2000 19:29:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9048A5DDF0; Mon, 11 Sep 2000 19:28:33 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F4AA5DDEC; Mon, 11 Sep 2000 19:28:33 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by segue.merit.edu (Postfix) with ESMTP id 01FD15DDCB for ; Mon, 11 Sep 2000 19:28:31 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Sep 2000 16:27:42 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29110BD8CB@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'idr@merit.edu'" Subject: RFC 1772 Date: Mon, 11 Sep 2000 16:27:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01C47.DE2200C0" Sender: owner-idr@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C01C47.DE2200C0 Content-Type: text/plain; charset="iso-8859-1" Has RFC 1772 been obsoleted by something else? I couldn't find it in the list of RFCs on the IDR WG page. -Anoop ------_=_NextPart_001_01C01C47.DE2200C0 Content-Type: text/html; charset="iso-8859-1" RFC 1772

Has RFC 1772 been obsoleted by something else?  I couldn't
find it in the list of RFCs on the IDR WG page.  -Anoop

------_=_NextPart_001_01C01C47.DE2200C0-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA05487 for ; Fri, 8 Sep 2000 17:29:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EFDD05DDCE; Fri, 8 Sep 2000 17:29:12 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D56315DE32; Fri, 8 Sep 2000 17:29:12 -0400 (EDT) Received: from io.equipecom.com (ns2.equipecommunications.com [209.6.39.130]) by segue.merit.edu (Postfix) with ESMTP id 34EEF5DDCE for ; Fri, 8 Sep 2000 17:29:11 -0400 (EDT) Received: from slim.equipecom.com. (slim.equipecom.com [192.168.254.2]) by io.equipecom.com (8.11.0/8.11.0) with ESMTP id e88LT6H17265; Fri, 8 Sep 2000 17:29:06 -0400 (EDT) Received: from eccexch01.equipecom.com (eccexch01.equipecom.com [192.168.1.11]) by slim.equipecom.com. (8.11.0/8.11.0) with ESMTP id e88LT6j06001; Fri, 8 Sep 2000 17:29:07 -0400 (EDT) Received: by eccexch01.equipecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 17:28:49 -0400 Message-ID: From: George Matey To: "'danny@tcb.net'" , idr@merit.edu Subject: RE: BGP Confederations Date: Fri, 8 Sep 2000 17:28:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Danny, First, I'm glad to see the banner was picked up, so this can progress to standards track. Thanks! Regarding your poll, I fully expected an updated spec to simply reverse the values. I would rather have that then require a knob to accommodate both scenarios ('historic' and 'updated' confederation formatting); that would serve no useful purpose. -- George > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: Friday, September 08, 2000 5:13 PM > To: idr@merit.edu > Subject: BGP Confederations > > > > Folks, > I'm updating the BGP Confederations spec and had a question. > It seems as > though the original code points: > > Value Segment Type > > 3 AS_CONFED_SET: unordered set of ASs in the local > confederation that the UPDATE message has traversed > > 4 AS_CONFED_SEQUENCE: ordered set of ASs in the local > confederation that the UPDATE message has traversed > > > specified in RFC 1965 were actually implemented backwards (3 = > AS_CONFED_SEQUENCE and 4 = AS_CONFED_SET) by several vendors, > and as such, > many newer implementations have realized this and implemented > them backwards > from RFC 1965 as well. > > That being the case, I was planning to change them in the > upcoming revision > but first wanted to take a poll and see what folks feelings > were on this? > > On a related note, I'm reviewing the archives to find other > bugs in the > current version, but if you're aware of any off the top of > your ahead please > do let me know. > > Thanks! > > -danny > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA05354 for ; Fri, 8 Sep 2000 17:24:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 337F65DFD6; Fri, 8 Sep 2000 17:21:54 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1F0315DF71; Fri, 8 Sep 2000 17:21:54 -0400 (EDT) Received: from vaio.zebra.org (4.arlington-08-09rs.va.dial-access.att.net [12.78.133.4]) by segue.merit.edu (Postfix) with ESMTP id C9E425DF76 for ; Fri, 8 Sep 2000 17:21:12 -0400 (EDT) Received: from localhost (vaio.zebra.org) [127.0.0.1] (kunihiro) by vaio.zebra.org with esmtp (Exim 3.12 #1 (Debian)) id 13XVbS-0000Bq-00; Fri, 08 Sep 2000 14:22:30 -0700 Date: Fri, 08 Sep 2000 14:22:29 -0700 Message-ID: <14777.22677.756355.29321F@vaio.zebra.org> From: Kunihiro Ishiguro To: danny@tcb.net Cc: idr@merit.edu Subject: Re: BGP Confederations User-Agent: Wanderlust/2.2.3 (Always) SEMI/1.13.4 (Terai) Chao/1.13.0 (JR Fujinomori) Emacs/20.7 (i686-pc-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >specified in RFC 1965 were actually implemented backwards (3 = >AS_CONFED_SEQUENCE and 4 = AS_CONFED_SET) by several vendors, and as such, >many newer implementations have realized this and implemented them backwards >from RFC 1965 as well. I also use below definition in Zebra's source code. It is hard to change deployed routers to follow RFC1965 value. #define AS_CONFED_SEQUENCE 3 #define AS_CONFED_SET 4 I think it is good think to revise RFC to deployed value. -- Kunihiro Ishiguro Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA05227 for ; Fri, 8 Sep 2000 17:13:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14C3E5DE70; Fri, 8 Sep 2000 17:12:29 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D59495DE86; Fri, 8 Sep 2000 17:12:28 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 7E6685DE70 for ; Fri, 8 Sep 2000 17:12:23 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id PAA12914 for ; Fri, 8 Sep 2000 15:12:43 -0600 Message-Id: <200009082112.PAA12914@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: BGP Confederations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Sep 2000 15:12:43 -0600 Sender: owner-idr@merit.edu Precedence: bulk Folks, I'm updating the BGP Confederations spec and had a question. It seems as though the original code points: Value Segment Type 3 AS_CONFED_SET: unordered set of ASs in the local confederation that the UPDATE message has traversed 4 AS_CONFED_SEQUENCE: ordered set of ASs in the local confederation that the UPDATE message has traversed specified in RFC 1965 were actually implemented backwards (3 = AS_CONFED_SEQUENCE and 4 = AS_CONFED_SET) by several vendors, and as such, many newer implementations have realized this and implemented them backwards from RFC 1965 as well. That being the case, I was planning to change them in the upcoming revision but first wanted to take a poll and see what folks feelings were on this? On a related note, I'm reviewing the archives to find other bugs in the current version, but if you're aware of any off the top of your ahead please do let me know. Thanks! -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27292 for ; Tue, 5 Sep 2000 12:06:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90B585DDB5; Tue, 5 Sep 2000 12:05:28 -0400 (EDT) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F0505DDB9; Tue, 5 Sep 2000 12:05:28 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 0045E5DDB5; Tue, 5 Sep 2000 12:05:26 -0400 (EDT) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA27030; Tue, 5 Sep 2000 09:05:34 -0700 (PDT) Message-Id: <200009051605.JAA27030@omega.cisco.com> To: Enke Chen Cc: yakov@cisco.com, skh@merit.edu, idr@merit.edu Subject: Re: draft-chen-bgp-route-filter-01.txt In-reply-to: Your message of "Mon, 21 Aug 2000 08:23:03 PDT." <20000821152349.91A8F17BC0D@postal.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27021.968169933.1@cisco.com> Date: Tue, 05 Sep 2000 09:05:34 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Enke, > Hi, Yakov and Sue: > I would like to request that the draft be considered as an IDR working > group document. Since we didn't hear any objections, this Internet Draft is now accepted as an IDR WG document. Yakov.