Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Dino Farinacci <dino@cisco.com>]

> The above fixation on keeping the scale*rate equation "happy", and
> on fast convergence of ETR addresses shows the lack of the system-wide
> perspective.

I don't know what "scale*rate" really means because previous  
references have documented "state*rate" which makes more sense to me.

> If the mapping databased does not reflect the actual state of
> reachability, then fast convergence on ETR addresses is not  
> sufficient.

Well if a path changes in the core to reach a specific ETR address,  
you want change quickly. And that will use BGP like it does today.

So, not sure what your point is.

> In fact, to be of any use such fast convergence also requires fast
> convergence of the actual reachability information. Whether one
> carries the actual reachability information in BGP, or via some
> other mechanism does not change this.

Right, and by determining reachability in a smaller topological region  
(the IGP) you have a better opportunity for faster convergence (inside  
of the site). And then if this new reachability status is carry in the  
data-plane, I think you have done pretty good. But if you don't agree,  
please tell me why not.

> Moreover, if one carries the reachability information by means other
> than BGP, then one needs to show the benefits of doing this on the

LISP is not replacing BGP. LISP is conveying 1) the ETR is up, 2) the  
ETR's CE-PE link is up and 3) the ETR thinks the PE is up. BGP still  
controls the policy and reachability of the locator addresses (the  
addresses of the ETRs).

> overall system behavior vs carrying this information in BGP. Just
> because one replaces BGP with some other mechanism to provide the
> reachability information does not guaratee that this other mechanism
> would consume less resources than BGP while providing comparable
> results in terms of timeliness and scalability.

The EID-prefixes don't have to go into the BGP core routers. Those  
addresses are the ones that decouple site addressing from physical  
topology.

So Yakov, do you not believe this level of indirection doesn't solve  
anything?

If not, how would you solve this problem? That is, if you really  
wanted to reduce the size of the core routing tables, how would you do  
it?

Dino

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg