Re: [Idr] Route becoming unfeasible triggers Decision Process?

[Glen Kent <[e-mail]>]

> 
> When a route becomes unfeasible because its next-hop is removed from
> the routing table (e.g., because a router dies and the loopback

I presume you mean the next-hop to reach the NEXT_HOP.

> address goes away), is it a must that the router will trigger Decision
> Process, to pick a replacement route to Loc-RIB from Adj-RIBs-in, and
> then propagate it to the peers (or, if a replacement is not found,
> just send a Withdraw)?

Yes.

> 
> The triggering of Decision Process seems to be supported by sections
> 9.1.2 and 9.2 of the BGP draft, but not stated explicitly AFAICS.
> 
> (An implementation is (IMHO clearly incorrectly) waiting until the the
> BGP session times out to replace unfeasible routes with feasible oes,
> and only then propagates them in iBGP.)

All implementations that i have worked on periodically scan the
reachability to the NEXT_HOPs to see if anything interesting has
happened since it ran the last time.

This is of course done in addition to other asynchronous notifications
that you may send to BGP when an interface/route comes up/goes down.

No implementation waits for the Hold Time to expire (in most of the
cases) before declaring the peer to be down.

Kent.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA28272 for <[e-mail]>; Wed, 17 Nov 2004 18:47:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZIL-0005TM-Uk; Wed, 17 Nov 2004 18:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZ4P-0001dt-B9 for [e-mail]; Wed, 17 Nov 2004 18:18:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01202 for <[e-mail]>; Wed, 17 Nov 2004 18:18:34 -0500 (EST)
Received: from rproxy.gmail.com ([64.233.170.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUZ6u-0000Q6-Ii for [e-mail]; Wed, 17 Nov 2004 18:21:12 -0500
Received: by rproxy.gmail.com with SMTP id b11so980506rne for <[e-mail]>; Wed, 17 Nov 2004 15:18:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=jpvHTWUabQOPj0kl7qC6gsKyir2oQ5RAeeS1DWK0MwTHgVrDZ3rfh/Bo9PCHoH7mow1tiMRDsdnYmKkxQ2aC44DxjInHadIXlR9dRMeuce1oRw5BD1fAlJMxH4QpNlY97ZY0D2dtL6vVEmhWBQ/Fs630oHlZRhSMWE6HB/2douE=
Received: by 10.38.67.8 with SMTP id p8mr253264rna; Wed, 17 Nov 2004 15:18:32 -0800 (PST)
Received: by 10.38.102.48 with HTTP; Wed, 17 Nov 2004 15:18:32 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 04:48:32 +0530
From: Glen Kent <[e-mail]>
To: Pekka Savola <[e-mail]>
Subject: Re: [Idr] Route becoming unfeasible triggers Decision Process?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Glen Kent <[e-mail]>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

> 
> When a route becomes unfeasible because its next-hop is removed from
> the routing table (e.g., because a router dies and the loopback

I presume you mean the next-hop to reach the NEXT_HOP.

> address goes away), is it a must that the router will trigger Decision
> Process, to pick a replacement route to Loc-RIB from Adj-RIBs-in, and
> then propagate it to the peers (or, if a replacement is not found,
> just send a Withdraw)?

Yes.

> 
> The triggering of Decision Process seems to be supported by sections
> 9.1.2 and 9.2 of the BGP draft, but not stated explicitly AFAICS.
> 
> (An implementation is (IMHO clearly incorrectly) waiting until the the
> BGP session times out to replace unfeasible routes with feasible oes,
> and only then propagates them in iBGP.)

All implementations that i have worked on periodically scan the
reachability to the NEXT_HOPs to see if anything interesting has
happened since it ran the last time.

This is of course done in addition to other asynchronous notifications
that you may send to BGP when an interface/route comes up/goes down.

No implementation waits for the Hold Time to expire (in most of the
cases) before declaring the peer to be down.

Kent.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA22179 for <[e-mail]>; Mon, 15 Nov 2004 09:30:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CThi3-0006UX-Ga; Mon, 15 Nov 2004 09:19:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CThhU-0006Nu-VE for [e-mail]; Mon, 15 Nov 2004 09:19:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26868 for <[e-mail]>; Mon, 15 Nov 2004 09:19:23 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CThjS-0007ud-LF for [e-mail]; Mon, 15 Nov 2004 09:21:30 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2004 06:19:15 -0800
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAFEIin0002493; Mon, 15 Nov 2004 06:18:44 -0800 (PST)
Received: from [10.61.64.73] (ams-clip-vpn-dhcp73.cisco.com [10.61.64.73]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYZ48789; Mon, 15 Nov 2004 06:23:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 06:18:41 -0800
From: Robert Raszuk <[e-mail]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola <[e-mail]>
Subject: Re: [Idr] Route becoming unfeasible triggers Decision Process?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Pekka,

How about an implementation which has already executed a decision 
process ahead of time (assuming the best path may fail) ? In such a case 
it will be no reason to state in any document what you suggested: "it a 
must that the router will trigger Decision Process".

And btw I don't know any implementation which would wait till "BGP 
session times out". Simply taking IBGP side as example next hop may be 
the remote ASBR/PE and you may be peering to RRs therefor your BGP 
session may never time out ;).

For EBGP side in the case of peering between loopbacks or interfaces it 
is just a matter of detecting the remote node being down via any 
available detection technics. One of them quite commonly used were 
clearly (or maybe unfortunate) BGP session keepalives .. Good news is 
that there are few other ways to detect your peer down these days 
without tuning BGP holdtime timer speeding keepalives.

Cheers,
R.


 > Pekka Savola wrote:
 >
> Hi,
> 
> Just to make sure that I've interpreted this correctly:
> 
> When a route becomes unfeasible because its next-hop is removed from the 
> routing table (e.g., because a router dies and the loopback address goes 
> away), is it a must that the router will trigger Decision Process, to 
> pick a replacement route to Loc-RIB from Adj-RIBs-in, and then propagate 
> it to the peers (or, if a replacement is not found, just send a Withdraw)?
> 
> The triggering of Decision Process seems to be supported by sections 
> 9.1.2 and 9.2 of the BGP draft, but not stated explicitly AFAICS.
> 
> (An implementation is (IMHO clearly incorrectly) waiting until the the 
> BGP session times out to replace unfeasible routes with feasible ones, 
> and only then propagates them in iBGP.)
> 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA19639 for <[e-mail]>; Mon, 15 Nov 2004 05:35:12 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTeAR-0006Fj-UT; Mon, 15 Nov 2004 05:33:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTe9G-00064B-Vz for [e-mail]; Mon, 15 Nov 2004 05:31:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14072 for <[e-mail]>; Mon, 15 Nov 2004 05:31:48 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTeBE-00040f-4t for [e-mail]; Mon, 15 Nov 2004 05:33:53 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAFAVEB09514 for <[e-mail]>; Mon, 15 Nov 2004 12:31:14 +0200
Date: Mon, 15 Nov 2004 12:31:14 +0200 (EET)
From: Pekka Savola <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Idr] Route becoming unfeasible triggers Decision Process?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi,

Just to make sure that I've interpreted this correctly:

When a route becomes unfeasible because its next-hop is removed from 
the routing table (e.g., because a router dies and the loopback 
address goes away), is it a must that the router will trigger Decision 
Process, to pick a replacement route to Loc-RIB from Adj-RIBs-in, and 
then propagate it to the peers (or, if a replacement is not found, 
just send a Withdraw)?

The triggering of Decision Process seems to be supported by sections 
9.1.2 and 9.2 of the BGP draft, but not stated explicitly AFAICS.

(An implementation is (IMHO clearly incorrectly) waiting until the the 
BGP session times out to replace unfeasible routes with feasible ones, 
and only then propagates them in iBGP.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07788 for <[e-mail]>; Fri, 12 Nov 2004 15:56:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShw3-0000u0-9G; Fri, 12 Nov 2004 15:22:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShhY-0007fm-Kz; Fri, 12 Nov 2004 15:07:20 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08247; Fri, 12 Nov 2004 15:07:18 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Fri, 12 Nov 2004 15:07:18 -0500
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-mibagent-survey-02.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP MIB V1 implementation survey
	Author(s)	: S. Hares, D. Hares
	Filename	: draft-ietf-idr-bgp-mibagent-survey-02.txt
	Pages		: 37
	Date		: 2004-11-12
	
This document provides of survey of BGP-4 [BGP4] protocol
   implementing RFC 1657 MIB agents according to the [BGP-v1-MIB]
   specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-mibagent-survey-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-mibagent-survey-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-mibagent-survey-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-mibagent-survey-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07744 for <[e-mail]>; Fri, 12 Nov 2004 15:51:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShqY-00052A-A3; Fri, 12 Nov 2004 15:16:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShhU-0007c5-4e; Fri, 12 Nov 2004 15:07:16 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08231; Fri, 12 Nov 2004 15:07:14 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Fri, 12 Nov 2004 15:07:13 -0500
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-implementation-02.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP 4 Implementation Report
	Author(s)	: S. Hares, A. Retana
	Filename	: draft-ietf-idr-bgp-implementation-02.txt
	Pages		: 86
	Date		: 2004-11-12
	
This document provides a survey of the BGP-4 implementation draft-
   ietf-idr-bgp4-24.txt.  After a brief summary, each response is
   listed. The editor makes no claim as to the accuracy of the
   information provided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-implementation-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-implementation-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-implementation-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-implementation-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02850 for <[e-mail]>; Wed, 10 Nov 2004 12:03:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvlt-0000D5-AI; Wed, 10 Nov 2004 11:56:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvdJ-0007E7-Bd for [e-mail]; Wed, 10 Nov 2004 11:47:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29460 for <[e-mail]>; Wed, 10 Nov 2004 11:47:40 -0500 (EST)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRve6-00077t-6f for [e-mail]; Wed, 10 Nov 2004 11:48:44 -0500
Received: (qmail 56079 invoked from network); 10 Nov 2004 16:47:20 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 10 Nov 2004 16:47:20 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAAGiKZ1068560; Wed, 10 Nov 2004 11:44:24 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 22:13:14 PST." <[e-mail]> 
Date: Wed, 10 Nov 2004 11:44:20 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pedro Roque Marques writes:
>  
> Curtis Villamizar writes:
>  
> >> AS X has an ibgp mesh. It receives a path originated by AS1
> >> advertised with multiple meds in different places. AS X border
> >> routers only know the lowest MED route. When that route flaps, all
> >> other ibgp mesh routers that have an alternate path do advertise
> >> their own path and then proceed to withdraw it if they see a better
> >> MED. The AS X border router to another AS Y can see a sequence of
> >> update -> withdrawls w/ the same as-path.
> >>  
> >> Same thing can happen w/ other attributes such as local-pref.
>  
>  
> > Sounds like an implementation bug.  When one is route is withdrawn
> > from within the IBPG, another BGP peer should announce the next best
> > route to IBGP immediately.  The peer on the other side of the
> > network sees no change within the MinInterval period.
>  
> If you assume that MinAdvInterval is used then
> a) it is typically used in ibgp also, as per spec.
> b) it is unclear when the interval period starts. 
>  
> Some implementations start the interval when the first event occurs
> and delay the advertisement... others start it at any possibly
> unrelated event and have an undeterministic delay.
>  
> > If the best IBGP route goes away, you propogate a route you already
> > know to IBGP immediately.  You propogate a route change that you
> > learned to EBGP after a delay.
>  
> That doesn't match reality in terms of deployments... You may get all
> the delays to line up and you may not.
>  
> Claiming that is an implementation bug is probably not going to
> help. It is delibrate behaviour with which you may agree or not. I
> personally don't believe that there is "one correct behaviour" that is
> optimal in all circunstances.
>  
>   Pedro.


Whether or not we call it a bug, this has been discussed long ago.  If
it isn't in the BGP spec we have an ommission.  Way back some
implementations advertised a route into IBGP even if it learned a
better route from IBGP specificly to avoid this.  The functionality
was changed to reduce the number of routes in IBGP routers but it was
noted that if this was done it shouldn't be counted in any of the
timers so that the change was not visible external to the AS.

Possible the only remnant of that is the paragraph below in section
"9.2.1.1 Frequency of Route Advertisement".

   Since fast convergence is needed within an autonomous system,
   either (a) the MinRouteAdvertisementIntervalTimer used for internal
   peers SHOULD be shorter than the MinRouteAdvertisementIntervalTimer
   used for external peers, or (b) the procedure describe in this
   section SHOULD NOT apply for routes sent to internal peers.

It is also the reason that in discussion of whether there should be a
separate and shorter MinRouteWithdrawInterval than the
MinRouteAdvertisementIntervalTimer the withdraw interval wouldn't be
set to zero.

Whether you want to call it a bug or not, the behavior you describe
does not conform to the above paragraph in BGP, although it does
specify a SHOULD rather than a MUST.

If we continue this discussion of how the BGP timers should be set, we
should start a separate thread.

Your point that bug or not, implementations do it is valid.

Using the AS-path as part of the key for flap history fixes a
problem.  It doesn't fix this problem.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA25806 for <[e-mail]>; Wed, 10 Nov 2004 01:17:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRlkr-00085T-Fx; Wed, 10 Nov 2004 01:14:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRljt-0007y9-Kg for [e-mail]; Wed, 10 Nov 2004 01:13:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28584 for <[e-mail]>; Wed, 10 Nov 2004 01:13:52 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRlkm-0001Bk-Do for [e-mail]; Wed, 10 Nov 2004 01:14:49 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id iAA6DFPm017583; Tue, 9 Nov 2004 22:13:15 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id iAA6DFC7017580; Tue, 9 Nov 2004 22:13:15 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 22:13:14 -0800
To: [e-mail]
Subject: Re: [Idr] Future of route flap dampening spec 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Curtis Villamizar writes:

>> AS X has an ibgp mesh. It receives a path originated by AS1
>> advertised with multiple meds in different places. AS X border
>> routers only know the lowest MED route. When that route flaps, all
>> other ibgp mesh routers that have an alternate path do advertise
>> their own path and then proceed to withdraw it if they see a better
>> MED. The AS X border router to another AS Y can see a sequence of
>> update -> withdrawls w/ the same as-path.
>>  
>> Same thing can happen w/ other attributes such as local-pref.


> Sounds like an implementation bug.  When one is route is withdrawn
> from within the IBPG, another BGP peer should announce the next best
> route to IBGP immediately.  The peer on the other side of the
> network sees no change within the MinInterval period.

If you assume that MinAdvInterval is used then
a) it is typically used in ibgp also, as per spec.
b) it is unclear when the interval period starts. 

Some implementations start the interval when the first event occurs
and delay the advertisement... others start it at any possibly
unrelated event and have an undeterministic delay.

> If the best IBGP route goes away, you propogate a route you already
> know to IBGP immediately.  You propogate a route change that you
> learned to EBGP after a delay.

That doesn't match reality in terms of deployments... You may get all
the delays to line up and you may not.

Claiming that is an implementation bug is probably not going to
help. It is delibrate behaviour with which you may agree or not. I
personally don't believe that there is "one correct behaviour" that is
optimal in all circunstances.

  Pedro.

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA25550 for <[e-mail]>; Wed, 10 Nov 2004 00:56:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRlQU-0005JZ-Lu; Wed, 10 Nov 2004 00:53:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRlOX-00052I-EK for [e-mail]; Wed, 10 Nov 2004 00:51:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27151 for <[e-mail]>; Wed, 10 Nov 2004 00:51:46 -0500 (EST)
Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRlPQ-0000nA-Vj for [e-mail]; Wed, 10 Nov 2004 00:52:45 -0500
Received: (qmail 73766 invoked from network); 10 Nov 2004 05:51:47 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay01.pair.com with SMTP; 10 Nov 2004 05:51:47 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAA5mnL8067386; Wed, 10 Nov 2004 00:48:53 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 20:59:15 PST." <[e-mail]> 
Date: Wed, 10 Nov 2004 00:48:49 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pedro Roque Marques writes:
>  
> Curtis Villamizar writes:
>  
>  
> > Undeterministic in the event of a network disaster is not a big
> > deal.
>  
> I'm not talking about any disaster... within normal operation you can
> get many paths flipping between as-paths. The ammount of state for
> that must be bound... if, when you hit whatever limit, the behaviour
> changes, this is underterministic behaviour that is very hard to
> troubleshoot.


The point is that you have to get a very large number of AS-path
advertised and withdrawn for a very large number of prefixes for there
to be a problem with allocating too much memory.  That would qualify
as a network disaster.


> > Anyway, this smarter allocation is outside of the scope of the
> > document.
>  
> The feasibility of what you propose depends on the resource
> consumption that it takes. I don't think it is outside the scope at all. 


A protocol spec need only point out that memory consumption can be an
issue.  It need not provide the solution to that issue.  It helps to
know that a feasible solution exists.  One such solution is add more
memory, and another involves using memory more wisely.


> > Please give an example where one MED change results in "advertise ->
> > withdrawl -> advertise -> withdrawl ..." where the same AS-path is
> > withdrawn multiple times.
>  
> AS X has an ibgp mesh. It receives a path originated by AS1 advertised
> with multiple meds in different places. AS X border routers only know
> the lowest MED route. When that route flaps, all other ibgp mesh
> routers that have an alternate path do advertise their own path and
> then proceed to withdraw it if they see a better MED. The AS X border
> router to another AS Y can see a sequence of update -> withdrawls w/
> the same as-path.
>  
> Same thing can happen w/ other attributes such as local-pref.


Sounds like an implementation bug.  When one is route is withdrawn
from within the IBPG, another BGP peer should announce the next best
route to IBGP immediately.  The peer on the other side of the network
sees no change within the MinInterval period.

