Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping

From: Paul Jakma <[email-masked]>
Date: Mon, 9 Jul 2007 13:22:20 +0100 (IST)

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 
> are not those which are listed in the IAB report.

Agreed.

One of the most obvious areas for information-reduction through 
hierarchy would be to note that we have two distinct number-spaces, 
the connectedness of one being a subset of the other, yet we 
propogate routing information for the /aggregate/ of the two spaces.

I.e. we can observe that:

- 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)

So in theory we could propogate messages to describe former 
seperately from the latter, describing AS routing via traditional 
Distance-Vector, and describing the IP:AS mappings in some other way 
(e.g. by flooding).

That would gain some efficiency in IDR messaging, retaining the 
policy-amienable DV routing we know from BGP, at the cost of IDR 
"traffic engineering" no longer being able to act directly on IP 
topology, but only on AS topology. Sadly there's no such thing as a 
free lunch. ;)

If careful fine-tuning of BGP doesn't work (as per Li and Hustons' 
draft), then we'll have to start looking at more radical things (like 
the above, or not ;) ) - which implies having to make some difficult 
choices on trade-offs between flexibility and information..

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Nothing shortens a journey so pleasantly as an account of misfortunes at
which the hearer is permitted to laugh.
 		-- Quentin Crisp

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Jul 2007 09:28:03 -0400

>    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

---

From: Paul Jakma <[email-masked]>
Date: Mon, 9 Jul 2007 14:56:09 +0100 (IST)

On Mon, 9 Jul 2007, Joe Abley wrote:

> not every connection between the same pair of ASes involves the 
> same exchange of reachability information; ISPs advertise the same 

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	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You can have peace.  Or you can have freedom. Don't ever count on having
both at once.
 		-- Lazarus Long

---

From: "Schliesser, Benson" <[email-masked]>
Date: Mon, 9 Jul 2007 09:50:19 -0500

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

> trade-offs of "detail" Vs "scaleability", like the one in that 

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
discussion around this would be valuable, I think.

Inter-AS/Global TE Features I'd like (non-exhaustive):
-control traffic proportions/balance across my available inter-network
links
-control whether and where I use multi-path for a given class of traffic
-direct certain classes of traffic to specific links

What other TE requirements are out there? (I know there are some, just
not at the tip of my fingers now.)

Cheers,
-Benson

---

From: Michael <[email-masked]>
Date: Thu, 12 Jul 2007 14:32:58 +0800

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" <[email-masked]>
To: "Robin Whittle" <[email-masked]>
Cc: "idr" <[email-masked]>; "K. Sriram" <[email-masked]>
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
>> timer holding back a withdrawal for 30 seconds just after an AA+
>> has been sent.
> 
> 
> MRAI is simply one other cause of diffraction, resulting in path  
> hunting and more unnecessary messaging.
> 
> 
>> "Path hunting" after a first advertisement is a consequence of
>> the path-vector protocol.  Maybe your proposed Path Length
>> Damping would be marginally effective at reducing the
>> propagation of sub-optimal "best paths" sometimes before the
>> final, stable, optimal "best path", by expediting the
>> announcements of shorter paths and withdrawals, and delaying
>> longer path announcements.
> 
> 
> Please read the rest of the draft.  ;-)  In particular the sections  
> on optimal path damping and delayed best path selection.
> 
> 
>> So more than 2/3 of activity is seems clearly to be associated
>> with delays caused by the MRAI timer in a small triangle of
>> routers/ASes, or in more complex mesh structures.
> 
> 
> Your assumption here seems to be that all delays are due to MRAI.   
> That seems highly unlikely.  MRAI just gives larger delays.  There  
> are others that are of influence as well.
> 
> 
>> Getting rid
>> of that mechanism would greatly reduce the burden of messages
>> and speed up the propagation of withdrawals.  Sequences of
>> multiple messages might be replaced by a single message, which
>> is more informative, and propagates quickly.
> 
> 
> Exactly why some implementations have taken that path.
> 
> 
>>>> I also believe that it is a major mistake to treat
>>>> advertisements differently than withrawns, specially from a
>>>> queuing/timing point of view. The only thing you are going to
>>>> get out of that is weird blackholes and more instability...
>>
>> This is written by someone who presumably knows far more about
>> BGP than I do, but I don't see why this would be true.
> 
> 
> Yes, Pedro knows a good bit about BGP.  I put high value on his opinion.
> 
> To understand his perspective, I think you also need to consider  
> cases where there are link failures within a more meshed topology.   
> Rapid propagation of withdrawals (bad news) and slow propagation of  
> alternate paths (good news) means that convergence to alternate paths  
> will go through unnecessary churn.  For example, the withdrawal might  
> rapidly propagate up past the point where the alternate path would  
> come into play and result in a blackhole while the alternate path  
> information slowly catches up.  As these are the cases where you  
> really would like to converge quickly, this is problematic.
> 
> 
>>>> AFAIK, no major vendor implements their advertisement
>>>> rate-controller/queueing in a way as to threat updates and
>>>> withrawns differently.
>>
>> Lets say we have 500,000 prefixes.  Do we have a single down
>> counter for each prefix?  I guess so.  As far as I know, the
>> same announcements go to all peers.
> 
> 
> This is fundamentally incorrect.  Policy is peer specific.
> 
> 
>> This is a major challenge to implement.  It is either a massive
>> number of downcounters each with its own pointers to whatever it
>> affects, or some kind of linked list of events to remember in
>> the future, which could get very long, and would require tricky
>> methods to take things out of and to incrementally chew through
>> and take action upon as time passes by.
>>
>> There would never be 500,000 timers active at once, so maybe it
>> could be implemented by having a pool of downcounters, say a few
>> thousand, which are used by the first instances which need them
>> and which are returned to the pool once they time out or no
>> longer needed.
> 
> 
> It's not particularly hard to set up a router that has multiple  
> copies of the full routing table, prefers only one of them, and then  
> has all of the preferred routes withdrawn.  So, yes, you need to  
> provision for all 500,000 timers.  This assumes you're willing to  
> bound your implementation to that number.  FWIW, that number is no  
> longer competitive and would need to be more like 1-2M.  Certain  
> folks seem to already be claiming 10M.
> 
> 
>> Then there is the question of each router's message queue to
>> each peer being throttled via TCP, with the software being able
>> to find messages in the queue and delete them if something else
>> happens after they were put in the queue.
> 
> 
> Removing messages after they are placed into the TCP stream is not a  
> practical approach.  Once the message has been played out of BGP and  
> into the TCP socket, it is quite effectively "gone".  The best that a  
> BGP implementation can do is to ensure that it has filled the socket  
> and not computed too many additional messages.  Such messages would  
> have to be explicitly buffered in BGP, which is expensive.  It's far  
> more effective to simply not compute updates faster than they are  
> consumed and leave the data in BGP's internal data structures.
> 
> 
>> Yet by 2002, we are told that Cisco, Juniper et. al. had given
>> up on following RFC 1771's strict instructions to exempt
>> withdrawals from the MRAI mechanism.
> 
> 
> You're assuming that they complied with it in the first place.
> 
> 
>> They presumably didn't do this lightly.
> 
> 
> True, but they didn't spend eons thinking about the problem either.
> 
> 
>> Now the cost of this simplification in implementations - now
>> mandated by the RFC 4271 - is either unacceptable or so costly
>> that the simple MRAI function needs to be replaced by something
>> fussier.
>>
>> CPUs and memories of newer routers have become faster, so maybe
>> it is easier now to have the more complex MRAI-like timer.  On
>> the other hand, there are now far more prefixes and maybe more
>> peers it has to be implemented for.
> 
> 
> The problem has not gotten easier.
> 
> 
>> Implementing a more complex MRAI-like timer in new firmware
>> upgrades to older routers may be prohibitive.
>>
>> So I guess the trick is to find the simplest solution which will
>> solve the problem.
> 
> 
> Isn't it always?  ;-)
> 
> 
>> It would be interesting to know what the difficulty was -
>> because those difficulties may still be important and might
>> prevent the adoption of Path Length Damping or some other
>> mechanisms as your I-D suggests.
> 
> 
> Rather than 'difficulty', I would say that developers made the  
> judgement call that the cost/benefit ratio was unacceptable.
> 
> Tony
> 
> 
>

---

