Re: Document 3: Symmetric Routing

[Enke Chen <[e-mail]>]

Curtis, 
Thanks for your comments.  Here are my replies.  

> Date:    Fri, 28 Apr 1995 22:58:08 -0400
> From:    Curtis Villamizar <[e-mail]>
> To:      Tony Bates <[e-mail]>
> CC:      [e-mail], [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 personally do not consider it a "hack" to use the AS path length 
in the decision process.  (actually I have been wondering why BGP 
does not include this.)  Anyway, we will revise the relevant text. 

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

Now I read it again, the text there was really not clear.  What we 
tried to say is really the administrative work, not the resouce or
the computational complexicity.  

We will revise the text. 
  
> 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.

Thanks.  We receive requests for load-balancing between between 
multi-providers, almost on a daily basis.  It is the biggest routing
headache for us.  Help from the BGP protocol is needed now!   
  

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

The "route flap dampenning" is a good idea. So is MED, and so is MPP :-)

- Enke