If the best IBGP route goes away, you propogate a route you already
know to IBGP immediately.  You propogate a route change that you
learned to EBGP after a delay.  This avoids the problem you just
mentioned and prevents inconsistent routes within IBGP.


> > One change (one down peering) can cause a very large number of
> > updates downstream.  If each causes the same prefix to be penalized
> > it is incorrectly suppressed.  That behaviour is considered
> > "harmfull".
>  
> Indeed. btw: lets be clear. It is paths that get penalized not
> prefixes. With the current behaviour one down peer only makes the
> prefix unavailiable if it is close to the source where you are likely
> to see same as-paths.
>  
> > Considering the AS-path eliminates this problem.  If this behavior
> > is considered harmfull and we eliminate this behavior, its an
> > improvement.
>  
> I don't think you have answered the objections i raise...
>  
> imho better improvement is to disable damping. Does it do anything
> useful ? Empirical evidence suggests that networks are much better off
> without it.


There is no evidence of harmful effects if implemented as per the
spec.  There is only evidence of harmful effects with the
non-compliant implementation and it is a harmful effect that was
warned about in the spec before that emperical evidence existed.
Violating the spec in this way has a predicable harmful effect and it
has been observed.

If you want to disable damping that's OK with me.


> >> I'm not going to argue the definition of what is "correctly
> >> implemented"...
>  
> > Implemented as per the spec.
>  
> These two statements, above and bellow seem contradictory to
> me. Specially coupled with the assumption that the resource
> consumption of other alternatives are outside of the scope, it seems
> to me that the most reasonable approach for an implementation today is
> to ignore as-path.
>  
> > Note that the spec allows the current behaviour to be offerred as a
> > configured option
>  
>  
>   Pedro.

The spec requires you to implement both options and allows the current
behavior to be configured.  It also states that the default should be
to consider AS-path.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA25052 for <[e-mail]>; Wed, 10 Nov 2004 00:02:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRkbo-0006jA-5R; Wed, 10 Nov 2004 00:01:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRkaH-0006SK-GK for [e-mail]; Tue, 09 Nov 2004 23:59:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23903 for <[e-mail]>; Tue, 9 Nov 2004 23:59:50 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRkbA-0008AX-Ml for [e-mail]; Wed, 10 Nov 2004 00:00:49 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id iAA4xGPm017473; Tue, 9 Nov 2004 20:59:16 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id iAA4xGHh017470; Tue, 9 Nov 2004 20:59:16 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 20:59:15 -0800
To: [e-mail]
Subject: Re: [Idr] Future of route flap dampening spec 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Curtis Villamizar writes:


> Undeterministic in the event of a network disaster is not a big
> deal.

I'm not talking about any disaster... within normal operation you can
get many paths flipping between as-paths. The ammount of state for
that must be bound... if, when you hit whatever limit, the behaviour
changes, this is underterministic behaviour that is very hard to
troubleshoot.
 
> Anyway, this smarter allocation is outside of the scope of the
> document.

The feasibility of what you propose depends on the resource
consumption that it takes. I don't think it is outside the scope at all. 

> Please give an example where one MED change results in "advertise ->
> withdrawl -> advertise -> withdrawl ..." where the same AS-path is
> withdrawn multiple times.

AS X has an ibgp mesh. It receives a path originated by AS1 advertised
with multiple meds in different places. AS X border routers only know
the lowest MED route. When that route flaps, all other ibgp mesh
routers that have an alternate path do advertise their own path and
then proceed to withdraw it if they see a better MED. The AS X border
router to another AS Y can see a sequence of update -> withdrawls w/
the same as-path.

Same thing can happen w/ other attributes such as local-pref.

> One change (one down peering) can cause a very large number of
> updates downstream.  If each causes the same prefix to be penalized
> it is incorrectly suppressed.  That behaviour is considered
> "harmfull".

Indeed. btw: lets be clear. It is paths that get penalized not
prefixes. With the current behaviour one down peer only makes the
prefix unavailiable if it is close to the source where you are likely
to see same as-paths.

> Considering the AS-path eliminates this problem.  If this behavior
> is considered harmfull and we eliminate this behavior, its an
> improvement.

I don't think you have answered the objections i raise...

imho better improvement is to disable damping. Does it do anything
useful ? Empirical evidence suggests that networks are much better off
without it.

>> I'm not going to argue the definition of what is "correctly
>> implemented"...

> Implemented as per the spec.

These two statements, above and bellow seem contradictory to
me. Specially coupled with the assumption that the resource
consumption of other alternatives are outside of the scope, it seems
to me that the most reasonable approach for an implementation today is
to ignore as-path.

> Note that the spec allows the current behaviour to be offerred as a
> configured option


  Pedro.

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA24865 for <[e-mail]>; Tue, 9 Nov 2004 23:47:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRkJr-0004Yb-2y; Tue, 09 Nov 2004 23:42:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRkH8-0004Jn-Hl for [e-mail]; Tue, 09 Nov 2004 23:40:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22355 for <[e-mail]>; Tue, 9 Nov 2004 23:40:03 -0500 (EST)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRkHx-0007mV-7F for [e-mail]; Tue, 09 Nov 2004 23:41:01 -0500
Received: (qmail 59639 invoked from network); 10 Nov 2004 04:40:00 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 10 Nov 2004 04:40:00 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAA4bA5K067173; Tue, 9 Nov 2004 23:37:10 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 18:47:07 PST." <[e-mail]> 
Date: Tue, 09 Nov 2004 23:37:10 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pedro Roque Marques writes:
>  
> Curtis Villamizar writes:
>  
> > The idea is to penalize any given route/AS-path only once when it is
> > no longer being used.  If dozens of other AS paths are advertised
> > and withdrawn or replaced they get penalized only once.
>  
> > If a single event ocurs, then the desired AS-paths are penalized
> > once.
>  
> > If a single prefix keeps switching between two prefixes, both will
> > get penalized and suppressed.
>  
> In that case one must maintain multiple <key, merit, bookkeeping>
> data. You say one may be "smart" about it and drop some... which then
> gives a different behaviour. I don't think this is an actractive
> option. Undeterministic behaviour is really not something i would
> consider a feature.

Undeterministic in the event of a network disaster is not a big deal.
If you toss the entries that are oldest or with lowest metric you
won't be tossing anything that you just added and you are tossing
history for the most stable prefixes that you have any history on.
This is done across the entire set, not across a single prefix.

Anyway, this smarter allocation is outside of the scope of the
document.

> >> But those multiple paths can all share the same as-path... i've
> >> seen situations where one med change in one as (which doesn't
> >> propagate meds outbound) causes 3 flaps and the route to be
> >> dampened by its peer. This is quite nasty...
>  
> > Each flap must have a different AS path.  If nothing changed, the
> > peer doesn't advertise a change.  If the 3 flaps have 3 different AS
> > paths, then each is penalized once.
>  
> advertise -> withdrawl -> advertise -> withdrawl ...


Please give an example where one MED change results in "advertise ->
withdrawl -> advertise -> withdrawl ..." where the same AS-path is
withdrawn multiple times.


> > Please reconsider what you wrote since you had misunderstood the use
> > of the AS-path in computing the penalty.  You may no longer feel
> > that we need to "start over from first principles".
>  
> I do believe that it is necessary. It is not evident to me that the
> option you point out in the spec, of including as-path in the key,
> leads to an improvement.


One change (one down peering) can cause a very large number of updates
downstream.  If each causes the same prefix to be penalized it is
incorrectly suppressed.  That behaviour is considered "harmfull".

Considering the AS-path eliminates this problem.  If this behavior is
considered harmfull and we eliminate this behavior, its an
improvement.


> > I'd also like to remind you that this in not discussion of a change
> > in the spec, but rather a discussion of the RFC as it is currently
> > written, but not correctly implemented.
>  
> I'm not going to argue the definition of what is "correctly
> implemented"...

Implemented as per the spec.

> The only reason the internet works at all is because implementors
> ignored the parts of 1771 that proven in the field to be drawbacks
> (igp synchronization comes to mind). No disrespect to the authors of
> 1771 or to the authors of flap damping. The best we can hope for is
> for authors to write down the best idea of consensus given what is
> known at the time... but we must be able to modify those
> specifications as new data and problems exist.
>  
> You may be correct that adding as-paths to the damping key is the
> silver bullet, but i don't see it... and i think your chances of
> convinving me or other implementors would increase if you can explain
> how the proposal matches a problem definition.
>  
> regards,
>   Pedro.   

