Re: Document 3: Symmetric Routing

[Dennis Ferguson <[e-mail]>]

Curtis,

> In the first draft you "made the assumption" that routers where
> forwarding based on local_pref, as path length, and MED for the sake
> of argument and as the basis of the examples.  Later on you imortalize
> this vendor specific hack in statements above, implying that what you
> are adding to the standard is just the MPP.  In the 3 or 4 places
> where you list local_pref, MPP, as path length, and MED would you
> please make this more clear with "AS path length for implementations
> which use this technique" and explain in each document that this is
> something added by one vendor and does not exist as a route selection
> criteria in the BGP spec.

Then again I don't know of a BGP implementation which has seen even
moderate use on the Internet which doesn't use AS path length as a
tie breaker (i.e. there is more than one implementation which does this).
While the behaviour is a bit under-specified, pragmatically speaking
it gives subjectively better results than breaking ties by comparing
BGP identifiers, and people rely on it because of this, so I don't think
it is too inappropriate to document this as existing practice (if maybe
not required behaviour).

> approach of prefix based symetrical routing.  Please remove "does not
> scale" since the scaling properties are those of a radix tree of
> log2(n) which is quite good.  Instead "requires administrative

While a single search of a radix trie takes an amount of work
proportional to log(n), the work required to filter n announcements
from a neighbour through the radix trie (and to load the radix tree
in the first place) goes as n*log(n).  This is not so good.  Since
other operations in a good routing protocol implementation should scale
no worse than n*log(n) the overhead this adds will not be insignificant.

In any case, I think the document might have been referring to administrative
overhead rather than CPU or memory, since in this respect full prefix
filtering clearing scales worse than the alternative.

Dennis