Re: The Hole in my proposal

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>OM>, Joel Halpern writes:
> Some people have suggested that BGP has "all of the functionality needed"
> for the determination of best paths.
> 
> Whether this is a true statement depends on the definitions one uses.
> 
> If the scope of the NHRP-like query is all within BGP, there are probably
> techniques to use the BGP information to detect relevant routing changes,
> and therefore keep the complexity down.
> 
> However, if one assumes that the scale will be large enough that aggregation
> is likely to occur within the boundaries of the ATM cloud, then even the
> BGP advertisements with next hop indication will have compressed out some
> of the necessary information.  Thus, de-aggreagtion is needed as part of
> the exit selection, not just the address resolution phase.
> (I do recognize that the allowance for such aggregation brings back
>  some risk of loop formation.  However, as long as we are within a single
>  protocol scope, even with aggreagation, I expect safety to be achievable.)
> 
> At least we are getting some discussion of these issues.
> Thank you,
> Joel M. Halpern			[e-mail]
> Newbridge Networks Inc.

Joel,

That is correct.  You cannot aggregate the off the NBMA LC within the
LC cloud.  You must carry full CIDR routing for the off the LC.  The
LC routers must be able to handle what a 3-4 year old 16 MB Ciscos can
almost handle (but not quite as we painfully know - get 64 MB) in
order to handle full off LC routing.

You cannot both have information and throw information away.  If the
method you have (NHRP) to recover information you have thrown away
(optimal exit point have been thrown away, NHRP tries to recover it)
only works for restricted cases (when the destination is singly homed
to the LC or directly attached to the LC), then you cannot throw
information away for the cases where the method (NHRP) does not work
(when the destination is multhomed to the LC).

Hope this helps clear things up.

Curtis