Note that the spec allows the current behaviour to be offerred as a
configured option so please get off the soapbox about implementors
ignoring the spec and doing whats right.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA23795 for <[e-mail]>; Tue, 9 Nov 2004 21:50:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRiXy-0005HB-Df; Tue, 09 Nov 2004 21:49:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRiWQ-0004yn-0C for [e-mail]; Tue, 09 Nov 2004 21:47:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13579 for <[e-mail]>; Tue, 9 Nov 2004 21:47:43 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRiXH-0005fT-Qh for [e-mail]; Tue, 09 Nov 2004 21:48:40 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id iAA2l7Pm017254; Tue, 9 Nov 2004 18:47:07 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id iAA2l7Bu017251; Tue, 9 Nov 2004 18:47:07 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 18:47:07 -0800
To: [e-mail]
Subject: Re: [Idr] Future of route flap dampening spec 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Curtis Villamizar writes:

> The idea is to penalize any given route/AS-path only once when it is
> no longer being used.  If dozens of other AS paths are advertised
> and withdrawn or replaced they get penalized only once.

> If a single event ocurs, then the desired AS-paths are penalized
> once.

> If a single prefix keeps switching between two prefixes, both will
> get penalized and suppressed.

In that case one must maintain multiple <key, merit, bookkeeping>
data. You say one may be "smart" about it and drop some... which then
gives a different behaviour. I don't think this is an actractive
option. Undeterministic behaviour is really not something i would
consider a feature.

>> But those multiple paths can all share the same as-path... i've
>> seen situations where one med change in one as (which doesn't
>> propagate meds outbound) causes 3 flaps and the route to be
>> dampened by its peer. This is quite nasty...

> Each flap must have a different AS path.  If nothing changed, the
> peer doesn't advertise a change.  If the 3 flaps have 3 different AS
> paths, then each is penalized once.

advertise -> withdrawl -> advertise -> withdrawl ...

> Please reconsider what you wrote since you had misunderstood the use
> of the AS-path in computing the penalty.  You may no longer feel
> that we need to "start over from first principles".

I do believe that it is necessary. It is not evident to me that the
option you point out in the spec, of including as-path in the key,
leads to an improvement.

> I'd also like to remind you that this in not discussion of a change
> in the spec, but rather a discussion of the RFC as it is currently
> written, but not correctly implemented.

I'm not going to argue the definition of what is "correctly
implemented"...

The only reason the internet works at all is because implementors
ignored the parts of 1771 that proven in the field to be drawbacks
(igp synchronization comes to mind). No disrespect to the authors of
1771 or to the authors of flap damping. The best we can hope for is
for authors to write down the best idea of consensus given what is
known at the time... but we must be able to modify those
specifications as new data and problems exist.

You may be correct that adding as-paths to the damping key is the
silver bullet, but i don't see it... and i think your chances of
convinving me or other implementors would increase if you can explain
how the proposal matches a problem definition.

regards,
  Pedro.   

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA23559 for <[e-mail]>; Tue, 9 Nov 2004 21:25:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRi9c-0001NZ-PJ; Tue, 09 Nov 2004 21:24:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRi8M-0000x4-VF for [e-mail]; Tue, 09 Nov 2004 21:22:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11921 for <[e-mail]>; Tue, 9 Nov 2004 21:22:52 -0500 (EST)
Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRi9E-0005ED-Fr for [e-mail]; Tue, 09 Nov 2004 21:23:48 -0500
Received: (qmail 39778 invoked from network); 10 Nov 2004 02:22:44 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay01.pair.com with SMTP; 10 Nov 2004 02:22:44 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAA2JqdG066663; Tue, 9 Nov 2004 21:19:56 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 16:57:07 PST." <[e-mail]> 
Date: Tue, 09 Nov 2004 21:19:52 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pedro Roque Marques writes:
>  
> Curtis Villamizar writes:
>  
> > There was speculation on whether the amount of memory would be too
> > great from the start.  Two things came of that.  One was to include
> > the ability to configure it off (to ignore the AS path).  The second
> > was the observation that a smart implementation could throw away
> > those entries that were the oldest in order to bound memory
> > consumption.
>  
> I would interpret that as saying that a route only gets penalized if
> it has an attribute change w/ the same as-path or if the route gets
> withdrawn and gets advertised back with the same as-path.
>  
> It changes the current model but it still penalizes events that are
> perfectly ok. So it doesn't solve the problem, imho...
>  
> The real issue is to first define what is the goal. What kind of
> events and situations are do we want to be dampen... to me the answer
> is far from clear. Once we understand that collectivly then maybe we
> can try to figure out if a given algorithm does or not meet the goal.

Your interpretation is close.

The idea is to penalize any given route/AS-path only once when it is
no longer being used.  If dozens of other AS paths are advertised and
withdrawn or replaced they get penalized only once.

If a single event ocurs, then the desired AS-paths are penalized once.

If a single prefix keeps switching between two prefixes, both will get
penalized and suppressed.  If one peering is switching between two AS
paths and another peering maintains a constant path, the constant path
will be used even if the others are otherwise more preferable.

> > The common case is where a small number of routes, less than 5% of
> > routes advertised account for the vast majority of route churn.
>  
> That observation apears to be confirmed by existing measurements.
>  
> >  An
> > uncommon case is where something very bad happenned a few hops away
> > and a very large number of prefixes cycled through a substantial set
> > of AS paths.
>  
> A path being deleted by the originator cycles through a substantial
> set of as-paths if you are observing it from a highly interconnected
> as. So i disagree with you here that this is uncommon. 

Bad word choice or insufficient context on my part.

Maybe I should replace "An uncommon case is where ..." with
"accounting for a far lesser amount of churn is the case where ...".

> >  In this case the smart implementation that had the
> > means to bound the consumption of memory would at worst toss out
> > history.
>  
> > It would avoid suppressing routes just becuase there was a large set
> > of potential paths and one path went down.
>  
> But those multiple paths can all share the same as-path... i've seen
> situations where one med change in one as (which doesn't propagate
> meds outbound) causes 3 flaps and the route to be dampened by its
> peer. This is quite nasty...

Each flap must have a different AS path.  If nothing changed, the peer
doesn't advertise a change.  If the 3 flaps have 3 different AS paths,
then each is penalized once.

> It would be nice to approach this problem from the point of view of
> trying to identify what types of events should be dampened and how to
> really distinguish them correctly from normal routing behaviour.
>  
>   Pedro.

Please reconsider what you wrote since you had misunderstood the use
of the AS-path in computing the penalty.  You may no longer feel that
we need to "start over from first principles".

I'd also like to remind you that this in not discussion of a change in
the spec, but rather a discussion of the RFC as it is currently
written, but not correctly implemented.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA22801 for <[e-mail]>; Tue, 9 Nov 2004 20:03:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRgrB-00077J-T1; Tue, 09 Nov 2004 20:01:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRgo3-0006ry-Ey for [e-mail]; Tue, 09 Nov 2004 19:57:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04911 for <[e-mail]>; Tue, 9 Nov 2004 19:57:49 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRgot-0003Qs-DQ for [e-mail]; Tue, 09 Nov 2004 19:58:44 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id iAA0vCPm017046; Tue, 9 Nov 2004 16:57:12 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id iAA0v7jD017043; Tue, 9 Nov 2004 16:57:08 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 16:57:07 -0800
To: [e-mail]
Subject: Re: [Idr] Future of route flap dampening spec 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Curtis Villamizar writes:

> There was speculation on whether the amount of memory would be too
> great from the start.  Two things came of that.  One was to include
> the ability to configure it off (to ignore the AS path).  The second
> was the observation that a smart implementation could throw away
> those entries that were the oldest in order to bound memory
> consumption.

I would interpret that as saying that a route only gets penalized if
it has an attribute change w/ the same as-path or if the route gets
withdrawn and gets advertised back with the same as-path.

It changes the current model but it still penalizes events that are
perfectly ok. So it doesn't solve the problem, imho...

The real issue is to first define what is the goal. What kind of
events and situations are do we want to be dampen... to me the answer
is far from clear. Once we understand that collectivly then maybe we
can try to figure out if a given algorithm does or not meet the goal.

> The common case is where a small number of routes, less than 5% of
> routes advertised account for the vast majority of route churn.

That observation apears to be confirmed by existing measurements.

>  An
> uncommon case is where something very bad happenned a few hops away
> and a very large number of prefixes cycled through a substantial set
> of AS paths.

A path being deleted by the originator cycles through a substantial
set of as-paths if you are observing it from a highly interconnected
as. So i disagree with you here that this is uncommon. 

>  In this case the smart implementation that had the
> means to bound the consumption of memory would at worst toss out
> history.

> It would avoid suppressing routes just becuase there was a large set
> of potential paths and one path went down.

But those multiple paths can all share the same as-path... i've seen
situations where one med change in one as (which doesn't propagate
meds outbound) causes 3 flaps and the route to be dampened by its
peer. This is quite nasty...

It would be nice to approach this problem from the point of view of
trying to identify what types of events should be dampened and how to
really distinguish them correctly from normal routing behaviour.

  Pedro. 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA21788 for <[e-mail]>; Tue, 9 Nov 2004 18:11:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRf6i-00037b-OH; Tue, 09 Nov 2004 18:09:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRf2u-0001iR-CI for [e-mail]; Tue, 09 Nov 2004 18:05:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24983 for <[e-mail]>; Tue, 9 Nov 2004 18:05:01 -0500 (EST)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRf3g-0001Ac-3w for [e-mail]; Tue, 09 Nov 2004 18:05:53 -0500
