Re: Document 3: Symmetric Routing

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>et>, Tony Bates writes:
>    (in terms of the "local_pref" parameter) in the route selection
>    process.  It also assumes the following order of preference is
>    followed for the purpose of route selection:  first the "local_pref"
>    parameter, followed by the MPP attribute, the shortest AS-path, the
>    MED, and the IGP metric.

Enke, Tony,

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.

I'd also prefer if you changed the wording describing the NSFNET
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
coordination and places a burden on routers with limited memory
capacity".  Add more RAM and things should scale nicely, linearly with
respect to number of prefixes (which with aggregation should be
considerably less than linear with respect to number of hosts) and
log2(N) with respect to CPU and number of prefixes (or better
considering number of hosts and aggregation).  Handling 10^3 prefixes
requires X amount of CPU, 10^6 require roughly 10X, 10^9 requires 20X;
that's not bad.  Nothing scales to the point where you add more
prefixes and don't need more memory or some CPU.  Administrative
headaches of keeping track of the lists scales linearly (maybe worse).

I think you have a very good proposal.  These are just wording nits.

As an aside- better get your favorite router vendor to implement route
flap dampenning _first_ if you are going to inject a metric based on
path length in the customer AS into all providers.  I'd certainly want
to see the providers have a knob to say "flap this value and it gets
clamped high" before giving the customer the rope to hang _you_ rather
than himself.

Curtis