From: Tony Li <[email-masked]>
Date: Wed, 11 Jul 2007 23:39:10 -0700

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

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 12 Jul 2007 09:12:51 -0700

Tony Li wrote:
>> 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.
> 
> 

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

---

From: Tony Li <[email-masked]>
Date: Thu, 12 Jul 2007 09:33:20 -0700

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  
>> heuristics.  There is no explicit information to tell us and the  
>> best that we can do is to make some educated guesses.
>

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

---

From: Paul Jakma <[email-masked]>
Date: Thu, 12 Jul 2007 19:18:52 +0100 (IST)

On Thu, 12 Jul 2007, Tony Li wrote:

> 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

6 has:

   1_2_5
   1_2_3_4
   1_2_7_8_9
   1_A_B_C_D_E

If 1-2 fails, then 6 should get successive withdraws. It can't 
immediately tell where the failure occured. On the second withdraw, 
it could, by comparison, note that 1_2 is common, and theorise that 
the other paths with 1_2 in the path have a higher probability of 
imminent withdrawal than the 1_A_B_C_D_E path.

That's still heuristics though, and a more complicated version of 3.4 
'path length damping' from your stability draft.

However, we could allow 6 to determine with /certainty/, if we had 
some kind of transitive Withdraw-Originater-AS attribute. With such:

- 1_2 fails
- 2 starts sending withdraws to 5, 3 and 7, each marked with
   some "AS2 started this.."
- 6 receives a withdraw (from 5, 4 or 9, matters not which)
- 6 starts best-path selection, taking the withdraw-originator into
   account
     - each path containing AS2 it can discount
     - leaving it to pick 1_A_B_C_D_E

I.e. use the AS_PATH to do what it's there for - detect cycles ;). 
(just on the withdraw side). ;)

(there'd be some additional details to take care of in the above 
scheme obviously..)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Bad cafeteria food landed all the sysadmins in the hospital.

---

From: Geoff Huston <[email-masked]>
Date: Fri, 13 Jul 2007 05:51:39 +1000

Paul Jakma wrote:
> "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:
> 

defer, not avoid - it may be that AS2 may have withdrawn the routing due 
to a policy change with respect to AS5 rather than the commencement of a 
path exploration leading to withdrawal.

There have been a number of proposals I've seen in the literature on 
this topic that attempt to address Jakob's desire to explicitly mark the 
"path exploration" phase. The "this is a withdrawal at origin" flag 
appears to be a common thread, where a withdrawal is intended to be 
marked with a flag that says "this origin is pulling this prefix, don't 
listen to path exploration updates as all hope is already lost!" In 
response to this flag a bgp speak upon receiving such a flagged 
withdrawal would not advertise any withdrawal-triggered updates. 
Variants of this propose a flag to say "this AS path pair of origin and 
nexthop is dead - no not use any adj-rib entry that includes this path 
pair for this prefix"

This explicit flagging would be more effective than attempting to second 
guess what is a path exploration update sequence, but there are likely 
some further considerations with the approach of explicit flagging of 
such events.

- Its a change to all BGP deployments to be effective, not just a local 
change to the way in which updates are interpreted. By no means a major 
concern, but it does imply some morphing of the BGP spec to apply some 
transitive attribute to withdrawals that are essentially not in the spec 
at the moment.

- While there are relatively simple topologies where this information of 
"complete withdrawal at source" is accessible, more complex topologies 
are tougher for a BGP speaker to determine whether to set such a flag or 
not. If thats the case then such explicit flagging of withdrawal "type" 
would only be present some of the time, leaving the issue of passive 
detection and damping of path exploration updates as one that would have 
some leverage in reducing the BGP update load.

I suspect that there is still a valid case for the passive detection of 
path exploration update detection using the relatively simple heuristic 
of detecting sequences of update messages where the common 
characteristic is a) closely coupled in time, b) refer to the same 
prefix, c) refer to the same origin AS, and d) contain AS path vectors 
of increasing length.

I also suspect (but I'm not convinced as yet) that a mechanism of 
deferral of further propagation of such detected updates could be a 
reasonable replacement for both route flap damping and the MRAI timer in 
BGP, given that both these mechanisms were similarly motivated by a 
desire to suppress the update load associated with the behaviour of 
distance vector algorithms in the face of a withdrawal. I should add 
however that this last suspicion (of potentially using this instead of 
MRAI and RFD) is pretty speculative, and the work I've done recently in 
looking at this used an approach of placing this detection on top of 
existing MRAI behaviour, so its not a case of have to use one or the 
other - both is a possible as well.

   Geoff

---

From: Paul Jakma <[email-masked]>
Date: Fri, 13 Jul 2007 02:35:42 +0100 (IST)

On Fri, 13 Jul 2007, Geoff Huston wrote:

> transitive attribute to withdrawals that are essentially not in the spec at 
> the moment.

Indeed.

However, given Curtis' email and his indication that there isn't any 
churn problem, least not of significance to justify any significant 
changes to BGP, is this idea feasible?

To attach attributes to withdrawals means using MP_UNREACH_NLRI style 
UPDATE messages. Information that would only be transitive until the 
first non-MP capable session. However, '5' (or 6 in my more complex 
example topology), would only need /one/ withdrawal to get through 
with this extra information for it to be useful to do 
withdrawal-cycle detection on the /remaining/ paths it has to choose 
from (see below).

> - While there are relatively simple topologies where this 
> information of "complete withdrawal at source" is accessible, more 
> complex topologies are tougher for a BGP speaker to determine 
> whether to set such a flag or not. If thats the case then such 
> explicit flagging of withdrawal "type" would only be present some 
> of the time, leaving the issue of passive detection and damping of 
> path exploration updates as one that would have some leverage in 
> reducing the BGP update load.

Well, someone has to 'originate' the withdrawal. Indeed, let's not 
call it a withdrawal, call it an update - a poisoned update, to make 
it more clear. We know poisoning works from other DV protocols, and 
we can do a more precise (better) job in BGP than that other DV 
protocol thanks to the AS_PATH attribute.

This poisoned update would withdraw the prefix, and provide an ASN 
which is 'poisoned' - any other path containing this ASN definitely 
is unuseable.

There'd be two possibilities for a speaker sending such an UPDATE to 
another 'poison aware' speaker:

a) There's an existing path-poison-ASN, leave that.
b) There's none, sending speaker inserts its own
    - it's either the originator of the withdraw, or the closest
      speaker this direction of the 'fault' able to insert
      path-poison.

Normal withdraws would be sent to speakers not aware of this 
mechanism, however that could /still/ allow remote speakers to take 
advantage of this scheme, e.g:

    2
   / \
-1   4
   \ /
    3

1 must withdraw some prefix. 2 is not poison-asn capable, 3 and 4 
are.

4 receives:

- normal withdraw from 2
- path-poison withdraw from 3, with ASN 1.

I.e. 4 can still receive the poison update, and use it to invalidate 
whatever other remaining paths it may have to the prefix concerned. 
It means that, if it received 2's withdraw first, 4 still would have 
'hunted', but the hunting stops once the poisoned-path withdraw is 
received from 3.

I.e. there'd be some incremental deployment benefit.

Does this seem worth pursuing?

> I suspect that there is still a valid case for the passive 
> detection of path exploration update detection using the relatively 
> simple heuristic of detecting sequences of update messages where 
> the common characteristic is a) closely coupled in time, b) refer 
> to the same prefix, c) refer to the same origin AS, and d) contain 
> AS path vectors of increasing length.

Yes indeed, that could still be applied to traditional withdrawals.

It has the risks you mention in the draft though, which poisoning 
does not. Poisoning would allow suppression of bad paths with 
certainty, I think.

> reasonable replacement for both route flap damping and the MRAI 
> timer in BGP, given that both these mechanisms were similarly 
> motivated by a desire to suppress the update load associated with 
> the behaviour of distance vector algorithms in the face of a 
> withdrawal.

The band-stop model of damping seems useful. With empirical data, as 
you've been gathering, we could find update-frequencies and 
path-selection hold times that could be shown to suppress X% of 
hunts, with Y% false suppressions of new better paths.

(i.e. use band-stop filtering, as per 3.3 of your draft, to influence 
whether to apply the delayed path-selection of 3.6 to a prefix).

Obviously we'd need to:

- ensure data gathered was representative
- gather new data periodically (every few years?) and review the
   parameters to ensure they were still correct

That seems a slight pain, when we could squash hunting with precision 
through poison (course, poisoning has the greater deployment 
barrier).

> I should add however that this last suspicion (of potentially using 
> this instead of MRAI and RFD) is pretty speculative, and the work 
> I've done recently in looking at this used an approach of placing 
> this detection on top of existing MRAI behaviour, so its not a case 
> of have to use one or the other - both is a possible as well.

Very interesting stuff :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Truth is the most valuable thing we have -- so let us economize it.
 		-- Mark Twain

---

From: Michael <[email-masked]>
Date: Fri, 13 Jul 2007 09:49:29 +0800

Hi,Paul:

The question is at some AS, a withdrawal message will stop propagating and it will be replaced by a new route advertisement if there is an alternate route available, in other words, the original route is withdrawn implicitly. It is this implicit withdrawal that blurs the difference between a withdrawal due to a real topology change (link down etc) and a state transition due to local route-chosen policy or reconfiguration of route policies. It is difficult to distinghish them. As I see, only the AS adjacent to the failed link can identify a real reason caused to its flap.

Best,
Michael

---

From: Paul Jakma <[email-masked]>
Date: Fri, 13 Jul 2007 04:57:05 +0100 (IST)

On Fri, 13 Jul 2007, Michael wrote:

> Hi,Paul:
>
> The question is at some AS, a withdrawal message will stop 
> propagating and it will be replaced by a new route advertisement if 
> there is an alternate route available, in other words, the original 
> routeis withdrawn implicitly.

Sure.

At present, that alternate route may in fact be another dead-path, 
for which a withdrawal will soon be received - the hunting behaviour 
Li and Huston describe and are trying to address.

With poisoning, the speaker would be able to discern with certainty 
between such 'also-dead' paths and other, hopefully viable, paths.

If, with the help of poisoning, a viable path can be picked, and so 
the speaker stops propogating the poison then that's fine - that's 
exactly what the poison is for. Poison should only serve to kill bad 
paths, not viable paths.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
What passes for optimism is most often the effect of an intellectual error.
 		-- Raymond Aron, "The Opium of the Intellectuals"

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jul 2007 00:22:43 -0400

> accurately.  Specifically, when would we ever fill in the field with  

Just provide an update RFC3514 documenting this usage with BGP.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jul 2007 00:30:21 -0400

> picking those as new best-paths.

Ignoring the fact that this means saving AS Path information for
withdrawn routes ...

What about if AS2 made a policy change and decided not to announce to
AS5, rather than AS2 lost the route.  How long would you suppress any
and all alternates that went through AS1-AS2?

Curtis

---

From: Paul Jakma <[email-masked]>
Date: Fri, 13 Jul 2007 14:22:33 +0100 (IST)

> Ignoring the fact that this means saving AS Path information for 

Ah, actually it doesn't. the speaker just has to examine its RIB and 
flag other routes as dead (1 bit), and setup a timer to re-examine 
those routes (a pointer and an entry on a list perhaps).

NB: Even it did mean saving AS-path info, the stability draft 
suggests this for some of its optimisations, iirc.

> What about if AS2 made a policy change and decided not to announce 
> to AS5, rather than AS2 lost the route.  How long would you 
> suppress any and all alternates that went through AS1-AS2?

For some short-period of time. Geoff Huston's column seems to suggest 
that BGP converges globally within 2 to 3 minutes, so that would be a 
suitable time-out.

That's a question that'll be common to all alterate-suppression 
approaches I think (e.g. suppression based on increasing 
path-length).

This only works for cycles with connected nodes, i.e. from Geoff's 
exmaple, where 5 had a path via 2 and is about to hunt over to a 
path via 3:

           5
          / \
         2---3

       1

It can't work for larger cycles, e.g.:

         5-3
        /  |
       2   4
        \ /
         6

         1

We'd need explicit poison information injected into the protocol to 
spot those I think, as per other emails.

-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Confession is good for the soul, but bad for the career.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jul 2007 12:35:07 -0400

> suggests this for some of its optimisations, iirc.

If you are going to save per AS Path information for a short period of
time, then implement Route Flap Damping as specified instead of per
prefix only and it won't need to be considered harmfull anymore.

Curtis