Received: (qmail 28157 invoked from network); 9 Nov 2004 23:04:57 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 9 Nov 2004 23:04:57 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iA9N2AHw065921; Tue, 9 Nov 2004 18:02:10 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 14:19:00 PST." <[e-mail]> 
Date: Tue, 09 Nov 2004 18:02:10 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pedro Roque Marques writes:
>  
> Curtis Villamizar writes:
>  
> > The major deviation from the spec in all of the implementations that
> > I am aware of is failure to implement the following as per spec:
>  
> I don't see how adding the as-path to the key fixes the problem...
>  
> While BGP is reconverging it may just as well change state a few
> times maintaining as-path... example neighoring as is using MEDs and
> has a big mesh: second best med election may cause the route to go up
> and down in rapid succession.
>  
> It also seems to me that adding it may create a much much worse
> problem; that would mean maintaining history for a large number of
> as-path combinations that a prefix may experience when being deleted.
>  
> It seems a non-starter...
>  
>   Pedro.


There was speculation on whether the amount of memory would be too
great from the start.  Two things came of that.  One was to include
the ability to configure it off (to ignore the AS path).  The second
was the observation that a smart implementation could throw away 
those entries that were the oldest in order to bound memory
consumption.

The common case is where a small number of routes, less than 5% of
routes advertised account for the vast majority of route churn.  An
uncommon case is where something very bad happenned a few hops away
and a very large number of prefixes cycled through a substantial set
of AS paths.  In this case the smart implementation that had the means
to bound the consumption of memory would at worst toss out history.

It would avoid suppressing routes just becuase there was a large set
of potential paths and one path went down.

Quite a lot of information is stored with BGP routes already.  AS path
usually effectively incurs 4 bytes per route because it is a pointer
to an AS path struct that is shared by many routes.  Each history
struct would be key size (prefix and AS path) plus figure-of-merit,
time-update, config block pointer, reuse list traversal pointers (2).
Seems like 28 bytes per history entry.

Curtis


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21536 for <[e-mail]>; Tue, 9 Nov 2004 17:45:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReZx-0003K6-DK; Tue, 09 Nov 2004 17:35:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReL4-00085y-QK for [e-mail]; Tue, 09 Nov 2004 17:19:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20499 for <[e-mail]>; Tue, 9 Nov 2004 17:19:44 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReLt-0008Tq-EU for [e-mail]; Tue, 09 Nov 2004 17:20:38 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id iA9MJ0Pm016788; Tue, 9 Nov 2004 14:19:00 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id iA9MJ0ZA016785; Tue, 9 Nov 2004 14:19:00 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 14:19:00 -0800
To: [e-mail]
Subject: Re: [Idr] Future of route flap dampening spec 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Curtis Villamizar writes:

> The major deviation from the spec in all of the implementations that
> I am aware of is failure to implement the following as per spec:

I don't see how adding the as-path to the key fixes the problem...

While BGP is reconverging it may just as well change state a few
times maintaining as-path... example neighoring as is using MEDs and
has a big mesh: second best med election may cause the route to go up
and down in rapid succession.

It also seems to me that adding it may create a much much worse
problem; that would mean maintaining history for a large number of
as-path combinations that a prefix may experience when being deleted.

It seems a non-starter...

  Pedro.

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21453 for <[e-mail]>; Tue, 9 Nov 2004 17:35:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReIN-0007ee-Dv; Tue, 09 Nov 2004 17:16:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReDu-0006nK-CN for [e-mail]; Tue, 09 Nov 2004 17:12:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19833 for <[e-mail]>; Tue, 9 Nov 2004 17:12:19 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReEi-0008Ia-Pa for [e-mail]; Tue, 09 Nov 2004 17:13:14 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C04CF2D4846; Tue,  9 Nov 2004 17:11:49 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41772-06-30; Tue,  9 Nov 2004 17:11:48 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 84E6E2D4816; Tue,  9 Nov 2004 17:11:48 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id iA9MBmg03445; Tue, 9 Nov 2004 17:11:48 -0500 (EST)
Date: Tue, 9 Nov 2004 17:11:48 -0500
From: Jeffrey Haas <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: [e-mail], Pekka Savola <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Tue, Nov 09, 2004 at 04:47:01PM -0500, Curtis Villamizar wrote:
> Ideally the IGP would
> hold down an adjacency that bounced a lot (the rfc does mention that
> even though it primarily addresses BGP).

I believe at a previous NANOG, Cengiz (for Packet Design) presented
a study of IGP convergence issues.

I don't recall a lot of that presentation, but I believe one bit
of speculation was that applying route damping to flapping LSAs
was a potentially sane way to deal with that particular problem space.

> Curtis

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA20983 for <[e-mail]>; Tue, 9 Nov 2004 17:03:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdy5-0003Rd-L9; Tue, 09 Nov 2004 16:56:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRds5-0001cN-QF for [e-mail]; Tue, 09 Nov 2004 16:49:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17254 for <[e-mail]>; Tue, 9 Nov 2004 16:49:47 -0500 (EST)
Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRdsu-0007fj-7k for [e-mail]; Tue, 09 Nov 2004 16:50:41 -0500
Received: (qmail 81536 invoked from network); 9 Nov 2004 21:49:47 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay01.pair.com with SMTP; 9 Nov 2004 21:49:47 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iA9Ll1r7065597; Tue, 9 Nov 2004 16:47:01 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 22:58:04 +0200." <[e-mail]> 
Date: Tue, 09 Nov 2004 16:47:01 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pekka Savola writes:
>  
> On Tue, 9 Nov 2004, Curtis Villamizar wrote:
> > No one seems to want to damp their own customers and exend an outage.
> > OTOH if someone else has a route that can't keep stable they'd rather
> > eliminate it.
>  
> Think about a problem in the link, which is causing problems.  This is 
> only applicable to those customers which are multihomed, and hence no 
> outage should occur unless I'm missing something..


In the better providers single homed customers are static routed on
the last hop specificly so that the route is never withdrawn.  The
problem is when the customer is multihomed to another provider.  If
the link is intermittent, then the provider instead of holding it down
will bring it back up and announce it as soon as it appears feasible
again.  There may be no BGP to the customer.  If there is, then it
isn't damped.  That's just what providers do.  Ideally the IGP would
hold down an adjacency that bounced a lot (the rfc does mention that
even though it primarily addresses BGP).

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA18044 for <[e-mail]>; Tue, 9 Nov 2004 16:02:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRd6s-00013x-58; Tue, 09 Nov 2004 16:01:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRd4f-0008W9-1D for [e-mail]; Tue, 09 Nov 2004 15:58:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12178 for <[e-mail]>; Tue, 9 Nov 2004 15:58:42 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRd5Q-0006Ip-Aw for [e-mail]; Tue, 09 Nov 2004 15:59:36 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9Kw4G27907; Tue, 9 Nov 2004 22:58:04 +0200
Date: Tue, 9 Nov 2004 22:58:04 +0200 (EET)
From: Pekka Savola <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Tue, 9 Nov 2004, Curtis Villamizar wrote:
> No one seems to want to damp their own customers and exend an outage.
> OTOH if someone else has a route that can't keep stable they'd rather
> eliminate it.

Think about a problem in the link, which is causing problems.  This is 
only applicable to those customers which are multihomed, and hence no 
outage should occur unless I'm missing something..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17999 for <[e-mail]>; Tue, 9 Nov 2004 15:57:11 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRd1W-0006yV-Fn; Tue, 09 Nov 2004 15:55:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcwm-0004gK-VG for [e-mail]; Tue, 09 Nov 2004 15:50:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11633 for <[e-mail]>; Tue, 9 Nov 2004 15:50:34 -0500 (EST)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRcxa-00069w-Oo for [e-mail]; Tue, 09 Nov 2004 15:51:28 -0500
Received: (qmail 3813 invoked from network); 9 Nov 2004 20:50:30 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 9 Nov 2004 20:50:30 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iA9Kliim065226; Tue, 9 Nov 2004 15:47:44 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Dorian Kim <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 15:21:31 EST." <[e-mail]> 
Date: Tue, 09 Nov 2004 15:47:44 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Dorian Kim writes:
>  
> On Tue, Nov 09, 2004 at 03:04:18PM -0500, Curtis Villamizar wrote:
> > In message <[e-mail]>
> > Dorian Kim writes:
> > >  
> > > On Tue, Nov 09, 2004 at 02:19:28PM -0500, Curtis Villamizar wrote:
> > > > I don't know what percentage of providers have opted to just turn of
> > > > damping and what percentage still have it enabled.  Providers continue
> > > > to ask that this feature be implemented.
> > >  
> > > [note, annectdotal evidence only]
> > >  
> > > It seems like most large providers have shifted away from dampening their
> > > customer prefixen and are only dampening their peers at this point.
> > >  
> > > -dorian
> > 
> > That means that it is in use.  Which means it would be premature to
> > move it to historic.
> > 
> > I do agree that route flap damping **as currently implemented** (in
> > violation of the spec), is harmful.  I'd rather we fixed the
> > implementations but that would require pressure from providers on
> > their vendors to make the fix.  Fixing the known problem in the spec
> > itself wouldn't be a bad idea either (yes - I know - I should be doing
> > that).
>  
> I think there's a third consideration here.
>  
> Even with fixed spec and fixed implementations, is flap dampening
> necessary in today's Internet? Things have changed considerably since
> the days when most routers were based on woefully underpowered 68K
> processors.

The point was always that route flap damping gave the option to get
rid of route announcements that just keep going up and down all day.
Continuous heavy flap can slow BGP convergence when a real change
occurs (not that BGP has ever been know to converge quickly).

Some providers still see a need to do this.

> As you say, the current state is pretty harmful.
>  
> I'm not sure if we've gone beyond needing flap dampening, but it seems
> like we could live without it currently.

I don't want to make a value judgement on this but its in use.  I do
think it could be useful and not harmful if implemented as per spec.

> This is probably a bit short sighted perspective, but given the
> current state of things, and the fact that it's getting to be
> non-trivial to get vendors fix their implementations, I do wonder if
> it's better to just declare victory and move on..
>  
> -dorian

There are people who could force the issue at providers for any of the
given major vendors.  I just don't happen to be one of them (the
people at a provider that can force the issue).

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17844 for <[e-mail]>; Tue, 9 Nov 2004 15:37:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcig-0005ve-Az; Tue, 09 Nov 2004 15:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcfk-0004Le-GR for [e-mail]; Tue, 09 Nov 2004 15:33:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10254 for <[e-mail]>; Tue, 9 Nov 2004 15:32:58 -0500 (EST)
Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRcgY-0005lp-4b for [e-mail]; Tue, 09 Nov 2004 15:33:51 -0500
Received: from petal.blackrose.org (localhost [127.0.0.1]) by petal.blackrose.org (8.12.11/8.12.4) with ESMTP id iA9KLWLL023106; Tue, 9 Nov 2004 15:21:32 -0500
Received: (from dorian@localhost) by petal.blackrose.org (8.12.11/8.12.11/Submit) id iA9KLVT0023104; Tue, 9 Nov 2004 15:21:31 -0500
Date: Tue, 9 Nov 2004 15:21:31 -0500
From: Dorian Kim <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Tue, Nov 09, 2004 at 03:04:18PM -0500, Curtis Villamizar wrote:
> In message <[e-mail]>
> Dorian Kim writes:
> >  
> > On Tue, Nov 09, 2004 at 02:19:28PM -0500, Curtis Villamizar wrote:
> > > I don't know what percentage of providers have opted to just turn of
> > > damping and what percentage still have it enabled.  Providers continue
> > > to ask that this feature be implemented.
> >  
> > [note, annectdotal evidence only]
> >  
> > It seems like most large providers have shifted away from dampening their
> > customer prefixen and are only dampening their peers at this point.
> >  
> > -dorian
> 
> That means that it is in use.  Which means it would be premature to
> move it to historic.
> 
> I do agree that route flap damping **as currently implemented** (in
> violation of the spec), is harmful.  I'd rather we fixed the
> implementations but that would require pressure from providers on
> their vendors to make the fix.  Fixing the known problem in the spec
> itself wouldn't be a bad idea either (yes - I know - I should be doing
> that).

I think there's a third consideration here.

Even with fixed spec and fixed implementations, is flap dampening necessary
in today's Internet? Things have changed considerably since the days when
most routers were based on woefully underpowered 68K processors. 

As you say, the current state is pretty harmful.

I'm not sure if we've gone beyond needing flap dampening, but it seems 
like we could live without it currently.

This is probably a bit short sighted perspective, but given the current state of 
things, and the fact that it's getting to be non-trivial to get vendors fix their 
implementations, I do wonder if it's better to just declare victory and move on..

-dorian

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17735 for <[e-mail]>; Tue, 9 Nov 2004 15:28:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcZc-0001FR-Sx; Tue, 09 Nov 2004 15:26:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcPd-00036j-3m for [e-mail]; Tue, 09 Nov 2004 15:16:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08479 for <[e-mail]>; Tue, 9 Nov 2004 15:16:19 -0500 (EST)
Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRcQR-0005PX-LD for [e-mail]; Tue, 09 Nov 2004 15:17:11 -0500
Received: (qmail 56050 invoked from network); 9 Nov 2004 20:16:19 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay01.pair.com with SMTP; 9 Nov 2004 20:16:19 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iA9KDYuC065018; Tue, 9 Nov 2004 15:13:34 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 21:40:51 +0200." <[e-mail]> 
Date: Tue, 09 Nov 2004 15:13:33 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pekka Savola writes:
>  
> In a slightly different order,
>  
> On Tue, 9 Nov 2004, Curtis Villamizar wrote:
>  
> > I don't know what percentage of providers have opted to just turn of
> > damping and what percentage still have it enabled.  Providers continue
> > to ask that this feature be implemented.
>  
> I think it's important to notice that different kinds of providers 
> likely have entirely different perspective to the need for damping and 
> where it should be applied (Tier-1 transit, smaller transit, edge ISP, 
> ...).
>  
> In the ideal case, I'd guess folks think that the 1st hop ISPs should 
> be doing flap dampening, but doing so further upstream may not make 
> sense (especially if the 1st hop ISPs would do the dampening :).


No one seems to want to damp their own customers and exend an outage.
OTOH if someone else has a route that can't keep stable they'd rather
eliminate it.

The original motivation for Route Flap Damping was massive instability
coming from parts of the Internet, some quite distant, in the 1993
time frame.  Some of the problem was sloppy circuits (lossy,
unreliable) and part was due to router problems in those days.  

Some of that (poor network administration) still goes on.  I don't
know if we still have any blocks of routes that withdraw and
readvertise 1,500 a day like we did in the old days.


> >  Why does this happen?
> >  ...
> >  Route flap damping parameter setting
> >      - Cisco/Juniper punishes virtually all route changes
> >
> > Anyone have an idea as to how to reflect that in the spec?  Should I
> > add a section describing known non-compliant implementations.
>  
> Further than that, Juniper penalizes both advertisement/withdrawal, 
> penalizing by default just after 1.5 flaps instead of 3.  That's not 
> good.
>  
> This particular incompliance could be made more explicit by:
>  
> In 4.8.3, "Processing Route Advertisements",
>  
> OLD:
>     If an damping structure exists, the figure of merit is decayed and
>     the figure of merit and last time updated fields are updated.  A
>     decision is now made as to whether the route can be used immediately
>     or needs to be suppressed for some period of time.
>  
> NEW:
>     If an damping structure exists, the figure of merit is decayed and
>     the last time updated field is updated; figure of merit doesn't increase.
>     A decision is now made as to whether the route can be used immediately
>     or needs to be suppressed for some period of time.


Very good suggestion.


> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17722 for <[e-mail]>; Tue, 9 Nov 2004 15:26:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcMR-0001e9-Lr; Tue, 09 Nov 2004 15:13:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcGg-0006Hv-AV for [e-mail]; Tue, 09 Nov 2004 15:07:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07064 for <[e-mail]>; Tue, 9 Nov 2004 15:07:04 -0500 (EST)
Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRcHT-0005Bh-P2 for [e-mail]; Tue, 09 Nov 2004 15:07:57 -0500
Received: (qmail 46923 invoked from network); 9 Nov 2004 20:07:04 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay02.pair.com with SMTP; 9 Nov 2004 20:07:04 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iA9K4IwW064971; Tue, 9 Nov 2004 15:04:18 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Dorian Kim <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 14:26:16 EST." <[e-mail]> 
Date: Tue, 09 Nov 2004 15:04:18 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Dorian Kim writes:
>  
> On Tue, Nov 09, 2004 at 02:19:28PM -0500, Curtis Villamizar wrote:
> > I don't know what percentage of providers have opted to just turn of
> > damping and what percentage still have it enabled.  Providers continue
> > to ask that this feature be implemented.
>  
> [note, annectdotal evidence only]
>  
> It seems like most large providers have shifted away from dampening their
> customer prefixen and are only dampening their peers at this point.
>  
> -dorian


That means that it is in use.  Which means it would be premature to
move it to historic.

I do agree that route flap damping **as currently implemented** (in
violation of the spec), is harmful.  I'd rather we fixed the
implementations but that would require pressure from providers on
their vendors to make the fix.  Fixing the known problem in the spec
itself wouldn't be a bad idea either (yes - I know - I should be doing
that).

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA17324 for <[e-mail]>; Tue, 9 Nov 2004 14:51:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbvT-0004vk-6e; Tue, 09 Nov 2004 14:45:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbrt-0004CU-6b for [e-mail]; Tue, 09 Nov 2004 14:41:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04659 for <[e-mail]>; Tue, 9 Nov 2004 14:41:27 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbsf-0004Yz-Qq for [e-mail]; Tue, 09 Nov 2004 14:42:19 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9JepG26057; Tue, 9 Nov 2004 21:40:52 +0200
Date: Tue, 9 Nov 2004 21:40:51 +0200 (EET)
From: Pekka Savola <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In a slightly different order,

On Tue, 9 Nov 2004, Curtis Villamizar wrote:

> I don't know what percentage of providers have opted to just turn of
> damping and what percentage still have it enabled.  Providers continue
> to ask that this feature be implemented.

I think it's important to notice that different kinds of providers 
likely have entirely different perspective to the need for damping and 
where it should be applied (Tier-1 transit, smaller transit, edge ISP, 
...).

In the ideal case, I'd guess folks think that the 1st hop ISPs should 
be doing flap dampening, but doing so further upstream may not make 
sense (especially if the 1st hop ISPs would do the dampening :).

>  Why does this happen?
>  ...
>  Route flap damping parameter setting
>      - Cisco/Juniper punishes virtually all route changes
>
> Anyone have an idea as to how to reflect that in the spec?  Should I
> add a section describing known non-compliant implementations.

Further than that, Juniper penalizes both advertisement/withdrawal, 
penalizing by default just after 1.5 flaps instead of 3.  That's not 
good.

This particular incompliance could be made more explicit by:

In 4.8.3, "Processing Route Advertisements",

OLD:
    If an damping structure exists, the figure of merit is decayed and
    the figure of merit and last time updated fields are updated.  A
    decision is now made as to whether the route can be used immediately
    or needs to be suppressed for some period of time.

NEW:
    If an damping structure exists, the figure of merit is decayed and
    the last time updated field is updated; figure of merit doesn't increase.
    A decision is now made as to whether the route can be used immediately
    or needs to be suppressed for some period of time.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA17232 for <[e-mail]>; Tue, 9 Nov 2004 14:43:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbrV-0004Ae-Ff; Tue, 09 Nov 2004 14:41:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRboG-0003cK-TF for [e-mail]; Tue, 09 Nov 2004 14:37:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04350 for <[e-mail]>; Tue, 9 Nov 2004 14:37:43 -0500 (EST)
Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbp4-0004Ux-0V for [e-mail]; Tue, 09 Nov 2004 14:38:35 -0500
Received: from petal.blackrose.org (localhost [127.0.0.1]) by petal.blackrose.org (8.12.11/8.12.4) with ESMTP id iA9JQGGb021988; Tue, 9 Nov 2004 14:26:16 -0500
Received: (from dorian@localhost) by petal.blackrose.org (8.12.11/8.12.11/Submit) id iA9JQGxp021987; Tue, 9 Nov 2004 14:26:16 -0500
Date: Tue, 9 Nov 2004 14:26:16 -0500
From: Dorian Kim <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Tue, Nov 09, 2004 at 02:19:28PM -0500, Curtis Villamizar wrote:
> I don't know what percentage of providers have opted to just turn of
> damping and what percentage still have it enabled.  Providers continue
> to ask that this feature be implemented.

[note, annectdotal evidence only]

It seems like most large providers have shifted away from dampening their
customer prefixen and are only dampening their peers at this point.

-dorian

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA17116 for <[e-mail]>; Tue, 9 Nov 2004 14:30:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbdE-0002Gc-Mj; Tue, 09 Nov 2004 14:26:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbZJ-0001i1-4r for [e-mail]; Tue, 09 Nov 2004 14:22:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03078 for <[e-mail]>; Tue, 9 Nov 2004 14:22:15 -0500 (EST)
Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRba7-0004Ba-4l for [e-mail]; Tue, 09 Nov 2004 14:23:07 -0500
Received: (qmail 34509 invoked from network); 9 Nov 2004 19:22:14 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay02.pair.com with SMTP; 9 Nov 2004 19:22:14 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iA9JJSue064596; Tue, 9 Nov 2004 14:19:29 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec 
In-reply-to: Your message of "Tue, 09 Nov 2004 19:57:04 +0200." <[e-mail]> 
Date: Tue, 09 Nov 2004 14:19:28 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pekka Savola writes:
>  
> Hi,
>  
> Just a bit of food for thought: is there something we want to do with 
> the route flap dampening spec?  Move to DS, deprecate, spin in place, 
> ...?
>  
> Apparently there is at least one implementation claiming to be 
> compliant to the spec while penalizing both at the withdraws and 
> re-advertisements.  That's one thing at least that might warrant 
> clarification; there may be other issues which may call for 
> clarification.
>  
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


The major deviation from the spec in all of the implementations that I
am aware of is failure to implement the following as per spec:

  4.4.3 Per Route State

   Information must be maintained per some tuple representing a route.
   At the very minimum, the NLRI (BGP prefix and length) must be
   contained in the tuple.  Different BGP attributes may be included or
   excluded depending on the specific situation.  The AS path should
   also be contained in the tuple by default.  The tuple may also
   optionally contain other BGP attributes such as
   MULTI_EXIT_DISCRIMINATOR (MED).

   The tuple representing a route for the purpose of route flap damping
   is:

      tuple entry            default      options
      -------------------------------------------
      NLRI
        prefix               required
        length               required
      AS path                included     option to exclude
      last AS set in path    excluded     option to include
      next hop               excluded     option to include
      MED                    excluded     option to include
                                          in comparisons only

   The AS path is generally included in order to identify downstream
   instability which is not being damped or not being sufficiently
   damped and is alternating between a stable and an unstable path.
   Under rare circumstances it may be desirable to exclude AS path for
   all or a subset of prefixes.  If an AS path ends in an AS set, in
   practice the path is always for an aggregate.  Changes to the
   trailing AS set should be ignored.  Ideally the AS path comparison
   should insure that at least one AS has remained constant in the old
   and new AS set, but completely ignoring the contents of a trailing AS
   set is also acceptable.

The AS path should be included in the comparison by default.  Current
implementations do not even support using AS Path as part of the key.

This results in the type of behavior complained about in "Route Flap
Damping: Harmful?" <http://www.nanog.org/mtg-0210/flap.html>.  The
slides there say:

  Why does this happen?
  ...
  Route flap damping parameter setting
      - Cisco/Juniper punishes virtually all route changes

Anyone have an idea as to how to reflect that in the spec?  Should I
add a section describing known non-compliant implementations.

Note that over the years a few people have sent corrections to the RFC
which I haven't bothered to make.  In some cases what is written in
the RFC is wrong in some fine details but implementers have coped with
it just fine.  The failure to include AS Path is the major shortcoming
of existing implementations and causes operational problems.

I don't know what percentage of providers have opted to just turn of
damping and what percentage still have it enabled.  Providers continue
to ask that this feature be implemented.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16986 for <[e-mail]>; Tue, 9 Nov 2004 14:17:08 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbR7-0008FA-ME; Tue, 09 Nov 2004 14:13:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbKK-0006rJ-Qf for [e-mail]; Tue, 09 Nov 2004 14:06:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01745 for <[e-mail]>; Tue, 9 Nov 2004 14:06:47 -0500 (EST)
Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbL7-0003rU-IK for [e-mail]; Tue, 09 Nov 2004 14:07:38 -0500
Received: from petal.blackrose.org (localhost [127.0.0.1]) by petal.blackrose.org (8.12.11/8.12.4) with ESMTP id iA9ItG7V021328; Tue, 9 Nov 2004 13:55:16 -0500
Received: (from dorian@localhost) by petal.blackrose.org (8.12.11/8.12.11/Submit) id iA9ItG9K021327; Tue, 9 Nov 2004 13:55:16 -0500
Date: Tue, 9 Nov 2004 13:55:16 -0500
From: Dorian Kim <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Future of route flap dampening spec
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: [e-mail], Pekka Savola <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Tue, Nov 09, 2004 at 10:47:13AM -0800, Pedro Roque Marques wrote:
> Pekka Savola writes:
> 
> > Hi, Just a bit of food for thought: is there something we want to do
> > with the route flap dampening spec?
> 
> Move to historic and publish "flap damping considered harmful" RFC.

Agreed on moving it to historical.

It's served its purpose.

-dorian

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16858 for <[e-mail]>; Tue, 9 Nov 2004 14:01:55 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbAG-0005F8-SC; Tue, 09 Nov 2004 13:56:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRb1w-0002ut-DH for [e-mail]; Tue, 09 Nov 2004 13:47:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29478 for <[e-mail]>; Tue, 9 Nov 2004 13:47:46 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRb2h-0003Es-40 for [e-mail]; Tue, 09 Nov 2004 13:48:38 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id iA9IlDPm016450; Tue, 9 Nov 2004 10:47:13 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id iA9IlDpM016447; Tue, 9 Nov 2004 10:47:13 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 10:47:13 -0800
To: Pekka Savola <[e-mail]>
Subject: [Idr] Future of route flap dampening spec
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Pekka Savola writes:

> Hi, Just a bit of food for thought: is there something we want to do
> with the route flap dampening spec?

Move to historic and publish "flap damping considered harmful" RFC.

  Pedro.

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA16416 for <[e-mail]>; Tue, 9 Nov 2004 13:04:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRaKq-0002tC-Dz; Tue, 09 Nov 2004 13:03:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRaFO-0001yy-61 for [e-mail]; Tue, 09 Nov 2004 12:57:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25401 for <[e-mail]>; Tue, 9 Nov 2004 12:57:34 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRaGA-00029R-TF for [e-mail]; Tue, 09 Nov 2004 12:58:27 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9Hv4822829 for <[e-mail]>; Tue, 9 Nov 2004 19:57:05 +0200
Date: Tue, 9 Nov 2004 19:57:04 +0200 (EET)
From: Pekka Savola <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [Idr] Future of route flap dampening spec
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi,

Just a bit of food for thought: is there something we want to do with 
the route flap dampening spec?  Move to DS, deprecate, spin in place, 
...?

Apparently there is at least one implementation claiming to be 
compliant to the spec while penalizing both at the withdraws and 
re-advertisements.  That's one thing at least that might warrant 
clarification; there may be other issues which may call for 
clarification.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA18109 for <[e-mail]>; Sun, 7 Nov 2004 19:43:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxa7-0003u5-KU; Sun, 07 Nov 2004 19:40:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxUJ-0002nV-0k for [e-mail]; Sun, 07 Nov 2004 19:34:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15162 for <[e-mail]>; Sun, 7 Nov 2004 19:34:22 -0500 (EST)
Received: from s-utl01-dcpop.stsn.com ([63.240.218.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQxUi-0000gS-EL for [e-mail]; Sun, 07 Nov 2004 19:34:53 -0500
Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110719341908337 for <[e-mail]>; Sun, 07 Nov 2004 19:34:19 -0500
Received: from skhtemp ([10.67.87.106]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 7 Nov 2004 19:34:19 -0500
Message-ID: <001401c4c52a$b12903d0$[e-mail]>
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Date: Sun, 7 Nov 2004 19:34:16 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-OriginalArrivalTime: 08 Nov 2004 00:34:19.0688 (UTC) FILETIME=[AF7F7280:01C4C52A]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: "Bose, Pratik" <[e-mail]>
Subject: [Idr] May I have a 10 minute slot
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1402614172=="
Sender: [e-mail]
Errors-To: [e-mail]

This is a multi-part message in MIME format.

--===============1402614172==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C4C500.C47C7860"

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C4C500.C47C7860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Yakov:

May I have a 10 minute slot  to discuss this
draft on AS Confederation Edges.

    =
http://ndzh.com/idr/Drafts/draft-ietf-hares-Bose-ASConfed-Edge-00.txt

Perhaps we have time.

Sue Hares

(not as the working group chair)
------=_NextPart_000_000F_01C4C500.C47C7860
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yakov:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>May I have a 10 minute slot&nbsp; to =
discuss=20
this</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>draft on AS Confederation =
Edges.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; <A=20
href=3D"http://ndzh.com/idr/Drafts/draft-ietf-hares-Bose-ASConfed-Edge-00=
.txt">http://ndzh.com/idr/Drafts/draft-ietf-hares-Bose-ASConfed-Edge-00.t=
xt</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Perhaps we have time.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sue Hares</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>(not as the working group=20
chair)</FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C4C500.C47C7860--



--===============1402614172==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--===============1402614172==--




Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA07707 for <[e-mail]>; Sun, 7 Nov 2004 03:34:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQiTi-0003jr-NF; Sun, 07 Nov 2004 03:32:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQiSg-0003Ym-Vd for [e-mail]; Sun, 07 Nov 2004 03:31:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02351 for <[e-mail]>; Sun, 7 Nov 2004 03:31:44 -0500 (EST)
Received: from [216.37.114.8] (helo=lxmail.xebeo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQiSn-00023h-MG for [e-mail]; Sun, 07 Nov 2004 03:32:05 -0500
Received: (qmail 15794 invoked from network); 7 Nov 2004 08:30:52 -0000
Received: from unknown (HELO xebeo.com) (172.16.104.130) by lxmail.nj.us.utstar.com with SMTP; 7 Nov 2004 08:30:52 -0000
Message-ID: <[e-mail]>
Date: Sun, 07 Nov 2004 10:31:14 +0100
From: Tony Przygienda <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact tie-breaking rules
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Enke Chen wrote:

> Hi, Tony:
>
> In general these rules are necessary for route reflection to function 
> properly,
> and they have been widely deployed for at least 6 or 7 years.
>
Hey Enke, that I know and my point was not that 'it does not work', it
was rather request for clarficiation of the spec to reflect reality better,
especially for ECMP ;-)

>
>
> Please see my comments inline.
>
> >     * To: idr at ietf.org
> >     * Subject: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact 
> tie-breaking rules
> >     * From: Tony Przygienda <prz at xebeo.com>
> >     * Date: Tue, 19 Oct 2004 09:55:24 +0200
> >
> > Reading through bis of the RR draft stumbled over
> >
> >
> > 9. Impact on Route Selection
> >
> >
> >   The BGP Decision Process Tie Breaking rules (Sect. 9.1.2.2, [1]) are
> >   modified as follows:
> >
> >
> >     If a route carries the ORIGINATOR_ID attribute, then in Step f)
> >     the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of
> >     the BGP speaker that has advertised the route.
> >
>
> This requirement probably should be a MUST.  Route selection for IBGP 
> paths
> must be consistent to avoid forwarding loops.  Thus, routers within an 
> AS must
> have a consistent view with respect to the BGP Identifier of the 
> router that
> sources the route in the AS. (BGP Identifier impacts route selection.)
>
> Forwarding loop can occur if RR is used in a network and some routers 
> do not
> follow this rule.
>
agreed. A sentence explaining what can or cannot happen if you have routers
that do not understand ORIGINATOR_ID and therefore don't follow this rule
would improve the spec IMHO.

>
>
> >
> >     In addition, the following rule SHOULD be inserted between Steps
> >     f) and g): a BGP Speaker SHOULD prefer a route with the shorter
> >     CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route
> >     does not carry the CLUSTER_LIST attribute.
>
> When the redundent RRs within a cluster are not configured with the 
> same cluster-id,
> a RR may receive a route from its client directly, and from the other 
> RR. With the
> right combinations of peering addresses, without this rule a RR may 
> select the one
> from the other RR as the best path (and then withdraw its own 
> advertisement), and
> routing may not converge. The rule is necessary to deal with this 
> corner case.
>
> As long as routing converges, forwarding loops wouldn't form even if some
> routers do not follow this rule. (The routes being compared are of the 
> same
> BGP Identifier, and thus the same next-hop anyway.)
>
yes, agreed of course.

>
>
> >
> > Now, the question comes up what to do with ECMP (which in many 
> implementations
> > slightly deviates from 'official' spec last I checked) especially 
> with connection
> > to the 'SHOULD'
>
> I am not aware of the existence of the "offical" spec for IBGP ECMP. 
> (Well I
> hacked up the limited support for IBGP ECMP several years ago, and 
> that seemed
> to have propagated ... :-(
>
> The first rule is important regardless of IBGP ECMP. The 2nd rule does 
> not seem
> to have any bearing on IBGP ECMP.
>

>
>
> >
> > Many implementations ignore the router_id for ECMP purposes & 
> load-balance
> > that way and it is interesting now to think whether we can still do 
> that when
> >
> > a) one route has an ORIGINATOR_ID and the other none
> > b) one route has an ORIGINATOR_ID_1 != ROUTER_ID_1 and 
> ORIGINATOR_ID_1 != ORIGINATOR_ID_2
> >     BUT ROUTER_ID_1 == ORIGINATOR_ID_2 [I admit, pathological but 
> possible]
> >
> > and so on.
> >
> >
> > Are we sure a mix of implementations old-style (ignoring the SHOULD) 
> and implementations
> > of new-style (take ORIGINATOR_ID always [or only sometimes] as 
> ROUTER_ID) will not form
> > loops with ECMP implementations ?
> >
> > The whole thing looks like another partial order in BGP route 
> ordering (the first infamous
> > one lead to quite a couple of med-this and med-other ... options in 
> many vendors) and I
> > wonder whether there is enough reason to do the same here.
> >
> > Same for CLUSTER_LIST length (albeit here I understand the scenario 
> that led to the
> > rule & it makes sense).
> >
>
ok, if the official stance is still 'there is no BGP ECMP spec' then 
we're in sync I guess
since my questoin implicitly cannot be asked ;-)

    thanks much, Enke

       -- tony


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr