Subject: Re: [lisp] lisp Digest, Vol 13, Issue 10

From: Charrie Sun <[email-masked]>
Date: Sat, 5 Dec 2009 08:37:37 +0800

can anyone tell me how to set each ALT node responsible for
mappings for certain EID blocks? If they do it spontaneously, wouldn't it
just like BGP, and each node contains a full mapping table?

2009/12/5 <[email-masked]>

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/lisp
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send lisp mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/lisp
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lisp digest..."
>
> Today's Topics:
>
>   1. Re: Fwd: Re: Re: A mapping system design-- specificationof
>      LISP+ALT (Dino Farinacci)
>   2. Re: Fwd: Re: Re: A mapping system design-- specificationof
>      LISP+ALT (Joel M. Halpern)
>
>
> ---------- 已转发邮件 ----------
> From: Dino Farinacci <[email-masked]>
> To: "Joel M. Halpern" <[email-masked]>
> Date: Thu, 3 Dec 2009 21:38:55 -0800
> Subject: Re: [lisp] Fwd: Re: Re: A mapping system design-- specificationof
> LISP+ALT
>
>> 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
>
>
> Yours,
>> Joel
>>
>> Noel Chiappa wrote:
>>
>>>   > 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
>>> _______________________________________________
>>> lisp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>>
>> _______________________________________________
>> lisp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lisp
>>
>
>
>
>
> ---------- 已转发邮件 ----------
> From: "Joel M. Halpern" <[email-masked]>
> To: Dino Farinacci <[email-masked]>
> Date: Fri, 04 Dec 2009 07:38:26 -0500
> Subject: Re: [lisp] Fwd: Re: Re: A mapping system design-- specificationof
> LISP+ALT
> Thanks.  That is a simpler way to do it.
> Yours,
> Joel
>
> Dino Farinacci wrote:
>
>> 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
>>
>>
>> Yours,
>>> Joel
>>>
>>> Noel Chiappa wrote:
>>>
>>>>   > 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
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>
>>> _______________________________________________
>>> lisp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>>
>>
>>
>>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>
>