headers
The IESG | 2 Jul 23:28
Picon
Favicon

Protocol Action: 'Avoid BGP Best Path Transitions from One External to Another' to Proposed Standard

The IESG has approved the following document:

- 'Avoid BGP Best Path Transitions from One External to Another '
   <draft-ietf-idr-avoid-transition-05.txt> as a Proposed Standard

This document is the product of the Inter-Domain Routing Working Group. 

The IESG contact persons are Dave Ward and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-05.txt

Technical Summary

   This document describes a revision to the BGP route selection
   rules that would avoid unnecessary best path transitions between
   external paths under certain conditions. The proposed revision would
   help the overall network stability, and more importantly, would
   eliminate certain BGP route oscillations in which more than one
   external paths from one BGP speaker contribute to the churn.

Working Group Summary

  The WG had consensus to advance this document.

Protocol Quality

  Bill Fenner reviewed this document for the IESG.
  The implementation report is available at
  http://www.ietf.org/IESG/Implementations/implem_EBGP.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Jakma | 9 Jul 14:22
Picon

Re: Re: BGP path hunting, MRAI timer and Path Length Damping

Hi,

On Sat, 23 Jun 2007, Robert Raszuk wrote:

> technology. Geoff's data that most churn is generated by roughly 
> 10% of bad netizens of the Internet and recent proposals from 
> tli/geoff have IMHO very good potential to vastly reduce churn 
> leaving more BGP dedicated CPUs for actual BGP update/best-path 
> processing.

These efforts are extremely interesting and admirable, the 
observations in that document are particularly insightful. However, 
let's be mindful that the proposals in the RFC are mostly 
'fine-tuning' of BGP to accomodate current conditions. As the RFC 
notes, the suggestions are heuristics - and heuristics tend only to 
go so far.

> problems from flat BGP to a new mapping plane ? And if this mapping 
> plane is free from such issues, why current BGP control plane could 
> not be ? After all only scalable & realistic deployment model is to 
> use those same CPUs and the same routers for all the work.

A hierarchy can alleviate scaling problems by reducing the amount of 
global state that must be kept - i.e. localising details. Hierarchies 
are not without their own cost, obviously (the hierarchy may require 
administration; the reduction of global state will reduce 
flexibility).

> * From my point of view the biggest gain one could envision while 
> introducing some form of mapping abstraction between EID & locators
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joe Abley | 9 Jul 15:28

Re: Re: BGP path hunting, MRAI timer and Path Length Damping


On 9-Jul-2007, at 08:22, Paul Jakma wrote:

> - ASes form a topology
>
>   (Information about ASes in BGP today can only be used reliably for
>    loop-detection, but the statement is true, and even today there's
>    enough information in BGP to work out the AS topology; witness
>    that there are tools available that do so)
>
> - AS topology is a strict subset of IP topology
>
>   (I.e. if you know the AS topology, and you know the IP:AS mappings,
>    you must know enough to do inter-AS IP routing)

It ought also to be mentioned that there's an additional mapping  
between prefix propagation and particular edges between ASes (i.e.  
not every connection between the same pair of ASes involves the same  
exchange of reachability information; ISPs advertise the same  
prefixes with different attributes across different links, or  
different sets of prefixes.)

Joe

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Jakma | 9 Jul 15:56
Picon

Re: Re: BGP path hunting, MRAI timer and Path Length Damping

On Mon, 9 Jul 2007, Joe Abley wrote:

> It ought also to be mentioned that there's an additional mapping 
> between prefix propagation and particular edges between ASes (i.e. 
> not every connection between the same pair of ASes involves the 
> same exchange of reachability information; ISPs advertise the same 
> prefixes with different attributes across different links, or 
> different sets of prefixes.)

Aye. A lot of that detail would be lost in an AS-topology routed 
scheme; the disadvantage would be loss of IP-topology-scale traffic 
engineering.

I'm not saying such a scheme would be the one to go for; I'm saying 
we may (or may not ;) ) one day have to face having to decide on 
trade-offs of "detail" Vs "scaleability", like the one in that 
scheme. ;)

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
You can have peace.  Or you can have freedom. Don't ever count on having
both at once.
 		-- Lazarus Long

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 1 comment |
headers
Schliesser, Benson | 9 Jul 16:50
Favicon
Gravatar

RE: Re: BGP path hunting, MRAI timer and Path Length Damping

(Sorry; I have 3 topics in 1 email. Please feel free to split the thread
if appropriate.)

Paul Jakma [mailto:paul <at> clubi.ie] wrote:
> Aye. A lot of that detail would be lost in an AS-topology routed 
> scheme; the disadvantage would be loss of IP-topology-scale traffic 
> engineering.
> 
> I'm not saying such a scheme would be the one to go for; I'm saying 
> we may (or may not ;) ) one day have to face having to decide on 
> trade-offs of "detail" Vs "scaleability", like the one in that 
> scheme. ;)

I agree that we need more discussion on detail vs scale. I have a gut
feeling that they are naturally opposing features of a routing system.
Maybe somebody more expert than me (and more mathematically inclined)
can comment on this?

Now pragmatically: On average, for TE purposes, the normal Internet AS
needs something less granular than per-prefix attributes but more
granular than per-AS. Thus I would imagine that in an AS-topology routed
scheme each network operator would end up with multiple AS numbers,
where each was used as a TE equivalence-class identifier. This makes
"AS" a bit of a misnomer in such a system. :)

In the Internet today, "traffic engineering" is already quite imprecise.
For the most part, the tools available are side-effects ("hacks"?) of
explicit features. If we were to build TE as an explicit feature of the
routing system, what would that look like? For that matter, what TE
capabilities are required? I have my own list (below), but some
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael | 12 Jul 08:32
Favicon

Re: Re: BGP path hunting, MRAI timer and Path Length Damping

Tony,

How to distinguish route changes due to a real topology change or a path hunting? as I understand, a real
topology change is one of the reasons triggering a path hunting, other reasons include the
reconfiguration of route policies or management and maintenance etc. And with respect to a very  far AS, a
BGP peer inside it can not tell what real reason causes it change.

Best,
Michael

----- Original Message ----- 
From: "Tony Li" <tli <at> cisco.com>
To: "Robin Whittle" <rw <at> firstpr.com.au>
Cc: "idr" <idr <at> ietf.org>; "K. Sriram" <ksriram <at> nist.gov>
Sent: Saturday, June 23, 2007 5:01 AM
Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping

> 
> Hi Robin,
> 
> 
>> Your I-D also states that "path hunting" occurs when a prefix is
>> first advertised, but that seems pretty natural and hard to
>> prevent.
> 
> 
> Please read the rest of the draft.  ;-)
> 
> 
>>   I don't think this would be as destructive as the MRAI
(Continue reading)

Permalink | Reply | 12 comments |
headers
Tony Li | 12 Jul 08:39
Picon
Favicon

Re: Re: BGP path hunting, MRAI timer and Path Length Damping


On Jul 11, 2007, at 11:32 PM, Michael wrote:

> How to distinguish route changes due to a real topology change or a  
> path hunting? as I understand, a real topology change is one of the  
> reasons triggering a path hunting, other reasons include the  
> reconfiguration of route policies or management and maintenance  
> etc. And with respect to a very  far AS, a BGP peer inside it can  
> not tell what real reason causes it change.

That is exactly why the mechanisms that we are exploring are  
heuristics.  There is no explicit information to tell us and the best  
that we can do is to make some educated guesses.

Regards,
Tony

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 11 comments |
headers
Jakob Heitz | 12 Jul 18:12

Re: Re: BGP path hunting, MRAI timer and Path Length Damping

Tony Li wrote:
> 
> On Jul 11, 2007, at 11:32 PM, Michael wrote:
> 
>> How to distinguish route changes due to a real topology change or a 
>> path hunting? as I understand, a real topology change is one of the 
>> reasons triggering a path hunting, other reasons include the 
>> reconfiguration of route policies or management and maintenance etc. 
>> And with respect to a very  far AS, a BGP peer inside it can not tell 
>> what real reason causes it change.
> 
> 
> That is exactly why the mechanisms that we are exploring are 
> heuristics.  There is no explicit information to tell us and the best 
> that we can do is to make some educated guesses.

Real information is always better than heuristic guesses.
Can we invent an attribute to add this: maybe "reason for update" ?

> 
> Regards,
> Tony

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 10 comments |
headers
Tony Li | 12 Jul 18:33
Picon
Favicon

Re: Re: BGP path hunting, MRAI timer and Path Length Damping


On Jul 12, 2007, at 9:12 AM, Jakob Heitz wrote:

>>> How to distinguish route changes due to a real topology change or  
>>> a path hunting? as I understand, a real topology change is one of  
>>> the reasons triggering a path hunting, other reasons include the  
>>> reconfiguration of route policies or management and maintenance  
>>> etc. And with respect to a very  far AS, a BGP peer inside it can  
>>> not tell what real reason causes it change.
>> That is exactly why the mechanisms that we are exploring are  
>> heuristics.  There is no explicit information to tell us and the  
>> best that we can do is to make some educated guesses.
>
> Real information is always better than heuristic guesses.
> Can we invent an attribute to add this: maybe "reason for update" ?

We could try, but I'm not sure that we can maintain that information  
accurately.  Specifically, when would we ever fill in the field with  
"path hunting"?

Tony

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 9 comments |
headers
Paul Jakma | 12 Jul 20:18
Picon

Re: Re: BGP path hunting, MRAI timer and Path Length Damping

On Thu, 12 Jul 2007, Tony Li wrote:

> We could try, but I'm not sure that we can maintain that information 
> accurately.  Specifically, when would we ever fill in the field with "path 
> hunting"?

Hmm, Jakob might be right...

We don't need to maintain 'path hunting' state, we need to maintain 
"where in the network did the withdraw start?". If we do that, then 
we can detect subsets of the topology that must be as dead as the 
path the withdraw is for. E.g., Geoff's example:

  http://www.potaroo.net/ispcol/2007-06/fig1.jpg

5 could easily note that, given the withdrawal by 2 of 2_1, its other 
paths of 3_2_1 and 4_3_2_1 all go through 2 - and just avoid/defer 
picking those as new best-paths.

This doesn't work if the failure is once (or more) removed, or for 
more complex cycles, e.g.:

          |
          |
      5---6-\
     /   / \ \
  1-2-3-4  9  E
  |  \    /  /
  |   7--8  /
  A--B--C--D
(Continue reading)

Permalink | Reply | 7 comments |

Gmane