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

[Yakov Rekhter <yakov@juniper.net>]

Eliot,

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

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.

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

With LISP in order to restore reachability the failure information
has to be propagated from ETRs all the way to ITRs.  In contrast
to this, with the current routing restoring reachability may require
(much) narrow scope of the the failure information propagation.
E.g., if a site is multi-homed to the same service provider, then
the reachability restoration requires to propagate PE/CE failure
*only* within that provider. E.g., if a site is multi-homed to two
providers, and these providers have a direct peering with each
other, then the reachability restoration requires to propagate PE/CE
failure to only these two providers.

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