From: Dino Farinacci <dino@cisco.com>
Date: January 7, 2008 11:11:53 AM PST
To: Yakov Rekhter <yakov@juniper.net>
Cc: raszuk@juniper.net, Eliot Lear <lear@cisco.com>, Routing
Research Group list <rrg@psg.com>
Subject: Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-
encaps architectures
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