[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
Greetings, Yakov,
If the mapping databased does not reflect the actual state of
reachability, then fast convergence on ETR addresses is not sufficient.
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.
Precisely so.
Moreover, if one carries the reachability information by means other
than BGP, then one needs to show the benefits of doing this on the
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.
Again, right on the money. In the case of LISP I think we're there, but
we would love lots more analysis. The whole point of offering a whole
new tunneling approach is to provide for locator reachability bits in
line with the data. By doing this, a failure on the part of one of the
far end ITRs can be transmitted to the near end ETR using those bits.
Similarly, when a failed far end ITR returns to service, it or another
far end ITR can indicate its reachability. Now, tell me how fast can
BGP handle either a withdraw or an announcement?
At the same time, if we look at the system-wide effects we see that
since the operational state has moved from a broadcast DFZ to a
bilateral mechanism, only communicating parties need to retain that
state. How shall we quantify that?
Finally, in terms of keeping the scale*rate equation "happy", there are
possible mechanisms to control the rate besides APT (or LISP for
that matter). E.g., see presentation by John Scudder and David Ward
at IETF-68.
Sure.
Regards,
Eliot
--
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