Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23993 for ; Fri, 29 Jun 2001 14:13:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E735F912D8; Fri, 29 Jun 2001 14:10:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA46D912DF; Fri, 29 Jun 2001 14:10:34 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93814912D8 for ; Fri, 29 Jun 2001 14:10:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7871F5DE16; Fri, 29 Jun 2001 14:11:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id D84235DE01 for ; Fri, 29 Jun 2001 14:11:38 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA11448; Fri, 29 Jun 2001 11:16:54 -0700 Date: Fri, 29 Jun 2001 11:16:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <5241307837.20010629111652@nexsi.com> To: "John G. Scudder" Cc: Ben Black , John Engelhart , Jeffrey Haas , Subject: Re: RFC 3065, confeds.. In-Reply-To: References: <7419455375.20010628023609@nexsi.com> <20010628175917.A35964@layer8.net> <1723106034.20010628184446@nexsi.com> <20010628184401.B35964@layer8.net> <1441291807.20010629000955@nexsi.com> <20010629093333.A50240@layer8.net> <11839613330.20010629104838@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk John, Thanks for historical info. I don't feel it is necessary, but if more people believe it makes sense to explicitly mention this, I won't object. -- Alex Zinin Friday, June 29, 2001, 10:57:02 AM, John G. Scudder wrote: > At 10:48 AM -0700 6/29/01, Alex Zinin wrote: >> > It wouldn't. >> >>IMO, we should avoid getting into the business of specifying how >>things do not work, unless there's an ambiguity. Among other things, >>the set of these "solutions" :) is infinite. > In general I agree. In this particular instance there is some case > to be made for mentioning you can't nest confeds since an earlier > iteration of the RFC alluded to nesting them. Since in fact you > cannot nest them, that was removed in the latest revision. (I think > the mention of nesting was a consequence of incompletely cribbing > confeds from IDRP. The ISO 10747 flavor *can* be nested, overlapped, > etc.) > It's not a big deal IMO, and by itself certainly doesn't justify > revving the RFC. > --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23644 for ; Fri, 29 Jun 2001 13:59:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 535E29129B; Fri, 29 Jun 2001 13:57:46 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EE54912D7; Fri, 29 Jun 2001 13:57:46 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2C3C9129B for ; Fri, 29 Jun 2001 13:57:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC23B5DE16; Fri, 29 Jun 2001 13:58:52 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 0938F5DE01 for ; Fri, 29 Jun 2001 13:58:52 -0400 (EDT) Received: from [192.168.42.3] (dhcp-171-69-182-140.cisco.com [171.69.182.140]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA28308; Fri, 29 Jun 2001 13:57:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <11839613330.20010629104838@nexsi.com> References: <7419455375.20010628023609@nexsi.com> <20010628175917.A35964@layer8.net> <1723106034.20010628184446@nexsi.com> <20010628184401.B35964@layer8.net> <1441291807.20010629000955@nexsi.com> <20010629093333.A50240@layer8.net> <11839613330.20010629104838@nexsi.com> Date: Fri, 29 Jun 2001 13:57:02 -0400 To: Alex Zinin From: "John G. Scudder" Subject: Re: RFC 3065, confeds.. Cc: Ben Black , John Engelhart , Jeffrey Haas , idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 10:48 AM -0700 6/29/01, Alex Zinin wrote: > > It wouldn't. > >IMO, we should avoid getting into the business of specifying how >things do not work, unless there's an ambiguity. Among other things, >the set of these "solutions" :) is infinite. In general I agree. In this particular instance there is some case to be made for mentioning you can't nest confeds since an earlier iteration of the RFC alluded to nesting them. Since in fact you cannot nest them, that was removed in the latest revision. (I think the mention of nesting was a consequence of incompletely cribbing confeds from IDRP. The ISO 10747 flavor *can* be nested, overlapped, etc.) It's not a big deal IMO, and by itself certainly doesn't justify revving the RFC. --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23353 for ; Fri, 29 Jun 2001 13:43:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE7ED9129A; Fri, 29 Jun 2001 13:42:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E1529129B; Fri, 29 Jun 2001 13:42:09 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C80F9129A for ; Fri, 29 Jun 2001 13:42:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 662705DDF0; Fri, 29 Jun 2001 13:43:16 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id EC8935DDDE for ; Fri, 29 Jun 2001 13:43:15 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id KAA11082; Fri, 29 Jun 2001 10:48:39 -0700 Date: Fri, 29 Jun 2001 10:48:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <11839613330.20010629104838@nexsi.com> To: Ben Black Cc: John Engelhart , Jeffrey Haas , idr@merit.edu Subject: Re: RFC 3065, confeds.. In-Reply-To: <20010629093333.A50240@layer8.net> References: <7419455375.20010628023609@nexsi.com> <20010628175917.A35964@layer8.net> <1723106034.20010628184446@nexsi.com> <20010628184401.B35964@layer8.net> <1441291807.20010629000955@nexsi.com> <20010629093333.A50240@layer8.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Ben, > It wouldn't. IMO, we should avoid getting into the business of specifying how things do not work, unless there's an ambiguity. Among other things, the set of these "solutions" :) is infinite. Alex. >> > Might it also be useful to explicitly state that nesting confederations >> > is not a valid configuration? >> >> Hmmm... Never thought about this. How would such a beast work? Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21990 for ; Fri, 29 Jun 2001 12:39:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2544C91296; Fri, 29 Jun 2001 12:37:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2E8C9129E; Fri, 29 Jun 2001 12:37:27 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E19C691296 for ; Fri, 29 Jun 2001 12:37:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1F025DDD5; Fri, 29 Jun 2001 12:38:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 30F7F5DDCB for ; Fri, 29 Jun 2001 12:38:33 -0400 (EDT) Received: (qmail 50298 invoked by uid 1000); 29 Jun 2001 16:33:33 -0000 Date: Fri, 29 Jun 2001 09:33:33 -0700 From: Ben Black To: Alex Zinin Cc: John Engelhart , Jeffrey Haas , idr@merit.edu Subject: Re: RFC 3065, confeds.. Message-ID: <20010629093333.A50240@layer8.net> References: <7419455375.20010628023609@nexsi.com> <20010628175917.A35964@layer8.net> <1723106034.20010628184446@nexsi.com> <20010628184401.B35964@layer8.net> <1441291807.20010629000955@nexsi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1441291807.20010629000955@nexsi.com>; from azinin@nexsi.com on Fri, Jun 29, 2001 at 12:09:55AM -0700 Sender: owner-idr@merit.edu Precedence: bulk --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It wouldn't. Ben On Fri, Jun 29, 2001 at 12:09:55AM -0700, Alex Zinin wrote: >=20 > > Might it also be useful to explicitly state that nesting confederations > > is not a valid configuration? >=20 > Hmmm... Never thought about this. How would such a beast work? >=20 > Alex. >=20 --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: OMFr2UwmI52C0xsbVLPI5C5Knhk9/tts iQA/AwUBOzyt3GM46bcYfOYxEQJPEQCg0i1uf9sNa+nH41AJniQDSSZvt1sAoPCT aLr10jGjMm0sMcx3Pu+vn5D/ =tY+4 -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA10059 for ; Fri, 29 Jun 2001 03:05:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEB7691203; Fri, 29 Jun 2001 03:03:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 101A8912C9; Fri, 29 Jun 2001 03:03:32 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A641991203 for ; Fri, 29 Jun 2001 03:03:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62C1B5DDB6; Fri, 29 Jun 2001 03:04:34 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id B6B265DE2E for ; Fri, 29 Jun 2001 03:04:33 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id AAA06840; Fri, 29 Jun 2001 00:09:56 -0700 Date: Fri, 29 Jun 2001 00:09:55 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1441291807.20010629000955@nexsi.com> To: Ben Black Cc: John Engelhart , Jeffrey Haas , idr@merit.edu Subject: Re: RFC 3065, confeds.. In-Reply-To: <20010628184401.B35964@layer8.net> References: <7419455375.20010628023609@nexsi.com> <20010628175917.A35964@layer8.net> <1723106034.20010628184446@nexsi.com> <20010628184401.B35964@layer8.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > Might it also be useful to explicitly state that nesting confederations > is not a valid configuration? Hmmm... Never thought about this. How would such a beast work? Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA02780 for ; Thu, 28 Jun 2001 21:55:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA01F912C7; Thu, 28 Jun 2001 21:54:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1948912C8; Thu, 28 Jun 2001 21:54:09 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0617912C7 for ; Thu, 28 Jun 2001 21:54:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77AF95DE13; Thu, 28 Jun 2001 21:55:15 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id B9D815DDB6 for ; Thu, 28 Jun 2001 21:55:14 -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 SAA32486 for ; Thu, 28 Jun 2001 18:54:27 -0600 Message-Id: <200106290054.SAA32486@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: RFC 3065, confeds.. Date: Thu, 28 Jun 2001 18:54:27 -0600 Sender: owner-idr@merit.edu Precedence: bulk I'll give it some work within the next few weeks, as folks seem to be pretty concerned. There are some other clarifications that need to be made, so I'll get to fix those as well. I'd encourage you to have your vendors fix their code if [you|they] think it's broken. Of course, this is what usually happens, regardless of what any document says. -danny Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA02662 for ; Thu, 28 Jun 2001 21:51:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4A2F9128D; Thu, 28 Jun 2001 21:48:00 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DBF0912D6; Thu, 28 Jun 2001 21:48:00 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 158199128D for ; Thu, 28 Jun 2001 21:47:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB9D25DE14; Thu, 28 Jun 2001 21:49:04 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 4C6255DE06 for ; Thu, 28 Jun 2001 21:49:04 -0400 (EDT) Received: (qmail 37692 invoked by uid 1000); 29 Jun 2001 01:44:01 -0000 Date: Thu, 28 Jun 2001 18:44:01 -0700 From: Ben Black To: Alex Zinin Cc: John Engelhart , Jeffrey Haas , idr@merit.edu Subject: Re: RFC 3065, confeds.. Message-ID: <20010628184401.B35964@layer8.net> References: <7419455375.20010628023609@nexsi.com> <20010628175917.A35964@layer8.net> <1723106034.20010628184446@nexsi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1723106034.20010628184446@nexsi.com>; from azinin@nexsi.com on Thu, Jun 28, 2001 at 06:44:46PM -0700 Sender: owner-idr@merit.edu Precedence: bulk --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Might it also be useful to explicitly state that nesting confederations is not a valid configuration? Ben On Thu, Jun 28, 2001 at 06:44:46PM -0700, Alex Zinin wrote: >=20 > Ben, >=20 > Seems to be indeed better to me. >=20 > "the any" should be "any" >=20 > Alex. >=20 > > I believe this could more effectively be communicated if you instead ma= ke > > a minor change to step 1 in (c): >=20 > > 1) if the first path segment of the AS_PATH is of type > > AS_CONFED_SEQUENCE, that segment and any immediately following > > segments of the type AS_CONFED_SET or AS_CONFED_SEQUENCE are > > removed from the AS_PATH attribute, leaving the sanitized > > AS_PATH attribute to be operated on by steps 2, or 3. >=20 > > Change this statement to: >=20 > > 1) if the any path segments of the AS_PATH are of type AS_CONFED_= SET > > or AS_CONFED_SEQUENCE, those segments are removed from the AS_= PATH > > attribute, leaving the sanitized AS_PATH attribute to be opera= ted > > on by steps 2 or 3. >=20 > > This removes the conflict between (c) and (c.1) that is present with the > > change you proposed above. >=20 >=20 > > Ben >=20 --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: QSMyzlZBFrkEZ0j73VAcK3fJKDQjO+Eu iQA/AwUBOzvdYGM46bcYfOYxEQKzZQCg7bQ5iBPe2VxlVPzVvjP9gbrMYFEAn0GA jTgNmGSfEG49khxhC/7T+xlm =6pux -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA02456 for ; Thu, 28 Jun 2001 21:40:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 855DC9128C; Thu, 28 Jun 2001 21:38:22 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5703C9128D; Thu, 28 Jun 2001 21:38:22 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F8DC9128C for ; Thu, 28 Jun 2001 21:38:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E5015DE06; Thu, 28 Jun 2001 21:39:28 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id 9D2E05DDB6 for ; Thu, 28 Jun 2001 21:39:27 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA04930; Thu, 28 Jun 2001 18:44:46 -0700 Date: Thu, 28 Jun 2001 18:44:46 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1723106034.20010628184446@nexsi.com> To: Ben Black Cc: John Engelhart , Jeffrey Haas , idr@merit.edu Subject: Re: RFC 3065, confeds.. In-Reply-To: <20010628175917.A35964@layer8.net> References: <7419455375.20010628023609@nexsi.com> <20010628175917.A35964@layer8.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Ben, Seems to be indeed better to me. "the any" should be "any" Alex. > I believe this could more effectively be communicated if you instead make > a minor change to step 1 in (c): > 1) if the first path segment of the AS_PATH is of type > AS_CONFED_SEQUENCE, that segment and any immediately following > segments of the type AS_CONFED_SET or AS_CONFED_SEQUENCE are > removed from the AS_PATH attribute, leaving the sanitized > AS_PATH attribute to be operated on by steps 2, or 3. > Change this statement to: > 1) if the any path segments of the AS_PATH are of type AS_CONFED_SET > or AS_CONFED_SEQUENCE, those segments are removed from the AS_PATH > attribute, leaving the sanitized AS_PATH attribute to be operated > on by steps 2 or 3. > This removes the conflict between (c) and (c.1) that is present with the > change you proposed above. > Ben Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA01656 for ; Thu, 28 Jun 2001 21:04:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1C3F79128A; Thu, 28 Jun 2001 21:03:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E42779128C; Thu, 28 Jun 2001 21:03:14 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 087E49128A for ; Thu, 28 Jun 2001 21:03:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93DA55DE06; Thu, 28 Jun 2001 21:04:20 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 3D8045DDB6 for ; Thu, 28 Jun 2001 21:04:20 -0400 (EDT) Received: (qmail 37026 invoked by uid 1000); 29 Jun 2001 00:59:17 -0000 Date: Thu, 28 Jun 2001 17:59:17 -0700 From: Ben Black To: Alex Zinin Cc: John Engelhart , Jeffrey Haas , idr@merit.edu Subject: Re: RFC 3065, confeds.. Message-ID: <20010628175917.A35964@layer8.net> References: <7419455375.20010628023609@nexsi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7419455375.20010628023609@nexsi.com>; from alexzinin@home.com on Thu, Jun 28, 2001 at 02:36:09AM -0700 Sender: owner-idr@merit.edu Precedence: bulk --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2001 at 02:36:09AM -0700, Alex Zinin wrote: >=20 > 6.1. AS_PATH Modification Rules >=20 > [...] >=20 > c) When a given BGP speaker advertises the route to a BGP speaker > located in a neighboring autonomous system that is not a member of > the current autonomous system confederation, the advertising > speaker shall update the AS_PATH attribute as follows: >=20 > /* Add: > ...as follows. Note that > the BGP speaker must ensure that no AS_CONDEF_SEQUENCE or AS_CONFED_SET > path segments are left in the AS_PATH attribute when it is announced outs= ide > of the confederation. >=20 > */ >=20 I believe this could more effectively be communicated if you instead make a minor change to step 1 in (c): 1) if the first path segment of the AS_PATH is of type AS_CONFED_SEQUENCE, that segment and any immediately following segments of the type AS_CONFED_SET or AS_CONFED_SEQUENCE are removed from the AS_PATH attribute, leaving the sanitized AS_PATH attribute to be operated on by steps 2, or 3. Change this statement to: 1) if the any path segments of the AS_PATH are of type AS_CONFED_SET or AS_CONFED_SEQUENCE, those segments are removed from the AS_PATH attribute, leaving the sanitized AS_PATH attribute to be operated on by steps 2 or 3. This removes the conflict between (c) and (c.1) that is present with the change you proposed above. Ben --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: qD6TQfXpE3Vk4Yet6zey5RO3DqURxUj0 iQA/AwUBOzvS5GM46bcYfOYxEQKEGgCfVHC73R2+UDJWVZ1TEn3JHi8PTRIAn2m8 GWt3XIKLHVSAxeF2SOhZotjS =M2Zw -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA11411 for ; Thu, 28 Jun 2001 05:31:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF928912C2; Thu, 28 Jun 2001 05:29:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCFF191378; Thu, 28 Jun 2001 05:29:08 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84852912C2 for ; Thu, 28 Jun 2001 05:29:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B19B75DDCC; Thu, 28 Jun 2001 05:30:12 -0400 (EDT) Delivered-To: idr@merit.edu Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by segue.merit.edu (Postfix) with ESMTP id 70A2C5DDCB for ; Thu, 28 Jun 2001 05:30:12 -0400 (EDT) Received: from khonsu.sw.nexsi.com ([24.250.169.131]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010628092925.MXGM12223.femail4.sdc1.sfba.home.com@khonsu.sw.nexsi.com>; Thu, 28 Jun 2001 02:29:25 -0700 Date: Thu, 28 Jun 2001 02:36:09 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7419455375.20010628023609@nexsi.com> To: John Engelhart Cc: Jeffrey Haas , idr@merit.edu Subject: Re: RFC 3065, confeds.. In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk John, > Allright, take 2 on this whole fiasco. This RFC needs work, ASAP. It has > now caused two major outages in the internet. I agree, to make sure people don't mess future implementations, this should be documented and the text should be changed to be more explicit about points a), b), and c) you mentioned. I agree with Jeff on d) however. Below is what I think can be added. It is redundant on purpose, so the WG can decide what to leave/add/take out. Regards, Alex. 5. AS_CONFED Segment Type Extension [...] This document reserves two additional segment types: 3 AS_CONFED_SEQUENCE: ordered set of Member AS Numbers in the local confederation that the UPDATE message has traversed 4 AS_CONFED_SET: unordered set of Member AS Numbers in the local confederation that the UPDATE message has traversed /* Add: The scope of distribution of the new segment types is limited to the borders of a specific confederation, i.e., no BGP update message sent over an external BGP session with a peer outside of the confederation should include an AS_CONFED_SEQUENCE or an AS_CONFED_SET segment in the AS_PATH attribute. */ 6. Operation [...] A BGP speaker receiving an AS_PATH attribute containing an autonomous system matching its own confederation shall treat the path in the same fashion as if it had received a path containing its own AS number. // ^+See Section 6.2 for more details. 6.1. AS_PATH Modification Rules [...] c) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is not a member of the current autonomous system confederation, the advertising speaker shall update the AS_PATH attribute as follows: /* Add: ...as follows. Note that the BGP speaker must ensure that no AS_CONDEF_SEQUENCE or AS_CONFED_SET path segments are left in the AS_PATH attribute when it is announced outside of the confederation. */ /* Add: 6.2 Processing Incoming Updates When processing an incoming update that contains an AS_CONFED_SEQUENCE or an AS_CONDEF_SET segment in the AS_PATH attribute, the BGP speaker should perform the following check. If the update is received from an external BGP neighbor that does not belong to the same AS confederation, or the update is received from an internal BGP neighbor, but the speaker itself is not configured to perform AS confederation functionality, the update packet should be ignored and an error should be logged locally. */ 8. Compatability Considerations [...] /* Add: To avoid potential disruption in the autonomous systems that do not support extensions described in this document, implementations must ensure that no confederation-specific information is announced to or received from the external BGP peers outside of the confederation (see Sections 6.1 and 6.2). */ Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA09916 for ; Thu, 28 Jun 2001 04:24:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B18D7912C0; Thu, 28 Jun 2001 04:23:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F010912C1; Thu, 28 Jun 2001 04:23:03 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AD81912C0 for ; Thu, 28 Jun 2001 04:23:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81B915DDB7; Thu, 28 Jun 2001 04:24:07 -0400 (EDT) Delivered-To: idr@merit.edu Received: from epitome.exodus.net (epitome.exodus.net [209.185.97.200]) by segue.merit.edu (Postfix) with ESMTP id D11E95DDB0 for ; Thu, 28 Jun 2001 04:24:06 -0400 (EDT) Received: from localhost (johne@localhost) by epitome.exodus.net (8.9.3+Sun/8.9.3) with ESMTP id BAA24879; Thu, 28 Jun 2001 01:21:50 -0700 (PDT) X-Authentication-Warning: epitome.exodus.net: johne owned process doing -bs Date: Thu, 28 Jun 2001 01:21:50 -0700 (PDT) From: John Engelhart To: Jeffrey Haas Cc: Subject: Re: RFC 3065, confeds.. In-Reply-To: <20010627105343.A7138@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Wed, 27 Jun 2001, Jeffrey Haas wrote: > On Tue, Jun 26, 2001 at 07:38:43PM -0700, John Engelhart wrote: > > > c) Implementations should only accept AS_CONFED_* info if confederations > > are enabled, else drop them as malformed as_paths (from edc) > > This is the currently specified behavior: > > : Any BGP speaker not supporting these extensions will generate a > : notification message specifying an "UPDATE Message Error" and a sub- > : code of "Malformed AS_PATH". Allright, take 2 on this whole fiasco. This RFC needs work, ASAP. It has now caused two major outages in the internet. Specifically, the above quoted section from the RFC is being interpreted by Cisco and Juniper to mean that even if confederations aren't enabled and configured, it's still valid to accept and pass them on to other IBGP peers. This is having devastating effects to non-3065 speakers in many providers networks. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23200 for ; Wed, 27 Jun 2001 14:26:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EFFD191379; Wed, 27 Jun 2001 14:23:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B930691378; Wed, 27 Jun 2001 14:23:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9428091373 for ; Wed, 27 Jun 2001 14:23:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB7FA5DDB0; Wed, 27 Jun 2001 14:24:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from epitome.exodus.net (epitome.exodus.net [209.185.97.200]) by segue.merit.edu (Postfix) with ESMTP id 69D0C5DD8D for ; Wed, 27 Jun 2001 14:24:52 -0400 (EDT) Received: from localhost (johne@localhost) by epitome.exodus.net (8.9.3+Sun/8.9.3) with ESMTP id LAA23173; Wed, 27 Jun 2001 11:22:32 -0700 (PDT) X-Authentication-Warning: epitome.exodus.net: johne owned process doing -bs Date: Wed, 27 Jun 2001 11:22:32 -0700 (PDT) From: John Engelhart To: Jeffrey Haas Cc: Subject: Re: RFC 3065, confeds.. In-Reply-To: <20010627105343.A7138@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Wed, 27 Jun 2001, Jeffrey Haas wrote: > On Tue, Jun 26, 2001 at 07:38:43PM -0700, John Engelhart wrote: > > We, Exodus, don't run with confederations. Some of our speakers are non > > RFC3065 capable. But, as point #1 states, this isn't a problem. Unless a > > vendor has bugs and starts leaking confed info into the BGP routing > > tables. > > If the vendor has bugs, the bugs should be FIXED. If the issue is > you're getting leakage due to bugs, how can you trust the peering > session at all? Yep. The vendor is fixing the bugs. But, IMHO, the spec needs some tweaking as well. > > a) Explicit language to not send AS_PATH AS_CONFED_* to EBGP peers > > The only way you SHOULD get this is if the router you are peering > with has explicitly configured your AS as a confederation member: > > : c) When a given BGP speaker advertises the route to a BGP speaker > : located in a neighboring autonomous system that is not a member of > : the current autonomous system confederation, the advertising > : speaker shall update the AS_PATH attribute as follows: > > And several sane rules follow. Yes, it's generally agreed that the spec says that you shouldn't leak confed info across AS boundires. I'm saying update the language to make it specific and explicit. > > c) Implementations should only accept AS_CONFED_* info if confederations > > are enabled, else drop them as malformed as_paths (from edc) > > This is the currently specified behavior: > > : Any BGP speaker not supporting these extensions will generate a > : notification message specifying an "UPDATE Message Error" and a sub- > : code of "Malformed AS_PATH". Here I disagree with you. Even if it's just an implementation tweak, I still think language should be added to the RFC 3065 for this. Why? We're here to learn from our mistakes. Big mistakes have been made. Let's document them and pass them on to future writers of BGP implemenations. I think everyone agrees that the spirit of the above was to disallow CONFED info if confederations weren't enabled. Unfortunatly, one very popular router vendor has a different interpertation of things. This is why I want it clarified. > > d) Confederations should be a negotiated capability, as it fundamentally > > alters RFC 1771 with dire results for non 3065 speakers. With no warning. > > A rude suprise for operational networks if someone just turns Confeds on > > without warning, > > The only way this SHOULD happen is your peer is misconfigured. This isn't an academic problem. This very scenerio whizzed through the internet last weekend and took down huge swaths in its wake. The spec is ambiguous on a few points. Let's clarify them with the painful knowledge we've learned from running a network. > > or it accidentally leaks across because non conformance > > with A or B. > > In which case, can you trust the router at all? This crosses my mind daily, unfortunatly. :( > > AS_PATH is a Mandatory attribute. Anything altering > > mandatory attributes in the core spec should be negotiated, because you're > > no longer core spec. > > IMO, capability advertisement (note - not negotiation) doesn't solve > any of your core issues, which seems to be buggy vendor code. If > you don't advertise the confederation capability, and the vendor > doesn't sanitize the AS_PATH, we still have the same issue. We've got buggy router code. Actually, probably most everyone out there does right now, as of today. But let's not leave things open for interpertation. Let's make it explicit. Ambiguity in the spec is bad, bad, bad. If everyone had followed rule A, nothing would have happened. Unfortunatly, a bug let it leak across. And then, they didn't implement rule B. And they didn't implment rule C, because they support RFC 3065 confederations, which means it's perfectly legal data for them to get. And everyone implements rule A, so I'm not getting this from an EBGP peer. It then happily passed all of this along to all the other routers like a virus. And killed non-RFC 3065 speakers. Again. And again. And again. > The only big bonus that capability advertisement would buy us is > having the capability payload verify that the peers are in the > same confederation and dropping the peering session otherwise. Point D is up for debate. It's mostly religous on my part, I hate things that are getting modified on you without your knowledge. It's one thing if you negotiate for the modifications, then everyone has the same common language. But just being able to switch extra bits in and out without forwarning.... not good. Had rules A through C been implemented, this would have been a total non issue. Since they can possibly help contain future outbreaks of similar confed bugs, I recommend the RFC be updated. Then, when someone else decides to write or add BGP confederation support, they'll go "Hmmm, makes sense" and avoid our mistakes. > -- > Jeff Haas > NextHop Technologies > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21863 for ; Wed, 27 Jun 2001 13:39:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C5DE9136F; Wed, 27 Jun 2001 13:37:48 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4192291370; Wed, 27 Jun 2001 13:37:48 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29E5D9136F for ; Wed, 27 Jun 2001 13:37:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A2195DDBA; Wed, 27 Jun 2001 13:38:51 -0400 (EDT) Delivered-To: idr@merit.edu Received: from smtp.adc.com (smtp.adc.com [155.226.10.207]) by segue.merit.edu (Postfix) with ESMTP id 489B55DDA6 for ; Wed, 27 Jun 2001 13:38:49 -0400 (EDT) Received: from kbenstead (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with SMTP id f5RHc1U13513; Wed, 27 Jun 2001 12:38:01 -0500 (CDT) From: "Ken Benstead" To: Subject: Testing Again Date: Wed, 27 Jun 2001 13:40:48 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idr@merit.edu Precedence: bulk Please ignore. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA18103 for ; Wed, 27 Jun 2001 10:55:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 082EF91275; Wed, 27 Jun 2001 10:53:37 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C608F91276; Wed, 27 Jun 2001 10:53:36 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C402C91275 for ; Wed, 27 Jun 2001 10:53:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D1625DDBA; Wed, 27 Jun 2001 10:54:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 4859D5DDB4 for ; Wed, 27 Jun 2001 10:54:39 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f5REroZ18953; Wed, 27 Jun 2001 10:53:50 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f5RErhY07267; Wed, 27 Jun 2001 10:53:43 -0400 (EDT) Date: Wed, 27 Jun 2001 10:53:43 -0400 From: Jeffrey Haas To: idr@merit.edu Cc: John Engelhart Subject: Re: RFC 3065, confeds.. Message-ID: <20010627105343.A7138@nexthop.com> References: <200106270111.TAA16713@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johne@exodus.net on Tue, Jun 26, 2001 at 07:38:43PM -0700 Sender: owner-idr@merit.edu Precedence: bulk On Tue, Jun 26, 2001 at 07:38:43PM -0700, John Engelhart wrote: > We, Exodus, don't run with confederations. Some of our speakers are non > RFC3065 capable. But, as point #1 states, this isn't a problem. Unless a > vendor has bugs and starts leaking confed info into the BGP routing > tables. If the vendor has bugs, the bugs should be FIXED. If the issue is you're getting leakage due to bugs, how can you trust the peering session at all? > a) Explicit language to not send AS_PATH AS_CONFED_* to EBGP peers The only way you SHOULD get this is if the router you are peering with has explicitly configured your AS as a confederation member: : c) When a given BGP speaker advertises the route to a BGP speaker : located in a neighboring autonomous system that is not a member of : the current autonomous system confederation, the advertising : speaker shall update the AS_PATH attribute as follows: And several sane rules follow. > c) Implementations should only accept AS_CONFED_* info if confederations > are enabled, else drop them as malformed as_paths (from edc) This is the currently specified behavior: : Any BGP speaker not supporting these extensions will generate a : notification message specifying an "UPDATE Message Error" and a sub- : code of "Malformed AS_PATH". > d) Confederations should be a negotiated capability, as it fundamentally > alters RFC 1771 with dire results for non 3065 speakers. With no warning. > A rude suprise for operational networks if someone just turns Confeds on > without warning, The only way this SHOULD happen is your peer is misconfigured. > or it accidentally leaks across because non conformance > with A or B. In which case, can you trust the router at all? > AS_PATH is a Mandatory attribute. Anything altering > mandatory attributes in the core spec should be negotiated, because you're > no longer core spec. IMO, capability advertisement (note - not negotiation) doesn't solve any of your core issues, which seems to be buggy vendor code. If you don't advertise the confederation capability, and the vendor doesn't sanitize the AS_PATH, we still have the same issue. The only big bonus that capability advertisement would buy us is having the capability payload verify that the peers are in the same confederation and dropping the peering session otherwise. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16598 for ; Wed, 27 Jun 2001 09:47:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A21091272; Wed, 27 Jun 2001 09:45:52 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25D6F9136E; Wed, 27 Jun 2001 09:45:52 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF65891272 for ; Wed, 27 Jun 2001 09:45:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 984165DE64; Wed, 27 Jun 2001 09:46:54 -0400 (EDT) Delivered-To: idr@merit.edu Received: from smtp.adc.com (smtp.adc.com [155.226.10.207]) by segue.merit.edu (Postfix) with ESMTP id 299F85DE63 for ; Wed, 27 Jun 2001 09:46:54 -0400 (EDT) Received: from kbenstead (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with SMTP id f5RDk8107610 for ; Wed, 27 Jun 2001 08:46:08 -0500 (CDT) From: "Ken Benstead" To: Subject: Test Date: Wed, 27 Jun 2001 09:48:55 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idr@merit.edu Precedence: bulk Please ignore Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA03396 for ; Tue, 26 Jun 2001 23:56:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54D0E91361; Tue, 26 Jun 2001 23:53:06 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E01D91364; Tue, 26 Jun 2001 23:53:06 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DBBD91361 for ; Tue, 26 Jun 2001 23:53:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78ED65DDB4; Tue, 26 Jun 2001 23:54:05 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ns.zhongxing.com (unknown [202.103.147.131]) by segue.merit.edu (Postfix) with ESMTP id 7994B5DD9B for ; Tue, 26 Jun 2001 23:54:04 -0400 (EDT) Received: from mail.zte.com.cn (unverified [10.30.1.249]) by ns.zhongxing.com (Rockliffe SMTPRA 4.2.4) with ESMTP id for ; Wed, 27 Jun 2001 12:01:10 +0800 Subject: question of rfc2858 To: idr@merit.edu X-Mailer: Lotus Notes Release 5.0.1 (Intl) 16 July 1999 Message-ID: From: ji.xiaowei@mail.zte.com.cn Date: Wed, 27 Jun 2001 10:46:39 +0800 X-MIMETrack: Serialize by Router on notes_svr7/zte_ltd(Release 5.0.6a |January 17, 2001) at 2001-06-27 11:51:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk As rfc2858 says,in a update message,the MP_REACH_NLRI attribute carry only one single instance of . I want to know,if i have many NLRIs to advertise by MP_REACH_NLRI,should I build same number of update messages as that of NLRIs?And is it efficient? thanks for your help. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA01986 for ; Tue, 26 Jun 2001 22:41:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1BFA91356; Tue, 26 Jun 2001 22:39:50 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BECCB9135A; Tue, 26 Jun 2001 22:39:49 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AFA891356 for ; Tue, 26 Jun 2001 22:39:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 66C1D5DE5A; Tue, 26 Jun 2001 22:40:51 -0400 (EDT) Delivered-To: idr@merit.edu Received: from epitome.exodus.net (epitome.exodus.net [209.185.97.200]) by segue.merit.edu (Postfix) with ESMTP id DFE8E5DDB4 for ; Tue, 26 Jun 2001 22:40:50 -0400 (EDT) Received: from localhost (johne@localhost) by epitome.exodus.net (8.9.3+Sun/8.9.3) with ESMTP id TAA21405 for ; Tue, 26 Jun 2001 19:38:43 -0700 (PDT) X-Authentication-Warning: epitome.exodus.net: johne owned process doing -bs Date: Tue, 26 Jun 2001 19:38:43 -0700 (PDT) From: John Engelhart To: Subject: RFC 3065, confeds.. In-Reply-To: <200106270111.TAA16713@tcb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk We've had some debate on this internally and I'd like to bounce them off the list. It is my opinion, and a few others, that RC 3065 should be modified to be a Capability Negotiated item. Why? Because it screws your network wholesale if it's not. RFC 3065 fundamentally alters RFC 1771. The problem with this is it gives the far side no forewarning that it's about to send data that it may not be prepared for. This may be fine if this is taken into account. Anyone who's going be using confederations had best make sure that all speakers can talk confederations. Usually not a problem. It's the "usually" part that screws you, and screwed us, big time. We, Exodus, don't run with confederations. Some of our speakers are non RFC3065 capable. But, as point #1 states, this isn't a problem. Unless a vendor has bugs and starts leaking confed info into the BGP routing tables. What's the only recourse for non speakers? Shut down the peering session. In a big network, this can be lots of fun. Keep in mind, this is no longer theoretical, it's happened. It's painful. So, IMHO, and open for discussion, I think the following changes should be made: a) Explicit language to not send AS_PATH AS_CONFED_* to EBGP peers b) Explicit language to not accept AS_PATH AS_CONFED_* from EBGP peers c) Implementations should only accept AS_CONFED_* info if confederations are enabled, else drop them as malformed as_paths (from edc) d) Confederations should be a negotiated capability, as it fundamentally alters RFC 1771 with dire results for non 3065 speakers. With no warning. A rude suprise for operational networks if someone just turns Confeds on without warning, or it accidentally leaks across because non conformance with A or B. AS_PATH is a Mandatory attribute. Anything altering mandatory attributes in the core spec should be negotiated, because you're no longer core spec. I'm really adamant about point D. If you open up a BGP connection with a peer, and nothing gets negotiated, you're speaking RFC 1771. If one guy decides to start sending extra information, but the other doesn't support it, who's at fault? In the end, it's the people using the network because the only recourse available is to close the peering session. And lemme tell you, this thing propagates like a VIRUS once let loose in the network. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA01446 for ; Tue, 26 Jun 2001 22:12:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B88191269; Tue, 26 Jun 2001 22:11:00 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4744C91353; Tue, 26 Jun 2001 22:11:00 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 516EF91269 for ; Tue, 26 Jun 2001 22:10:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 118AA5DE58; Tue, 26 Jun 2001 22:12:02 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 58C495DDB4 for ; Tue, 26 Jun 2001 22:12:01 -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 TAA16713 for ; Tue, 26 Jun 2001 19:11:17 -0600 Message-Id: <200106270111.TAA16713@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: RFC 3065, Confederation... Date: Tue, 26 Jun 2001 19:11:17 -0600 Sender: owner-idr@merit.edu Precedence: bulk > My email doesn't appear to be showing up on idr. I'm mailing you because > I think it's important. Yep, the idr-post(?) list... As for your points, they'll be clarified/corrected if/when another update is made. Thanks! -danny Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA26910 for ; Tue, 26 Jun 2001 18:10:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF1DD9134A; Tue, 26 Jun 2001 18:09:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A04A39134E; Tue, 26 Jun 2001 18:09:04 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB17F9134A for ; Tue, 26 Jun 2001 18:09:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 30B585DE50; Tue, 26 Jun 2001 18:10:06 -0400 (EDT) Delivered-To: idr@merit.edu Received: from gevurah.exodus.net (unknown [216.32.171.180]) by segue.merit.edu (Postfix) with ESMTP id A6C295DE05 for ; Tue, 26 Jun 2001 18:10:05 -0400 (EDT) Received: (from edc@localhost) by gevurah.exodus.net (8.10.2/8.10.2) id f5QK9Yk11283; Tue, 26 Jun 2001 15:09:34 -0500 (CDT) Date: Tue, 26 Jun 2001 15:09:34 -0500 From: edc@exodus.net To: Yakov Rekhter Cc: idr@merit.edu Subject: as path attr, as segment t(3|4) handling Message-ID: <20010626150934.C9296@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 3065 specifies a specific order for as path segments in it's ebgp announcement cleanup operations (sec.6.1,c,1). This is valid if you assume that all vendors implement spec correctly; this is obviously not going to be the case. It would be better if the the entire as-path attr. was examined for cleanup, rather than assuming correct ordering. Also, it would might be good to specify that processing for as segment type 3,4 is /off/ when confed. is not configured on a receiving device, and that, as a result, a notification should be generated as in 3065, sec.8. -ed --> Yakov Rekhter [010626 14:18]: > fyi > ------- Forwarded Message > > Date: Tue, 26 Jun 2001 13:03:54 -0700 > From: John Engelhart > To: , > cc: , > "Ed 'I turned out just television' Crabbe" > Subject: RFC 3065, Confederation clarification (fwd) > > Hi guys, > > My email doesn't appear to be showing up on idr. I'm mailing you because > I think it's important. > > Furthermore, we've since found one additional point of contention. RFC > 3065, section 6.1.b.1 and 6.1.b.2 specifiy the position in which AS_CONFED > path info must appear in an AS_PATH announcement. IMHO, position is > irrelevent, as long as it's only one of each type (seq & set). > > Do you have to subscribe to another list in order to post to IDR? > > - ---------- Forwarded message ---------- > Date: Mon, 25 Jun 2001 16:17:38 -0700 (PDT) > From: John Engelhart > To: idr@merit.edu > Subject: RFC 3065, Confederation clarification > > Correct me if I'm wrong, but shouldn't the behaviour of confederation > logic work something like this: > > a) Do not send AS_PATH AS_CONFED_* to EBGP peers > > b) Do not accept AS_PATH AS_CONFED_* from EBGP peers > > While the RFC is clear about item A, it is not clear about item B. If a > vendors implementation doesn't support confederations, the result of > sending CONFED info across EBGP links is clear- tear down the session with > a NOTIFY of malformed as-path. > > However, if the vendors implementation DOES support confederations, the > result is less clear. Expected, intuitive behaviour is either the > sanitization of the AS_PATH, or more preferebly, a NOTIFY with malformed > as-path sent to the remote peer. > > If a vendors BGP implementation doesnt do this, and you don't run > confederations, you end up leaking confederation information into your AS > and destorying BGP with non-confederation speaking BGP peers. This is not > good. > > I bring this up because it's already happened. I'm tossing it out with > the suggestion that the RFC be clarified with regard to receiving CONFED > AS_PATHs from an EBGP peer. > > > > > ------- End of Forwarded Message -- Edward Crabbe ============= Sr. Network Architect Backbone Group Exodus Communications ------------- v0x: 408 346 1544 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA25942 for ; Tue, 26 Jun 2001 17:19:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42B7A9134C; Tue, 26 Jun 2001 17:15:21 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09BF091357; Tue, 26 Jun 2001 17:15:20 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42C549134C for ; Tue, 26 Jun 2001 17:15:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A87FD5DE55; Tue, 26 Jun 2001 17:16:19 -0400 (EDT) Delivered-To: idr@merit.edu Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 1CF795DE52 for ; Tue, 26 Jun 2001 17:16:19 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA10656 for ; Tue, 26 Jun 2001 14:15:34 -0700 (PDT) Message-Id: <200106262115.OAA10656@red.juniper.net> To: idr@merit.edu Subject: reposting e-mail MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77670.993590133.1@juniper.net> Date: Tue, 26 Jun 2001 14:15:33 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk fyi ------- Forwarded Message Date: Tue, 26 Jun 2001 13:03:54 -0700 From: John Engelhart To: , cc: , "Ed 'I turned out just television' Crabbe" Subject: RFC 3065, Confederation clarification (fwd) Hi guys, My email doesn't appear to be showing up on idr. I'm mailing you because I think it's important. Furthermore, we've since found one additional point of contention. RFC 3065, section 6.1.b.1 and 6.1.b.2 specifiy the position in which AS_CONFED path info must appear in an AS_PATH announcement. IMHO, position is irrelevent, as long as it's only one of each type (seq & set). Do you have to subscribe to another list in order to post to IDR? - ---------- Forwarded message ---------- Date: Mon, 25 Jun 2001 16:17:38 -0700 (PDT) From: John Engelhart To: idr@merit.edu Subject: RFC 3065, Confederation clarification Correct me if I'm wrong, but shouldn't the behaviour of confederation logic work something like this: a) Do not send AS_PATH AS_CONFED_* to EBGP peers b) Do not accept AS_PATH AS_CONFED_* from EBGP peers While the RFC is clear about item A, it is not clear about item B. If a vendors implementation doesn't support confederations, the result of sending CONFED info across EBGP links is clear- tear down the session with a NOTIFY of malformed as-path. However, if the vendors implementation DOES support confederations, the result is less clear. Expected, intuitive behaviour is either the sanitization of the AS_PATH, or more preferebly, a NOTIFY with malformed as-path sent to the remote peer. If a vendors BGP implementation doesnt do this, and you don't run confederations, you end up leaking confederation information into your AS and destorying BGP with non-confederation speaking BGP peers. This is not good. I bring this up because it's already happened. I'm tossing it out with the suggestion that the RFC be clarified with regard to receiving CONFED AS_PATHs from an EBGP peer. ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23870 for ; Tue, 26 Jun 2001 15:48:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F16C91333; Tue, 26 Jun 2001 15:46:45 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E59691334; Tue, 26 Jun 2001 15:46:45 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EE2C91333 for ; Tue, 26 Jun 2001 15:46:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B2A05DE5E; Tue, 26 Jun 2001 15:47:46 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id 04D845DE5C for ; Tue, 26 Jun 2001 15:47:46 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA13707; Tue, 26 Jun 2001 12:52:02 -0700 Date: Tue, 26 Jun 2001 12:52:02 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <313895461.20010626125202@nexsi.com> To: Alvaro Retana Cc: Ben Black , Enke Chen , Danny McPherson , Subject: Re: route reflection language change suggestion In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Alvaro, Something like the text below is what I meant. :) We definitely don't want to make the spec a deployment guidelines doc, but a small note is good. Thanks, -- Alex Zinin Tuesday, June 26, 2001, 11:37:42 AM, Alvaro Retana wrote: > On Tue, 26 Jun 2001, Alex Zinin wrote: > Alex: ->> Maybe we should also add some text about hierarchical ->> route reflection. > Like what? ;-) > IMHO, hierarchical RRs are "already covered" as the clusters are > independent from each other. In other words, a client that is also a RR > (for a different set of clients) is just a "special case " in which the > non-client(s) also happen to be RRs. ;-) > On the other hand, Section 9 reads: > 9. Configuration and Deployment Considerations > The BGP protocol provides no way for a Client to identify itself > dynamically as a Client of an RR. The simplest way to achieve this > is by manual configuration. > The only thing I can think about adding is something like: > A commonly deployed configuration is the use of hierarchical route > reflectors. Specifically, a hierarchical route reflector configuration is > one in which a client in a cluster is also configured as a route reflector > (for a different cluster). Care should be taken so that the CLUSTER_ID > assigned to the route reflector and the client (acting as a route > reflector for a different set of clients) is not the same. > My 2c. > Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22222 for ; Tue, 26 Jun 2001 14:49:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5506491337; Tue, 26 Jun 2001 14:41:25 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C37291332; Tue, 26 Jun 2001 14:41:24 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 80CC291335 for ; Tue, 26 Jun 2001 14:41:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3CE45DE4D; Tue, 26 Jun 2001 14:42:21 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 2ACF75DE0F for ; Tue, 26 Jun 2001 14:42:21 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.66.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5QIbeh09163; Tue, 26 Jun 2001 11:37:40 -0700 (PDT) Date: Tue, 26 Jun 2001 14:37:42 -0400 (EDT) From: Alvaro Retana To: Alex Zinin Cc: Ben Black , Enke Chen , Danny McPherson , Subject: Re: route reflection language change suggestion In-Reply-To: <1632072610.20010626105416@nexsi.com> Message-ID: X-Save: no MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Tue, 26 Jun 2001, Alex Zinin wrote: Alex: -> Maybe we should also add some text about hierarchical -> route reflection. Like what? ;-) IMHO, hierarchical RRs are "already covered" as the clusters are independent from each other. In other words, a client that is also a RR (for a different set of clients) is just a "special case " in which the non-client(s) also happen to be RRs. ;-) On the other hand, Section 9 reads: 9. Configuration and Deployment Considerations The BGP protocol provides no way for a Client to identify itself dynamically as a Client of an RR. The simplest way to achieve this is by manual configuration. The only thing I can think about adding is something like: A commonly deployed configuration is the use of hierarchical route reflectors. Specifically, a hierarchical route reflector configuration is one in which a client in a cluster is also configured as a route reflector (for a different cluster). Care should be taken so that the CLUSTER_ID assigned to the route reflector and the client (acting as a route reflector for a different set of clients) is not the same. My 2c. Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20680 for ; Tue, 26 Jun 2001 13:50:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 915E79131C; Tue, 26 Jun 2001 13:48:45 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71F9F9131E; Tue, 26 Jun 2001 13:48:43 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2961F9131C for ; Tue, 26 Jun 2001 13:48:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3755F5DDB2; Tue, 26 Jun 2001 13:49:44 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (sdsl-208-185-176-210.dsl.sjc.megapath.net [208.185.176.210]) by segue.merit.edu (Postfix) with ESMTP id 2FEAF5DD8E for ; Tue, 26 Jun 2001 13:49:43 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id KAA11916; Tue, 26 Jun 2001 10:54:17 -0700 Date: Tue, 26 Jun 2001 10:54:16 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1632072610.20010626105416@nexsi.com> To: Ben Black Cc: Alvaro Retana , Enke Chen , Danny McPherson , Subject: Re: route reflection language change suggestion In-Reply-To: <20010615204013.A45350@layer8.net> References: <20010615122202.D36809@layer8.net> <20010615204013.A45350@layer8.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Ben, Alvaro Maybe we should also add some text about hierarchical route reflection. -- Alex Zinin Friday, June 15, 2001, 8:40:14 PM, Ben Black wrote: > I like your wording solution. > Ben > On Fri, Jun 15, 2001 at 11:25:50PM -0400, Alvaro Retana wrote: >> On Fri, 15 Jun 2001, Ben Black wrote: >> >> Ben: >> >> -> If routes are reflected between clients (meaning they aren't meshed >> -> with each other), then the reflectors serving those clients should >> -> have unique cluster IDs. >> >> Recommending different cluster-ids in all cases where the clients are not >> meshed is not the solution. As Enke pointed out, it will result in >> additional routes. The problem you're pointing to is real, but in most >> topologies will only occur in a failure scenario. >> >> -> If routes are not reflected between clients (meaning they are meshed >> -> with each other), then the reflectors serving those clients may have >> -> the same cluster ID. >> >> On the same token, what happens if the connectivity between two clients is >> lost? We'll run into the same problem because the RRs have the same >> cluster-id... :-( >> >> -> Further comments? >> >> How about this? >> >> 6. Redundant RRs >> >> While a set of clients may be served by a single RR, this >> configuration represents a single point of failure. To mitigate the >> risk, the same set of clients may be served by one or more additional >> RRs. Configuration of all the RRs in the cluster with the same 4- >> byte CLUSTER_ID allows them to discard routes from other RRs in the >> same cluster. However, it can lead to reachability problems between >> clients if conectivity is lost between one of the RRs and at least >> one of the clients. >> >> The CLUSTER_ID assignment in multiple RR scenarios should be >> considered carefully in light of the deployment considerations >> mentioned in Section 9. >> >> >> I think it addresses your concern about clarifying the fact that using the >> same cluster-id may lead to blackholes...and it also points to Section 9 >> for more criteria about configuration (where it talks about the importance >> of the topology). It also doesn't set absolute constraints on any one >> configuration, but it leaves it up to the people configuring the network. >> :-) >> >> Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA10447 for ; Wed, 20 Jun 2001 19:07:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7711591255; Wed, 20 Jun 2001 19:06:25 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40BE691256; Wed, 20 Jun 2001 19:06:25 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3498291255 for ; Wed, 20 Jun 2001 19:06:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CB0B5DDA7; Wed, 20 Jun 2001 19:07:15 -0400 (EDT) Delivered-To: idr@merit.edu Received: from hotmail.com (f109.law14.hotmail.com [64.4.21.109]) by segue.merit.edu (Postfix) with ESMTP id DE88E5DD93 for ; Wed, 20 Jun 2001 19:07:14 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Jun 2001 16:06:37 -0700 Received: from 65.198.24.253 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 20 Jun 2001 23:06:37 GMT X-Originating-IP: [65.198.24.253] From: "proto man" To: idr@merit.edu Subject: invalid origin code Date: Wed, 20 Jun 2001 23:06:37 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Jun 2001 23:06:37.0734 (UTC) FILETIME=[A88DFC60:01C0F9DD] Sender: owner-idr@merit.edu Precedence: bulk Folks, I just noticed a behaviour in a major vendor box accepting and propagating an invalid origin value (4) From the latest draft, i understand an invalid origin value should be handled disruptively. "If the ORIGIN attribute has an undefined value, then the Error Subcode is set to Invalid Origin Attribute" Is this just a vendor's bug or is there work going on to make BGP sessions more stable. Thanks, Priya ( I had similar issue with confederation value (1966) but the RFC has been updated to reflect a vendo'rs behaviour ) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA01358 for ; Wed, 20 Jun 2001 11:36:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3FE0991240; Wed, 20 Jun 2001 11:35:00 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0996B91241; Wed, 20 Jun 2001 11:34:59 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15C4691240 for ; Wed, 20 Jun 2001 11:34:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86D1C5DDC8; Wed, 20 Jun 2001 11:35:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 435415DDAC for ; Wed, 20 Jun 2001 11:35:49 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f5KFZC764080 for ; Wed, 20 Jun 2001 11:35:12 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f5KFZCr02402 for idr@merit.edu; Wed, 20 Jun 2001 11:35:12 -0400 (EDT) Date: Wed, 20 Jun 2001 11:35:12 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Re: question on cluster-list Message-ID: <20010620113512.A2385@nexthop.com> References: <6B190B34070BD411ACA000B0D0214E56A936DE@newman.tenornet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6B190B34070BD411ACA000B0D0214E56A936DE@newman.tenornet.com>; from jtsillas@tenornetworks.com on Tue, Jun 19, 2001 at 04:06:36PM -0400 Sender: owner-idr@merit.edu Precedence: bulk >From Section 7 of said RFC: When a RR reflects a route, it must prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new one. On Tue, Jun 19, 2001 at 04:06:36PM -0400, Tsillas, Jim wrote: > RFC 2796 says that a route received from a client-peer > should be sent to all client and non-client peers. When > sending these routes to non-client peers, is it still > required that the RR prepend/add the cluster-id to the > cluster-list attribute? > > thanks, > -Jim. > -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08017 for ; Tue, 19 Jun 2001 16:14:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DF0E91213; Tue, 19 Jun 2001 16:13:12 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DD7691298; Tue, 19 Jun 2001 16:13:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 579F491213 for ; Tue, 19 Jun 2001 16:13:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 382325DD94; Tue, 19 Jun 2001 16:14:00 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id BC0605DD92 for ; Tue, 19 Jun 2001 16:13:59 -0400 (EDT) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JKDNK06248 for ; Tue, 19 Jun 2001 16:13:23 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; TUE, 19 Jun 2001 16:06:37 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 16:06:37 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56A936DE@newman.tenornet.com> From: "Tsillas, Jim" To: "'idr@merit.edu'" Subject: question on cluster-list Date: Tue, 19 Jun 2001 16:06:36 -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 RFC 2796 says that a route received from a client-peer should be sent to all client and non-client peers. When sending these routes to non-client peers, is it still required that the RR prepend/add the cluster-id to the cluster-list attribute? thanks, -Jim. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA04953 for ; Mon, 18 Jun 2001 12:32:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 264F69128A; Mon, 18 Jun 2001 12:30:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFA449128B; Mon, 18 Jun 2001 12:30:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0E339128A for ; Mon, 18 Jun 2001 12:30:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 795215DDA2; Mon, 18 Jun 2001 12:30:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 36DB15DD9E for ; Mon, 18 Jun 2001 12:30:57 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f5IGUJ769328 for ; Mon, 18 Jun 2001 12:30:19 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f5IGUJ417406 for idr@merit.edu; Mon, 18 Jun 2001 12:30:19 -0400 (EDT) Date: Mon, 18 Jun 2001 12:30:19 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? Message-ID: <20010618123019.L16885@nexthop.com> References: <94B9091E1149D411A45C00508BACEB359CDBE7@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDBE7@entmail.gnilink.com>; from cmartin@gnilink.net on Mon, Jun 18, 2001 at 12:02:22PM -0400 Sender: owner-idr@merit.edu Precedence: bulk On Mon, Jun 18, 2001 at 12:02:22PM -0400, Martin, Christian wrote: > How about an extension to > NO_EXPORT, perhaps using a new extended community that says "Announce this > NLRI only to this(these) ASNs - otherwise, NO_EXPORT? > > Apologies if this has been considered before... IDRP has the dist_list_incl and dist_list_excl. IDRP is ISO document 10747. We keep adding stuff from IDRP into BGP, probably to the amusement of several people who said we should have gone to IDRP in the first place. :-) > chris -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA02709 for ; Mon, 18 Jun 2001 10:39:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A819491286; Mon, 18 Jun 2001 10:37:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73A8491287; Mon, 18 Jun 2001 10:37:28 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 800A991286 for ; Mon, 18 Jun 2001 10:37:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 197845DDEC; Mon, 18 Jun 2001 10:38:14 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id EBCA15DDE9 for ; Mon, 18 Jun 2001 10:38:13 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f5IEbe764485 for ; Mon, 18 Jun 2001 10:37:40 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f5IEbeG17071 for idr@merit.edu; Mon, 18 Jun 2001 10:37:40 -0400 (EDT) Date: Mon, 18 Jun 2001 10:37:40 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? Message-ID: <20010618103740.D16885@nexthop.com> References: <200106132000.NAA09209@red.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106132000.NAA09209@red.juniper.net>; from yakov@juniper.net on Wed, Jun 13, 2001 at 01:00:00PM -0700 Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jun 13, 2001 at 01:00:00PM -0700, Yakov Rekhter wrote: > For previous work on TTL on BGP routes see IDRP, and specifically > text on RD_HOP_COUNT attribute. After taking a look at the relevant section of IDRP, this isn't quite what I had intended. The version in IDRP essentially gives you the diameter of RD's that routes have passed through. What I had envisioned was having the route originator set a TTL value which is decremented as it passes through an RD (AS) and is not propagated when the value is zero. I have received some comments offline asking if an ID is in the works for something like this. Honestly, I was casually asking to see if anyone else had thoughts on this. Please consider: o This is a hammer. It is a very clumsy one. o Depending on the "topology of the Internet", it may be an ineffective hammer and wont actually solve any problems. It may create more problems than we want. o This hammer would work best when some amount of "hierarchy" in the Internet is present. With the "topology of the Internet" that I think we're seeing, this may be the wrong hammer. o This hammer really wants the IDRP DIST_LIST_INCL as an override to the proposed TTL to allow selective bleedover. This is yet more complexity. Several parties have observed that the "topology of the Internet" is flattening out. A more effective hammer may involve classifying the AS's that constitute the "core" and using a global community that says "these more specifics need not cross the core". Given the wrangling over who is a tier-1 ISP on other mailing lists, I find it unlikely that we can get this classification to happen easily without some impartial third-party. > Yakov. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA04769 for ; Fri, 15 Jun 2001 23:40:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 173B491265; Fri, 15 Jun 2001 23:39:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD33891266; Fri, 15 Jun 2001 23:39:04 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED72991265 for ; Fri, 15 Jun 2001 23:39:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D60DC5DDA6; Fri, 15 Jun 2001 23:39:45 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 7F3725DDA5 for ; Fri, 15 Jun 2001 23:39:45 -0400 (EDT) Received: (qmail 45392 invoked by uid 1000); 16 Jun 2001 03:40:14 -0000 Date: Fri, 15 Jun 2001 20:40:14 -0700 From: Ben Black To: Alvaro Retana Cc: Enke Chen , Danny McPherson , idr@merit.edu Subject: Re: route reflection language change suggestion Message-ID: <20010615204013.A45350@layer8.net> References: <20010615122202.D36809@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aretana@cisco.com on Fri, Jun 15, 2001 at 11:25:50PM -0400 Sender: owner-idr@merit.edu Precedence: bulk I like your wording solution. Ben On Fri, Jun 15, 2001 at 11:25:50PM -0400, Alvaro Retana wrote: > On Fri, 15 Jun 2001, Ben Black wrote: > > Ben: > > -> If routes are reflected between clients (meaning they aren't meshed > -> with each other), then the reflectors serving those clients should > -> have unique cluster IDs. > > Recommending different cluster-ids in all cases where the clients are not > meshed is not the solution. As Enke pointed out, it will result in > additional routes. The problem you're pointing to is real, but in most > topologies will only occur in a failure scenario. > > -> If routes are not reflected between clients (meaning they are meshed > -> with each other), then the reflectors serving those clients may have > -> the same cluster ID. > > On the same token, what happens if the connectivity between two clients is > lost? We'll run into the same problem because the RRs have the same > cluster-id... :-( > > -> Further comments? > > How about this? > > 6. Redundant RRs > > While a set of clients may be served by a single RR, this > configuration represents a single point of failure. To mitigate the > risk, the same set of clients may be served by one or more additional > RRs. Configuration of all the RRs in the cluster with the same 4- > byte CLUSTER_ID allows them to discard routes from other RRs in the > same cluster. However, it can lead to reachability problems between > clients if conectivity is lost between one of the RRs and at least > one of the clients. > > The CLUSTER_ID assignment in multiple RR scenarios should be > considered carefully in light of the deployment considerations > mentioned in Section 9. > > > I think it addresses your concern about clarifying the fact that using the > same cluster-id may lead to blackholes...and it also points to Section 9 > for more criteria about configuration (where it talks about the importance > of the topology). It also doesn't set absolute constraints on any one > configuration, but it leaves it up to the people configuring the network. > :-) > > Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA04669 for ; Fri, 15 Jun 2001 23:31:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F27B191263; Fri, 15 Jun 2001 23:29:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA28991264; Fri, 15 Jun 2001 23:29:58 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C453191263 for ; Fri, 15 Jun 2001 23:29:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BFC55DDA5; Fri, 15 Jun 2001 23:30:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id F36865DD8D for ; Fri, 15 Jun 2001 23:30:38 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.66.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5G3Pr908778; Fri, 15 Jun 2001 20:25:53 -0700 (PDT) Date: Fri, 15 Jun 2001 23:25:50 -0400 (EDT) From: Alvaro Retana To: Ben Black Cc: Enke Chen , Danny McPherson , Subject: Re: route reflection language change suggestion In-Reply-To: <20010615122202.D36809@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Fri, 15 Jun 2001, Ben Black wrote: Ben: -> If routes are reflected between clients (meaning they aren't meshed -> with each other), then the reflectors serving those clients should -> have unique cluster IDs. Recommending different cluster-ids in all cases where the clients are not meshed is not the solution. As Enke pointed out, it will result in additional routes. The problem you're pointing to is real, but in most topologies will only occur in a failure scenario. -> If routes are not reflected between clients (meaning they are meshed -> with each other), then the reflectors serving those clients may have -> the same cluster ID. On the same token, what happens if the connectivity between two clients is lost? We'll run into the same problem because the RRs have the same cluster-id... :-( -> Further comments? How about this? 6. Redundant RRs While a set of clients may be served by a single RR, this configuration represents a single point of failure. To mitigate the risk, the same set of clients may be served by one or more additional RRs. Configuration of all the RRs in the cluster with the same 4- byte CLUSTER_ID allows them to discard routes from other RRs in the same cluster. However, it can lead to reachability problems between clients if conectivity is lost between one of the RRs and at least one of the clients. The CLUSTER_ID assignment in multiple RR scenarios should be considered carefully in light of the deployment considerations mentioned in Section 9. I think it addresses your concern about clarifying the fact that using the same cluster-id may lead to blackholes...and it also points to Section 9 for more criteria about configuration (where it talks about the importance of the topology). It also doesn't set absolute constraints on any one configuration, but it leaves it up to the people configuring the network. :-) Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA27083 for ; Fri, 15 Jun 2001 15:22:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB3B391259; Fri, 15 Jun 2001 15:20:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F0E79125B; Fri, 15 Jun 2001 15:20:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9775491259 for ; Fri, 15 Jun 2001 15:20:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D52185DDE4; Fri, 15 Jun 2001 15:21:36 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 553CB5DDDE for ; Fri, 15 Jun 2001 15:21:36 -0400 (EDT) Received: (qmail 37654 invoked by uid 1000); 15 Jun 2001 19:22:03 -0000 Date: Fri, 15 Jun 2001 12:22:03 -0700 From: Ben Black To: Alvaro Retana Cc: Enke Chen , Danny McPherson , idr@merit.edu Subject: Re: route reflection language change suggestion Message-ID: <20010615122202.D36809@layer8.net> References: <20010615165800.7B57515D3C1@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aretana@cisco.com on Fri, Jun 15, 2001 at 03:09:12PM -0400 Sender: owner-idr@merit.edu Precedence: bulk How about the following guidelines: If routes are reflected between clients (meaning they aren't meshed with each other), then the reflectors serving those clients should have unique cluster IDs. If routes are not reflected between clients (meaning they are meshed with each other), then the reflectors serving those clients may have the same cluster ID. Further comments? Ben Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA26995 for ; Fri, 15 Jun 2001 15:14:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F59591261; Fri, 15 Jun 2001 15:12:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EA4A91259; Fri, 15 Jun 2001 15:12:58 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 181C09125A for ; Fri, 15 Jun 2001 15:12:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5369B5DDB8; Fri, 15 Jun 2001 15:13:38 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id B69605DDDE for ; Fri, 15 Jun 2001 15:13:37 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.66.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5FJ9B904523; Fri, 15 Jun 2001 12:09:11 -0700 (PDT) Date: Fri, 15 Jun 2001 15:09:12 -0400 (EDT) From: Alvaro Retana To: Enke Chen Cc: Ben Black , Danny McPherson , Subject: Re: route reflection language change suggestion In-Reply-To: <20010615165800.7B57515D3C1@popserv1.redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Fri, 15 Jun 2001, Enke Chen wrote: -> Here we are talking about ibgp peers which should be using the -> loopbacks for peering. So the peering can not be lost unless there -> is no longer any connectivity between the peering routers, in which -> case configuring different cluser-id would not have helped. In fact, it **would** help. :-) Going back to Ben's diagram...assume different cluster-ids... [A]----[B] | \ / | | \/ | | /\ | | / \ | [1] [2] If we assume that the loss in connectivity *only* happens between [1] and [B] *and* between [2] and [A], then the routes from [2] will in fact reach all the other routers in the picture. :-) Of course we can both come up with multiple topologies in which problems may or may not happen, depending on the failure mode. ;-) -> It is certainly the case that the RRs in a cluster do not need to be -> configured with the same cluser-id. Storing the extra paths would -> lead to higher memory consumption, though. Completely agreed. :-) I also agree that in most cases iBGP peers should peer using the loopback interface. The rfc reads: 9. Configuration and Deployment Considerations ... To prevent routing loops and maintain consistent routing view, it is essential that the network topology be carefully considered in designing a route reflection topology. In general, the route reflection topology should congruent with the network topology when there exist multiple paths for a prefix. If I remember correctly, there are "harmful" topologies (IMHO, mostly resulting from misconfigurations) that can be achieved if the physical topology is not congruent when assigning RRs. IMHO, Ben's point is valid as to potential problems. But the RFC is *clear* in spelling out the possible pitfalls one may run into when not following the physical topology. In most networks (specially ones built w/the physical topology in mind and using loopback peering), the failure scenarios must be pretty radical (as Danny pointed out) for a blackhole or a loop to occur...it all depends on the failure mode *and* the steady state configuration. =:-) For whatever's worth, I think that the rfc already points out possible problems, so no extra text in needed. Taking the above paragraph into account, the correct decision should be made by the network implementors. My 2c. Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA26985 for ; Fri, 15 Jun 2001 15:14:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5EA7F9125A; Fri, 15 Jun 2001 15:12:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DFE79125B; Fri, 15 Jun 2001 15:12:57 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E5F691259 for ; Fri, 15 Jun 2001 15:12:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9A175DDE4; Fri, 15 Jun 2001 15:13:37 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 43F3E5DDB8 for ; Fri, 15 Jun 2001 15:13:37 -0400 (EDT) Received: (qmail 37479 invoked by uid 1000); 15 Jun 2001 19:14:03 -0000 Date: Fri, 15 Jun 2001 12:14:03 -0700 From: Ben Black To: Alvaro Retana Cc: Enke Chen , Danny McPherson , idr@merit.edu Subject: Re: route reflection language change suggestion Message-ID: <20010615121403.C36809@layer8.net> References: <20010615165800.7B57515D3C1@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aretana@cisco.com on Fri, Jun 15, 2001 at 03:09:12PM -0400 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jun 15, 2001 at 03:09:12PM -0400, Alvaro Retana wrote: > > For whatever's worth, I think that the rfc already points out possible > problems, so no extra text in needed. Taking the above paragraph into > account, the correct decision should be made by the network implementors. > The RFC also reads: 6. Redundant RRs Usually a cluster of clients will have a single RR. In that case, the cluster will be identified by the ROUTER_ID of the RR. However, this represents a single point of failure so to make it possible to have multiple RRs in the same cluster, all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster. This is the source of my concern, not a vague reference to the possibility of bad things happening with the "wrong" topology (of which there are no examples in the RFC). Ben Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA26621 for ; Fri, 15 Jun 2001 14:55:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5E8F91257; Fri, 15 Jun 2001 14:54:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71AE291258; Fri, 15 Jun 2001 14:54:18 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71B1691257 for ; Fri, 15 Jun 2001 14:54:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A17995DDDE; Fri, 15 Jun 2001 14:54:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 058785DDE5 for ; Fri, 15 Jun 2001 14:54:58 -0400 (EDT) Received: (qmail 37116 invoked by uid 1000); 15 Jun 2001 18:55:24 -0000 Date: Fri, 15 Jun 2001 11:55:24 -0700 From: Ben Black To: "Martin, Christian" Cc: Danny McPherson , idr@merit.edu Subject: Re: route reflection language change suggestion Message-ID: <20010615115524.A36809@layer8.net> References: <94B9091E1149D411A45C00508BACEB359CDBDF@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDBDF@entmail.gnilink.com>; from cmartin@gnilink.net on Fri, Jun 15, 2001 at 06:32:21AM -0400 Sender: owner-idr@merit.edu Precedence: bulk Christian, As Rex has kindly reminded me, you need not lose 2 peering sessions, as in my extreme example, you need only lose 1, at which point one of the reflectors will start rejecting routes (for example, B would start rejecting routes from 2 reflected by A, which is fine until the peering from 2 to B fails). I do not find the insistence on the use of a loopback address for peering compelling as the specification does not require it. Router B need not be in the forwarding path (nor was I saying that in my example) for this to be a problem. To directly address your assertion of a routing loop, I think you have forgotten the behavior of the ORIGINATOR_ID. A route which came back through to router [1] would be rejected since the ORIGINATOR_ID and the ROUTER_ID would be the same. There is no loop here. Also note that your example is not a routing loop, but an oscillation, as it fails to actually converge. Ben On Fri, Jun 15, 2001 at 06:32:21AM -0400, Martin, Christian wrote: > > > If the problem exists in the configuration the RFC suggests, but not > > in the configuration I am suggesting, why not make the change? Is > > there a drawback I do not see for unique CLUSTER_IDs? > > Ben, > > The reason I have been able to come up with in this regard is that this > would allow the reflected route that originated from [1] to come back to > [1], which violates split horizon - thus creating a _routing_ loop. Given > the following example, and using your diagram for reference: > > An external route R is announced to [1]. [1] announces it to [A}. [A], by > rule reflects it to [B] after adding the originator id of [1] and [A]'s > cluster id. [B] receives the route and prepends its cluster id to R, then > reflectes it back to [1]. Now, if [1] has a policy to set a local > preference of 100 to routes from [B], and 90 for external routes, [1] shall > install a route to R via [B]. At this point, the next-hop changes for R via > [B], and since the best path is now internal, [1] wthdraws the anouncement > from [A], which withdraws from [B], which withdraws from [1], which > reannounces to [A] with external nh, and on and on around we go! > > > > > > > > [A]----[B] > > > > | \ / | > > > > | \/ | > > > > | /\ | > > > > | / \ | > > > > [1] [2] > > > > > > > > Routers A and B are both reflectors with cluster ID 100. > > Routers 1 and > > > > 2 are reflector clients of both A and B. If router 1 > > loses its peering > > > > session with router B and router 2 loses its peering > > session with router > > > > A, then router A will reject the routes to router 2 via > > router B, and > > > > likewise for B and routes via A to 1. > > This is really no different in a full mesh topology. If any two iBGP > speakers lose connectivity to each other, they no longer can see routes from > each other. > > I should point out that what you propose works to provide redundancy, so > long as reflected routes are never prefered over external or local > originated routes on a client. I believe some NSPs are doing this now for > redundancy purposes, but it can break things. Perhaps it can be reworded to > state this a a caveat to your proposal. > > regards, > chris > > > > > > > > So realistically, what's the probability of: > > > > > > o router 1 losing it's peering session to router B > > > o AND router 2 losing it's peering session to router A > > > o AND routers A & B STILL having connectivity > > > o AND routers 1 & 2 still having connectivity > > > o AND the BGP NEXT_HOP via router 2 being accessible from > > > router 1 (and/or the BGP NEXT_HOP via router 1 being accessible > > > from router 2)? > > > > > > > I don't feel this is a desirable trait. > > > > > > Then perhaps not employing client-to-client reflection would > > > alleviate your concern? > > > > > > -danny > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24163 for ; Fri, 15 Jun 2001 12:59:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F400291251; Fri, 15 Jun 2001 12:57:52 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDAD09134E; Fri, 15 Jun 2001 12:57:51 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B9A5B91251 for ; Fri, 15 Jun 2001 12:57:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B66135DDDE; Fri, 15 Jun 2001 12:58:31 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 4AB045DDDD for ; Fri, 15 Jun 2001 12:58:31 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 2CA6F1191678; Fri, 15 Jun 2001 09:58:01 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 7B57515D3C1; Fri, 15 Jun 2001 09:58:00 -0700 (PDT) To: Ben Black Cc: Danny McPherson , idr@merit.edu Subject: Re: route reflection language change suggestion In-Reply-To: Message from Ben Black of "Fri, 15 Jun 2001 01:55:19 PDT." <20010615015519.F24003@layer8.net> Date: Fri, 15 Jun 2001 09:58:00 -0700 From: Enke Chen Message-Id: <20010615165800.7B57515D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Ben, Here we are talking about ibgp peers which should be using the loopbacks for peering. So the peering can not be lost unless there is no longer any connectivity between the peering routers, in which case configuring different cluser-id would not have helped. It is certainly the case that the RRs in a cluster do not need to be configured with the same cluser-id. Storing the extra paths would lead to higher memory consumption, though. -- Enke > Received: (qmail 28217 invoked by uid 1000); 15 Jun 2001 08:55:19 -0000 > Date: Fri, 15 Jun 2001 01:55:19 -0700 > From: Ben Black > To: Danny McPherson > Cc: idr@merit.edu > Subject: Re: route reflection language change suggestion > Message-ID: <20010615015519.F24003@layer8.net> > References: <200106150748.BAA14142@tcb.net> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > In-Reply-To: <200106150748.BAA14142@tcb.net>; from danny@ambernetworks.com on Fri, Jun 15, 2001 at 01:48:42AM -0600 > Sender: owner-idr@merit.edu > Precedence: bulk > > Danny, > > Consider the following: > > [A]----[B] > | \ / | > | \/ | > | /\ | > | / \ | > [1] [2] > > Routers A and B are both reflectors with cluster ID 100. Routers 1 and > 2 are reflector clients of both A and B. If router 1 loses its peering > session with router B and router 2 loses its peering session with router > A, then router A will reject the routes to router 2 via router B, and > likewise for B and routes via A to 1. > > I don't feel this is a desirable trait. > > > Ben > > On Fri, Jun 15, 2001 at 01:48:42AM -0600, Danny McPherson wrote: > > > > Ben, > > Can you describe an example of when this occurs? > > > > Thanks! > > > > -danny > > > > > RFC2796 makes several references to configuring multiple reflectors > > > with the same cluster ID. After discussing the issue with several > > > people, I believe this to be incorrect. Placing multiple reflectors > > > in the same cluster can render sets of clients mutually unreachable. > > > > > > I would suggest that section 6 be reworded along the following lines: > > > > > > While a set of clients may be served by a single RR, this represents > > > a single point of failure. To mitigate this risk, the same set of > > > clients may be served by one or more additional RRs, each configured > > > with its own, unique, 4-byte CLUSTER_ID, generally the ROUTER_ID of > > > each RR. Configuration of multiple RRs with the same CLUSTER_ID > > > is discouraged as it can lead to reachability problems between > > > clients of those RRs. > > > > > > > > > > > > Ben > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA16062 for ; Fri, 15 Jun 2001 05:35:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6546391244; Fri, 15 Jun 2001 05:34:50 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3102391344; Fri, 15 Jun 2001 05:34:50 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B67291244 for ; Fri, 15 Jun 2001 05:34:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3FFC5DDA5; Fri, 15 Jun 2001 05:35:29 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 3B75E5DD96 for ; Fri, 15 Jun 2001 05:35:29 -0400 (EDT) Received: (qmail 29115 invoked by uid 1000); 15 Jun 2001 09:35:53 -0000 Date: Fri, 15 Jun 2001 02:35:53 -0700 From: Ben Black To: Danny McPherson Cc: idr@merit.edu Subject: Re: route reflection language change suggestion Message-ID: <20010615023553.I24003@layer8.net> References: <200106150827.CAA14286@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106150827.CAA14286@tcb.net>; from danny@ambernetworks.com on Fri, Jun 15, 2001 at 02:27:20AM -0600 Sender: owner-idr@merit.edu Precedence: bulk If the problem exists in the configuration the RFC suggests, but not in the configuration I am suggesting, why not make the change? Is there a drawback I do not see for unique CLUSTER_IDs? Ben On Fri, Jun 15, 2001 at 02:27:20AM -0600, Danny McPherson wrote: > > > Consider the following: > > > > [A]----[B] > > | \ / | > > | \/ | > > | /\ | > > | / \ | > > [1] [2] > > > > Routers A and B are both reflectors with cluster ID 100. Routers 1 and > > 2 are reflector clients of both A and B. If router 1 loses its peering > > session with router B and router 2 loses its peering session with router > > A, then router A will reject the routes to router 2 via router B, and > > likewise for B and routes via A to 1. > > So realistically, what's the probability of: > > o router 1 losing it's peering session to router B > o AND router 2 losing it's peering session to router A > o AND routers A & B STILL having connectivity > o AND routers 1 & 2 still having connectivity > o AND the BGP NEXT_HOP via router 2 being accessible from > router 1 (and/or the BGP NEXT_HOP via router 1 being accessible > from router 2)? > > > I don't feel this is a desirable trait. > > Then perhaps not employing client-to-client reflection would > alleviate your concern? > > -danny Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA16021 for ; Fri, 15 Jun 2001 05:32:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83FCA91243; Fri, 15 Jun 2001 05:27:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53C8891344; Fri, 15 Jun 2001 05:27:54 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7003091243 for ; Fri, 15 Jun 2001 05:27:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3CF65DDA5; Fri, 15 Jun 2001 05:28:32 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 6A2765DD96 for ; Fri, 15 Jun 2001 05:28:32 -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 CAA14286 for ; Fri, 15 Jun 2001 02:27:20 -0600 Message-Id: <200106150827.CAA14286@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: route reflection language change suggestion Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 02:27:20 -0600 Sender: owner-idr@merit.edu Precedence: bulk > Consider the following: > > [A]----[B] > | \ / | > | \/ | > | /\ | > | / \ | > [1] [2] > > Routers A and B are both reflectors with cluster ID 100. Routers 1 and > 2 are reflector clients of both A and B. If router 1 loses its peering > session with router B and router 2 loses its peering session with router > A, then router A will reject the routes to router 2 via router B, and > likewise for B and routes via A to 1. So realistically, what's the probability of: o router 1 losing it's peering session to router B o AND router 2 losing it's peering session to router A o AND routers A & B STILL having connectivity o AND routers 1 & 2 still having connectivity o AND the BGP NEXT_HOP via router 2 being accessible from router 1 (and/or the BGP NEXT_HOP via router 1 being accessible from router 2)? > I don't feel this is a desirable trait. Then perhaps not employing client-to-client reflection would alleviate your concern? -danny Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA15174 for ; Fri, 15 Jun 2001 04:55:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7467191241; Fri, 15 Jun 2001 04:54:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DD7691242; Fri, 15 Jun 2001 04:54:16 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4844691241 for ; Fri, 15 Jun 2001 04:54:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B0B7C5DDC8; Fri, 15 Jun 2001 04:54:55 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 2F6AD5DDA5 for ; Fri, 15 Jun 2001 04:54:55 -0400 (EDT) Received: (qmail 28217 invoked by uid 1000); 15 Jun 2001 08:55:19 -0000 Date: Fri, 15 Jun 2001 01:55:19 -0700 From: Ben Black To: Danny McPherson Cc: idr@merit.edu Subject: Re: route reflection language change suggestion Message-ID: <20010615015519.F24003@layer8.net> References: <200106150748.BAA14142@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106150748.BAA14142@tcb.net>; from danny@ambernetworks.com on Fri, Jun 15, 2001 at 01:48:42AM -0600 Sender: owner-idr@merit.edu Precedence: bulk Danny, Consider the following: [A]----[B] | \ / | | \/ | | /\ | | / \ | [1] [2] Routers A and B are both reflectors with cluster ID 100. Routers 1 and 2 are reflector clients of both A and B. If router 1 loses its peering session with router B and router 2 loses its peering session with router A, then router A will reject the routes to router 2 via router B, and likewise for B and routes via A to 1. I don't feel this is a desirable trait. Ben On Fri, Jun 15, 2001 at 01:48:42AM -0600, Danny McPherson wrote: > > Ben, > Can you describe an example of when this occurs? > > Thanks! > > -danny > > > RFC2796 makes several references to configuring multiple reflectors > > with the same cluster ID. After discussing the issue with several > > people, I believe this to be incorrect. Placing multiple reflectors > > in the same cluster can render sets of clients mutually unreachable. > > > > I would suggest that section 6 be reworded along the following lines: > > > > While a set of clients may be served by a single RR, this represents > > a single point of failure. To mitigate this risk, the same set of > > clients may be served by one or more additional RRs, each configured > > with its own, unique, 4-byte CLUSTER_ID, generally the ROUTER_ID of > > each RR. Configuration of multiple RRs with the same CLUSTER_ID > > is discouraged as it can lead to reachability problems between > > clients of those RRs. > > > > > > > > Ben > Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA15110 for ; Fri, 15 Jun 2001 04:50:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76BE691240; Fri, 15 Jun 2001 04:49:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AA9291241; Fri, 15 Jun 2001 04:49:15 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 54C2591240 for ; Fri, 15 Jun 2001 04:49:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCAE95DDC8; Fri, 15 Jun 2001 04:49:54 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 347E25DDA5 for ; Fri, 15 Jun 2001 04:49: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 BAA14142 for ; Fri, 15 Jun 2001 01:48:42 -0600 Message-Id: <200106150748.BAA14142@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: route reflection language change suggestion Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 01:48:42 -0600 Sender: owner-idr@merit.edu Precedence: bulk Ben, Can you describe an example of when this occurs? Thanks! -danny > RFC2796 makes several references to configuring multiple reflectors > with the same cluster ID. After discussing the issue with several > people, I believe this to be incorrect. Placing multiple reflectors > in the same cluster can render sets of clients mutually unreachable. > > I would suggest that section 6 be reworded along the following lines: > > While a set of clients may be served by a single RR, this represents > a single point of failure. To mitigate this risk, the same set of > clients may be served by one or more additional RRs, each configured > with its own, unique, 4-byte CLUSTER_ID, generally the ROUTER_ID of > each RR. Configuration of multiple RRs with the same CLUSTER_ID > is discouraged as it can lead to reachability problems between > clients of those RRs. > > > > Ben Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA14488 for ; Fri, 15 Jun 2001 04:05:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 977099123F; Fri, 15 Jun 2001 04:04:38 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6147E91344; Fri, 15 Jun 2001 04:04:38 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56A419123F for ; Fri, 15 Jun 2001 04:04:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DE095DDB8; Fri, 15 Jun 2001 04:05:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 8B4E15DDB3 for ; Fri, 15 Jun 2001 04:05:16 -0400 (EDT) Received: (qmail 27430 invoked by uid 1000); 15 Jun 2001 08:05:40 -0000 Date: Fri, 15 Jun 2001 01:05:40 -0700 From: Ben Black To: idr@merit.edu Subject: route reflection language change suggestion Message-ID: <20010615010540.D24003@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idr@merit.edu Precedence: bulk RFC2796 makes several references to configuring multiple reflectors with the same cluster ID. After discussing the issue with several people, I believe this to be incorrect. Placing multiple reflectors in the same cluster can render sets of clients mutually unreachable. I would suggest that section 6 be reworded along the following lines: While a set of clients may be served by a single RR, this represents a single point of failure. To mitigate this risk, the same set of clients may be served by one or more additional RRs, each configured with its own, unique, 4-byte CLUSTER_ID, generally the ROUTER_ID of each RR. Configuration of multiple RRs with the same CLUSTER_ID is discouraged as it can lead to reachability problems between clients of those RRs. Ben Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA07705 for ; Thu, 14 Jun 2001 22:04:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3CE8191342; Thu, 14 Jun 2001 22:03:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0821C91343; Thu, 14 Jun 2001 22:03:32 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE59E91342 for ; Thu, 14 Jun 2001 22:03:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A52E75DDAA; Thu, 14 Jun 2001 22:04:11 -0400 (EDT) Delivered-To: idr@merit.edu Received: from hotmail.com (f63.law14.hotmail.com [64.4.21.63]) by segue.merit.edu (Postfix) with ESMTP id 6236B5DDA4 for ; Thu, 14 Jun 2001 22:04:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Jun 2001 19:03:41 -0700 Received: from 65.198.24.253 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 15 Jun 2001 02:03:41 GMT X-Originating-IP: [65.198.24.253] From: "proto man" To: tli@Procket.com Cc: idr@merit.edu Subject: Re: Update Message Notification error subcodes Date: Fri, 15 Jun 2001 02:03:41 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jun 2001 02:03:41.0996 (UTC) FILETIME=[66A136C0:01C0F53F] Sender: owner-idr@merit.edu Precedence: bulk Hi, Thanks, I am guessing the hole is not filled up for backwards compatibility of error subcodes... Can we change the listing to include 7 - unused value -Priya >From: Tony Li >To: "proto man" >CC: idr@merit.edu >Subject: Update Message Notification error subcodes >Date: Thu, 14 Jun 2001 18:41:52 -0700 (PDT) > > > | I meant to add, is it because sending notification when receiving >looped > | paths is disruptive..? > > >Exactly. One thing that we discovered was that it was far less disruptive >to simply log things or to ignore and count them than to generate a >NOTIFICATION. > >Breaking BGP connections when you don't have to is Harmful to The Internet. > >Tony _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA07276 for ; Thu, 14 Jun 2001 21:42:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75C569133F; Thu, 14 Jun 2001 21:41:44 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B20F91340; Thu, 14 Jun 2001 21:41:44 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3345D9133F for ; Thu, 14 Jun 2001 21:41:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 127475DD93; Thu, 14 Jun 2001 21:42:23 -0400 (EDT) Delivered-To: idr@merit.edu Received: from alpha-tli.procket.com (flowpoint.procket.com [209.140.237.1]) by segue.merit.edu (Postfix) with ESMTP id 5D3B25DD8C for ; Thu, 14 Jun 2001 21:42:22 -0400 (EDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id SAA29683; Thu, 14 Jun 2001 18:41:52 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15145.26592.438262.416337@alpha-tli.procket.com> Date: Thu, 14 Jun 2001 18:41:52 -0700 (PDT) To: "proto man" Cc: idr@merit.edu Subject: Update Message Notification error subcodes In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-idr@merit.edu Precedence: bulk | I meant to add, is it because sending notification when receiving looped | paths is disruptive..? Exactly. One thing that we discovered was that it was far less disruptive to simply log things or to ignore and count them than to generate a NOTIFICATION. Breaking BGP connections when you don't have to is Harmful to The Internet. Tony Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA07220 for ; Thu, 14 Jun 2001 21:39:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97BFD9133E; Thu, 14 Jun 2001 21:38:12 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6501F9133F; Thu, 14 Jun 2001 21:38:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5542F9133E for ; Thu, 14 Jun 2001 21:38:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D06D5DD93; Thu, 14 Jun 2001 21:38:51 -0400 (EDT) Delivered-To: idr@merit.edu Received: from hotmail.com (f50.law14.hotmail.com [64.4.21.50]) by segue.merit.edu (Postfix) with ESMTP id DFF115DD8C for ; Thu, 14 Jun 2001 21:38:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Jun 2001 18:38:21 -0700 Received: from 65.198.24.253 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 15 Jun 2001 01:38:21 GMT X-Originating-IP: [65.198.24.253] From: "proto man" To: idr@merit.edu Subject: Update Message Notification error subcodes Date: Fri, 15 Jun 2001 01:38:21 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jun 2001 01:38:21.0580 (UTC) FILETIME=[DC6424C0:01C0F53B] Sender: owner-idr@merit.edu Precedence: bulk oops. I meant to add, is it because sending notification when receiving looped paths is disruptive..? Thanks, -Priya Moniker _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA07137 for ; Thu, 14 Jun 2001 21:36:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B00CF9133D; Thu, 14 Jun 2001 21:34:39 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 878659133E; Thu, 14 Jun 2001 21:34:39 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 698679133D for ; Thu, 14 Jun 2001 21:34:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1ED205DD93; Thu, 14 Jun 2001 21:35:18 -0400 (EDT) Delivered-To: idr@merit.edu Received: from hotmail.com (f25.law14.hotmail.com [64.4.21.25]) by segue.merit.edu (Postfix) with ESMTP id D1B5B5DD8C for ; Thu, 14 Jun 2001 21:35:17 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Jun 2001 18:34:48 -0700 Received: from 65.198.24.253 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 15 Jun 2001 01:34:48 GMT X-Originating-IP: [65.198.24.253] From: "proto man" To: idr@merit.edu Subject: Update Message Notification error subcodes Date: Fri, 15 Jun 2001 01:34:48 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jun 2001 01:34:48.0388 (UTC) FILETIME=[5D51A040:01C0F53B] Sender: owner-idr@merit.edu Precedence: bulk Hi, The Update Message error sub codes as per draft-ietf-idr-bgp4-12.txt are listed as : UPDATE Message Error subcodes: 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid ORIGIN Attribute 8 - Invalid NEXT_HOP Attribute. 9 - Optional Attribute Error. 10 - Invalid Network Field. 11 - Malformed AS_PATH. Value 7 was used in RFC 1771 for routing-loop. Why is it no longer listed... Thanks, -Priya Moniker _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA22243 for ; Thu, 14 Jun 2001 08:41:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D52B991228; Thu, 14 Jun 2001 08:40:31 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D09D91324; Thu, 14 Jun 2001 08:40:31 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B330391228 for ; Thu, 14 Jun 2001 08:40:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6965A5DDB0; Thu, 14 Jun 2001 08:41:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from email1.broadslate.net (unknown [216.142.210.128]) by segue.merit.edu (Postfix) with ESMTP id 040955DDA7 for ; Thu, 14 Jun 2001 08:41:09 -0400 (EDT) Received: by EMAIL1 with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 08:42:59 -0400 Message-ID: From: "Hire, Ejay" To: "'idr@merit.edu'" Subject: RE: Previous work on TTL on BGP routes? Date: Thu, 14 Jun 2001 08:38:21 -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 I was thinking about it this morning, and their is a problem with this. In the scenario with an as path of 1-2-3, Where 2 advertises the route and a aggregate sufficient enough to trigger the route drop but ignores the MPAAL (as in the case of a router without this feature enabled). 3 will receive both routes but discard the more specific route. In the event that 2 withdraws the summary route, 2 will not re-advertise the more specific route causing 3 to lose reachability information to the more specific subnet. Rewording it to prevent this becomes: The "Maximum-Parallel-Advertised-Aggregate-Length" (MPAAL) is a optional transitive path attribute that says "If this route is being advertised to a peer in addition to an aggregate route encompassing it with a prefix of less than the MPAAL, Remove the more specific route from the Adj-RIB-Out. If the aggregate route is withdrawn from the Adj-RIB-Out, the more specific route should be reinserted into the Adj-RIB-Out. In this Context, Prefix is referring to the subnet mask length expressed in bits. -----Original Message----- From: Ben Black [mailto:ben@layer8.net] Cc: 'idr@merit.edu' Subject: Re: Previous work on TTL on BGP routes? This was suggested some time ago by Curtis, but I've not seen a full draft on it. Ben On Wed, Jun 13, 2001 at 03:59:27PM -0400, Hire, Ejay wrote: > What if the instead of a TTL value, there was a > "Maximum-Parallel-Advertised-Aggregate-Length" (MPAAL). A value that says > "If this route is received on an interface in addition to an aggregate route > encompassing it with a prefix (Subnet mask length expressed in bits) of less > than the MPAAL, Discard the more specific route. > > If it was a optional transitive attribute, it would be backwards compatible > with current BGP implementations because it would be passed on and ignored > by systems that did not understand the function. > > Ejay Hire > 804-591-4564 > > Is this a new idea? Is it worthy of an RFC? Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA08344 for ; Wed, 13 Jun 2001 19:09:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF80691224; Wed, 13 Jun 2001 19:07:53 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C175E91311; Wed, 13 Jun 2001 19:07:52 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C972891224 for ; Wed, 13 Jun 2001 19:07:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CEB45DDC8; Wed, 13 Jun 2001 19:08:29 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shell-beach.layer8.net (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 17F395DD8F for ; Wed, 13 Jun 2001 19:08:29 -0400 (EDT) Received: (qmail 96786 invoked by uid 1000); 13 Jun 2001 23:08:45 -0000 Date: Wed, 13 Jun 2001 16:08:45 -0700 From: Ben Black To: "Hire, Ejay" Cc: "'idr@merit.edu'" Subject: Re: Previous work on TTL on BGP routes? Message-ID: <20010613160845.B96681@layer8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Ejay.Hire@Broadslate.net on Wed, Jun 13, 2001 at 03:59:27PM -0400 Sender: owner-idr@merit.edu Precedence: bulk This was suggested some time ago by Curtis, but I've not seen a full draft on it. Ben On Wed, Jun 13, 2001 at 03:59:27PM -0400, Hire, Ejay wrote: > What if the instead of a TTL value, there was a > "Maximum-Parallel-Advertised-Aggregate-Length" (MPAAL). A value that says > "If this route is received on an interface in addition to an aggregate route > encompassing it with a prefix (Subnet mask length expressed in bits) of less > than the MPAAL, Discard the more specific route. > > If it was a optional transitive attribute, it would be backwards compatible > with current BGP implementations because it would be passed on and ignored > by systems that did not understand the function. > > Ejay Hire > 804-591-4564 > > Is this a new idea? Is it worthy of an RFC? > > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@nexthop.com] > Sent: Wednesday, June 13, 2001 3:42 PM > To: idr@merit.edu > Subject: Re: Previous work on TTL on bgp routes? > > > On Wed, Jun 13, 2001 at 03:13:27PM -0400, Hire, Ejay wrote: > > This feature could cause sporadic and difficult to troubleshoot > reachability > > issues. > > Assume to following scenario. > > You are multihomed to two providers that are X Hops apart. > > You are advertising non-aggregate-able space to one or both providers. > > If your BGP TTL > X then you should retain reachability to both providers > in > > the event of a single link failure. > > > > In the event of a link failure on your part, and a routing failure on > their > > part causing X+n hops to separate the two providers, your BGP TTL may < > X+n > > and you will not be reachable by both providers. > > > > Is their a break in my logic here? > > The logic is sound. > > However, this feature - if it existed - should only be used on > routes that are covered by a less specific route. > In the event of a topology shift as suggest above, your inter-domain > traffic engineering would suffer, but you'd maintain reachability. > > An implementation should only propagate the TTL attribute iff > a less specific route is also being propagated. If the less > specific is to be withdrawn, the more specific must be re-advertised > without the TTL attribute. > > Additionally, only the originator of a route should set the TTL. > > -- > Jeff Haas > NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA05211 for ; Wed, 13 Jun 2001 16:03:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C58A9131A; Wed, 13 Jun 2001 16:01:43 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4993C91341; Wed, 13 Jun 2001 16:01:43 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A5B89131A for ; Wed, 13 Jun 2001 16:01:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D41DF5DDB0; Wed, 13 Jun 2001 16:02:19 -0400 (EDT) Delivered-To: idr@merit.edu Received: from email1.broadslate.net (unknown [216.142.210.128]) by segue.merit.edu (Postfix) with ESMTP id 7DF3F5DDF3 for ; Wed, 13 Jun 2001 16:02:19 -0400 (EDT) Received: by EMAIL1 with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 16:04:10 -0400 Message-ID: From: "Hire, Ejay" To: "'idr@merit.edu'" Subject: RE: Previous work on TTL on BGP routes? Date: Wed, 13 Jun 2001 15:59:27 -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 What if the instead of a TTL value, there was a "Maximum-Parallel-Advertised-Aggregate-Length" (MPAAL). A value that says "If this route is received on an interface in addition to an aggregate route encompassing it with a prefix (Subnet mask length expressed in bits) of less than the MPAAL, Discard the more specific route. If it was a optional transitive attribute, it would be backwards compatible with current BGP implementations because it would be passed on and ignored by systems that did not understand the function. Ejay Hire 804-591-4564 Is this a new idea? Is it worthy of an RFC? -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Wednesday, June 13, 2001 3:42 PM To: idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? On Wed, Jun 13, 2001 at 03:13:27PM -0400, Hire, Ejay wrote: > This feature could cause sporadic and difficult to troubleshoot reachability > issues. > Assume to following scenario. > You are multihomed to two providers that are X Hops apart. > You are advertising non-aggregate-able space to one or both providers. > If your BGP TTL > X then you should retain reachability to both providers in > the event of a single link failure. > > In the event of a link failure on your part, and a routing failure on their > part causing X+n hops to separate the two providers, your BGP TTL may < X+n > and you will not be reachable by both providers. > > Is their a break in my logic here? The logic is sound. However, this feature - if it existed - should only be used on routes that are covered by a less specific route. In the event of a topology shift as suggest above, your inter-domain traffic engineering would suffer, but you'd maintain reachability. An implementation should only propagate the TTL attribute iff a less specific route is also being propagated. If the less specific is to be withdrawn, the more specific must be re-advertised without the TTL attribute. Additionally, only the originator of a route should set the TTL. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA05183 for ; Wed, 13 Jun 2001 16:01:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CC6991318; Wed, 13 Jun 2001 15:59:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E18291319; Wed, 13 Jun 2001 15:59:57 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35FF891318 for ; Wed, 13 Jun 2001 15:59:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 254625DDC1; Wed, 13 Jun 2001 16:00:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id E09135DE3F for ; Wed, 13 Jun 2001 16:00:27 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA09209 for ; Wed, 13 Jun 2001 13:00:00 -0700 (PDT) Message-Id: <200106132000.NAA09209@red.juniper.net> To: idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86883.992462399.1@juniper.net> Date: Wed, 13 Jun 2001 13:00:00 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, For previous work on TTL on BGP routes see IDRP, and specifically text on RD_HOP_COUNT attribute. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04805 for ; Wed, 13 Jun 2001 15:43:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7347A91314; Wed, 13 Jun 2001 15:41:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4291391315; Wed, 13 Jun 2001 15:41:54 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F07091314 for ; Wed, 13 Jun 2001 15:41:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B62A15DDF6; Wed, 13 Jun 2001 15:42:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 9F1C65DDF4 for ; Wed, 13 Jun 2001 15:42:30 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f5DJg3713042 for ; Wed, 13 Jun 2001 15:42:03 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f5DJg3p13388 for idr@merit.edu; Wed, 13 Jun 2001 15:42:03 -0400 (EDT) Date: Wed, 13 Jun 2001 15:42:03 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? Message-ID: <20010613154202.A13357@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Ejay.Hire@Broadslate.net on Wed, Jun 13, 2001 at 03:13:27PM -0400 Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jun 13, 2001 at 03:13:27PM -0400, Hire, Ejay wrote: > This feature could cause sporadic and difficult to troubleshoot reachability > issues. > Assume to following scenario. > You are multihomed to two providers that are X Hops apart. > You are advertising non-aggregate-able space to one or both providers. > If your BGP TTL > X then you should retain reachability to both providers in > the event of a single link failure. > > In the event of a link failure on your part, and a routing failure on their > part causing X+n hops to separate the two providers, your BGP TTL may < X+n > and you will not be reachable by both providers. > > Is their a break in my logic here? The logic is sound. However, this feature - if it existed - should only be used on routes that are covered by a less specific route. In the event of a topology shift as suggest above, your inter-domain traffic engineering would suffer, but you'd maintain reachability. An implementation should only propagate the TTL attribute iff a less specific route is also being propagated. If the less specific is to be withdrawn, the more specific must be re-advertised without the TTL attribute. Additionally, only the originator of a route should set the TTL. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04369 for ; Wed, 13 Jun 2001 15:17:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C9F59122F; Wed, 13 Jun 2001 15:15:38 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 068CD91314; Wed, 13 Jun 2001 15:15:37 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24CE19122F for ; Wed, 13 Jun 2001 15:15:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CD1A5DDF3; Wed, 13 Jun 2001 15:16:14 -0400 (EDT) Delivered-To: idr@merit.edu Received: from email1.broadslate.net (unknown [216.142.210.128]) by segue.merit.edu (Postfix) with ESMTP id 385CB5DDB0 for ; Wed, 13 Jun 2001 15:16:14 -0400 (EDT) Received: by EMAIL1 with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 15:18:04 -0400 Message-ID: From: "Hire, Ejay" To: idr@merit.edu Subject: RE: Previous work on TTL on bgp routes? Date: Wed, 13 Jun 2001 15:13:27 -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 This feature could cause sporadic and difficult to troubleshoot reachability issues. Assume to following scenario. You are multihomed to two providers that are X Hops apart. You are advertising non-aggregate-able space to one or both providers. If your BGP TTL > X then you should retain reachability to both providers in the event of a single link failure. In the event of a link failure on your part, and a routing failure on their part causing X+n hops to separate the two providers, your BGP TTL may < X+n and you will not be reachable by both providers. Is their a break in my logic here? -----Original Message----- From: Alex Zinin [mailto:azinin@nexsi.com] Sent: Wednesday, June 13, 2001 2:57 PM To: Brijesh Kumar Cc: Jeffrey Haas; idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? Brijesh, > On the basis of what knowledge will you recommend to choose this TTL value? Same as today---based on the limited knowledge of your upstream topology. > And more so, what exactly will you gain by this? See below. > To me restricting routing information on the basis of TTL defeats the basic > principle that information about routes must be propogated to every router > that needs to know this information (let them filter on the basis of their > needs). Expressing policies in terms of TTL is meaningless since you may > have no idea how this information is applicable beyond your direct > neighbours. This is not about policies in terms of TTL. A TTL would provide an mechanism to automatically remove specifics and leave an aggregate in the multihoming scenarios without having an arbitrary AS configure route aggregation. The benefit is---decreased size of the routing table. > If you need to control the distribution of routing information, then use the > method similar to IDRP which has attributes to control the distribution of > routing information by expressely listing the ADs to which this route > information is to be distributed or excluded from. A good thing about the TTL approach is that the originator does not need to know the (constantly changing) AS topology to control the radius of the route distribution region. There always are multiple methods to do the same thing with their pros and cons. Thanks, Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA03666 for ; Wed, 13 Jun 2001 14:52:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D45C79121E; Wed, 13 Jun 2001 14:51:02 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A659F91222; Wed, 13 Jun 2001 14:51:02 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA4419121E for ; Wed, 13 Jun 2001 14:51:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E9B4E5DDBF; Wed, 13 Jun 2001 14:51:38 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id E13115DDB0 for ; Wed, 13 Jun 2001 14:51:37 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA30301; Wed, 13 Jun 2001 11:57:17 -0700 Date: Wed, 13 Jun 2001 11:57:15 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <18049078150.20010613115715@nexsi.com> To: Brijesh Kumar Cc: Jeffrey Haas , idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Brijesh, > On the basis of what knowledge will you recommend to choose this TTL value? Same as today---based on the limited knowledge of your upstream topology. > And more so, what exactly will you gain by this? See below. > To me restricting routing information on the basis of TTL defeats the basic > principle that information about routes must be propogated to every router > that needs to know this information (let them filter on the basis of their > needs). Expressing policies in terms of TTL is meaningless since you may > have no idea how this information is applicable beyond your direct > neighbours. This is not about policies in terms of TTL. A TTL would provide an mechanism to automatically remove specifics and leave an aggregate in the multihoming scenarios without having an arbitrary AS configure route aggregation. The benefit is---decreased size of the routing table. > If you need to control the distribution of routing information, then use the > method similar to IDRP which has attributes to control the distribution of > routing information by expressely listing the ADs to which this route > information is to be distributed or excluded from. A good thing about the TTL approach is that the originator does not need to know the (constantly changing) AS topology to control the radius of the route distribution region. There always are multiple methods to do the same thing with their pros and cons. Thanks, Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA24347 for ; Tue, 12 Jun 2001 04:12:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC0A6912C2; Tue, 12 Jun 2001 04:11:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9310912C3; Tue, 12 Jun 2001 04:11:03 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDE0C912C2 for ; Tue, 12 Jun 2001 04:11:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BB0F5DDEA; Tue, 12 Jun 2001 04:11:37 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id 9CB3A5DD8F for ; Tue, 12 Jun 2001 04:11:36 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id BAA09396; Tue, 12 Jun 2001 01:17:31 -0700 Date: Tue, 12 Jun 2001 01:17:29 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <2750836038.20010612011729@nexsi.com> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? In-Reply-To: <20010611170300.C26229@nexthop.com> References: <20010611170300.C26229@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Jeffrey, The idea has been floating around for a while, but I do not think it was documented. I believe it has merit, especially considering the way route aggregation is implemented and deployed now. -- Alex Zinin Monday, June 11, 2001, 2:03:00 PM, Jeffrey Haas wrote: > Has there been any previous work on TTL in announced bgp routes? > I'm using TTL in the IP sense - it goes through N hops, > in this case AS's, and is propagated no further. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA14753 for ; Mon, 11 Jun 2001 19:45:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFF49912B6; Mon, 11 Jun 2001 19:44:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1007912B4; Mon, 11 Jun 2001 19:44:09 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82629912B5 for ; Mon, 11 Jun 2001 19:44:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD9F15DDD6; Mon, 11 Jun 2001 19:44:38 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id 2CDB65DD92 for ; Mon, 11 Jun 2001 19:44:38 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id QAA04537 for ; Mon, 11 Jun 2001 16:50:43 -0700 Date: Mon, 11 Jun 2001 16:50:43 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <9720430527.20010611165043@nexsi.com> To: idr@merit.edu Subject: Re: Proposed text for 9.1.2 In-Reply-To: <49FF5C6DDBD8D311BBBD009027DE980C0210F4C7@mailwest.unispherenetworks.com> References: <49FF5C6DDBD8D311BBBD009027DE980C0210F4C7@mailwest.unispherenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Folks, Below is the text incorporating the latest comments, and including some minor changes I thought were useful. Alex. > 3. Summary of Operation > > Two systems form a transport protocol connection between one another. > They exchange messages to open and confirm the connection parameters. > The initial data flow is complete BGP routing information. Incremental > updates are sent as the routing information changes. BGP does not > require periodic refresh of all BGP routes. Therefore, a BGP speaker > must retain the current version of the entire BGP routing tables of > all of its peers for the duration of the connection. If the > implementation decides to not store the routes that have been received > from a peer, but have been filtered out according to configured local > policy, the BGP Route Refresh option [10] may be used to request the > full set of routes from a peer without resetting the BGP session when > the local policy configuration changes... > > [...] > > 3.1 Routes: Advertisement and Storage > > [...] > - 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 Routing Table; > and routes that are received from other BGP speakers are present > in the Adj-RIBs-In. > > [...] > > 3.2 Routing Information Bases > > [...] > > In summary, the Adj-RIBs-In contain unprocessed routing information > that has been advertised to the local BGP speaker by its peers; the > Loc-RIB contains the routes that have been selected by the local BGP > speaker's Decision Process; and the Adj-RIBs-Out organize the routes > for advertisement to specific peers by means of the local speaker's > UPDATE messages. > > Routing information that the router uses to forward packets > (or to construct the forwarding table that is used for packet > forwarding) is maintained in the Routing Table. The Routing Table > accumulates routes to directly connected networks, static routes, > routes learned from the IGP protocols, and routes learned from BGP. > Whether or not a specific BGP route should be installed in the Routing > Table, and whether a BGP route should override a route to the same > destination installed by another source is a local policy decision, > not specified in this document. Besides actual packet forwarding, > the Routing Table is used for resolution of the next-hop addresses > specified in BGP updates (see Section 9.1.2). > > [...] > > 6. BGP Error Handling. > > [...] > > The phrase "the BGP connection is closed" means that the transport > protocol connection has been closed, the associated Adj-RIB-In has > been cleared, and that all resources for that BGP connection have > been deallocated. Entries in the Loc-RIB associated with the remote > peer are marked as invalid... > > [...] > > 6.1 Multiple Networks Per Message > > > The BGP protocol allows for multiple address prefixes with the same > AS path and next-hop gateway to be specified in one message. Making > use of this capability is highly recommended. With one address prefix > per message there is a substantial increase in overhead in the > receiver. Not only does the system overhead increase due to the > reception of multiple messages, but the overhead of scanning the > Loc-RIB for updates to BGP peers and other routing protocols > (and sending the associated messages) is incurred multiple times as > well. One method of building messages containing many address > prefixes per AS path and gateway from the Loc-RIB that is not > organized per AS path is to build many messages as the Loc-RIB > is scanned. As each address prefix is processed, a message for the > associated AS path and gateway is allocated, if it does not exist, > and the new address prefix is added to it. If such a message exists, > the new address prefix is just appended to it. If the message lacks > the space to hold the new address prefix, it is transmitted, a new > message is allocated, and the new address prefix is inserted into the > new message. When the entire Loc-RIB has been scanned, all > allocated messages are sent and their resources released. Maximum > compression is achieved when all the destinations covered by the > address prefixes share a gateway and common path attributes, making > it possible to send many address prefixes in one 4096-byte message. > When peering with a BGP implementation that does not compress > multiple address prefixes into one message, it may be necessary to > take steps to reduce the overhead from the flood of data received > when a peer is acquired or a significant network topology change > occurs. One method of doing this is to limit the rate of updates. > This will eliminate the redundant scanning of the Loc-RIB to > > [...] > > > 9.1.2 Phase 2: Route Selection > > [...] > > If the NEXT_HOP attribute of a BGP route is not resolvable or it would > become unresolvable if the route was installed in the routing table, > the BGP route should be excluded from the Phase 2 decision function > (see Section 9.1.2.1). > > [...] > > For each set of destinations for which a feasible route exists in the > Adj-RIBs-In, the local BGP speaker shall identify the route that has: > > a) the highest degree of preference of any route to the same set > of destinations, or > > b) is the only route to that destination, or > > c) is selected as a result of the Phase 2 tie breaking rules > specified in 9.1.2.1. > > // ^^^^^^^->"9.1.2.2" > > > [...] > > The local speaker SHALL then install that route in the Loc-RIB, > replacing any route to the same destination that is currently being > held in the Loc-RIB. If the new BGP route is installed in the Routing > Table (as a result of the local policy decision), care must be taken > to ensure that invalid BGP routes to the same destination are removed > from the Routing Table. Whether or not the new route replaces an already > existing non-BGP route in the routing table depends on the policy > configured on the BGP speaker. > > The local speaker MUST determine the immediate next hop to the address > depicted by the NEXT_HOP attribute of the selected route by performing > a best matching route lookup in the Routing Table and selecting one > of the possible paths (if multiple best paths to the same prefix are > available). If the route to the address depicted by the NEXT_HOP > attribute changes such that the immediate next hop or the IGP cost to > the NEXT_HOP (if the NEXT_HOP is resolved through an IGP route) changes, > route selection should be recalculated as specified above. > > Notice that even though BGP routes do not have to be installed in > the Routing Table with the immediate next hop(s), implementations > must take care that before any packets are forwarded along a BGP > route, it's associated NEXT_HOP address is resolved to the immediate > (directly connected) next-hop address and this address (or multiple > addresses) is finally used for actual packet forwarding. > > Unfeasible routes SHALL be removed from the Loc-RIB and the routing > table. However, corresponding unfeasible routes MUST be kept in > the Adj-RIBs-In. > > 9.1.2.1 Route Resolvability Condition > > As indicated in Section 9.1.2, BGP routers should exclude unresolvable > routes from the Phase 2 decision. This ensures that only valid routes > are installed in Loc-RIB and the Routing Table. > > The route resolvability condition is defined as follows. > > 1. A route Rte1, referencing only the intermediate network address, > is considered resolvable if the Routing Table contains at least > one resolvable route Rte2 that matches Rte1's intermediate network > address and is not recursively resolved (directly or indirectly) > through Rte1. If multiple matching routes are available, only > the longest matching route should be considered. > > 2. Routes referencing interfaces (with or without intermediate > addresses) are considered resolvable if the state of the referenced > interface is up and IP processing is enabled on this interface. > > BGP routes do not refer to interfaces, but can be resolved through the > routes in the Routing Table that can be of both types. IGP routes and > routes to directly connected networks are expected to specify the > outbound interface. > > Note that a BGP route is considered unresolvable not only in situations > where the router's Routing Table contains no route matching the BGP > route's NEXT_HOP. Mutually recursive routes (routes resolving each other > or themselves), also fail the resolvability check. > > It is also important that implementations do not consider feasible > routes that would become unresolvable if they were installed in > the Routing Table even if their NEXT_HOPs are resolvable using the > current contents of the Routing Table. This check ensures that a BGP > speaker does not install in the Routing Table routes that will be > removed and not used by the speaker. Therefore, in addition to local > Routing Table stability, this check also improves behavior of > the protocol in the network. > > Whenever a BGP speaker identifies a route that fails the resolvability > check because of mutual recursion, an error message should be logged. > > > 9.1.2.1 Breaking Ties (Phase 2) > > ^^^^^^^-->9.1.2.2 ... > > [...] > > b) Remove from consideration any routes with less-preferred > interior cost. The interior cost of a route is determined by > calculating the metric to the next hop for the route using the > Routing Table. If the next hop for a route is reachable, but no > cost can be determined, then this step should be should be skipped > (equivalently, consider all routes to have equal costs). > > [...] > > 9.1.3 Phase 3: Route Dissemination > > [...] > > When the updating of the Adj-RIBs-Out and the Routing Table is complete, > the local BGP speaker shall run the external update process of 9.2.2. > > > 9.2.2 External Updates > > The external update process is concerned with the distribution of > routing information to external peers. As part of Phase 3 route > selection process, the BGP speaker has updated its Adj-RIBs-Out and > its Routing Table. > > [...] > > > References > > [...] > > [10] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, > September 2000. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA12121 for ; Mon, 11 Jun 2001 17:04:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CAE5912AC; Mon, 11 Jun 2001 17:02:53 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C6F9912AD; Mon, 11 Jun 2001 17:02:53 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 408BD912AC for ; Mon, 11 Jun 2001 17:02:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F29075DDD0; Mon, 11 Jun 2001 17:03:25 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id AD2925DD92 for ; Mon, 11 Jun 2001 17:03:25 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f5BL30707299 for ; Mon, 11 Jun 2001 17:03:00 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f5BL30C26249 for idr@merit.edu; Mon, 11 Jun 2001 17:03:00 -0400 (EDT) Date: Mon, 11 Jun 2001 17:03:00 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Previous work on TTL on bgp routes? Message-ID: <20010611170300.C26229@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idr@merit.edu Precedence: bulk Has there been any previous work on TTL in announced bgp routes? I'm using TTL in the IP sense - it goes through N hops, in this case AS's, and is propagated no further. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03374 for ; Mon, 11 Jun 2001 10:56:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C0BB91284; Mon, 11 Jun 2001 10:55:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 438B991285; Mon, 11 Jun 2001 10:55:03 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5809491284 for ; Mon, 11 Jun 2001 10:55:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8037A5DDD9; Mon, 11 Jun 2001 10:55:35 -0400 (EDT) Delivered-To: idr@merit.edu Received: from EXCHANGE.kerenix.com (unknown [212.150.1.82]) by segue.merit.edu (Postfix) with ESMTP id C2F455DDD7 for ; Mon, 11 Jun 2001 10:55:31 -0400 (EDT) Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 17:57:25 +0300 Message-ID: <2B15221907365C468941FDFC02C8776940B8B5@EXCHANGE.kerenix.com> From: Yosi Yarchi To: "'Jeffrey Haas'" Cc: idr@merit.edu Subject: RE: reposting an e-mail Date: Mon, 11 Jun 2001 17:57:22 +0300 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 Jeffrey I'm talking about not to implement the Adj-RIBs-Out at all, not by pointers, nor by any other methods. On naive implementation, when BGP decides new path, it have to update the Adj-RIBs-Out and, if Adj-RIBs-Out actually changed (depending on output filters) - to advertise route to the peer. I'm talking about shortening the process. When BGP decides new path, it passes (1) the old path through the output filter, then (2) the new path through output filter. The delta is sent to peer. My question regards not only compliancy to the standard, but also implementation and performance aspects. I'm afraid that (1) I didn't pay attention to SW activities required by current RFC's or drafts that assumes real existence of Adj-RIBs-Out (=absent of Adj-RIBs-Out will lead to compensation by over processing, complicated code, etc.) (2) Implementation complexity will be too high. For example, what happens when the operator tries to replace route map for specific peer? You have to maintain temporarily two maps, the old and the new, to re-calculate the Adj-RIBs-Out for both, to send the deltas to your peer, then cancel the old one and remain with the new one. With best regards Yosi yarchi -------------------------------------------------- Yosi Yarchi http://www.kerenix.com Phone: +972-3-9050783 Mobile: 972-58-512783 Fax: +972-3-9347720 mailto:yosi_yarchi@kerenix.com 70 Pinsker St., Petach-Tikva 49221 ISRAEL -------------------------------------------------- > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@nexthop.com] > Sent: Friday, June 08, 2001 6:08 PM > To: yosi_yarchi@kerenix.com > Cc: idr@merit.edu > Subject: Re: reposting an e-mail > > > Yosi, > > This is answered in section 3.2 of RFC 1771: > > : Although the conceptual model distinguishes between Adj-RIBs-In, > : Loc-RIB, and Adj-RIBs-Out, this neither implies nor > requires that an > : implementation must maintain three separate copies of the routing > : information. The choice of implementation (for example, > 3 copies of > : the information vs 1 copy with pointers) is not > constrained by the > : protocol. > > > -- > Jeff Haas > NextHop Technologies > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA16783 for ; Sun, 10 Jun 2001 21:07:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2FBE291268; Sun, 10 Jun 2001 21:06:00 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E99E09126A; Sun, 10 Jun 2001 21:05:59 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF28A91268 for ; Sun, 10 Jun 2001 21:05:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC84E5DD9C; Sun, 10 Jun 2001 21:06:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by segue.merit.edu (Postfix) with ESMTP id BE9435DD8D for ; Sun, 10 Jun 2001 21:06:30 -0400 (EDT) Received: from TWINKLE.mcs.anl.gov (vpnclient154.mcs.anl.gov [140.221.11.154]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id UAA20118 for ; Sun, 10 Jun 2001 20:06:04 -0500 Message-Id: <5.1.0.14.0.20010610200135.02d401f8@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Jun 2001 20:05:17 -0500 To: idr@merit.edu From: Bill Nickless Subject: Updated draft-nickless-safi-mcast-app-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idr@merit.edu Precedence: bulk The rest of this note is an updated version of draft-nickless-safi-mcast-app-00.txt which includes changes based on David Meyer's comments (Thanks, Dave!) Under separate cover I have sent this draft to internet-drafts@ietf.org for posting. Internet Draft B. Nickless Document: draft-nickless-safi-mcast-app-00.txt Argonne National Laboratory Expires: December 2001 June 2001 Application of Multiprotocol BGP-4 to IPv4 Multicast Routing Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract BGP-4 Multiprotocol Extensions [BGP-MP] defines the values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. This document defines how compliant systems should make use of these values for the purpose of routing IP multicast traffic. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................2 Introduction and Terminology.......................................2 Application of Multiprotocol BGP-4 SAFI Field......................2 Security Considerations............................................3 Acknowledgements...................................................3 References.........................................................4 Author's Address...................................................4 Nickless Informational - Expires November 2001 1 Application of Multiprotocol BGP-4 April 2001 To IPv4 Multicast Routing Overview Inter-Autonomous System IPv4 multicast routing is supported by the BGPv4 Multiprotocol Extensions. The topology defined by BGPv4 for multicast routing is used for two purposes: guiding the creation and direction of source-based multicast distribution trees, and assisting MSDP to flood knowledge of active Anycast sources. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Introduction and Terminology IPv4 multicast [MCAST] is an internetwork service that allows IPv4 datagrams sent from a source to be delivered to more than one interested receiver. That is, a given source sends a packet the network with a destination address 224/4 CIDR [CIDR] range. The network transports this packet to all receivers (replicated where necessary) that have registered their interest in receiving these packets. Application of Multiprotocol BGP-4 SAFI Field The topology of inter-domain IPv4 multicast forwarding is determined by BGPv4 [BGPV4] policy, as is IPv4 unicast forwarding. BGP provides reachability information. Reachability information for IPv4 Unicast and IPv4 Multicast prefixes can be advertised separately. (See [MBGP] for details and the definition of Network Layer Reachability Information (NLRI) and Subsequent Address Family Information (SAFI).) The practical definition of reachability is different for IPv4 unicast (NLRI=Unicast, SAFI=1) and IPv4 multicast (NLRI=Multicast, SAFI=2). In the case of BGP multicast advertisements (NLRI=Multicast, SAFI=2), reachability is defined to mean two things: First, IPv4 datagrams can be requested (or accepted) from multicast sources within the advertised prefix range. This causes the creation of source-rooted multicast distribution trees. Such requests MAY be made to the advertised NEXT_HOP by means of the PIM Sparse Mode [PIM-SM] protocol. Any other mutually agreed upon Nickless Informational - Expires December 2001 2 Application of Multiprotocol BGP-4 April 2001 To IPv4 Multicast Routing protocol that supports source-specific traffic requests MAY be used to support this requirement. Second, the MSDP [MSDP] speaker with the NEXT_HOP address SHOULD provide MSDP Source Active messages with the Source Active RP- Address field matching the advertised prefix range. Any other mutually agreed upon protocol that supports the spreading of knowledge of active Anycast sources MAY be used to support this requirement in lieu of, or in addition to, MSDP. These two definitions of BGP NLRI=Multicast flow from the original use of the Distance Vector Multicast Routing Protocol [DVMRP] for IPv4 multicast routing. (The BGP NLRI=Multicast topology replaces the topology functions of DVMRP.) DVMRP is a "dense" routing protocol, which means traffic is flooded outwards from the sources to all possible receivers. In this situation, an IPv4 multicast router has to decide which incoming interface may accept IPv4 datagrams from a given source (to avoid forwarding loops), as well as which incoming interface is appropriate for learning about a given multicast source. The current "sparse" inter-domain forwarding model (requiring source-specific requests for traffic) requires both interpretations of BGP NLRI=Multicast became necessary for interoperability with the DVMRP-based model. Note that while MSDP is not strictly necessary for Autonomous Systems that only support Source Specific Multicast [SSM], MSDP depends on the latter interpretation of BGP NLRI=Multicast to avoid MSDP SA forwarding loops. There is a real danger of causing MSDP SA forwarding "black holes" unless Autonomous Systems with BGP NLRI=Multicast capable peerings also exchange MSDP Source Active messages. MBGP also supports combined multicast and unicast advertisements (SAFI=3). We define these advertisements to include the multicast meanings above in addition to reachability for unicast forwarding. This is an optimization for the case where the unicast forwarding and multicast acceptance/request/source-discovery topologies are congruent. Security Considerations The extensions defined in this document allow BGP speakers to make use of reachability information about IPv4 multicast sources. As such, no new security issues are raised beyond those that already exist in BGPv4, PIM-SM, and MSDP. Acknowledgements The author would like to thank David Meyer for his useful comments and suggestions, which have been incorporated in this Draft. Nickless Informational - Expires December 2001 3 Application of Multiprotocol BGP-4 April 2001 To IPv4 Multicast Routing This work was supported by the Mathematical, Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, U.S. Department of Energy, under Contract W-31-109-Eng-38. References [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering. Aug-01-1989. [CIDR] RFC 1519: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. [BGPV4] RFC 1771: A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. [MBGP] RFC 2858: Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. June 2000. [PIM-SM] RFC 2117: Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1997. [MSDP] draft-ietf-msdp-spec-09.txt: Multicast Source Discovery Protocol (MSDP). D. Meyer (Editor). March 2001. [DVMRP] RFC 1075: Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. November 1988. Author's Address Bill Nickless Argonne National Laboratory 9700 South Cass Avenue #221 Phone: +1 630 252 7390 Argonne, IL 60439 Email: nickless@mcs.anl.gov Nickless Informational - Expires December 2001 4 === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA25367 for ; Fri, 8 Jun 2001 14:32:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6949A91220; Fri, 8 Jun 2001 14:30:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3930E91410; Fri, 8 Jun 2001 14:30:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CD9891220 for ; Fri, 8 Jun 2001 14:30:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DED135DDC4; Fri, 8 Jun 2001 14:31:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by segue.merit.edu (Postfix) with ESMTP id AA1485DDBD for ; Fri, 8 Jun 2001 14:31:22 -0400 (EDT) Received: from robcrane40@netscape.net by imo-m04.mx.aol.com (mail_out_v30.22.) id m.1c.173dbd6 (16232) for ; Fri, 8 Jun 2001 14:30:56 -0400 (EDT) Received: from netscape.com (aimmail06.aim.aol.com [205.188.144.198]) by air-in02.mx.aol.com (v78_r3.8) with ESMTP; Fri, 08 Jun 2001 14:30:56 -0400 Date: Fri, 08 Jun 2001 14:30:56 -0400 From: robcrane40@netscape.net To: idr@merit.edu Subject: Valid IP host address Mime-Version: 1.0 Message-ID: <1849539E.3FC7F830.106E1E70@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk The BGP spec requires several fields (BGP identifier in OPEN, next-hop in UPDATE, and aggregator address in UPDATE) to be a "valid IP (host) address". Could we add some more precise language to the spec to define more precisely what constitutes a valid host address. For example: a) Is a class D or class E address a "valid IP host address"? b) Is a loopback address (e.g. 127.0.0.1) a "valid IP host address"? c) Is network zero (e.g. 0.0.0.1) a "valid IP host address"? Also, what should a BGP implementation do when it receives an aggregator address which is not a valid IP address? Send a notification? __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20232 for ; Fri, 8 Jun 2001 11:09:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B4A39138C; Fri, 8 Jun 2001 11:07:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A44791398; Fri, 8 Jun 2001 11:07:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EAF4A9138C for ; Fri, 8 Jun 2001 11:07:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 673B25DDBB; Fri, 8 Jun 2001 11:08:23 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 224235DDB0 for ; Fri, 8 Jun 2001 11:08:23 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f58F82H35554; Fri, 8 Jun 2001 11:08:02 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f58F81c24659; Fri, 8 Jun 2001 11:08:01 -0400 (EDT) Date: Fri, 8 Jun 2001 11:08:01 -0400 From: Jeffrey Haas To: yosi_yarchi@kerenix.com Cc: idr@merit.edu Subject: Re: reposting an e-mail Message-ID: <20010608110801.A24635@nexthop.com> References: <200106081500.IAA08256@red.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106081500.IAA08256@red.juniper.net>; from yakov@juniper.net on Fri, Jun 08, 2001 at 08:00:27AM -0700 Sender: owner-idr@merit.edu Precedence: bulk Yosi, This is answered in section 3.2 of RFC 1771: : Although the conceptual model distinguishes between Adj-RIBs-In, : Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an : implementation must maintain three separate copies of the routing : information. The choice of implementation (for example, 3 copies of : the information vs 1 copy with pointers) is not constrained by the : protocol. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20191 for ; Fri, 8 Jun 2001 11:06:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CDD629138A; Fri, 8 Jun 2001 11:05:29 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AC8D9138C; Fri, 8 Jun 2001 11:05:29 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23D3D9138A for ; Fri, 8 Jun 2001 11:05:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E9BA5DDBB; Fri, 8 Jun 2001 11:05:55 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 4A29C5DDB0 for ; Fri, 8 Jun 2001 11:05:55 -0400 (EDT) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f58F5XK15702; Fri, 8 Jun 2001 11:05:33 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 8 Jun 2001 10:59:14 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 10:59:14 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56A936C0@newman.tenornet.com> From: "Tsillas, Jim" To: "'Yakov Rekhter'" , idr@merit.edu Cc: yosi_yarchi@kerenix.com Subject: RE: reposting an e-mail Date: Fri, 8 Jun 2001 10:59:13 -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 yes -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Friday, June 08, 2001 11:00 AM To: idr@merit.edu Cc: yosi_yarchi@kerenix.com Subject: reposting an e-mail Folks, I've been asked to repost the following. Yakov. ------- Forwarded Message From: yosi_yarchi@kerenix.com To: Idr (E-mail); 'idr@merit.edu' Sent: 6/6/2001 11:40 AM Subject: BGP4 implementation of Adj-RIBs-Out Hi I have question regarding possible BGP4 implementation: Anlyzing BGP, I found that: (1) Implementor is required to implement Adj-RIBs-Out for each peer, to hold advertised routes (RFC1771) (2) The Adj-RIBs-Out data base is not really involved in update/withdraw operations, because when BGP decides to prefer another path in it's Loc-RIB, it should update Adj-RIBs-Out in accordance with route-maps etc., and send update to all peers. The route-map filter is applied anyway, and the update is sent anyway. So, the Adj-RIBs-Out does not really participating in the update/withdraw process (3) The Adj-RIBs-Out data base participates in special operations. For example, when peer request for refresh, or when the operator request to show the advertised routes of specific peer. Both operations are not performance critical, because they are not frequent and because they could be executed in lower priority than other BGP activities, thus not degrading the forwarding performance. (4) The Adj-RIBs-Out consumes lot of memory, because it is per peer. My question is: is it possible to implement BGP4 without real Adj-RIBs-Out, and instead maintain virtual Adj-RIBs-Out, where each entry is generated upon demand from Loc-RIB and the relevant route-maps (something like /proc file system in linux)? With best regards Yosi yarchi - -------------------------------------------------- Yosi Yarchi http://www.kerenix.com Phone: +972-3-9050783 Mobile: 972-58-512783 Fax: +972-3-9347720 mailto:yosi_yarchi@kerenix.com 70 Pinsker St., Petach-Tikva 49221 ISRAEL - -------------------------------------------------- ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20108 for ; Fri, 8 Jun 2001 11:02:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8D0C91369; Fri, 8 Jun 2001 11:00:24 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 201839138A; Fri, 8 Jun 2001 11:00:23 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C75A891369 for ; Fri, 8 Jun 2001 11:00:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16CF25DDBB; Fri, 8 Jun 2001 11:00:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 812295DDB0 for ; Fri, 8 Jun 2001 11:00:48 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA08256; Fri, 8 Jun 2001 08:00:27 -0700 (PDT) Message-Id: <200106081500.IAA08256@red.juniper.net> To: idr@merit.edu Cc: yosi_yarchi@kerenix.com Subject: reposting an e-mail MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81791.992012427.1@juniper.net> Date: Fri, 08 Jun 2001 08:00:27 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, I've been asked to repost the following. Yakov. ------- Forwarded Message From: yosi_yarchi@kerenix.com To: Idr (E-mail); 'idr@merit.edu' Sent: 6/6/2001 11:40 AM Subject: BGP4 implementation of Adj-RIBs-Out Hi I have question regarding possible BGP4 implementation: Anlyzing BGP, I found that: (1) Implementor is required to implement Adj-RIBs-Out for each peer, to hold advertised routes (RFC1771) (2) The Adj-RIBs-Out data base is not really involved in update/withdraw operations, because when BGP decides to prefer another path in it's Loc-RIB, it should update Adj-RIBs-Out in accordance with route-maps etc., and send update to all peers. The route-map filter is applied anyway, and the update is sent anyway. So, the Adj-RIBs-Out does not really participating in the update/withdraw process (3) The Adj-RIBs-Out data base participates in special operations. For example, when peer request for refresh, or when the operator request to show the advertised routes of specific peer. Both operations are not performance critical, because they are not frequent and because they could be executed in lower priority than other BGP activities, thus not degrading the forwarding performance. (4) The Adj-RIBs-Out consumes lot of memory, because it is per peer. My question is: is it possible to implement BGP4 without real Adj-RIBs-Out, and instead maintain virtual Adj-RIBs-Out, where each entry is generated upon demand from Loc-RIB and the relevant route-maps (something like /proc file system in linux)? With best regards Yosi yarchi - -------------------------------------------------- Yosi Yarchi http://www.kerenix.com Phone: +972-3-9050783 Mobile: 972-58-512783 Fax: +972-3-9347720 mailto:yosi_yarchi@kerenix.com 70 Pinsker St., Petach-Tikva 49221 ISRAEL - -------------------------------------------------- ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA05264 for ; Thu, 7 Jun 2001 21:36:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB95C913FF; Thu, 7 Jun 2001 21:35:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DA6391401; Thu, 7 Jun 2001 21:35:09 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B78CD913FF for ; Thu, 7 Jun 2001 21:35:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 052A35DD96; Thu, 7 Jun 2001 21:35:32 -0400 (EDT) Delivered-To: idr@merit.edu Received: from pine.ggn.net (pine.ggn.net [198.207.193.2]) by segue.merit.edu (Postfix) with SMTP id 927AC5DD8C for ; Thu, 7 Jun 2001 21:35:31 -0400 (EDT) Received: (qmail 12882 invoked by user marklist) by pine.ggn.net; 8 Jun 2001 01:35:11 -0000 Date: Thu, 7 Jun 2001 21:35:11 -0400 (EDT) From: Mark Mentovai To: Cc: IDR Subject: Re: =?gb2312?b?tPC4tDpSRTo=?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk ji.xiaowei@mail.zte.com.cn wrote: >maybe i have not expressed my question clearly. > >I just want to know while we do the connection collision detection, >should we know the state of PEER speaker,and if we should know peer >speaker's state,how can we know? A speaker always knows the local state of its own connections. When a speaker receives an OPEN message, it is guaranteed that the sending neighbor is in the OpenSent or OpenConfirm state. Since a speaker's own ID is always known, and a neighbor's ID is known once an OPEN is received, implementation of the collision avoidance algorithm is now trivial. Mark Return-Path: Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA08544 for ; Wed, 6 Jun 2001 21:39:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A75FD91332; Wed, 6 Jun 2001 21:38:06 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7292C91333; Wed, 6 Jun 2001 21:38:06 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9598591332 for ; Wed, 6 Jun 2001 21:38:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 059395DDB1; Wed, 6 Jun 2001 21:38:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id 923B85DDAD for ; Wed, 6 Jun 2001 21:38:29 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA05825; Wed, 6 Jun 2001 18:42:28 -0700 Date: Mon, 4 Jun 2001 12:45:09 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <97174254354.20010604124509@nexsi.com> To: "Shekhar, Ravi" Cc: idr@merit.edu Subject: Re: Proposed text for 9.1.2 In-Reply-To: <49FF5C6DDBD8D311BBBD009027DE980C0210F4C7@mailwest.unispherenetworks.com> References: <49FF5C6DDBD8D311BBBD009027DE980C0210F4C7@mailwest.unispherenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Ravi, I'll change this part as Yakov suggested. I guess this should satisfy all parties. -- Alex Zinin Monday, June 04, 2001, 8:06:09 AM, Shekhar, Ravi wrote: >> > have revised opinion here: >> > It MUST be MUST >> >> Yes, I think this is the better way. >> It is also consistent with Section 3: >> >> > BGP does >> not require >> > periodic refresh of the entire BGP routing table. >> Therefore, a BGP >> > speaker must retain the current version of the entire BGP routing >> > tables of all of its peers for the duration of the connection. >> > Alex, that simply means this does not hold true anymore.. unless you > are insistent on not considering route-refresh, which I dont > see any reason not to consider because route-refresh is already > an RFC.. > - Ravi Shekhar. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17864 for ; Fri, 1 Jun 2001 17:37:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 11C419133E; Fri, 1 Jun 2001 17:31:40 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD4FC91341; Fri, 1 Jun 2001 17:31:39 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD2B59133E for ; Fri, 1 Jun 2001 17:31:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E28315DDB5; Fri, 1 Jun 2001 17:31:48 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 9BB9C5DDB0 for ; Fri, 1 Jun 2001 17:31:48 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f51LVbH74125 for ; Fri, 1 Jun 2001 17:31:37 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f51LVb025382 for idr@merit.edu; Fri, 1 Jun 2001 17:31:37 -0400 (EDT) Date: Fri, 1 Jun 2001 17:31:37 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Re: NULLROUTE Community Message-ID: <20010601173137.U24478@nexthop.com> References: <200106011951.NAA23195@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106011951.NAA23195@tcb.net>; from danny@ambernetworks.com on Fri, Jun 01, 2001 at 01:51:36PM -0600 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jun 01, 2001 at 01:51:36PM -0600, Danny McPherson wrote: > > Often, it would be useful for one BGP speaker to inform another that it has > > no interest in receiving traffic addressed to certain destinations. Such a > > capability could be used to effectively create destination-based access > > lists on a BGP neighbor. This topic was brought up on the NANOG list under the topic of Subject: How does one make not playing nice with each other scale? (Was: net.terrorism) > Isn't this the purpose of Enke's ORF stuff (i.e., draft-ietf-idr-route-filter-0 > 3.txt)? This seems to be a poor fit for ORF. Unless you mean "I don't want routes with holes, so don't send me routes that have the community that says there is a hole present". > filtering policy, but the same mechanism could be > employed (though I'm not sure BGP is the right place > for it). Well, you want to apply it for forwarding purposes, and passing around reachability is what we're doing. > The difference between the above and what you propose here is > that there'd be less scope of attribute advertisement. Then again, > it would still likely be a matter of policy within the local domain, > and could be broken if folks forget to configure things like BGP > "send-community" in some implementations. These, among other related > reasons, are why folks weren't to keen on the AVOID_ME & PREFER_ME > communities ID a while back either. If we're going to pass around this stuff in bgp, it probably should be in mpbgp since its a type of "non-reachability". Perhaps a new SAFI. If we were to bother with this stuff, I'd want to see the following behavior: When a route is present that is a more specific and shares common attributes as a less specific route, And that route is tagged as a forwarding "hole", And this hole isn't already covered by something that is reachable and is more specific than the aggregate with the hole: Find the next best route Synthesize a route in your RIB/FIB for the hole that has the next best route's properties. Install *that* in your FIB, if policy says so. NEVER PROPAGATE IT. One of the arguments from the NANOG thread was that passing around unreachability doesn't likely scale. Storing it in the IRR, maybe, but not passing it around in bgp. > -danny -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA17097 for ; Fri, 1 Jun 2001 16:56:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D64791331; Fri, 1 Jun 2001 16:52:45 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AC5691328; Fri, 1 Jun 2001 16:52:45 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F147191331 for ; Fri, 1 Jun 2001 16:52:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21FEE5DDB0; Fri, 1 Jun 2001 16:52:24 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 597575DDA2 for ; Fri, 1 Jun 2001 16:52: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 NAA23195 for ; Fri, 1 Jun 2001 13:51:36 -0600 Message-Id: <200106011951.NAA23195@tcb.net> X-Mailer: exmh version 2.0.3 To: IDR From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: NULLROUTE Community Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Jun 2001 13:51:36 -0600 Sender: owner-idr@merit.edu Precedence: bulk > Often, it would be useful for one BGP speaker to inform another that it has > no interest in receiving traffic addressed to certain destinations. Such a > capability could be used to effectively create destination-based access > lists on a BGP neighbor. Isn't this the purpose of Enke's ORF stuff (i.e., draft-ietf-idr-route-filter-0 3.txt)? Given, it just applies to routing information policy versus packet filtering policy, but the same mechanism could be employed (though I'm not sure BGP is the right place for it). > There are many ways that this mechanism could be incorporated into BGP, but > perhaps one of the cleanest and simplest is to use the existing COMMUNITIES > attribute framework. A NULLROUTE community could be defined and used to > inform others that traffic sent to the networks given in the UPDATE > message's NLRI is not desired and should be discarded immediately. Besides ORFish (no pun intended :-) stuff, there are implementations that provide capabilities more/less identical to this already (see Cisco's IOS Essentials WP wrt DOS/NH/CEF for a hint of what I'm referring to). > Obviously, this can be configured on many existing routers, but I feel that > everyone can benefit from a globally consistent system that does not require > excess configuration. As such, it is my opinion that optimum utility could > be realized if the NULLROUTE community was defined as a well-known one. The difference between the above and what you propose here is that there'd be less scope of attribute advertisement. Then again, it would still likely be a matter of policy within the local domain, and could be broken if folks forget to configure things like BGP "send-community" in some implementations. These, among other related reasons, are why folks weren't to keen on the AVOID_ME & PREFER_ME communities ID a while back either. What Cisco's done is interesting and accomplishes this w/o touching the protocol. -danny Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA15675 for ; Fri, 1 Jun 2001 15:57:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B99E9131B; Fri, 1 Jun 2001 15:56:43 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58DC59131C; Fri, 1 Jun 2001 15:56:43 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 491FE9131B for ; Fri, 1 Jun 2001 15:56:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6665B5DDB0; Fri, 1 Jun 2001 15:56:56 -0400 (EDT) Delivered-To: idr@merit.edu Received: from oak.ggn.net (oak.ggn.net [198.207.193.5]) by segue.merit.edu (Postfix) with SMTP id 3A3455DDA2 for ; Fri, 1 Jun 2001 15:56:51 -0400 (EDT) Received: (qmail 1808 invoked by user marklist) by oak.ggn.net; 1 Jun 2001 19:56:36 -0000 Date: Fri, 1 Jun 2001 15:56:36 -0400 (EDT) From: Mark Mentovai To: Ramana Gollamudi Cc: IDR Subject: RE: NULLROUTE Community In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Ramana Gollamudi wrote: >Why would a BGP speaker advertise a route (with or without a NULL community) >if it is not going to forward any traffic to that destination in the first >place? I'm sorry, this should have been more clear. This is intended to be used when the speaker is already advertising a less-specific route for the destination, but does not wish to receive the more-specific traffic. For example, it provides an alternative to contacting an upstream provider to build or modify an access list when a host or network is receiving unwanted traffic (as in the case of a denial-of-service attack.) It also has the advantage of being able to propagate itself to other BGP speakers, so the unwanted traffic traverses the fewest number of links and devices possible. Mark Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14112 for ; Fri, 1 Jun 2001 15:00:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF45B91311; Fri, 1 Jun 2001 14:59:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A02759131B; Fri, 1 Jun 2001 14:59:20 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF69A91311 for ; Fri, 1 Jun 2001 14:59:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE5E85DDA2; Fri, 1 Jun 2001 14:59:29 -0400 (EDT) Delivered-To: idr@merit.edu Received: from oak.ggn.net (oak.ggn.net [198.207.193.5]) by segue.merit.edu (Postfix) with SMTP id 52C545DD96 for ; Fri, 1 Jun 2001 14:59:29 -0400 (EDT) Received: (qmail 938 invoked by user marklist) by oak.ggn.net; 1 Jun 2001 18:59:18 -0000 Date: Fri, 1 Jun 2001 14:59:18 -0400 (EDT) From: Mark Mentovai To: IDR Subject: NULLROUTE Community Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Is there any interest in exploring a way to communicate null routes from within BGP? Often, it would be useful for one BGP speaker to inform another that it has no interest in receiving traffic addressed to certain destinations. Such a capability could be used to effectively create destination-based access lists on a BGP neighbor. There are many ways that this mechanism could be incorporated into BGP, but perhaps one of the cleanest and simplest is to use the existing COMMUNITIES attribute framework. A NULLROUTE community could be defined and used to inform others that traffic sent to the networks given in the UPDATE message's NLRI is not desired and should be discarded immediately. Obviously, this can be configured on many existing routers, but I feel that everyone can benefit from a globally consistent system that does not require excess configuration. As such, it is my opinion that optimum utility could be realized if the NULLROUTE community was defined as a well-known one. If there is interest, I will prepare an I-D. I would appreciate the group's comments and support. Mark Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA12461 for ; Fri, 1 Jun 2001 13:57:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 934C091305; Fri, 1 Jun 2001 13:56:26 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5877F91306; Fri, 1 Jun 2001 13:56:26 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4ABBD91305 for ; Fri, 1 Jun 2001 13:56:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 413165DDAF; Fri, 1 Jun 2001 13:56:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id AB2935DD92 for ; Fri, 1 Jun 2001 13:56:38 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA19599; Fri, 1 Jun 2001 10:56:27 -0700 (PDT) Message-Id: <200106011756.KAA19599@red.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Proposed text for 9.1.2 In-Reply-To: Your message of "Thu, 31 May 2001 21:18:38 PDT." <18125974319.20010531211838@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3663.991418187.1@juniper.net> Date: Fri, 01 Jun 2001 10:56:27 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > Yes, I think this is the better way. > It is also consistent with Section 3: > > > BGP does not require > > periodic refresh of the entire BGP routing table. Therefore, a BGP > > speaker must retain the current version of the entire BGP routing > > tables of all of its peers for the duration of the connection. > > > OK, below is the result of an attempt to address the comments > made on the list. I changed wording in Section 3 to not refer > to the routing table, since the terms are not defined yet. > I also introduced the term "Routing Table" in 3.2 and checked > usage of "routing table" and "forwarding information table" > to use the right term (either Loc-RIB or Routing Table). > I also added some text in 9.1.2 to clarify usage of > the intermediate next-hop, changed some wording, etc. > The pseudo-code is removed from the subsection describing > the route resolvability condition. > > Comments are welcome. > > --- > Alex Zinin. > > > > 3. Summary of Operation > > Two systems form a transport protocol connection between one another. > They exchange messages to open and confirm the connection parameters. > The initial data flow is the entire BGP routing table. Incremental > updates are sent as the routing tables change. BGP does not require > periodic refresh of the entire BGP routing table. Therefore, a BGP > speaker must retain the current version of the entire BGP routing > tables of all of its peers for the duration of the connection... > > /* Change to: > > Two systems form a transport protocol connection between one another. > They exchange messages to open and confirm the connection parameters. > The initial data flow is complete BGP routing information. Incremental > updates are sent as the routing information changes. BGP does not > require periodic refresh of all BGP routes. Therefore, a BGP speaker > must retain the current version of the entire set of BGP routes of all > of its peers for the duration of the connection... > */ If a BGP speaker and its peer use BGP Refresh (rfc2918), then the last statement in the above is not correct. Therefore I would suggest to change it as follows: Therefore, unless a BGP speaker and its peer use BGP Route Refresh [RFC2918], the speaker must retain the current version of the entire set of BGP routes received from the peer for the duration of the connection with the peer. Yakov. Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA09304 for ; Fri, 1 Jun 2001 11:50:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A635912FF; Fri, 1 Jun 2001 11:47:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F91A91300; Fri, 1 Jun 2001 11:47:04 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED658912FF for ; Fri, 1 Jun 2001 11:47:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B40285DDB5; Fri, 1 Jun 2001 11:47:16 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 712645DDB0 for ; Fri, 1 Jun 2001 11:47:16 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f51Fl5H57325; Fri, 1 Jun 2001 11:47:05 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f51Fl5s24619; Fri, 1 Jun 2001 11:47:05 -0400 (EDT) Date: Fri, 1 Jun 2001 11:47:05 -0400 From: Jeffrey Haas To: ks s Cc: idr@merit.edu Subject: Re: bgp auth. Message-ID: <20010601114705.E24478@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from radix4@hotmail.com on Thu, May 31, 2001 at 06:53:26PM -0000 Sender: owner-idr@merit.edu Precedence: bulk On Thu, May 31, 2001 at 06:53:26PM -0000, ks s wrote: > 1. are there any implementations, which support the auth. > as explained by rfc1771 None that I'm aware of. Theoretically, one could use it for such a thing as a message authentication digest for individual bgp messages. > 2. whats the use of auth. in open packet, in lieu of rfc2385 If anyone knows of any use for this field, please let me know. It'll be going into the next BGP mib. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA11787 for ; Fri, 1 Jun 2001 00:13:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D6E1912E8; Fri, 1 Jun 2001 00:12:19 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCFDC912E9; Fri, 1 Jun 2001 00:12:18 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7B25912E8 for ; Fri, 1 Jun 2001 00:12:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B302F5DD97; Fri, 1 Jun 2001 00:12:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id 3B98F5DD8F for ; Fri, 1 Jun 2001 00:12:30 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id VAA04768; Thu, 31 May 2001 21:18:38 -0700 Date: Thu, 31 May 2001 21:18:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) UNREG / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <18125974319.20010531211838@nexsi.com> To: edc@exodus.net Cc: idr@merit.edu Subject: Re: Proposed text for 9.1.2 In-Reply-To: <20010531174253.A1644@exodus.net> References: <20010531174253.A1644@exodus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > have revised opinion here: > It MUST be MUST Yes, I think this is the better way. It is also consistent with Section 3: > BGP does not require > periodic refresh of the entire BGP routing table. Therefore, a BGP > speaker must retain the current version of the entire BGP routing > tables of all of its peers for the duration of the connection. OK, below is the result of an attempt to address the comments made on the list. I changed wording in Section 3 to not refer to the routing table, since the terms are not defined yet. I also introduced the term "Routing Table" in 3.2 and checked usage of "routing table" and "forwarding information table" to use the right term (either Loc-RIB or Routing Table). I also added some text in 9.1.2 to clarify usage of the intermediate next-hop, changed some wording, etc. The pseudo-code is removed from the subsection describing the route resolvability condition. Comments are welcome. --- Alex Zinin. 3. Summary of Operation Two systems form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters. The initial data flow is the entire BGP routing table. Incremental updates are sent as the routing tables change. BGP does not require periodic refresh of the entire BGP routing table. Therefore, a BGP speaker must retain the current version of the entire BGP routing tables of all of its peers for the duration of the connection... /* Change to: Two systems form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters. The initial data flow is complete BGP routing information. Incremental updates are sent as the routing information changes. BGP does not require periodic refresh of all BGP routes. Therefore, a BGP speaker must retain the current version of the entire set of BGP routes of all of its peers for the duration of the connection... */ [...] 3.1 Routes: Advertisement and Storage [...] - 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. /* Change to ...and the next hop for each of these routes must be present in the local BGP speaker's Routing Table... */ 3.2 Routing Information Bases [...] In summary, the Adj-RIBs-In contain unprocessed routing information that has been advertised to the local BGP speaker by its peers; the Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process; and the Adj-RIBs-Out organize the routes for advertisement to specific peers by means of the local speaker's UPDATE messages. /* Add: Routing information that the router uses to forward packets (or to construct the forwarding table that is used for packet forwarding) is maintained in the Routing Table. The Routing Table accumulates routes to directly connected networks, static routes, routes learnt from the IGP protocols, and routes learnt from BGP. Whether or not a specific BGP route should be installed in the routing table, and whether a BGP route should override a route to the same destination installed by another source is a local policy decision, not specified in this document. Besides actual packet forwarding, the Routing Table is used for resolution of the next-hop addresses specified in BGP updates (see Section 9.1.2). */ [...] 6. BGP Error Handling. [...] The phrase "the BGP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGP connection have been deallocated. Routing table entries associated with the remote peer are marked as invalid... /* Change to: The phrase "the BGP connection is closed" means that the transport protocol connection has been closed, the associated Adj-RIB-In has been cleared, and that all resources for that BGP connection have been deallocated. Entries in the Loc-RIB associated with the remote peer are marked as invalid... */ 6.1 Multiple Networks Per Message The BGP protocol allows for multiple address prefixes with the same AS path and next-hop gateway to be specified in one message. Making use of this capability is highly recommended. With one address prefix per message there is a substantial increase in overhead in the receiver. Not only does the system overhead increase due to the reception of multiple messages, but the overhead of scanning the routing table for updates to BGP peers and other routing protocols // ^^^^^^^^^^^^^^ change to "Loc-RIB" (and sending the associated messages) is incurred multiple times as well. One method of building messages containing many address prefixes per AS path and gateway from a routing table that is not // ^^^^^^^^^^^^^->"Loc-RIB" organized per AS path is to build many messages as the routing table // "Loc-RIB"<-^^^^^^^^^^^^^ is scanned. As each address prefix is processed, a message for the associated AS path and gateway is allocated, if it does not exist, and the new address prefix is added to it. If such a message exists, the new address prefix is just appended to it. If the message lacks the space to hold the new address prefix, it is transmitted, a new message is allocated, and the new address prefix is inserted into the new message. When the entire routing table has been scanned, all // ^^^^^^^^^^^^^->"Loc-RIB" allocated messages are sent and their resources released. Maximum compression is achieved when all the destinations covered by the address prefixes share a gateway and common path attributes, making it possible to send many address prefixes in one 4096-byte message. When peering with a BGP implementation that does not compress multiple address prefixes into one message, it may be necessary to take steps to reduce the overhead from the flood of data received when a peer is acquired or a significant network topology change occurs. One method of doing this is to limit the rate of updates. This will eliminate the redundant scanning of the routing table to // "Loc-RIB"<-^^^^^^^^^^^^^ [...] 9.1.2 Phase 2: Route Selection [...] If the NEXT_HOP attribute of a BGP route depicts an address to which the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route should be excluded from the Phase 2 decision function. /* Change to: If the NEXT_HOP attribute of a BGP route is not resolvable or it would become unresolvable if the route was installed in the routing table, the BGP route should be excluded from the Phase 2 decision function (see Section 9.1.2.1). */ [...] For each set of destinations for which a feasible route exists in the Adj-RIBs-In, the local BGP speaker shall identify the route that has: a) the highest degree of preference of any route to the same set of destinations, or b) is the only route to that destination, or c) is selected as a result of the Phase 2 tie breaking rules specified in 9.1.2.1. // ^^^^^^^->"9.1.2.2" [...] The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being held in the Loc-RIB. The local speaker MUST determine the immediate next hop to the address depicted by the NEXT_HOP attribute of the selected route by performing a lookup in the IGP and selecting one of the possible paths in the IGP. This immediate next hop MUST be used when installing the selected route in the Loc-RIB. If the route to the address depicted by the NEXT_HOP attribute changes such that the immediate next hop changes, route selection should be recalculated as specified above. /* Change to: The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being held in the Loc-RIB. If the new BGP route is installed in the Routing Table (as a result of the local policy decision), care must be taken to ensure that invalid BGP routes to the same destination are removed from the Routing Table. Whether or not the new route replaces an already existing non-BGP route in the routing table depends on the policy configured on the BGP speaker. The local speaker MUST determine the immediate next hop to the address depicted by the NEXT_HOP attribute of the selected route by performing a best matching route lookup in the Routing Table and selecting one of the possible paths (if multiple best paths to the same prefix are available). If the route to the address depicted by the NEXT_HOP attribute changes such that the immediate next hop or the IGP cost to the NEXT_HOP (if the NEXT_HOP is resolved through an IGP route) changes, route selection should be recalculated as specified above. Notice that even though BGP routes do not have to be installed in the Routing Table with the immediate next hop(s), implementations must take care that before any packets are forwarded along a BGP route, it's associated NEXT_HOP address is resolved to the immediate (directly connected) next-hop address and this address (or multiple addresses) is finally used for actual packet forwarding. */ Unfeasible routes shall be removed from the Loc-RIB, and corresponding unfeasible routes shall then be removed from the Adj- RIBs-In. /* Change to: Unfeasible routes SHALL be removed from the Loc-RIB and the routing table. However, corresponding unfeasible routes MUST be kept in the Adj-RIBs-In. */ // Section on route resolvability: 9.1.2.1 Route Resolvability Condition As indicated in Section 9.1.2, BGP routers should exclude unresolvable routes from the Phase 2 decision. This ensures that only valid routes are installed in Loc-RIB and the Routing Table. The route resolvability condition is defined as follows. 1. A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indirectly) through Rte1. 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the referenced interface is up and IP processing is enabled on this interface. BGP routes do not refer to interfaces, but can be resolved through the routes in the Routing Table that can be of both types. IGP routes and routes to directly connected networks are expected to specify the outbound interface. Note that a BGP route is considered unresolvable not only in situations where the router's Routing Table contains no route matching the BGP route's NEXT_HOP. Mutually recursive routes (routes resolving each other or themselves), also fail the resolvability check. It is also important that implementations do not consider feasible routes that would become unresolvable if they were installed in the Routing Table even if their NEXT_HOPs are resolvable using the current contents of the Routing Table. This check ensures that a BGP speaker does not install in the Routing Table routes that will be removed and not used by the speaker. Therefore, in addition to local Routing Table stability, this check also improves behavior of the protocol in the network. Whenever a BGP speaker identifies a route that fails the resolvability check because of mutual recursion, an error message should be logged. 9.1.2.1 Breaking Ties (Phase 2) /* Change to: 9.1.2.2 ... */ 9.1.3 Phase 3: Route Dissemination [...] When the updating of the Adj-RIBs-Out and the Forwarding Information Base (FIB) is complete, the local BGP speaker shall run the external update process of 9.2.2. /* Change to When the updating of the Adj-RIBs-Out and the Routing Table is complete, the local BGP speaker shall run the external update process of 9.2.2. */ 9.2.2 External Updates The external update process is concerned with the distribution of routing information to external peers. As part of Phase 3 route selection process, the BGP speaker has updated its Adj-RIBs-Out and its Forwarding Table. [...] // ^^^^^^^^^^^^^^^^->"Routing Table"