Re: [DMM] Mobility Exposure and Selection WT call

[Alexandru Petrescu <[e-mail]>]

Le 22/04/2015 18:51, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:[e-mail]]
>> Sent: Tuesday, April 21, 2015 12:42 PM
>> To: Templin, Fred L; Jouni Korhonen; [e-mail]
>> Subject: Re: [DMM] Mobility Exposure and Selection WT call
>>
>> Le 31/03/2015 00:42, Templin, Fred L a écrit :
>>> Hi Alex,
>>>
>>>> -----Original Message----- From: dmm [mailto:[e-mail]]
>>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03
>>>> PM To: Jouni Korhonen; [e-mail] Subject: Re: [DMM] Mobility
>>>> Exposure and Selection WT call
>>>>
>>>> Le 26/03/2015 13:17, Jouni Korhonen a écrit :
>>>>> Alex,
>>>>>
>>>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti:
>>>>>
>>>>> [snip]
>>>>>
>>>>>>> I thought by "fixed" you meant it stays the same wherever the
>>>>>>> Host goes (something like the Home Address).
>>>>>>
>>>>>> Alper - I think a LL address can also be qualified as 'fixed' -
>>>>>> it never changes.
>>>>>
>>>>> Does LL here mean link-local or link-layer? If it is the former
>>>>> one, then the above assertion is not correct.
>>>>
>>>> Link-local.
>>>>
>>>> And you seem to say a link-local address is not fixed?  I think
>>>> link-local addresses _are_ fixed set in stone.  They are formed
>>>> locally without need of help from router.
>>>
>>> AERO provides a fixed link-local address that is formed from a
>>> prefix received by DHCPv6 Prefix Delegation (PD).
>>
>> Fred - but why should this ll prefix be provided by DHCP?  Is it of
>> variable value?  Or is the link-local constant all the time? (in which
>> case it could be hardcoded everywhere).
>
> DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO
> Client (e.g., 2001:db8:1:2::/64). The Client then constructs an
> AERO link-local address from the prefix as fe80::2001:db8:1:2
> (i.e., it embeds the 64-bit prefix from the prefix delegation in
> the 64-bit interface identifier of an IPv6 link-local address).

Fred, that looks weird.  Never saw a prefix to be used as an Interface 
Identifier.

I guess this breaks the DHCP prefix delegation specification.

Why does not the DHCPv6 server assign a link-local address altogether 
(rather than assigning a prefix, to be used as an IID).

Alex

> Once the prefix delegation and AERO address configuration
> are done, they stay fixes as long as the Client remains
> associated with the same AERO link.
>
>>> Once the AERO Client is given a PD (either IPv6 or IPv4) it can form
>>> an AERO link-local address that stays the same wherever the Client
>>> moves and with no need to perform Duplicate Address Detection (DAD).
>>> It makes IPv6 ND simple and seamless.
>>
>> Is that prefix fe80::/10?
>
> No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link
> has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which
> longer global IPv6 prefixes are delegated to each Client. The Client then
> gets to keep and continually use its prefix delegation as long as it stays
> associated with the same AERO link.
>
> Thanks - Fred
> [e-mail]
>
>> Alex
>>
>>>
>>> Thanks - Fred [e-mail]
>>>
>>>> Alex
>>>>
>>>>>
>>>>> - Jouni
>>>>>
>>>>>>
>>>>>> I think it's hard to disagree with that, no?
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> So, I guess, I should have referred to the "nomadic" address
>>>>>>> to mean the one that is constant, wherever the Host goes.
>>>>>>>
>>>>>>> As such, my suggestion is that a "nomadic" address can never
>>>>>>> be an RFC7217 address.
>>>>>>>
>>>>>>> In practice that would mean that if you configure an address
>>>>>>> to be "nomadic" you must also tell the kernel to not run
>>>>>>> RFC7217 on it.
>>>>>>>
>>>>>>> But ok, one might think that these two aspects ("nomadic" and
>>>>>>> RFC7217) are orthogonal at this point in time.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>>
>>>>>>>> I don't know if it makes sense to request a fixed and
>>>>>>>> random-based IP address. But if someone does it, it works.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Alper
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or
>>>>>>>>>>> registered (RFC 6775).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Orthogonal.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> E.g. a nomadic address could never be a link-local
>>>>>>>>>>> address.
>>>>>>>>>>>
>>>>>>>>>>>> #2. Describe how IP address type information is
>>>>>>>>>>>> conveyed from network to MN.
>>>>>>>>>>>
>>>>>>>>>>> If one designs a protocol to convey address type
>>>>>>>>>>> information from the network to the end node, then
>>>>>>>>>>> one could also add the other types mentioned above.
>>>>>>>>>>>
>>>>>>>>>>> SLAAC could never 'convey' the address type to the
>>>>>>>>>>> end-node, because SLAAC is an operation happening
>>>>>>>>>>> with as heavy weight from the Server (router) as from
>>>>>>>>>>> the Client (Host): the Router decides the prefix but
>>>>>>>>>>> the Client decides the Interface ID.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Still, the network can convey the type of IP address to
>>>>>>>>>> the host. Also, one can imagine augmenting Router
>>>>>>>>>> Solicitation to let the host convey its requested
>>>>>>>>>> type.
>>>>>>>>>
>>>>>>>>> I agree.
>>>>>>>>>
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Address Registration Option of 6lo and BTLE would
>>>>>>>>>>> have the Host conveying this information to the
>>>>>>>>>>> Router (and not vice-versa).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> OK.
>>>>>>>>>>
>>>>>>>>>> Alper
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Yours,
>>>>>>>>>>>
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility
>>>>>>>>>>>> as the baseline for item#1 (the API). A revision of
>>>>>>>>>>>> the draft will also include a new section to cover
>>>>>>>>>>>> backward compatibility (Danny will provide the
>>>>>>>>>>>> draft text). Comments on the draft are welcome.
>>>>>>>>>>>>
>>>>>>>>>>>> The next call will be about items #2/#3 (IP
>>>>>>>>>>>> address configuration enhancements associated with
>>>>>>>>>>>> the API). We intend to schedule that one in about 2
>>>>>>>>>>>> weeks.
>>>>>>>>>>>>
>>>>>>>>>>>> Alper
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> See below for the Webex details. Remember, the
>>>>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't
>>>>>>>>>>>>> forget to read the documents in the reading list
>>>>>>>>>>>>> prior to the call.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Attendees _shall read _the following material
>>>>>>>>>>>>>> before the call so that we can directly jump to
>>>>>>>>>>>>>> the discussions:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1.
>>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>
>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>>>>>>> 3.
>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>
>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>>>>>>> 5.
>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>> Alper
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *DMM - Mobility Exposure and Selection WT*
>>>>>>>>>>>>> Tuesday 10 February 2015 16:00  |  Europe Time
>>>>>>>>>>>>> (Paris, GMT+01:00)  |  1 hr 30 min
>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Join WebEx meeting*
>>>>>>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>
>> Meeting number:641 085 326
>>>>>>>>>>>>>> Meeting password:dmm1911
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll
>>>>>>>>>>>>>> free number (US/Canada) *1-650-479-3208*
>>>>>>>>>>>>>> Call-in toll number (US/Canada) Access code:
>>>>>>>>>>>>>> 641 085 326 Toll-free calling restrictions
>>>>>>>>>>>>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>> Add this meeting
>>>>>>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>> to your calendar.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can't join the meeting? Contact support.
>>>>>>>>>>>>>> <https://ietf.webex.com/ietf/mc>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx
>>>>>>>>>>>>>> service allows audio and other information sent
>>>>>>>>>>>>>> during the session to be recorded, which may be
>>>>>>>>>>>>>> discoverable in a legal matter. By joining this
>>>>>>>>>>>>>> session, you automatically consent to such
>>>>>>>>>>>>>> recordings. If you do not consent to being
>>>>>>>>>>>>>> recorded, discuss your concerns with the host
>>>>>>>>>>>>>> or do not join the session.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> <WebEx_Meeting.ics>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Poll is closed, and majority selected the
>>>>>>>>>>>>>> following date for the call:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please mark your calendars.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In this call, we'll aim making progress on the
>>>>>>>>>>>>>> I-D for item#1 (an API for source address
>>>>>>>>>>>>>> selection).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Attendees _shall read _the following material
>>>>>>>>>>>>>> before the call so that we can directly jump to
>>>>>>>>>>>>>> the discussions:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1.
>>>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>
>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>>>>>>> 3.
>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>
>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>>>>>>> 5.
>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>> Alper
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please mark your availability on the
>>>>>>>>>>>>>>> following doodle for our next DMM WG Mobility
>>>>>>>>>>>>>>> Exposure and Selection WT call:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Register your availability no later than the
>>>>>>>>>>>>>>> end of Monday (Jan 26).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Alper
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________ dmm
>>>>>>>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________ dmm
>>>>>>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ dmm mailing
>>>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ dmm mailing
>>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>
>>>>
>>>> _______________________________________________ dmm mailing list
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
>>
>
>
>