[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Yakov, now that I have answered your questions, can you answer the ones I have asked yesterday. See questions below, they are at the end. Thanks.

Dino

Begin forwarded message:

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


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