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

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

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

No; not more mappings. The mapping would still be to a site
border router for the destination's site, but the ETR could
be deeply embedded within the site. The way it would work is
that the encapsulated packets would be directed to a (globally
routable) locator for a site border router, but once the
packets reach the site they are forwarded to the ETR within
the site by routing on the identifier in the inner header.

Or, we could just leave the ETR at the site border routers
themselves or at some middlebox within the site; the choice
is up to the individual sites.

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

One benefit of locating the ETR close to the end system is
that the closer one gets to the end system the more it tends
to resemble true end-to-end.

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

Sure, and the ITR can do that even if it is co-resident on
the same physical platform as the end system.

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

I don't follow this. IMHO, we can place the ITRs as close
to the end systems as we like - even on the same physical
platform as the end system - without incurring any scaling
issues.
 
> The mapping function is again key here.

Right, but we do have some candidates on the table.

Thanks - Fred
fred.l.templin at boeing.com

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