Subject: Re: [lisp] Fwd: Re: Re: A mapping system design-- specificationof LISP+ALT

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Dec 2009 13:44:21 -0500 (EST)

> From: Sam Hartman <[email-masked]>

    >> we should _first_ decide it we want to _allow_ overlapping mappings, or
    >> just outlaw them. Only if we decide to keep them would we need to go
    >> through and make them work right (which involves a number of things,
    >> not just the 'don't discard longer entries').

    > Agreed.

Since you're tweaking the 'open issues' list on the data-tracker, want to add
that one so we don't forget it?

    > The strongest argument for permitting overlapping mappings I've seen is
    > the default PETR case.

Let me make sure I understand what you're speaking of here.

I take this to mean that a 'default PETR' (i.e. an ETR which is used by a
site behind a LISP encapsulator to gain access to the _rest_ of the
non-yet-LISP Internet - more on this below) would want to advertize a mapping
which covers the entire 'identity' namespace (technically, it's actually
'addresses', since sites which have not concerted do not yet have separate
location and identity), so that any attempt by that site's ITR to look up a
destination which is not yet LISPed is guaranteed to get a mapping back for
that destination?

(Note that although a 'normal' LISP site trying to send packets to a
destination which is not yet LISPed would get back a negative Map-Reply, in
response to which it would simply not encapsulate the packets in question,
but send them natively, there are circumstances in which a LISP site would
have no option but to encapsulate the packets, if it is to get them to the
destination at all. An example would be a mobile LISP node which has migrated
to a foreign network; it cannot emit 'native' packets, but only
LISP-encapsulated packets, and thus to communicate with a non-LISP site would
need to use a PETR.)

Such a 'default mapping' would of course overlap all the mappings from actual
LISP sites. Interesting... Not only does this argue that we need to support
overlapping mappings, it also says that some techniques for doing so (e.g.
bundle all the overlapped mappings together with the overlapping mapping,
when responding to the mapping request) are infeasible.

(Sorry for being a bit long-winded, but I like to trudge up the steps one
by one - when one  takes them in threes, sometimes one misses one... :-)

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Dec 2009 13:50:29 -0500

Actually, if the default conceptually represents all unmapped ID space, 
then if it is responding to a request, it probably needs to respond with 
  a /32 (or /128 for v6 based IDs) answer.  One could argue that it can 
respond with a nice short prefix.  But, the ITR would need to explicitly 
check any other EID anyway.  So responding with the short prefix 
actually does not do any good.

Yours,
Joel

Noel Chiappa wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 3 Dec 2009 21:38:55 -0800

> Actually, if the default conceptually represents all unmapped ID  
> space, then if it is responding to a request, it probably needs to  
> respond with  a /32 (or /128 for v6 based IDs) answer.  One could  
> argue that it can respond with a nice short prefix.  But, the ITR  
> would need to explicitly check any other EID anyway.  So responding  
> with the short prefix actually does not do any good.
>

That is not the way PETRs work and this is not the way we want them to  
work. What an ITR will get in terms of a map-cache entry is a negative  
map-reply which indicates the shortest prefix which covers the  
destination requested in the Map-Request.

Then the ITR is *configured* to use a PETR where all negative map- 
cache entries will use this configured PETR (can be more than one). So  
you have the fewest number of map-cache entries to encapsulate to.

The ALT tells you what the mask-length is of this prefix and the map- 
resolver which receives the ECM for the Map-Request will return the  
negative Map-Reply.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 04 Dec 2009 07:38:26 -0500

Thanks.  That is a simpler way to do it.
Yours,
Joel

Dino Farinacci wrote:
> Then the ITR is *configured* to use a PETR where all negative map-cache 
> entries will use this configured PETR (can be more than one). So you 
> have the fewest number of map-cache entries to encapsulate to.
> 
> The ALT tells you what the mask-length is of this prefix and the 
> map-resolver which receives the ECM for the Map-Request will return the 
> negative Map-Reply.
> 
> Dino
> 
> 
>> Yours,
>> Joel
>>
>> Noel Chiappa wrote: