Re: [DMM] Mobility Exposure and Selection WT call

["Templin, Fred L" <[e-mail]>]

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