Re: [RRG] Long term clean-slate only for the RRG?

[Yakov Rekhter <yakov@juniper.net>]

Dino,

> > Dino,
> >
> > Like I said, it has been a while since I looked at it. I'd have to  
> > go through it again and refresh my memory. Perhaps I can find some  
> > time in the near future to do that, right now, I've unfortunately  
> > got too much else happening.
> >
> >         jak
> 
> This kinda reinforces your point about how a small group of people  
> that are focused solely on this problem is really the most efficient  
> way to get a solution to get traction.
> 
> The sort of management issues I see what LISP are:
> 
> 1) There is a new namespace.
> 2) There is encapsulation.
> 3) There is a mapping database.
> 
> As for 1), it is no different than managing 2 address spaces, each in  
> different VRFs. So network operators have experience with this. We  
> aren't introducing anything monumentally new.
> 
> As for 2), we understand tunneling. We have seen it in so many forms  
> over the last decade and a half. We know why it's good and what the  
> disadvantages are. So there are no surprises here. Nothing  
> monumentally new.
> 
> As for 3), the mapping database is something that has to scale on a  
> grander scale that what we've seen with other mapping or caching  
> databases. Some exiting ones to note are ARP, DNS, an NAT. For ARP,  
> the problem is constrained to link-local usage but I have seen some  
> layer-2 networks with 10^5 MACs on it. As for DNS, I think it works  
> remarkably well for the grand scale it is being used for. In fact, I  
> just saw an article about Paul Mock and the *25th anniversary* of DNS.  
> So we can borrow some of the *simple* ideas from DNS. As for NAT, we  
> have seen large NAT tables (in the places where people are connecting  
> sites and SPs together). 

There is an important difference between NAT tables and LISP. NAT
table is a cache, but this cache is populated based only on the
information *local* to the NAT. In contrast, caches on LISP routers
can not be populated based only on the information local to the
routers, but require to acquire this information over the network.

> NAT has a major OpEx hit but again the  
> mapping database proposals especially LISP-ALT is not really  
> introducing anything monumentally new. 

Wrt "NAT has a major OpEx hit", the (very wide) deployment of NATs
should give you a hint that its benefits (significantly) outweight
its cost. And what matters is not whether one claims that it is "a
major OpEx hit", but that the experience showed that its benefits
justify its cost.  And yes, I know that some folks have a knee jerk
reaction when they hear the word "NAT".

> It's just BGP over tunnels and  
> you send Map-Request and return Map-Replies over this topology.

Here are few more management issues that you may consider:

4) Use of cache based routers, and not just cache-based routers, but 
   routers where the information needed to populate the forwarding 
   cache is not present on the routers.

5) Routers using of ICMP to determine reachability.
  
Btw, the above is by no means complete...

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