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" <dmm-boun...@ietf.org on behalf of alexandre.petre...@gmail.com> 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" >>>>>>> <l...@ietf.org> >>>>>>> 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 <chang.hong.s...@intel.com> >>>>>>>> To: Sri Gundavelli <sgund...@cisco.com>,Dapeng Liu >>>>>>>> <maxpass...@gmail.com>,Terry Manderson >>>>>>>> <terry.mander...@icann.org>,Suresh >>>>>>>> Krishnan <sur...@kaloom.com>,Robert Hinden >>>>>>>><bob.hin...@gmail.com>,Ole >>>>>>>> Troan <otr...@employees.org> >>>>>>>> Cc: Dapeng Liu <maxpass...@gmail.com>,Terry Manderson >>>>>>>> <terry.mander...@icann.org>,IPv6 Maintenance Discussion List >>>>>>>> <i...@ietf.org>,Ole Troan <otr...@employees.org>,Sri Gundavelli >>>>>>>> <sgund...@cisco.com>,The IETF Chair <ch...@ietf.org>,Robert Hinden >>>>>>>> <bob.hin...@gmail.com>,Distributed Mobility Management Discussion >>>>>>>> List >>>>>>>> <dmm@ietf.org>,Suresh Krishnan <sur...@kaloom.com> >>>>>>>> Response Contacts: georg.mayer.hua...@gmx.com,3gppliai...@etsi.org >>>>>>>> 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 >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
