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

[Yakov Rekhter <yakov@juniper.net>]

Eliot,

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

Ok, let's gloss over details... After all, it is precisely
in the details where the devil is...

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

So am I.

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

Consider a multi-homed site connected to two ISPs, ISP1 and ISP2.
The ETRs are maintained by ISPs. How would you get the information
about ETR failure via IGP in this scenario ?

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

You are mistaken - this is exactly how the Internet routing system
works today. Specifically, the time to restore reachability is
less then the time it takes to propagate the failure information
Internet-wide.

> So why do you think it will be acceptable in the future?  

Because it works.

Yakov.

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