[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
Yakov Rekhter wrote:
Just because you piggyback control information on data does not
change the fact that this is control information, and thus
has to be processed by the control plane.
True, but let's not get hung up just yet on how we process control plane
information.
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?
What matters is how fast one could restore reachability, as the
service is reachability, not BGP.
Right. But I'm looking for a comparison between methods to restore
reachability ;-)
With LISP in order to restore reachability the failure information
has to be propagated from ETRs all the way to ITRs.
Well, let's put this in more quantifiable terms. Link goes down. IGP
floods that to other ETRs as traffic shifts from one ETR to another.
Let's agree that IGP has to converge no matter whether we're talking
LISP or BGP ;-) Now it is a mere matter of 1/2 RTT between the new ETR
and ITR. So, when you say "all the way", sure. But put in terms of
time, I'd like to understand the numbers, especially if the router has
failed. A count to infinity is not fun. I've tried it ;-)
In contrast
to this, with the current routing restoring reachability may require
(much) narrow scope of the the failure information propagation.
This has always been an option, but it's not solely used by any serious
enterprise. So why do you think it will be acceptable in the future?
Einstein had something to say about that logic. And where it's not
particularly useful to the enterprise, it's downright hostile to the
consumer. Today the consumer has really two wires into her house: phone
and cable. We ought to engineer for that at least for today instead of
insisting that she have two phone or two cable lines for redundancy, or
worse imposing business practices on the service providers to manage the
redundancy through wholesale mechanisms.
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