Re: [DMM] FW: New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement"

["Sri Gundavelli (sgundave)" <[e-mail]>]

Alex:

> I propose you add the following draft about ND Prefix Delegation
>extensions to Neighbor Discovery:
https://tools.ietf.org/html/draft-kaiser-nd-pd-01 (it is not about
coloring the prefix, but it is about prefix delegation
options in ND)


[Sri] Do not see the relevance for adding a generic PD document reference
here. But, to save time with debates, I will just throw that there.

Thanks every one for the comments. This discussion thread is now closed.

Sri







On 1/31/18, 11:23 PM, "dmm on behalf of Alexandre Petrescu"
<[e-mail] on behalf of [e-mail]> wrote:

>
>
>Le 31/01/2018 à 22:14, Sri Gundavelli (sgundave) a écrit :
>> 
>> Based on the feedback and some offline discussions with Danny and
>>others,
>> here is the response with some corrections. Please comment.
>> 
>> 
>>   
>> 
>> 
>> ------------------------------------
>> 
>> Dear 3GPP SA2 Chair:
>> 
>> 
>> Thank you for your LS query (Reference:
>> https://datatracker.ietf.org/liaison/1554/). The IETF DMM working group
>> has reviewed the LS statement and below is our response.
>> 
>> 
>> In our view, the work-item described in the LS query has three
>>components:
>> 
>> 
>> 
>> 1.) The approach of coloring IPv4 and IPv6 addresses/prefixes with
>> mobility properties.
>> 
>> This is about standardizing IP address address/prefix ³types". Each
>>³type"
>> has a certain behavior that the network is expected to provide. Section
>> 3.1, of draft-ietf-dmm-ondemand-mobility-13 defines the following four
>> address types, which are applicable to both IPv4 and IPv6 addresses and
>> prefixes.
>> 
>> #a. Fixed IP Address
>> #b. Session-lasting IP Address
>> #c. Non-persistent IP Address
>> #d. Graceful Replacement IP Address
>> 
>> 
>> These modes, #a, #b, #c,and #d can be mapped to the 3GPP SSC modes 1, 2
>> and 3.
>> 
>> We are happy to report that this work-item is on track to become an
>> ³informational standard", and will most likely will hit IESG very soon.
>> 
>> 
>> 
>> We kindly request 3GPP to provide any feedback that you may have on this
>> draft.
>> 
>> 
>> 
>> 
>> 2.) The approach of network including property meta-data in address
>> assignment procedures
>> 
>> There are multiple mechanisms for address configuration delivery to the
>> end-host:
>> 
>> #a.) DHCPv4
>> #b.) DHCPv6
>> #c.) IPv6 ND (PIO Options, others ..etc)
>> #d.) IKEv2 Address Configuration Options
>> 
>> 
>> There are many proposals on this including:
>> 
>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt
>> https://www.ietf.org/id/draft-moses-dmm-dhcp-ondemand-mobility-08.txt
>> 
>> Also, some proposals from the previous years:
>> 
>> https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-ndp-support-03.txt
>> https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-id-02.txt
>> 
>>https://www.ietf.org/archive/id/draft-bhandari-dhc-class-based-prefix-05.
>>txt
>
>I propose you add the following draft about ND Prefix Delegation
>extensions to Neighbor Discovery:
>https://tools.ietf.org/html/draft-kaiser-nd-pd-01
>(it is not about coloring the prefix, but it is about prefix delegation
>options in ND)
>
>Alex
>
>> ...
>> 
>> 
>> Currently, these documents are under review in the IETF DMM WG. However,
>> the DMM working group has not chosen any specific draft as WG document.
>> Given the interest from 3GPP for this work, we will try to accelerate
>>the
>> document selection process and will try to move this work forward. This
>>is
>> subject to finding consensus for taking up this work.
>> 
>> We also like to point out that, all though the LS statement explicitly
>> refers to both IPv4 and IPv6 address types, however it only mentions
>>about
>> (RA) (IPv6 ND implied) as the mechanism for address property delivery.
>>It
>> is to be noted that the approach of delivering coloring meta-data in RA
>> messages will most likely be to limited to IPv6 address/prefix types and
>> will not be extended to IPv4 addresses. If this capability is required
>>for
>> IPv4, we may have to possibly extend DHCP protocol(s).
>> 
>> 
>> We kindly request SA2 to clarify if the Ask is explicitly for IPv6, or
>>if
>> its for both IPv4 and IPv6 address/prefix types.
>> 
>> 
>> 
>> 
>> 3.) The approach of indicating the coloring meta-data to the
>>applications
>> on the mobile node (UE in 3GPP terminology).
>> 
>> This is about extending socket interface with the property tags. This is
>> covered in draft-ietf-dmm-ondemand-mobility-13,
>> 
>> We are happy to report that this work is on track to become an
>> ³informational standard", and will most likely will hit IESG very soon.
>> 
>> 
>> We kindly request 3GPP to provide any feedback that you may have on this
>> draft.
>> 
>> 
>> 
>> 
>> 
>> Regards
>> Dapeng Liu and Sri Gundavelli
>> (Chairs IETF DMM Working Group)
>> 
>> 
>> -----------------------------------------------------------
>> 
>> 
>> 
>>>
>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/16/18, 2:45 PM, "Liaison Statement Management Tool"
>>>>>>> <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Title: LS on indicating service continuity usage of the additional
>>>>>>>> IPv6
>>>>>>>> prefix in Router Advertisement
>>>>>>>> Submission Date: 2018-01-16
>>>>>>>> URL of the IETF Web page:
>>>>>>>>https://datatracker.ietf.org/liaison/1554/
>>>>>>>>
>>>>>>>> From: Chang hong <[e-mail]>
>>>>>>>> To: Sri Gundavelli <[e-mail]>,Dapeng Liu
>>>>>>>> <[e-mail]>,Terry Manderson
>>>>>>>> <[e-mail]>,Suresh
>>>>>>>> Krishnan <[e-mail]>,Robert Hinden
>>>>>>>><[e-mail]>,Ole
>>>>>>>> Troan <[e-mail]>
>>>>>>>> Cc: Dapeng Liu <[e-mail]>,Terry Manderson
>>>>>>>> <[e-mail]>,IPv6 Maintenance Discussion List
>>>>>>>> <[e-mail]>,Ole Troan <[e-mail]>,Sri Gundavelli
>>>>>>>> <[e-mail]>,The IETF Chair <[e-mail]>,Robert Hinden
>>>>>>>> <[e-mail]>,Distributed Mobility Management Discussion
>>>>>>>> List
>>>>>>>> <[e-mail]>,Suresh Krishnan <[e-mail]>
>>>>>>>> Response Contacts: [e-mail],[e-mail]
>>>>>>>> Technical Contacts:
>>>>>>>> Purpose: For information
>>>>>>>>
>>>>>>>> Body: 1. Overall Description:
>>>>>>>> 3GPP working group SA2 (System Architecture) would like to inform
>>>>>>>>the
>>>>>>>> IETF that SA2 has defined three SSC (Session and Service
>>>>>>>>Continuity)
>>>>>>>> modes in 3GPP TS 23.501 ("Architecture for the 5G System") clause
>>>>>>>> 5.6.9
>>>>>>>> as follows:
>>>>>>>> -     With SSC mode 1, the network preserves the connectivity
>>>>>>>>service
>>>>>>>> provided to the UE. For the case of PDU Session of IPv4 or IPv6
>>>>>>>>type,
>>>>>>>> the
>>>>>>>> IP address is preserved.
>>>>>>>> -     With SSC mode 2, the network may release the connectivity
>>>>>>>> service
>>>>>>>> delivered to the UE and release the corresponding PDU Session. For
>>>>>>>> the
>>>>>>>> case of IPv4 or IPv6 type, the network may release IP address(es)
>>>>>>>> that
>>>>>>>> had been allocated to the UE.
>>>>>>>> -     With SSC mode 3, changes to the user plane can be visible to
>>>>>>>> the
>>>>>>>> UE,
>>>>>>>> while the network ensures that the UE suffers no loss of
>>>>>>>> connectivity.
>>>>>>>> A
>>>>>>>> connection through new PDU Session Anchor point is established
>>>>>>>>before
>>>>>>>> the
>>>>>>>> previous connection is terminated in order to allow for better
>>>>>>>> service
>>>>>>>> continuity. For the case of IPv4 or IPv6 type, the IP address is
>>>>>>>>not
>>>>>>>> preserved in this mode when the PDU Session Anchor changes.
>>>>>>>> SA2 has also adopted the use of IPv6 multi-homing in a PDU Session
>>>>>>>> (referred to as "multi-homed IPv6 PDU Session") as described in
>>>>>>>>3GPP
>>>>>>>> TS
>>>>>>>> 23.501 clause 5.6.4.3, a PDU Session being an association between
>>>>>>>>the
>>>>>>>> UE
>>>>>>>> and a Data Network that provides a data connectivity service,
>>>>>>>>which
>>>>>>>> is
>>>>>>>> also defined in 3GPP TS 23.501.
>>>>>>>> When a new IPv6 Prefix is assigned to the UE for a multi-homed
>>>>>>>>IPv6
>>>>>>>> PDU
>>>>>>>> Session, SA2 has decided to use the Router Advertisement message
>>>>>>>> according to IETF RFC 4191 to deliver the new IPv6 prefix to the
>>>>>>>>UE
>>>>>>>> and
>>>>>>>> configure the Routing Rules in the UE by using the Route
>>>>>>>>Information
>>>>>>>> Option.
>>>>>>>> SA2 is looking for a mechanism to deliver information regarding
>>>>>>>>the
>>>>>>>> service continuity usage (e.g. whether the prefix can be replaced
>>>>>>>> with
>>>>>>>> or
>>>>>>>> without grace period) associated with the new IPv6 prefix to the
>>>>>>>>UE
>>>>>>>> via
>>>>>>>> the 5G System user plane.
>>>>>>>>
>>>>>>>> SA2 understands that the IETF draft
>>>>>>>> "draft-ietf-dmm-ondemand-mobility-12"
>>>>>>>> defines four IP address types that can be mapped to the three SSC
>>>>>>>> modes
>>>>>>>> as follows:
>>>>>>>>
>>>>>>>> -     SSC mode 1 corresponds to either FIXED or SESSION_LASTING;
>>>>>>>> -     SSC mode 2 corresponds to NON_PERSISTENT;
>>>>>>>> -     SSC mode 3 corresponds to GRACEFUL_REPLACEMENT.
>>>>>>>>
>>>>>>>> SA2 would like to understand if there is any IETF work related to
>>>>>>>> delivery of the IP address type (according to IETF draft
>>>>>>>> "draft-ietf-dmm-ondemand-mobility-12") in the Router Advertisement
>>>>>>>> message, which could be used for delivery of the service
>>>>>>>>continuity
>>>>>>>> usage
>>>>>>>> associated with a new IPv6 prefix in a multi-homed IPv6 PDU
>>>>>>>>Session.
>>>>>>>>
>>>>>>>> 2. Actions:
>>>>>>>> To IETF Internet Area, DMM, 6MAN:
>>>>>>>> ACTION:       SA2 respectfully asks IETF Internet Area, DMM and
>>>>>>>>6MAN
>>>>>>>> to
>>>>>>>> provide feedback on any IETF work related to delivery of IP
>>>>>>>>address
>>>>>>>> type
>>>>>>>> (according to IETF draft "draft-ietf-dmm-ondemand-mobility-12") in
>>>>>>>> the
>>>>>>>> Router Advertisement message.
>>>>>>>>
>>>>>>>> 3. Date of Next SA2 Meetings:
>>>>>>>> 3GPPSA2#125  OR 22 - 26 Jan 2018    Gothenburg       SE
>>>>>>>> 3GPPSA2#126  OR 26 Feb - 2 Mar 2018    US            US
>>>>>>>> Attachments:
>>>>>>>>
>>>>>>>>     
>>>>>>>> 
>>>>>>>>S2-179625_e-mail_rev2_S2-179363_LS_out_to_IETF_Internet_Area_DMM_6M
>>>>>>>>AN
>>>>>>>>
>>>>>>>> 
>>>>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-16-3g
>>>>>>>>pp
>>>>>>>> -
>>>>>>>> t
>>>>>>>> sg
>>>>>>>> s
>>>>>>>> 
>>>>>>>>a-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the
>>>>>>>>-a
>>>>>>>> d
>>>>>>>> d
>>>>>>>> it
>>>>>>>> i
>>>>>>>> onal-ipv6-prefix-in-router-advertisement-attachment-1.doc
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>> 
>
>_______________________________________________
>dmm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmm