Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP)

[Eliot Lear <lear at cisco.com>]

Hi Fred,
> > it's possible that the LISP mapping function would move closer and
> >     
> > close to the hosts,
> >     
>
> I have been saying this all along; once even to you, IIRC.
>   

It depends on what you mean, but in general I would view this as a bad 
thing.  Let's again discuss ETRs and ITRs separately.  If you wish to 
move the ETR function closer to the host then you must either advertise 
a more specific EID/prefix match, in which case you will explode the 
number of mappings (still not a good thing), or you will impose 
suboptimal routing if multiple interior ETRs advertise the same 
EID/prefix.  In the general case, there are only so many ways into and 
out of an end site, and so it's not clear what benefit you buy by moving 
these things toward the host, other than perhaps distributing the 
untunneling load, assuming the cost of doing so is huge to begin with (I 
do not believe it is).

ITRs are also best kept to a minimum, but it is less demanding on 
everyone else because we don't have to know about where you put your 
ITRs (although you still impose load in terms of determining the 
mapping).  Still, each ITR is going to need to play the mapping game.  
This means that either there is a predistributed and precomputed TIB, to 
borrow terminology from Juanjo, or you must reconstruct the entries 
realtime (or a mixture of both).  I think you want to do as little of 
that as possible, no matter which way you slice it.  It is true it would 
reduce your memory requirements on single devices, but it also adds 
complexity into your IGP which for most end sites is not there today.

The mapping function is again key here.

Eliot

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram