Thank you Erik for the feedback. Sri
On 1/18/18, 4:36 AM, "Erik Kline" <e...@google.com> wrote: >Whatever the outcome, we should encourage them to consider separate >RAs from separate link-local router addresses for logically separate >data. (Like PvDs, essentially) > >Trying to allocate bits in the PIO and RIO for address type won't >really prove sustainable. > >On 18 January 2018 at 21:30, Sri Gundavelli (sgundave) ><sgund...@cisco.com> wrote: >> Dear All, >> >> Please review the attached LS from 3GPP SA2 on the RA meta-data related >> work. Please send any comments you have to the chairs. >> >> >> Sri >> >> >>> >>> >>>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_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-add >>>>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
