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

From: Uma Chunduri <[email-masked]>
Date: Fri, 2 Feb 2018 19:07:06 +0000

Sri,

Your summary is comprehensive as it includes DHCP & IKEv2 too though they didn't ask specifically.

For IKEv2 I see similar stuff needed for Config Payloads (for most of the attribute types), but not sure how this would be used in FMC cases (non-3GPP access).

--
Uma C.

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, January 31, 2018 1:15 PM
To: [email-masked]
Subject: Re: [DMM] FW: New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement"

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

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"
>>>>><[email-masked]>
>>>>>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 <[email-masked]>
>>>>>>To: Sri Gundavelli <[email-masked]>,Dapeng Liu 
>>>>>><[email-masked]>,Terry Manderson 
>>>>>><[email-masked]>,Suresh
>>>>>>Krishnan <[email-masked]>,Robert Hinden 
>>>>>><[email-masked]>,Ole Troan <[email-masked]>
>>>>>>Cc: Dapeng Liu <[email-masked]>,Terry Manderson
>>>>>><[email-masked]>,IPv6 Maintenance Discussion List 
>>>>>><[email-masked]>,Ole Troan <[email-masked]>,Sri Gundavelli 
>>>>>><[email-masked]>,The IETF Chair <[email-masked]>,Robert Hinden 
>>>>>><[email-masked]>,Distributed Mobility Management Discussion 
>>>>>>List <[email-masked]>,Suresh Krishnan <[email-masked]> Response 
>>>>>>Contacts: [email-masked],[email-masked]
>>>>>>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_6
>>>>>>MAN
>>>>>>
>>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-16-3
>>>>>>gpp
>>>>>>-
>>>>>>t
>>>>>>sg
>>>>>>s
>>>>>>a-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-th
>>>>>>e-a
>>>>>>d
>>>>>>d
>>>>>>it
>>>>>>i
>>>>>>onal-ipv6-prefix-in-router-advertisement-attachment-1.doc
>>>>>
>>>>
>>>> _______________________________________________
>>>> dmm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>_______________________________________________
>>dmm mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 2 Feb 2018 11:55:33 -0800

Hello Sri,

This is more about address coloring than the Liaison statement.

> The approach of coloring IPv4 and IPv6 addresses/prefixes with
> mobility properties.
>
> 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

If one gets a non-persistent IP address and somehow as events unfold 
there is a need for a persistent IP address, is it required to change 
addresses?  Or can one change the color of the address in use?

If one gets a fixed IP address, but never hosts any persistent sessions, 
can the address be re-colored?

Is the expectation that users will be charged different rates depending 
upon the color of their address?  If the address could be re-colored, 
would the charging regime change at the time the address gets a new color?

Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 2 Feb 2018 22:07:18 +0000

Uma,

>Your summary is comprehensive as it includes DHCP & IKEv2 too though they

[Sri] Right, they did not ask, but those all the pieces in the puzzle.

>
>For IKEv2 I see similar stuff needed for Config Payloads (for most of the
>attribute types), but not sure how this would be used in FMC cases
>(non-3GPP access).

[Sri] It will be used on the untrusted non-3GPP access interface (SWu for
4G and the corresponding 5G interface). There are some draft proposals for
this that we proposed in the past.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 2 Feb 2018 22:08:57 +0000

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"
<[email-masked] on behalf of [email-masked]> 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.
>> 
>> 
>>   
>> 
>> 
>> https://datatracker.ietf.org/liaison/1554/). The IETF DMM working group
>> has reviewed the LS statement and below is our response.
>> 
>> 
>> 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.
>> 
>> 
>> 
>>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.
>> 
>> 
>>>>>>>> List
>>>>>>>> <[email-masked]>,Suresh Krishnan <[email-masked]>
>>>>>>>> Response Contacts: [email-masked],[email-masked]
>>>>>>>> Technical Contacts:
>>>>>>>> Purpose: For information
>>>>>>>>
>>>>>>>> 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:
>>>>>>>>type,
>>>>>>>> IP address is preserved.
>>>>>>>> case of IPv4 or IPv6 type, the network may release IP address(es)
>>>>>>>> that
>>>>>>>> had been allocated to the UE.
>>>>>>>>before
>>>>>>>> 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.
>>>>>>>>3GPP
>>>>>>>> TS
>>>>>>>> UE
>>>>>>>> and a Data Network that provides a data connectivity service,
>>>>>>>>which
>>>>>>>> is
>>>>>>>> also defined in 3GPP TS 23.501.
>>>>>>>> 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.
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> modes
>>>>>>>>continuity
>>>>>>>> usage
>>>>>>>> associated with a new IPv6 prefix in a multi-homed IPv6 PDU
>>>>>>>>Session.
>>>>>>>>
>>>>>>>> 2. Actions:
>>>>>>>>address
>>>>>>>> type
>>>>>>>> (according to IETF draft "draft-ietf-dmm-ondemand-mobility-12") in
>>>>>>>> the
>>>>>>>> Router Advertisement message.
>>>>>>>>
>>>>>>>>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