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

[Yakov Rekhter <yakov@juniper.net>]

Robert,

> Hi Eliot,
> 
>  > If someone can explain to me how that is possible with APT
> 
> Let me take a shot ...
> 
> Assume you are allocating some address block /28 for customer from 240 
> pool. Today you are connected to two ISPs. Mapping entry list two ETRs 
> for your block either your CE or your ISP PE router. When you need to 
> switch one ISP with another all you do is to change the ETR address in 
> the mapping database.
> 
> ETR address is a routable address in any of the schemes. Also in any of 
> the schemes you will get it in some way from an upstream ISP if ETR is 
> on CE.
> 
> Moreover scale*rate equation is happy ... proposed BGP to provide 
> mapping services while does grow in scale ... goes very well down in 
> rate. 

> ETR addresses need to fast converge not mapping database.

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.

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.

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.

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. 

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