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

[Alexandre Petrescu <[e-mail]>]

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_6MAN
>>>>>>>
>>>>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-16-3gpp
>>>>>>> -
>>>>>>> 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
>