From nobody Wed May 2 00:28:18 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4249112D947 for ; Wed, 2 May 2018 00:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XfJZXabgBjh for ; Wed, 2 May 2018 00:28:13 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C580B126E64 for ; Wed, 2 May 2018 00:28:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w427S8JW033839; Wed, 2 May 2018 09:28:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CEA98200E6B; Wed, 2 May 2018 09:28:08 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BFCA5200E06; Wed, 2 May 2018 09:28:08 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w427S8gQ004610; Wed, 2 May 2018 09:28:08 +0200 To: "Sri Gundavelli (sgundave)" References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> Cc: "dmm@ietf.org" From: Alexandre Petrescu Message-ID: Date: Wed, 2 May 2018 09:28:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 07:28:17 -0000 Le 25/04/2018 à 05:00, Sri Gundavelli (sgundave) a écrit : > Hi Alex, > > I cannot comment on the supported network/service configuration in any > operator's network. But, I’d think the allocation of stable /64’s is > similar to static IPv4 (/32) address allocations that are supported in > many operator networks today. There are also RADIUS / DIAMETER attributes > such as Framed-IPv6-Prefix ..etc which can be used for obtaining > statically configured values by PGW. So, IMO, its very much possible to > allocate static IPv6 Per-UE prefixes for the UE. Its also possible to > allocate static IPv6 prefixes for the networks behind UE. IMO, this is > just a configuration and operators can surely do this today. > > But, I am not sure where we are going with this? I am asking because I would like it to happen as you describe as being possible. I can agree that the possibility with RADIUS/DIAMETER permits to alocate a stable prefix in RA to a UE. However, I have never seen it in practice in a cellular network. When I connect I always get a different IPv6 prefix in RA. Where are we going with this? Let us go towards identifying first if _anybody_ (any cellular network) allocates a stable IPv6 prefix in RA to UE. It may be someone does allocate such, as it may be nobody does. In the first case, then I will suggest my operator to do likewise. In the latter case, then let us go in a direction where we understand _why_ operators dont implement stable IPv6 prefixes per UE. Alex > > > Sri > > > > > On 4/24/18, 7:31 AM, "Alexandre Petrescu" > wrote: > >> Hi Sri, >> >> Is there an operator today that allocates a stable /64 in RA to User >> Equipment? (resists re-connection) >> >> Alex >> >> >> Le 26/03/2018 à 07:14, Sri Gundavelli (sgundave) a écrit : >>> Alex: >>> >>> This is a good point. Yes, there is DHCPv6 prefix delegation support in >>> 3GPP architecture for supporting mobile router use-cases. This is >>> essentially for delegating prefixes for the networks attached to the UE. >>> This was introduced in Rel-10 by cisco. I have not followed the recent >>> SA2 >>> discussions and I do not know if MR support based on DHCPv6 will >>> continue >>> to be supported or not, and if they have considered the alternative >>> options for supporting the same. I think we can certainly ask that >>> question, but I also wonder if the coloring is specific to the PDU >>> session, or if its broadly applicable for all UE address/prefix >>> assignments. >>> >>> >>> Sri >>> >>> >>> >>> >>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>> wrote: >>> >>>> >>>> >>>> Le 22/03/2018 à 18:49, Liaison Statement Management Tool a écrit : >>>> [...] >>>> >>>>> SA2 would like to point out that among the four mechanisms for >>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, and >>>>> in particular the Router Advertisement message, seem to be applicable >>>>> in the 5G System architecture in the specific context of Multi-homed >>>>> IPv6 PDU Sessions. >>>> Please tell SA2 that current 4G cellular networks are specified to, and >>>> do use to some extent, DHCPv6 Prefix Delegation to assign a prefix to >>>> an >>>> end node like an IoT Router. >>>> >>>> A /56 prefix delivered to the end node should have the same >>>> capabilities >>>> as an address. We also want that /56 prefix to be more stable, or less >>>> stable, etc. >>>> >>>> I dont understand why 5G System architecture excludes DHCPv6 from the >>>> list of applicable address configuration delivery. >>>> >>>> I understand why 5G System architectures prefers ND - it is for >>>> addresses. >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> With respect to the following question in the IETF¹s reply LS: >>>>> 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 request 3GPP to clarify if the Ask is explicitly >>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>> >>>>> >>>>> SA2 would like to clarify that the request is explicitly for IPv6. SA2 >>>>> discussed the example documents that were referenced in your LS reply >>>>> and concluded that the following draft seems to be the most promising >>>>> candidate for the problem under discussion in this correspondence: >>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>> updated >>>>> of the work on the subject of including property meta-data in IPv6 ND >>>>> address assignment procedures for potential use in the 5G System to >>>>> indicate the mobility property of additional IPv6 prefixes assigned as >>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>> >>>>> >>>>> 2 Actions >>>>> To IETF DMM working group: >>>>> ACTION: SA2 would like to kindly ask IETF DMM working group to >>>>> keep SA2 updated of the work on the subject of including property >>>>> meta-data in IPv6 ND address assignment procedures for potential use >>>>> in >>>>> the 5G System to indicate the mobility property of additional IPv6 >>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>> functionality. >>>>> >>>>> >>>>> 3 Dates of next TSG SA WG2 meetings >>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>> TSG SA WG2 Meeting 127-Bis 28 May ­ 1 Jun 2018 Newport Beach, US >>>>> Attachments: >>>>> >>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>> >>>>> >>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22-3gpp-t >>>>> sg >>>>> >>>>> sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the-ad >>>>> di >>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> > > From nobody Wed May 2 07:29:25 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47F712D882 for ; Wed, 2 May 2018 07:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TNeIkD8VzQn for ; Wed, 2 May 2018 07:29:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D0012D881 for ; Wed, 2 May 2018 07:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8463; q=dns/txt; s=iport; t=1525271361; x=1526480961; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GoQX6dVIgZabU5gDDjFtYofsQI1wsIXf256e0PC1AXM=; b=ViXKJBA/PLg3qiUaflUg/4oVOr8hb1l+jXbTDOsviJ8VD8MHvNeIA+B1 XwgqJMUYQhrzBgSe80F4Z/MAwC1Ia+eK4kRG6IFUwlAP3kz6MQTOHaEq+ gJwpuNzwOuvCBlNg3J1EwP7S1C2DRKP+dO4LDjoPSajELQ4ZGlkgMBglZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AAD2yula/4ENJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYXooCotljG2BdIEPhnaMJIF4CxgLhANGAoMCITQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEBAgEBAWwLBQsCAQgSBiMLIQYLFw4CBA4FhHcDDQg?= =?us-ascii?q?PqlOHBw2BK4I9BYgagVQ/hBqCT0IBAYE5J4VUApdoLAgCi0yCfYE1g2CHQ4o?= =?us-ascii?q?EhhQCERMBgSQBHDiBUnAVO4JDgXlPiEiFPQFvAY1ngS6BGAEB?= X-IronPort-AV: E=Sophos;i="5.49,354,1520899200"; d="scan'208";a="108260403" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 14:29:20 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w42ETKnU013012 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 May 2018 14:29:20 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 2 May 2018 09:29:20 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Wed, 2 May 2018 09:29:19 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "dmm@ietf.org" Thread-Topic: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" Thread-Index: AQHT4iH1wD8w+4p+P0ubbekxY8iS4A== Date: Wed, 2 May 2018 14:29:19 +0000 Message-ID: References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="windows-1254" Content-ID: <1D7C47FB3940694D8BBF9BF7F1498CC1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 14:29:25 -0000 > I can agree that the possibility with RADIUS/DIAMETER permits to alocate a stable prefix in RA to a UE. However, I have never seen it in practice in a cellular network. Enabling static IP allocation by default has a scaling issue. The IPv6 prefix that is allocated to the UE is part of an aggregate block configured on a given PGW node. Reserving IPv6 prefixes from that block makes that one PGW node as the anchor for that UE. Operators loose flexibility with respect to gateway assignments. If you look at some of the work that went in 3GPP Rel 10 timeframe, it was about enhancements to gateway selection logic based on number of access-network parameters. It allowed operators to allow gateway selection based on proximity, policy and other parameters. Now, any time there is an IPv6 prefix reservation that flexibility is lost, as that creates a Gateway/Subscriber stickiness, and potentially resulting in uneven distribution of subscriber session across all the gateways. So, this is an operational problems and may be v6ops is the right group for such discussions. Sri On 5/2/18, 12:28 AM, "Alexandre Petrescu" wrote: > > >Le 25/04/2018 =E0 05:00, Sri Gundavelli (sgundave) a =E9crit : >> Hi Alex, >>=20 >> I cannot comment on the supported network/service configuration in any >> operator's network. But, I=92d think the allocation of stable /64=92s is >> similar to static IPv4 (/32) address allocations that are supported in >> many operator networks today. There are also RADIUS / DIAMETER >>attributes >> such as Framed-IPv6-Prefix ..etc which can be used for obtaining >> statically configured values by PGW. So, IMO, its very much possible to >> allocate static IPv6 Per-UE prefixes for the UE. Its also possible to >> allocate static IPv6 prefixes for the networks behind UE. IMO, this is >> just a configuration and operators can surely do this today. >>=20 >> But, I am not sure where we are going with this? > >I am asking because I would like it to happen as you describe as being >possible. > >I can agree that the possibility with RADIUS/DIAMETER permits to alocate >a stable prefix in RA to a UE. > >However, I have never seen it in practice in a cellular network. > >When I connect I always get a different IPv6 prefix in RA. > >Where are we going with this? Let us go towards identifying first if >_anybody_ (any cellular network) allocates a stable IPv6 prefix in RA to >UE. It may be someone does allocate such, as it may be nobody does. > >In the first case, then I will suggest my operator to do likewise. > >In the latter case, then let us go in a direction where we understand >_why_ operators dont implement stable IPv6 prefixes per UE. > >Alex > >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >> On 4/24/18, 7:31 AM, "Alexandre Petrescu" >> wrote: >>=20 >>> Hi Sri, >>> >>> Is there an operator today that allocates a stable /64 in RA to User >>> Equipment? (resists re-connection) >>> >>> Alex >>> >>> >>> Le 26/03/2018 =E0 07:14, Sri Gundavelli (sgundave) a =E9crit : >>>> Alex: >>>> >>>> This is a good point. Yes, there is DHCPv6 prefix delegation support >>>>in >>>> 3GPP architecture for supporting mobile router use-cases. This is >>>> essentially for delegating prefixes for the networks attached to the >>>>UE. >>>> This was introduced in Rel-10 by cisco. I have not followed the recent >>>> SA2 >>>> discussions and I do not know if MR support based on DHCPv6 will >>>> continue >>>> to be supported or not, and if they have considered the alternative >>>> options for supporting the same. I think we can certainly ask that >>>> question, but I also wonder if the coloring is specific to the PDU >>>> session, or if its broadly applicable for all UE address/prefix >>>> assignments. >>>> >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>>> >>>>wrote: >>>> >>>>> >>>>> >>>>> Le 22/03/2018 =E0 18:49, Liaison Statement Management Tool a =E9crit = : >>>>> [...] >>>>> >>>>>> SA2 would like to point out that among the four mechanisms for >>>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, and >>>>>> in particular the Router Advertisement message, seem to be >>>>>>applicable >>>>>> in the 5G System architecture in the specific context of Multi-homed >>>>>> IPv6 PDU Sessions. >>>>> Please tell SA2 that current 4G cellular networks are specified to, >>>>>and >>>>> do use to some extent, DHCPv6 Prefix Delegation to assign a prefix to >>>>> an >>>>> end node like an IoT Router. >>>>> >>>>> A /56 prefix delivered to the end node should have the same >>>>> capabilities >>>>> as an address. We also want that /56 prefix to be more stable, or >>>>>less >>>>> stable, etc. >>>>> >>>>> I dont understand why 5G System architecture excludes DHCPv6 from the >>>>> list of applicable address configuration delivery. >>>>> >>>>> I understand why 5G System architectures prefers ND - it is for >>>>> addresses. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> >>>>>> With respect to the following question in the IETF=B9s reply LS: >>>>>> 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 request 3GPP to clarify if the Ask is >>>>>>explicitly >>>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>>> >>>>>> >>>>>> SA2 would like to clarify that the request is explicitly for IPv6. >>>>>>SA2 >>>>>> discussed the example documents that were referenced in your LS >>>>>>reply >>>>>> and concluded that the following draft seems to be the most >>>>>>promising >>>>>> candidate for the problem under discussion in this correspondence: >>>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>>> updated >>>>>> of the work on the subject of including property meta-data in IPv6 >>>>>>ND >>>>>> address assignment procedures for potential use in the 5G System to >>>>>> indicate the mobility property of additional IPv6 prefixes assigned >>>>>>as >>>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>>> >>>>>> >>>>>> 2 Actions >>>>>> To IETF DMM working group: >>>>>> ACTION: SA2 would like to kindly ask IETF DMM working group >>>>>>to >>>>>> keep SA2 updated of the work on the subject of including property >>>>>> meta-data in IPv6 ND address assignment procedures for potential use >>>>>> in >>>>>> the 5G System to indicate the mobility property of additional IPv6 >>>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>>> functionality. >>>>>> >>>>>> >>>>>> 3 Dates of next TSG SA WG2 meetings >>>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>>> TSG SA WG2 Meeting 127-Bis 28 May =AD 1 Jun 2018 Newport Beach, US >>>>>> Attachments: >>>>>> >>>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>>> =20 >>>>>> >>>>>>=20 >>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22-3gpp >>>>>>-t >>>>>> sg >>>>>> >>>>>>=20 >>>>>>sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the- >>>>>>ad >>>>>> di >>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>=20 >>=20 From nobody Wed May 2 08:18:42 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E34512D88C; Wed, 2 May 2018 08:18:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dmm-chairs@ietf.org, suresh@kaloom.com, dmm@ietf.org, sgundave@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152527431802.11203.8290773266595743557.idtracker@ietfa.amsl.com> Date: Wed, 02 May 2018 08:18:38 -0700 Archived-At: Subject: [DMM] dmm - New Meeting Session Request for IETF 102 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 15:18:38 -0000 A new meeting session request has just been submitted by Sri Gundavelli, a Chair of the dmm working group. --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Sri Gundavelli Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: ipwave Second Priority: intarea People who must be present: Sri Gundavelli Suresh Krishnan Dapeng Liu Resources Requested: Special Requests: Preferred day: Monday --------------------------------------------------------- From nobody Wed May 2 10:11:04 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B460B124B17; Wed, 2 May 2018 10:11:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sri Gundavelli To: X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Sri Gundavelli , sgundave@cisco.com, iesg-secretary@ietf.org, dmm@ietf.org, Dapeng Liu , dmm-chairs@ietf.org Message-ID: <152528106273.11122.10862854331460176505.idtracker@ietfa.amsl.com> Date: Wed, 02 May 2018 10:11:02 -0700 Archived-At: Subject: [DMM] Publication has been requested for draft-ietf-dmm-ondemand-mobility-14 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 17:11:03 -0000 Sri Gundavelli has requested publication of draft-ietf-dmm-ondemand-mobility-14 as Informational on behalf of the DMM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ From nobody Thu May 3 00:06:26 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79013126D73 for ; Thu, 3 May 2018 00:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV34SptGMgL6 for ; Thu, 3 May 2018 00:06:21 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3658B126B6E for ; Thu, 3 May 2018 00:06:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4376H4G024959; Thu, 3 May 2018 09:06:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 618D020222B; Thu, 3 May 2018 09:06:17 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53B97201365; Thu, 3 May 2018 09:06:17 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4376HTs009673; Thu, 3 May 2018 09:06:17 +0200 To: "Sri Gundavelli (sgundave)" Cc: "dmm@ietf.org" References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: Date: Thu, 3 May 2018 09:06:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 07:06:24 -0000 Le 02/05/2018 à 16:29, Sri Gundavelli (sgundave) a écrit : >> I can agree that the possibility with RADIUS/DIAMETER permits to alocate > a stable prefix in RA to a UE. However, I have never seen it in practice > in a cellular network. > > > Enabling static IP allocation by default has a scaling issue. The IPv6 > prefix that is allocated to the UE is part of an aggregate block > configured on a given PGW node. Reserving IPv6 prefixes from that block > makes that one PGW node as the anchor for that UE. Operators loose > flexibility with respect to gateway assignments. Yes, I agree. > If you look at some of the work that went in 3GPP Rel 10 timeframe, it was > about enhancements to gateway selection logic based on number of > access-network parameters. It allowed operators to allow gateway selection > based on proximity, policy and other parameters. Now, any time there is an > IPv6 prefix reservation that flexibility is lost, as that creates a > Gateway/Subscriber stickiness, and potentially resulting in uneven > distribution of subscriber session across all the gateways. So, this is an > operational problems and may be v6ops is the right group for such > discussions. I can agree - it is an operational issue. It is probably the only reason at this time that makes Mobile IP still necessary. Alex > > > Sri > > > > > > > On 5/2/18, 12:28 AM, "Alexandre Petrescu" > wrote: > >> >> >> Le 25/04/2018 à 05:00, Sri Gundavelli (sgundave) a écrit : >>> Hi Alex, >>> >>> I cannot comment on the supported network/service configuration in any >>> operator's network. But, I’d think the allocation of stable /64’s is >>> similar to static IPv4 (/32) address allocations that are supported in >>> many operator networks today. There are also RADIUS / DIAMETER >>> attributes >>> such as Framed-IPv6-Prefix ..etc which can be used for obtaining >>> statically configured values by PGW. So, IMO, its very much possible to >>> allocate static IPv6 Per-UE prefixes for the UE. Its also possible to >>> allocate static IPv6 prefixes for the networks behind UE. IMO, this is >>> just a configuration and operators can surely do this today. >>> >>> But, I am not sure where we are going with this? >> >> I am asking because I would like it to happen as you describe as being >> possible. >> >> I can agree that the possibility with RADIUS/DIAMETER permits to alocate >> a stable prefix in RA to a UE. >> >> However, I have never seen it in practice in a cellular network. >> >> When I connect I always get a different IPv6 prefix in RA. >> >> Where are we going with this? Let us go towards identifying first if >> _anybody_ (any cellular network) allocates a stable IPv6 prefix in RA to >> UE. It may be someone does allocate such, as it may be nobody does. >> >> In the first case, then I will suggest my operator to do likewise. >> >> In the latter case, then let us go in a direction where we understand >> _why_ operators dont implement stable IPv6 prefixes per UE. >> >> Alex >> >>> >>> >>> Sri >>> >>> >>> >>> >>> On 4/24/18, 7:31 AM, "Alexandre Petrescu" >>> wrote: >>> >>>> Hi Sri, >>>> >>>> Is there an operator today that allocates a stable /64 in RA to User >>>> Equipment? (resists re-connection) >>>> >>>> Alex >>>> >>>> >>>> Le 26/03/2018 à 07:14, Sri Gundavelli (sgundave) a écrit : >>>>> Alex: >>>>> >>>>> This is a good point. Yes, there is DHCPv6 prefix delegation support >>>>> in >>>>> 3GPP architecture for supporting mobile router use-cases. This is >>>>> essentially for delegating prefixes for the networks attached to the >>>>> UE. >>>>> This was introduced in Rel-10 by cisco. I have not followed the recent >>>>> SA2 >>>>> discussions and I do not know if MR support based on DHCPv6 will >>>>> continue >>>>> to be supported or not, and if they have considered the alternative >>>>> options for supporting the same. I think we can certainly ask that >>>>> question, but I also wonder if the coloring is specific to the PDU >>>>> session, or if its broadly applicable for all UE address/prefix >>>>> assignments. >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>>>> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> Le 22/03/2018 à 18:49, Liaison Statement Management Tool a écrit : >>>>>> [...] >>>>>> >>>>>>> SA2 would like to point out that among the four mechanisms for >>>>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, and >>>>>>> in particular the Router Advertisement message, seem to be >>>>>>> applicable >>>>>>> in the 5G System architecture in the specific context of Multi-homed >>>>>>> IPv6 PDU Sessions. >>>>>> Please tell SA2 that current 4G cellular networks are specified to, >>>>>> and >>>>>> do use to some extent, DHCPv6 Prefix Delegation to assign a prefix to >>>>>> an >>>>>> end node like an IoT Router. >>>>>> >>>>>> A /56 prefix delivered to the end node should have the same >>>>>> capabilities >>>>>> as an address. We also want that /56 prefix to be more stable, or >>>>>> less >>>>>> stable, etc. >>>>>> >>>>>> I dont understand why 5G System architecture excludes DHCPv6 from the >>>>>> list of applicable address configuration delivery. >>>>>> >>>>>> I understand why 5G System architectures prefers ND - it is for >>>>>> addresses. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> >>>>>>> With respect to the following question in the IETF¹s reply LS: >>>>>>> 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 request 3GPP to clarify if the Ask is >>>>>>> explicitly >>>>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>>>> >>>>>>> >>>>>>> SA2 would like to clarify that the request is explicitly for IPv6. >>>>>>> SA2 >>>>>>> discussed the example documents that were referenced in your LS >>>>>>> reply >>>>>>> and concluded that the following draft seems to be the most >>>>>>> promising >>>>>>> candidate for the problem under discussion in this correspondence: >>>>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>>>> updated >>>>>>> of the work on the subject of including property meta-data in IPv6 >>>>>>> ND >>>>>>> address assignment procedures for potential use in the 5G System to >>>>>>> indicate the mobility property of additional IPv6 prefixes assigned >>>>>>> as >>>>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>>>> >>>>>>> >>>>>>> 2 Actions >>>>>>> To IETF DMM working group: >>>>>>> ACTION: SA2 would like to kindly ask IETF DMM working group >>>>>>> to >>>>>>> keep SA2 updated of the work on the subject of including property >>>>>>> meta-data in IPv6 ND address assignment procedures for potential use >>>>>>> in >>>>>>> the 5G System to indicate the mobility property of additional IPv6 >>>>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>>>> functionality. >>>>>>> >>>>>>> >>>>>>> 3 Dates of next TSG SA WG2 meetings >>>>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>>>> TSG SA WG2 Meeting 127-Bis 28 May ­ 1 Jun 2018 Newport Beach, US >>>>>>> Attachments: >>>>>>> >>>>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22-3gpp >>>>>>> -t >>>>>>> sg >>>>>>> >>>>>>> >>>>>>> sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the- >>>>>>> ad >>>>>>> di >>>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>> >>> > > From nobody Thu May 3 06:55:45 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41E5126D05 for ; Thu, 3 May 2018 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-Y8pkUth1an for ; Thu, 3 May 2018 06:55:42 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C1F124C27 for ; Thu, 3 May 2018 06:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9960; q=dns/txt; s=iport; t=1525355742; x=1526565342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NkXyUo8bOZfJErlydp7V+G3AXDm5ZFj72KZZsxBszfU=; b=Cb8UFqSLlkxRM4zxtvtBVIEVAgM7abnfIDrMFCbcA6WvhpTGgPY3wJ0+ 9k/1dxDtZzYVUFrV3ApHGaNfrveRHaEWdzWcajatgfL9bpADPfvfEltVw VIztkgO0d/lRD+nJGPWzFjSMap3+UyvKoGrot2jNu9/LetvKuVDdJ5ML0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAwDxE+ta/4wNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYXooCphUgT07gQ+GdowkgXgLGAuEA0YCgi4hNhYBAgE?= =?us-ascii?q?BAQEBAQJsHAyFKAEBAQECAQEBbAsFCwIBCBIGIwshBgsXDgIEDgWEdwMNCA+?= =?us-ascii?q?rAocPDYErgj0FiB2BVD+EGoJPQgEBgTknhVQCl24sCAKLTYJ9gTWDYIdEiga?= =?us-ascii?q?GFQIREwGBJAEjATCBUnAVO4JDgXlPiEiFPQFvAY4WgS6BGAEB?= X-IronPort-AV: E=Sophos;i="5.49,358,1520899200"; d="scan'208";a="390123659" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 13:55:41 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w43Dtf4Q029486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 May 2018 13:55:41 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 08:55:40 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Thu, 3 May 2018 08:55:40 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "dmm@ietf.org" Thread-Topic: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" Thread-Index: AQHT4uZrnEkL3DFdyUeWFUzyYgXURA== Date: Thu, 3 May 2018 13:55:40 +0000 Message-ID: References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 13:55:45 -0000 > It is probably the only reason at this time that makes Mobile IP still >necessary. Not really. You will have the same issue with Mobile IP. Static allocation implies the UE=92s session is anchored on a gateway node which is the topological anchor for that address block. Unless, the assigned prefixes are dynamically programmed (ignoring other issues), UE=92s session always needs to anchored on the same node. Sri On 5/3/18, 12:06 AM, "Alexandre Petrescu" wrote: > > >Le 02/05/2018 =E0 16:29, Sri Gundavelli (sgundave) a =E9crit : >>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>alocate >> a stable prefix in RA to a UE. However, I have never seen it in practice >> in a cellular network. >>=20 >>=20 >> Enabling static IP allocation by default has a scaling issue. The IPv6 >> prefix that is allocated to the UE is part of an aggregate block >> configured on a given PGW node. Reserving IPv6 prefixes from that block >> makes that one PGW node as the anchor for that UE. Operators loose >> flexibility with respect to gateway assignments. > >Yes, I agree. > >> If you look at some of the work that went in 3GPP Rel 10 timeframe, it >>was >> about enhancements to gateway selection logic based on number of >> access-network parameters. It allowed operators to allow gateway >>selection >> based on proximity, policy and other parameters. Now, any time there is >>an >> IPv6 prefix reservation that flexibility is lost, as that creates a >> Gateway/Subscriber stickiness, and potentially resulting in uneven >> distribution of subscriber session across all the gateways. So, this is >>an >> operational problems and may be v6ops is the right group for such >> discussions. > >I can agree - it is an operational issue. > >It is probably the only reason at this time that makes Mobile IP still >necessary. > >Alex > >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 5/2/18, 12:28 AM, "Alexandre Petrescu" >> wrote: >>=20 >>> >>> >>> Le 25/04/2018 =E0 05:00, Sri Gundavelli (sgundave) a =E9crit : >>>> Hi Alex, >>>> >>>> I cannot comment on the supported network/service configuration in any >>>> operator's network. But, I=92d think the allocation of stable /64=92s = is >>>> similar to static IPv4 (/32) address allocations that are supported in >>>> many operator networks today. There are also RADIUS / DIAMETER >>>> attributes >>>> such as Framed-IPv6-Prefix ..etc which can be used for obtaining >>>> statically configured values by PGW. So, IMO, its very much possible >>>>to >>>> allocate static IPv6 Per-UE prefixes for the UE. Its also possible to >>>> allocate static IPv6 prefixes for the networks behind UE. IMO, this is >>>> just a configuration and operators can surely do this today. >>>> >>>> But, I am not sure where we are going with this? >>> >>> I am asking because I would like it to happen as you describe as being >>> possible. >>> >>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>alocate >>> a stable prefix in RA to a UE. >>> >>> However, I have never seen it in practice in a cellular network. >>> >>> When I connect I always get a different IPv6 prefix in RA. >>> >>> Where are we going with this? Let us go towards identifying first if >>> _anybody_ (any cellular network) allocates a stable IPv6 prefix in RA >>>to >>> UE. It may be someone does allocate such, as it may be nobody does. >>> >>> In the first case, then I will suggest my operator to do likewise. >>> >>> In the latter case, then let us go in a direction where we understand >>> _why_ operators dont implement stable IPv6 prefixes per UE. >>> >>> Alex >>> >>>> >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> On 4/24/18, 7:31 AM, "Alexandre Petrescu" >>>> >>>> wrote: >>>> >>>>> Hi Sri, >>>>> >>>>> Is there an operator today that allocates a stable /64 in RA to User >>>>> Equipment? (resists re-connection) >>>>> >>>>> Alex >>>>> >>>>> >>>>> Le 26/03/2018 =E0 07:14, Sri Gundavelli (sgundave) a =E9crit : >>>>>> Alex: >>>>>> >>>>>> This is a good point. Yes, there is DHCPv6 prefix delegation support >>>>>> in >>>>>> 3GPP architecture for supporting mobile router use-cases. This is >>>>>> essentially for delegating prefixes for the networks attached to the >>>>>> UE. >>>>>> This was introduced in Rel-10 by cisco. I have not followed the >>>>>>recent >>>>>> SA2 >>>>>> discussions and I do not know if MR support based on DHCPv6 will >>>>>> continue >>>>>> to be supported or not, and if they have considered the alternative >>>>>> options for supporting the same. I think we can certainly ask that >>>>>> question, but I also wonder if the coloring is specific to the PDU >>>>>> session, or if its broadly applicable for all UE address/prefix >>>>>> assignments. >>>>>> >>>>>> >>>>>> Sri >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Le 22/03/2018 =E0 18:49, Liaison Statement Management Tool a =E9cri= t : >>>>>>> [...] >>>>>>> >>>>>>>> SA2 would like to point out that among the four mechanisms for >>>>>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, >>>>>>>>and >>>>>>>> in particular the Router Advertisement message, seem to be >>>>>>>> applicable >>>>>>>> in the 5G System architecture in the specific context of >>>>>>>>Multi-homed >>>>>>>> IPv6 PDU Sessions. >>>>>>> Please tell SA2 that current 4G cellular networks are specified to, >>>>>>> and >>>>>>> do use to some extent, DHCPv6 Prefix Delegation to assign a prefix >>>>>>>to >>>>>>> an >>>>>>> end node like an IoT Router. >>>>>>> >>>>>>> A /56 prefix delivered to the end node should have the same >>>>>>> capabilities >>>>>>> as an address. We also want that /56 prefix to be more stable, or >>>>>>> less >>>>>>> stable, etc. >>>>>>> >>>>>>> I dont understand why 5G System architecture excludes DHCPv6 from >>>>>>>the >>>>>>> list of applicable address configuration delivery. >>>>>>> >>>>>>> I understand why 5G System architectures prefers ND - it is for >>>>>>> addresses. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> With respect to the following question in the IETF=B9s reply LS: >>>>>>>> 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 request 3GPP to clarify if the Ask is >>>>>>>> explicitly >>>>>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>>>>> >>>>>>>> >>>>>>>> SA2 would like to clarify that the request is explicitly for IPv6. >>>>>>>> SA2 >>>>>>>> discussed the example documents that were referenced in your LS >>>>>>>> reply >>>>>>>> and concluded that the following draft seems to be the most >>>>>>>> promising >>>>>>>> candidate for the problem under discussion in this correspondence: >>>>>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>>>>> updated >>>>>>>> of the work on the subject of including property meta-data in IPv6 >>>>>>>> ND >>>>>>>> address assignment procedures for potential use in the 5G System >>>>>>>>to >>>>>>>> indicate the mobility property of additional IPv6 prefixes >>>>>>>>assigned >>>>>>>> as >>>>>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>>>>> >>>>>>>> >>>>>>>> 2 Actions >>>>>>>> To IETF DMM working group: >>>>>>>> ACTION: SA2 would like to kindly ask IETF DMM working >>>>>>>>group >>>>>>>> to >>>>>>>> keep SA2 updated of the work on the subject of including property >>>>>>>> meta-data in IPv6 ND address assignment procedures for potential >>>>>>>>use >>>>>>>> in >>>>>>>> the 5G System to indicate the mobility property of additional IPv6 >>>>>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>>>>> functionality. >>>>>>>> >>>>>>>> >>>>>>>> 3 Dates of next TSG SA WG2 meetings >>>>>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>>>>> TSG SA WG2 Meeting 127-Bis 28 May =AD 1 Jun 2018 Newport Beach, US >>>>>>>> Attachments: >>>>>>>> >>>>>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>>>>> =20 >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22-3g >>>>>>>>pp >>>>>>>> -t >>>>>>>> sg >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>>sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-th >>>>>>>>e- >>>>>>>> ad >>>>>>>> di >>>>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>> >>>> >>=20 >>=20 From nobody Thu May 3 07:05:17 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2432812E889 for ; Thu, 3 May 2018 07:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0RClPkDPBYF for ; Thu, 3 May 2018 07:05:12 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2782B12E85B for ; Thu, 3 May 2018 07:05:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w43E57Nu018039; Thu, 3 May 2018 16:05:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 912F1205D49; Thu, 3 May 2018 16:05:07 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8328E205C67; Thu, 3 May 2018 16:05:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w43E57BW029752; Thu, 3 May 2018 16:05:07 +0200 To: "Sri Gundavelli (sgundave)" Cc: "dmm@ietf.org" References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: <2b717987-1806-d84b-2525-a41f5bfd97f5@gmail.com> Date: Thu, 3 May 2018 16:05:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 14:05:15 -0000 Le 03/05/2018 à 15:55, Sri Gundavelli (sgundave) a écrit : >> It is probably the only reason at this time that makes Mobile IP still >> necessary. > > > Not really. You will have the same issue with Mobile IP. > > Static allocation implies the UE’s session is anchored on a gateway node > which is the topological anchor for that address block. Well, one can have one own's HA (not cellular network's) to manage the static prefix allocated to the UE, and the cellular network to assign a variable prefix in RA. > Unless, the assigned prefixes are dynamically programmed (ignoring other > issues), UE’s session always needs to anchored on the same node. Yes, the HA. Alex > > Sri > > > > > > On 5/3/18, 12:06 AM, "Alexandre Petrescu" > wrote: > >> >> >> Le 02/05/2018 à 16:29, Sri Gundavelli (sgundave) a écrit : >>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>> alocate >>> a stable prefix in RA to a UE. However, I have never seen it in practice >>> in a cellular network. >>> >>> >>> Enabling static IP allocation by default has a scaling issue. The IPv6 >>> prefix that is allocated to the UE is part of an aggregate block >>> configured on a given PGW node. Reserving IPv6 prefixes from that block >>> makes that one PGW node as the anchor for that UE. Operators loose >>> flexibility with respect to gateway assignments. >> >> Yes, I agree. >> >>> If you look at some of the work that went in 3GPP Rel 10 timeframe, it >>> was >>> about enhancements to gateway selection logic based on number of >>> access-network parameters. It allowed operators to allow gateway >>> selection >>> based on proximity, policy and other parameters. Now, any time there is >>> an >>> IPv6 prefix reservation that flexibility is lost, as that creates a >>> Gateway/Subscriber stickiness, and potentially resulting in uneven >>> distribution of subscriber session across all the gateways. So, this is >>> an >>> operational problems and may be v6ops is the right group for such >>> discussions. >> >> I can agree - it is an operational issue. >> >> It is probably the only reason at this time that makes Mobile IP still >> necessary. >> >> Alex >> >>> >>> >>> Sri >>> >>> >>> >>> >>> >>> >>> On 5/2/18, 12:28 AM, "Alexandre Petrescu" >>> wrote: >>> >>>> >>>> >>>> Le 25/04/2018 à 05:00, Sri Gundavelli (sgundave) a écrit : >>>>> Hi Alex, >>>>> >>>>> I cannot comment on the supported network/service configuration in any >>>>> operator's network. But, I’d think the allocation of stable /64’s is >>>>> similar to static IPv4 (/32) address allocations that are supported in >>>>> many operator networks today. There are also RADIUS / DIAMETER >>>>> attributes >>>>> such as Framed-IPv6-Prefix ..etc which can be used for obtaining >>>>> statically configured values by PGW. So, IMO, its very much possible >>>>> to >>>>> allocate static IPv6 Per-UE prefixes for the UE. Its also possible to >>>>> allocate static IPv6 prefixes for the networks behind UE. IMO, this is >>>>> just a configuration and operators can surely do this today. >>>>> >>>>> But, I am not sure where we are going with this? >>>> >>>> I am asking because I would like it to happen as you describe as being >>>> possible. >>>> >>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>> alocate >>>> a stable prefix in RA to a UE. >>>> >>>> However, I have never seen it in practice in a cellular network. >>>> >>>> When I connect I always get a different IPv6 prefix in RA. >>>> >>>> Where are we going with this? Let us go towards identifying first if >>>> _anybody_ (any cellular network) allocates a stable IPv6 prefix in RA >>>> to >>>> UE. It may be someone does allocate such, as it may be nobody does. >>>> >>>> In the first case, then I will suggest my operator to do likewise. >>>> >>>> In the latter case, then let us go in a direction where we understand >>>> _why_ operators dont implement stable IPv6 prefixes per UE. >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> On 4/24/18, 7:31 AM, "Alexandre Petrescu" >>>>> >>>>> wrote: >>>>> >>>>>> Hi Sri, >>>>>> >>>>>> Is there an operator today that allocates a stable /64 in RA to User >>>>>> Equipment? (resists re-connection) >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> Le 26/03/2018 à 07:14, Sri Gundavelli (sgundave) a écrit : >>>>>>> Alex: >>>>>>> >>>>>>> This is a good point. Yes, there is DHCPv6 prefix delegation support >>>>>>> in >>>>>>> 3GPP architecture for supporting mobile router use-cases. This is >>>>>>> essentially for delegating prefixes for the networks attached to the >>>>>>> UE. >>>>>>> This was introduced in Rel-10 by cisco. I have not followed the >>>>>>> recent >>>>>>> SA2 >>>>>>> discussions and I do not know if MR support based on DHCPv6 will >>>>>>> continue >>>>>>> to be supported or not, and if they have considered the alternative >>>>>>> options for supporting the same. I think we can certainly ask that >>>>>>> question, but I also wonder if the coloring is specific to the PDU >>>>>>> session, or if its broadly applicable for all UE address/prefix >>>>>>> assignments. >>>>>>> >>>>>>> >>>>>>> Sri >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Le 22/03/2018 à 18:49, Liaison Statement Management Tool a écrit : >>>>>>>> [...] >>>>>>>> >>>>>>>>> SA2 would like to point out that among the four mechanisms for >>>>>>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>>>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, >>>>>>>>> and >>>>>>>>> in particular the Router Advertisement message, seem to be >>>>>>>>> applicable >>>>>>>>> in the 5G System architecture in the specific context of >>>>>>>>> Multi-homed >>>>>>>>> IPv6 PDU Sessions. >>>>>>>> Please tell SA2 that current 4G cellular networks are specified to, >>>>>>>> and >>>>>>>> do use to some extent, DHCPv6 Prefix Delegation to assign a prefix >>>>>>>> to >>>>>>>> an >>>>>>>> end node like an IoT Router. >>>>>>>> >>>>>>>> A /56 prefix delivered to the end node should have the same >>>>>>>> capabilities >>>>>>>> as an address. We also want that /56 prefix to be more stable, or >>>>>>>> less >>>>>>>> stable, etc. >>>>>>>> >>>>>>>> I dont understand why 5G System architecture excludes DHCPv6 from >>>>>>>> the >>>>>>>> list of applicable address configuration delivery. >>>>>>>> >>>>>>>> I understand why 5G System architectures prefers ND - it is for >>>>>>>> addresses. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> With respect to the following question in the IETF¹s reply LS: >>>>>>>>> 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 request 3GPP to clarify if the Ask is >>>>>>>>> explicitly >>>>>>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>>>>>> >>>>>>>>> >>>>>>>>> SA2 would like to clarify that the request is explicitly for IPv6. >>>>>>>>> SA2 >>>>>>>>> discussed the example documents that were referenced in your LS >>>>>>>>> reply >>>>>>>>> and concluded that the following draft seems to be the most >>>>>>>>> promising >>>>>>>>> candidate for the problem under discussion in this correspondence: >>>>>>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>>>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>>>>>> updated >>>>>>>>> of the work on the subject of including property meta-data in IPv6 >>>>>>>>> ND >>>>>>>>> address assignment procedures for potential use in the 5G System >>>>>>>>> to >>>>>>>>> indicate the mobility property of additional IPv6 prefixes >>>>>>>>> assigned >>>>>>>>> as >>>>>>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2 Actions >>>>>>>>> To IETF DMM working group: >>>>>>>>> ACTION: SA2 would like to kindly ask IETF DMM working >>>>>>>>> group >>>>>>>>> to >>>>>>>>> keep SA2 updated of the work on the subject of including property >>>>>>>>> meta-data in IPv6 ND address assignment procedures for potential >>>>>>>>> use >>>>>>>>> in >>>>>>>>> the 5G System to indicate the mobility property of additional IPv6 >>>>>>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>>>>>> functionality. >>>>>>>>> >>>>>>>>> >>>>>>>>> 3 Dates of next TSG SA WG2 meetings >>>>>>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>>>>>> TSG SA WG2 Meeting 127-Bis 28 May ­ 1 Jun 2018 Newport Beach, US >>>>>>>>> Attachments: >>>>>>>>> >>>>>>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22-3g >>>>>>>>> pp >>>>>>>>> -t >>>>>>>>> sg >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-th >>>>>>>>> e- >>>>>>>>> ad >>>>>>>>> di >>>>>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From nobody Thu May 3 14:32:13 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E8212EAE0 for ; Thu, 3 May 2018 14:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvx82HLEWVaz for ; Thu, 3 May 2018 14:32:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CCF12E866 for ; Thu, 3 May 2018 14:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=910; q=dns/txt; s=iport; t=1525383129; x=1526592729; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=IYydGXajcziDCaYswZwgs5bwjQzVKsx6+OKZg8qWAII=; b=l0dqyV3ifoFpQ9x85BDKmDHML0xDgVyzM9TzQmbAAnjwVpPqQpxLuw+D K1vFuxrsBknbvpb7/99jG0qpCQ5XcVubYPdBcfXUUrlEant5Ubc+fnTgK MER1/sh95C1EL/ubA02IBPIR1UYUnW2PrakqCohHEzOXUjr6rTTcBRJKb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQATf+ta/4UNJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNDgVsyi2WMb4E9gUqTGxSBZAuHHiE0GAECAQEBAQEBAmwdC4V?= =?us-ascii?q?MHVEBPkInBIUiq2ODOoEeg26CQoglgVQ/hVuCfwESAYVzAocShH6MCggCjkq?= =?us-ascii?q?BNYNgh0SQGwIREwGBJAEcOGFxcBWCf4IrjiKPMYEfgRgBAQ?= X-IronPort-AV: E=Sophos;i="5.49,360,1520899200"; d="scan'208";a="388300312" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 21:32:08 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w43LW8Gn003345 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 May 2018 21:32:08 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 16:32:08 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Thu, 3 May 2018 16:32:08 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT4yYw0Rb3M63dqU2LakuH2Dl9gQ== Date: Thu, 3 May 2018 21:32:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F2E0546F0DF404697B356447361A229@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:32:11 -0000 The DMM working group is planning to meet in IETF 102, week of 16th of July, 2018 at Montreal. We currently have requested for one meeting, which is a 2.5 hour slot. We realize in IETF101 we had many items with a fully packaged agenda, and could not allocate enough time for any of the topics. For this meeting, we want to avoid that problem by asking for an additional meeting slot, but we want to be sure there are enough items for discussion before we lock the resources. So, if you need a presentation slot, please send your request to the chairs (as a response to this email) with the following information. We still have time and so its not required that you need a published I-D, but do let us know in the next few days if you are planning to make a presentation.=20 --- >Topic Name: >Presenter Name: >Time: >Draft Reference: (Optional) >--- Regards Dapeng & Sri >> > From nobody Thu May 3 14:38:36 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2877012EAF3 for ; Thu, 3 May 2018 14:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvzkjBCz2jWl for ; Thu, 3 May 2018 14:38:34 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC79212EAEC for ; Thu, 3 May 2018 14:38:33 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7EE80753D95CE for ; Thu, 3 May 2018 22:38:29 +0100 (IST) Received: from YYZEML702-CHM.china.huawei.com (10.218.33.72) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 3 May 2018 22:38:30 +0100 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.136]) by YYZEML702-CHM.china.huawei.com ([169.254.6.46]) with mapi id 14.03.0382.000; Thu, 3 May 2018 17:38:24 -0400 From: Arashmid Akhavain To: Sri Gundavelli , "dmm@ietf.org" Thread-Topic: draft-gundavelli-dmm-mfa Thread-Index: AdPjJkKqeU0dQ2OyRTS8AFGEhuZHtg== Date: Thu, 3 May 2018 21:38:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.47] Content-Type: multipart/alternative; boundary="_000_D57109449177B54F8B9C093953AC5BCD74B6538DYYZEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] draft-gundavelli-dmm-mfa X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:38:36 -0000 --_000_D57109449177B54F8B9C093953AC5BCD74B6538DYYZEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, Please find below some questions and comments. Best regards, Arashmid 1- This technique certainly eliminates the need for fixed anchor points fro= m the data plane point of view. However, it is not clear what happens to other functions provided by the ex= isting 3GPP fixed anchor points. It should be possible to program the nodes for these additional functions a= s well. I think a list of existing functions or those required by 5G in 3GP= P would be a good starting point for the discussion. 2- Performance is another issue. How fast can we detect and then program MF= A nodes? This is the issue that applies to all different approaches. I thin= k performance merits a section in the draft. 3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document we= ll. Appendix? 4- Page 5, end of MFA-MNA paragraph: " Typically, the MFA-MNA function will be collocated with the UPF in the 3G= PP 5G system architecture." Couldn't it be collocated with the gNB as well? Or did you purposely took g= NB out to avoid touching the N3 interface? 5- When correspondent nodes are mobile themselves. e.g. UE-UE communication= , isn't the MFA-CNA is just another MFA-MNA? Some clarification in the draf= t might come handy. 6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-= CNA in the figure. 7- How does paging work? Not sure about this one, but is it possible for a = UE to go to be idle (a new inactive state has also been added in the spec) = in one gNB and wake in another that connects to a different first hop route= r? 8- Page 19 after step 10: It might be useful to talk about how and when MFA= -CN removes the rule for H1::/64 from AG-2. I guess it is something along w= hat described in 4.3. 9- Page 20, section 4.3, step 1: Might be useful to indicate how the syste= m would know when a flow is inactive and hence the rules associated with it= are no longer need. --_000_D57109449177B54F8B9C093953AC5BCD74B6538DYYZEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sri,

Please find below some questions and comments. =

 

Best regards,

Arashmid

 

1- This technique certainly eliminates the need for = fixed anchor points from the data plane point of view.

However, it is not clear what happens to other funct= ions provided by the existing 3GPP fixed anchor points.

It should be possible to program the nodes for these= additional functions as well. I think a list of existing functions or thos= e required by 5G in 3GPP would be a good starting point for the discussion.=

 

2- Performance is another issue. How fast can we det= ect and then program MFA nodes? This is the issue that applies to all diffe= rent approaches. I think performance merits a section in the draft.

 

3- An example with SRv6 and/or SRv6 with ID-LOC migh= t serve the document well. Appendix?

 

4- Page 5, end of MFA-MNA paragraph:

" Typically, the MFA-MNA function will be collo= cated with the UPF in the 3GPP 5G system architecture."

Couldn't it be collocated with the gNB as well? Or d= id you purposely took gNB out to avoid touching the N3 interface?

 

5- When correspondent nodes are mobile themselves. e= .g. UE-UE communication, isn't the MFA-CNA is just another MFA-MNA? Some cl= arification in the draft might come handy.

 

6- Page 14, figure 5: Need to change MFA-NMAàMFA-MNA, and MFA-CANà MFA-CNA in the figure.

 

7- How does paging work? Not sure about this one, bu= t is it possible for a UE to go to be idle (a new inactive state has also b= een added in the spec) in one gNB and wake in another that connects to a di= fferent first hop router?

 

8- Page 19 after step 10: It might be useful to talk= about how and when MFA-CN removes the rule for H1::/64 from AG-2. I guess = it is something along what described in 4.3.

 

9-  Page 20, section 4.3, step 1: Might be usef= ul to indicate how the system would know when a flow is inactive and hence = the rules associated with it are no longer need.

--_000_D57109449177B54F8B9C093953AC5BCD74B6538DYYZEML701CHMchi_-- From nobody Thu May 3 16:39:40 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0912DA70 for ; Thu, 3 May 2018 16:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34xkHx29BGOD for ; Thu, 3 May 2018 16:39:36 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4899D12DA6A for ; Thu, 3 May 2018 16:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9166; q=dns/txt; s=iport; t=1525390776; x=1526600376; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EAC9VezPanRsU7u8p4NYyEZYjf3nfCYLTAtbRjhqviY=; b=dQX9kH9zC83HTtzWELKsGY/hCtrSyWBtRgt1la4ChqRyQazZhmiaHCJ3 1HHBEv0WLx2o42MlB8hWznhjErKttB7BNWJHrDeRKgXZO2nEDR/n2QnZN n3g+NOB9zFZRkdPdp6u7cb3CHbZMiAb4Ae6E3x8wBKYhyvHW8ZUr8htQp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBynOta/4sNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdmEXYygKi2WMb4E9O4EPjiqEcRSBZAuEbAKCMCE0GAE?= =?us-ascii?q?CAQEBAQEBAmwohSgBAQEBAycGXAIBCBEBAgECKAcyFAMGCAIEARKEK2SqfDO?= =?us-ascii?q?EWINugkKIJYFUP4EOgwyEN1wGhS4ChxKFM4tVCAKOSoE1g2CHRJAbAhETAYE?= =?us-ascii?q?kARw4gVJwFTuCQ4IgF44Xb49hgRgBAQ?= X-IronPort-AV: E=Sophos;i="5.49,360,1520899200"; d="scan'208,217";a="109119505" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 23:39:35 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w43NdZCt021742 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 May 2018 23:39:35 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 18:39:34 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Thu, 3 May 2018 18:39:34 -0500 From: "Sri Gundavelli (sgundave)" To: Arashmid Akhavain , "dmm@ietf.org" Thread-Topic: draft-gundavelli-dmm-mfa Thread-Index: AQHT4zf+wI0651Jd80ScpE1rz+a3pg== Date: Thu, 3 May 2018 23:39:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: multipart/alternative; boundary="_000_D710EB8C2B5868sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] draft-gundavelli-dmm-mfa X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 23:39:39 -0000 --_000_D710EB8C2B5868sgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Arashmid, Thanks for the review feedback !! I will let Marco respond to this thread. Regards Sri From: Arashmid Akhavain > Date: Thursday, May 3, 2018 at 2:38 PM To: Sri Gundavelli >, "dmm@ie= tf.org" > Subject: draft-gundavelli-dmm-mfa Hi Sri, Please find below some questions and comments. Best regards, Arashmid 1- This technique certainly eliminates the need for fixed anchor points fro= m the data plane point of view. However, it is not clear what happens to other functions provided by the ex= isting 3GPP fixed anchor points. It should be possible to program the nodes for these additional functions a= s well. I think a list of existing functions or those required by 5G in 3GP= P would be a good starting point for the discussion. 2- Performance is another issue. How fast can we detect and then program MF= A nodes? This is the issue that applies to all different approaches. I thin= k performance merits a section in the draft. 3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document we= ll. Appendix? 4- Page 5, end of MFA-MNA paragraph: " Typically, the MFA-MNA function will be collocated with the UPF in the 3G= PP 5G system architecture." Couldn't it be collocated with the gNB as well? Or did you purposely took g= NB out to avoid touching the N3 interface? 5- When correspondent nodes are mobile themselves. e.g. UE-UE communication= , isn't the MFA-CNA is just another MFA-MNA? Some clarification in the draf= t might come handy. 6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-= CNA in the figure. 7- How does paging work? Not sure about this one, but is it possible for a = UE to go to be idle (a new inactive state has also been added in the spec) = in one gNB and wake in another that connects to a different first hop route= r? 8- Page 19 after step 10: It might be useful to talk about how and when MFA= -CN removes the rule for H1::/64 from AG-2. I guess it is something along w= hat described in 4.3. 9- Page 20, section 4.3, step 1: Might be useful to indicate how the syste= m would know when a flow is inactive and hence the rules associated with it= are no longer need. --_000_D710EB8C2B5868sgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Arashmid,

Thanks for the review feedback !! I will let Marco respond to this thr= ead.


Regards
Sri


From: Arashmid Akhavain <arashmid.akhavain@huawei.com&g= t;
Date: Thursday, May 3, 2018 at 2:38= PM
To: Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: draft-gundavelli-dmm-mfa

Hi Sri,

Please find below some questions and comments. =

 

Best regards,

Arashmid

 

1- This technique certainly eliminates the need for = fixed anchor points from the data plane point of view.

However, it is not clear what happens to other funct= ions provided by the existing 3GPP fixed anchor points.

It should be possible to program the nodes for these= additional functions as well. I think a list of existing functions or thos= e required by 5G in 3GPP would be a good starting point for the discussion.=

 

2- Performance is another issue. How fast can we det= ect and then program MFA nodes? This is the issue that applies to all diffe= rent approaches. I think performance merits a section in the draft.

 

3- An example with SRv6 and/or SRv6 with ID-LOC migh= t serve the document well. Appendix?

 

4- Page 5, end of MFA-MNA paragraph:

" Typically, the MFA-MNA function will be collo= cated with the UPF in the 3GPP 5G system architecture."

Couldn't it be collocated with the gNB as well? Or d= id you purposely took gNB out to avoid touching the N3 interface?

 

5- When correspondent nodes are mobile themselves. e= .g. UE-UE communication, isn't the MFA-CNA is just another MFA-MNA? Some cl= arification in the draft might come handy.

 

6- Page 14, figure 5: Need to change MFA-NMA=E0MFA-MNA, and MFA-CAN=E0 MFA-CNA in the figure.

 

7- How does paging work? Not sure about this one, bu= t is it possible for a UE to go to be idle (a new inactive state has also b= een added in the spec) in one gNB and wake in another that connects to a di= fferent first hop router?

 

8- Page 19 after step 10: It might be useful to talk= about how and when MFA-CN removes the rule for H1::/64 from AG-2. I guess = it is something along what described in 4.3.

 

9-  Page 20, section 4.3, step 1: Might be usef= ul to indicate how the system would know when a flow is inactive and hence = the rules associated with it are no longer need.

 --_000_D710EB8C2B5868sgundaveciscocom_-- From nobody Thu May 3 16:43:29 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3915712DB6E for ; Thu, 3 May 2018 16:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABROdNjddxrL for ; Thu, 3 May 2018 16:43:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABE312EB29 for ; Thu, 3 May 2018 16:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11592; q=dns/txt; s=iport; t=1525390997; x=1526600597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q5gRrNGjsUu6jcJvK7DZPDprmtr2hX+kni9+/Ef76XI=; b=RhyVJ2LFShaGmoDJ8oWc2oxYMFp34ozNdkixuprTVJppeknrgr8pWhk1 UZmTjSsd1VL7dFh6HOk2euuaGSE3nunjkzpvx2fnLIzjkICXeLl7TY84a muTgrH9ZDk0ex0KeFEoEu6JW9seGXi5SnLP0DZUL88m+M90LquZ77IYhE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAgATnuta/5BdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYXooCphUgT07gQ+GdowlgXgLGAuEA0YCgjAhNRcBAgE?= =?us-ascii?q?BAQEBAQJsHAyFKAEBAQECAQEBbAsQAgEIEgYjCyEGCxcOAgQOBYR3Aw0ID6s?= =?us-ascii?q?lhw4NgSuCPQWIJYFUP4Qagk9CAQGBOSeFVAKXbiwIAotNgn2BNYNgh0SKBoY?= =?us-ascii?q?VAhETAYEkAR4DM4FScBU7gkOBeU+ISIU9AW8BjjKBLoEYAQE?= X-IronPort-AV: E=Sophos;i="5.49,360,1520899200"; d="scan'208";a="108644411" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 23:43:16 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w43NhGNq031579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 May 2018 23:43:16 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 18:43:15 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Thu, 3 May 2018 18:43:15 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "dmm@ietf.org" Thread-Topic: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" Thread-Index: AQHT4ziBTxoW4DTmqEOacMFhXey4VA== Date: Thu, 3 May 2018 23:43:15 +0000 Message-ID: References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> <2b717987-1806-d84b-2525-a41f5bfd97f5@gmail.com> In-Reply-To: <2b717987-1806-d84b-2525-a41f5bfd97f5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="windows-1254" Content-ID: <5DF550A92253604395DE7DBECF39515B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 23:43:25 -0000 >> Well, one can have one own's HA (not cellular network's) to manage the >>static prefix allocated to the UE, and the cellular network to assign a >>variable prefix in RA. Sure, but now the discussion is no longer about the IPv6 prefix allocation for the LTE access. You can do this today if you have a MIPv6 client stack, and its already supported over IKEv2/IPsec. Sri On 5/3/18, 7:05 AM, "Alexandre Petrescu" wrote: > > >Le 03/05/2018 =E0 15:55, Sri Gundavelli (sgundave) a =E9crit : >>> It is probably the only reason at this time that makes Mobile IP still >>> necessary. >>=20 >>=20 >> Not really. You will have the same issue with Mobile IP. >>=20 >> Static allocation implies the UE=92s session is anchored on a gateway no= de >> which is the topological anchor for that address block. > >Well, one can have one own's HA (not cellular network's) to manage the >static prefix allocated to the UE, and the cellular network to assign a >variable prefix in RA. > >> Unless, the assigned prefixes are dynamically programmed (ignoring other >> issues), UE=92s session always needs to anchored on the same node. > >Yes, the HA. > >Alex > >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >> On 5/3/18, 12:06 AM, "Alexandre Petrescu" >> wrote: >>=20 >>> >>> >>> Le 02/05/2018 =E0 16:29, Sri Gundavelli (sgundave) a =E9crit : >>>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>>> alocate >>>> a stable prefix in RA to a UE. However, I have never seen it in >>>>practice >>>> in a cellular network. >>>> >>>> >>>> Enabling static IP allocation by default has a scaling issue. The IPv6 >>>> prefix that is allocated to the UE is part of an aggregate block >>>> configured on a given PGW node. Reserving IPv6 prefixes from that >>>>block >>>> makes that one PGW node as the anchor for that UE. Operators loose >>>> flexibility with respect to gateway assignments. >>> >>> Yes, I agree. >>> >>>> If you look at some of the work that went in 3GPP Rel 10 timeframe, it >>>> was >>>> about enhancements to gateway selection logic based on number of >>>> access-network parameters. It allowed operators to allow gateway >>>> selection >>>> based on proximity, policy and other parameters. Now, any time there >>>>is >>>> an >>>> IPv6 prefix reservation that flexibility is lost, as that creates a >>>> Gateway/Subscriber stickiness, and potentially resulting in uneven >>>> distribution of subscriber session across all the gateways. So, this >>>>is >>>> an >>>> operational problems and may be v6ops is the right group for such >>>> discussions. >>> >>> I can agree - it is an operational issue. >>> >>> It is probably the only reason at this time that makes Mobile IP still >>> necessary. >>> >>> Alex >>> >>>> >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 5/2/18, 12:28 AM, "Alexandre Petrescu" >>>> >>>> wrote: >>>> >>>>> >>>>> >>>>> Le 25/04/2018 =E0 05:00, Sri Gundavelli (sgundave) a =E9crit : >>>>>> Hi Alex, >>>>>> >>>>>> I cannot comment on the supported network/service configuration in >>>>>>any >>>>>> operator's network. But, I=92d think the allocation of stable /64=92= s is >>>>>> similar to static IPv4 (/32) address allocations that are supported >>>>>>in >>>>>> many operator networks today. There are also RADIUS / DIAMETER >>>>>> attributes >>>>>> such as Framed-IPv6-Prefix ..etc which can be used for obtaining >>>>>> statically configured values by PGW. So, IMO, its very much possible >>>>>> to >>>>>> allocate static IPv6 Per-UE prefixes for the UE. Its also possible >>>>>>to >>>>>> allocate static IPv6 prefixes for the networks behind UE. IMO, this >>>>>>is >>>>>> just a configuration and operators can surely do this today. >>>>>> >>>>>> But, I am not sure where we are going with this? >>>>> >>>>> I am asking because I would like it to happen as you describe as >>>>>being >>>>> possible. >>>>> >>>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>>> alocate >>>>> a stable prefix in RA to a UE. >>>>> >>>>> However, I have never seen it in practice in a cellular network. >>>>> >>>>> When I connect I always get a different IPv6 prefix in RA. >>>>> >>>>> Where are we going with this? Let us go towards identifying first if >>>>> _anybody_ (any cellular network) allocates a stable IPv6 prefix in RA >>>>> to >>>>> UE. It may be someone does allocate such, as it may be nobody does. >>>>> >>>>> In the first case, then I will suggest my operator to do likewise. >>>>> >>>>> In the latter case, then let us go in a direction where we understand >>>>> _why_ operators dont implement stable IPv6 prefixes per UE. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> >>>>>> Sri >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4/24/18, 7:31 AM, "Alexandre Petrescu" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hi Sri, >>>>>>> >>>>>>> Is there an operator today that allocates a stable /64 in RA to >>>>>>>User >>>>>>> Equipment? (resists re-connection) >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>> Le 26/03/2018 =E0 07:14, Sri Gundavelli (sgundave) a =E9crit : >>>>>>>> Alex: >>>>>>>> >>>>>>>> This is a good point. Yes, there is DHCPv6 prefix delegation >>>>>>>>support >>>>>>>> in >>>>>>>> 3GPP architecture for supporting mobile router use-cases. This is >>>>>>>> essentially for delegating prefixes for the networks attached to >>>>>>>>the >>>>>>>> UE. >>>>>>>> This was introduced in Rel-10 by cisco. I have not followed the >>>>>>>> recent >>>>>>>> SA2 >>>>>>>> discussions and I do not know if MR support based on DHCPv6 will >>>>>>>> continue >>>>>>>> to be supported or not, and if they have considered the >>>>>>>>alternative >>>>>>>> options for supporting the same. I think we can certainly ask that >>>>>>>> question, but I also wonder if the coloring is specific to the PDU >>>>>>>> session, or if its broadly applicable for all UE address/prefix >>>>>>>> assignments. >>>>>>>> >>>>>>>> >>>>>>>> Sri >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 22/03/2018 =E0 18:49, Liaison Statement Management Tool a =E9c= rit >>>>>>>>>: >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> SA2 would like to point out that among the four mechanisms for >>>>>>>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>>>>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, >>>>>>>>>> and >>>>>>>>>> in particular the Router Advertisement message, seem to be >>>>>>>>>> applicable >>>>>>>>>> in the 5G System architecture in the specific context of >>>>>>>>>> Multi-homed >>>>>>>>>> IPv6 PDU Sessions. >>>>>>>>> Please tell SA2 that current 4G cellular networks are specified >>>>>>>>>to, >>>>>>>>> and >>>>>>>>> do use to some extent, DHCPv6 Prefix Delegation to assign a >>>>>>>>>prefix >>>>>>>>> to >>>>>>>>> an >>>>>>>>> end node like an IoT Router. >>>>>>>>> >>>>>>>>> A /56 prefix delivered to the end node should have the same >>>>>>>>> capabilities >>>>>>>>> as an address. We also want that /56 prefix to be more stable, or >>>>>>>>> less >>>>>>>>> stable, etc. >>>>>>>>> >>>>>>>>> I dont understand why 5G System architecture excludes DHCPv6 from >>>>>>>>> the >>>>>>>>> list of applicable address configuration delivery. >>>>>>>>> >>>>>>>>> I understand why 5G System architectures prefers ND - it is for >>>>>>>>> addresses. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> With respect to the following question in the IETF=B9s reply LS: >>>>>>>>>> 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 request 3GPP to clarify if the Ask is >>>>>>>>>> explicitly >>>>>>>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> SA2 would like to clarify that the request is explicitly for >>>>>>>>>>IPv6. >>>>>>>>>> SA2 >>>>>>>>>> discussed the example documents that were referenced in your LS >>>>>>>>>> reply >>>>>>>>>> and concluded that the following draft seems to be the most >>>>>>>>>> promising >>>>>>>>>> candidate for the problem under discussion in this >>>>>>>>>>correspondence: >>>>>>>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>>>>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>>>>>>> updated >>>>>>>>>> of the work on the subject of including property meta-data in >>>>>>>>>>IPv6 >>>>>>>>>> ND >>>>>>>>>> address assignment procedures for potential use in the 5G System >>>>>>>>>> to >>>>>>>>>> indicate the mobility property of additional IPv6 prefixes >>>>>>>>>> assigned >>>>>>>>>> as >>>>>>>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2 Actions >>>>>>>>>> To IETF DMM working group: >>>>>>>>>> ACTION: SA2 would like to kindly ask IETF DMM working >>>>>>>>>> group >>>>>>>>>> to >>>>>>>>>> keep SA2 updated of the work on the subject of including >>>>>>>>>>property >>>>>>>>>> meta-data in IPv6 ND address assignment procedures for potential >>>>>>>>>> use >>>>>>>>>> in >>>>>>>>>> the 5G System to indicate the mobility property of additional >>>>>>>>>>IPv6 >>>>>>>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>>>>>>> functionality. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3 Dates of next TSG SA WG2 meetings >>>>>>>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>>>>>>> TSG SA WG2 Meeting 127-Bis 28 May =AD 1 Jun 2018 Newport Beach, = US >>>>>>>>>> Attachments: >>>>>>>>>> >>>>>>>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>>>>>>> =20 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>=20 >>>>>>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22- >>>>>>>>>>3g >>>>>>>>>> pp >>>>>>>>>> -t >>>>>>>>>> sg >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>=20 >>>>>>>>>>sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of- >>>>>>>>>>th >>>>>>>>>> e- >>>>>>>>>> ad >>>>>>>>>> di >>>>>>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>=20 >>=20 From nobody Thu May 3 17:25:33 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32A127058 for ; Thu, 3 May 2018 17:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizonwireless.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkcHaVORcW6s for ; Thu, 3 May 2018 17:25:30 -0700 (PDT) Received: from mercury.verizonwireless.com (mercury.verizonwireless.com [162.115.227.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2146F12704A for ; Thu, 3 May 2018 17:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1525393529; x=1556929529; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=e8rdfPmrHMFd2ZYkda824AzQuKEXscZy+0umjGU2+eo=; b=Tkka3/GQXA2DljrS2oUvdy5OhGMF4wLO79kJYqO8fjFJHfdh87xW1non IVpvC4avC8u0sJMaTOmFSpFlznluSIPvWLfL2ewsM5z8d2o9c6uffUiDS Tc97ZZ6qUcgzY1AGzPCoKYScac04Gq5z1IrsYFN1DNhcNubg0+d4bswb3 g=; X-Host: viking.odc.vzwcorp.com Received: from casac1exh003.uswin.ad.vzwcorp.com ([10.11.218.45]) by mercury.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 04 May 2018 00:25:28 +0000 Received: from scwexch05apd.uswin.ad.vzwcorp.com (153.114.130.24) by CASAC1EXH003.uswin.ad.vzwcorp.com (10.11.218.45) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 3 May 2018 17:25:27 -0700 Received: from scwexch12apd.uswin.ad.vzwcorp.com (153.114.130.31) by scwexch05apd.uswin.ad.vzwcorp.com (153.114.130.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 17:25:27 -0700 Received: from scwexch12apd.uswin.ad.vzwcorp.com ([153.114.130.31]) by scwexch12apd.uswin.ad.vzwcorp.com ([153.114.130.31]) with mapi id 15.00.1320.000; Thu, 3 May 2018 17:25:26 -0700 From: "Bogineni, Kalyani" To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT4yYw0Rb3M63dqU2LakuH2Dl9gaQeteiA Date: Fri, 4 May 2018 00:25:26 +0000 Message-ID: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.11.60.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 00:25:32 -0000 Dapeng, Sri: Can you include this in the agenda? Topic Name: Optimized Mobile User Plane Solutions for 5G=20 Presenter Name: Kalyani Bogineni and others Time: 30 minutes Draft Reference: draft-bogineni-dmm-optimized-mobile-user-plane-solutions.t= xt Kalyani -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Thursday, May 3, 2018 5:32 PM To: dmm@ietf.org Subject: [E] [DMM] IETF102 - Call for agenda items The DMM working group is planning to meet in IETF 102, week of 16th of July= , 2018 at Montreal. We currently have requested for one meeting, which is a= 2.5 hour slot. We realize in IETF101 we had many items with a fully packaged agenda, and c= ould not allocate enough time for any of the topics. For this meeting, we w= ant to avoid that problem by asking for an additional meeting slot, but we = want to be sure there are enough items for discussion before we lock the re= sources. So, if you need a presentation slot, please send your request to the chairs= (as a response to this email) with the following information. We still hav= e time and so its not required that you need a published I-D, but do let us= know in the next few days if you are planning to make a presentation.=20 --- >Topic Name: >Presenter Name: >Time: >Draft Reference: (Optional) >--- Regards Dapeng & Sri >> > _______________________________________________ dmm mailing list dmm@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DIdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3Ym= CyVAoiC_ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm= 8flSZ8ZZ7ASgw&e=3D From nobody Thu May 3 20:12:50 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF56126C25 for ; Thu, 3 May 2018 20:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOOaGrwaBcdd for ; Thu, 3 May 2018 20:12:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909571274D2 for ; Thu, 3 May 2018 20:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1996; q=dns/txt; s=iport; t=1525403565; x=1526613165; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tss16qNpUmTFLfHtaNotFKYMF1NzUTsmQdKYFk9xUG4=; b=TkO1CGi8+NYH6ZgJKE9kmj7UIjtc2fIXpoJ2ciI86Mfsw043MfJihXqb EskH7zdVLDntB4RewxzBk3LHDy1k/ocwF9H3rGy50syJrm9Iwhdb/DHyk M52T1PjW0xdVCEPpRl1SlJGZ/61vRQZi+CoGCeQ+o01PWFHC3OKPENRDE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AADQzuta/49dJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYXooCotljG+BPTuBD5MbFIFkCyWERwKCMCE0GAECAQE?= =?us-ascii?q?BAQEBAmwcDIUoAQEBAQMdHTQXBAIBCBEEAQEfCQcyFAkIAgQBEhuEdA+qJIM?= =?us-ascii?q?6gR6DbII9BYglgVQ/hBqBQYFQBBiBEwESAR8HMYUcAocShH6MCggChWKIaIE?= =?us-ascii?q?1g2CHRIlAhlsCERMBgSQBHDhhcXAVO4JDgiyDUIpSbwEBjj6BH4EYAQE?= X-IronPort-AV: E=Sophos;i="5.49,360,1520899200"; d="scan'208";a="382739344" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2018 03:12:44 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w443Cj4p004615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 May 2018 03:12:45 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 22:12:44 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Thu, 3 May 2018 22:12:44 -0500 From: "Sri Gundavelli (sgundave)" To: "Bogineni, Kalyani" , "dmm@ietf.org" Thread-Topic: IETF102 - Call for agenda items Thread-Index: AQHT41XF0Rb3M63dqU2LakuH2Dl9gQ== Date: Fri, 4 May 2018 03:12:44 +0000 Message-ID: References: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> In-Reply-To: <19d362ac8df34281b7875645cd5fae68@scwexch12apd.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 03:12:48 -0000 Kalyani - Sure! Sri On 5/3/18, 5:25 PM, "Bogineni, Kalyani" wrote: >Dapeng, Sri: > >Can you include this in the agenda? > >Topic Name: Optimized Mobile User Plane Solutions for 5G >Presenter Name: Kalyani Bogineni and others >Time: 30 minutes >Draft Reference:=20 >draft-bogineni-dmm-optimized-mobile-user-plane-solutions.txt > >Kalyani > >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >(sgundave) >Sent: Thursday, May 3, 2018 5:32 PM >To: dmm@ietf.org >Subject: [E] [DMM] IETF102 - Call for agenda items > >The DMM working group is planning to meet in IETF 102, week of 16th of >July, 2018 at Montreal. We currently have requested for one meeting, >which is a 2.5 hour slot. > >We realize in IETF101 we had many items with a fully packaged agenda, and >could not allocate enough time for any of the topics. For this meeting, >we want to avoid that problem by asking for an additional meeting slot, >but we want to be sure there are enough items for discussion before we >lock the resources. > >So, if you need a presentation slot, please send your request to the >chairs (as a response to this email) with the following information. We >still have time and so its not required that you need a published I-D, >but do let us know in the next few days if you are planning to make a >presentation.=20 > > > --- >>Topic Name: >>Presenter Name: >>Time: >>Draft Reference: (Optional) >>--- > >Regards >Dapeng & Sri >>> >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_dmm&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DIdiS >ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=3D3YmCyVAoi= C_ >ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY&s=3DAHrommWakT2klf1og05nny7we_JVQm8flSZ8Z= Z7 >ASgw&e=3D From nobody Mon May 7 00:25:37 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2F4126D74 for ; Mon, 7 May 2018 00:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD7vfEh5Ujaf for ; Mon, 7 May 2018 00:25:33 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C63126D0C for ; Mon, 7 May 2018 00:25:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w477PSAE045101; Mon, 7 May 2018 09:25:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3134B202171; Mon, 7 May 2018 09:25:28 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2338420203E; Mon, 7 May 2018 09:25:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w477PRat013990; Mon, 7 May 2018 09:25:28 +0200 To: "Sri Gundavelli (sgundave)" Cc: "dmm@ietf.org" References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> <2b717987-1806-d84b-2525-a41f5bfd97f5@gmail.com> From: Alexandre Petrescu Message-ID: <6396178d-d6d7-81ad-dc71-de5a82c7eaa2@gmail.com> Date: Mon, 7 May 2018 09:25:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 07:25:36 -0000 Le 04/05/2018 à 01:43, Sri Gundavelli (sgundave) a écrit : >>> Well, one can have one own's HA (not cellular network's) to manage the >>> static prefix allocated to the UE, and the cellular network to assign a >>> variable prefix in RA. > > > Sure, but now the discussion is no longer about the IPv6 prefix allocation > for the LTE access. You can do this today if you have a MIPv6 client > stack, and its already supported over IKEv2/IPsec. Sure. Why operators have no scaling issue allocating a stable IPv4 address to UE but have such an issue when allocating a stable IPv6 prefix to UE? Why operators live ok with gateway/subscriber stickiness for IPv4 (and thus allocate a stable IPv4 address to UE) but not for IPv6 (dont allocate a stable IPv6 to UE)? Alex > > > Sri > > > > > > On 5/3/18, 7:05 AM, "Alexandre Petrescu" > wrote: > >> >> >> Le 03/05/2018 à 15:55, Sri Gundavelli (sgundave) a écrit : >>>> It is probably the only reason at this time that makes Mobile IP still >>>> necessary. >>> >>> >>> Not really. You will have the same issue with Mobile IP. >>> >>> Static allocation implies the UE’s session is anchored on a gateway node >>> which is the topological anchor for that address block. >> >> Well, one can have one own's HA (not cellular network's) to manage the >> static prefix allocated to the UE, and the cellular network to assign a >> variable prefix in RA. >> >>> Unless, the assigned prefixes are dynamically programmed (ignoring other >>> issues), UE’s session always needs to anchored on the same node. >> >> Yes, the HA. >> >> Alex >> >>> >>> Sri >>> >>> >>> >>> >>> >>> On 5/3/18, 12:06 AM, "Alexandre Petrescu" >>> wrote: >>> >>>> >>>> >>>> Le 02/05/2018 à 16:29, Sri Gundavelli (sgundave) a écrit : >>>>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>>>> alocate >>>>> a stable prefix in RA to a UE. However, I have never seen it in >>>>> practice >>>>> in a cellular network. >>>>> >>>>> >>>>> Enabling static IP allocation by default has a scaling issue. The IPv6 >>>>> prefix that is allocated to the UE is part of an aggregate block >>>>> configured on a given PGW node. Reserving IPv6 prefixes from that >>>>> block >>>>> makes that one PGW node as the anchor for that UE. Operators loose >>>>> flexibility with respect to gateway assignments. >>>> >>>> Yes, I agree. >>>> >>>>> If you look at some of the work that went in 3GPP Rel 10 timeframe, it >>>>> was >>>>> about enhancements to gateway selection logic based on number of >>>>> access-network parameters. It allowed operators to allow gateway >>>>> selection >>>>> based on proximity, policy and other parameters. Now, any time there >>>>> is >>>>> an >>>>> IPv6 prefix reservation that flexibility is lost, as that creates a >>>>> Gateway/Subscriber stickiness, and potentially resulting in uneven >>>>> distribution of subscriber session across all the gateways. So, this >>>>> is >>>>> an >>>>> operational problems and may be v6ops is the right group for such >>>>> discussions. >>>> >>>> I can agree - it is an operational issue. >>>> >>>> It is probably the only reason at this time that makes Mobile IP still >>>> necessary. >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 5/2/18, 12:28 AM, "Alexandre Petrescu" >>>>> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> Le 25/04/2018 à 05:00, Sri Gundavelli (sgundave) a écrit : >>>>>>> Hi Alex, >>>>>>> >>>>>>> I cannot comment on the supported network/service configuration in >>>>>>> any >>>>>>> operator's network. But, I’d think the allocation of stable /64’s is >>>>>>> similar to static IPv4 (/32) address allocations that are supported >>>>>>> in >>>>>>> many operator networks today. There are also RADIUS / DIAMETER >>>>>>> attributes >>>>>>> such as Framed-IPv6-Prefix ..etc which can be used for obtaining >>>>>>> statically configured values by PGW. So, IMO, its very much possible >>>>>>> to >>>>>>> allocate static IPv6 Per-UE prefixes for the UE. Its also possible >>>>>>> to >>>>>>> allocate static IPv6 prefixes for the networks behind UE. IMO, this >>>>>>> is >>>>>>> just a configuration and operators can surely do this today. >>>>>>> >>>>>>> But, I am not sure where we are going with this? >>>>>> >>>>>> I am asking because I would like it to happen as you describe as >>>>>> being >>>>>> possible. >>>>>> >>>>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>>>> alocate >>>>>> a stable prefix in RA to a UE. >>>>>> >>>>>> However, I have never seen it in practice in a cellular network. >>>>>> >>>>>> When I connect I always get a different IPv6 prefix in RA. >>>>>> >>>>>> Where are we going with this? Let us go towards identifying first if >>>>>> _anybody_ (any cellular network) allocates a stable IPv6 prefix in RA >>>>>> to >>>>>> UE. It may be someone does allocate such, as it may be nobody does. >>>>>> >>>>>> In the first case, then I will suggest my operator to do likewise. >>>>>> >>>>>> In the latter case, then let us go in a direction where we understand >>>>>> _why_ operators dont implement stable IPv6 prefixes per UE. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> >>>>>>> Sri >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/24/18, 7:31 AM, "Alexandre Petrescu" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Sri, >>>>>>>> >>>>>>>> Is there an operator today that allocates a stable /64 in RA to >>>>>>>> User >>>>>>>> Equipment? (resists re-connection) >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> >>>>>>>> Le 26/03/2018 à 07:14, Sri Gundavelli (sgundave) a écrit : >>>>>>>>> Alex: >>>>>>>>> >>>>>>>>> This is a good point. Yes, there is DHCPv6 prefix delegation >>>>>>>>> support >>>>>>>>> in >>>>>>>>> 3GPP architecture for supporting mobile router use-cases. This is >>>>>>>>> essentially for delegating prefixes for the networks attached to >>>>>>>>> the >>>>>>>>> UE. >>>>>>>>> This was introduced in Rel-10 by cisco. I have not followed the >>>>>>>>> recent >>>>>>>>> SA2 >>>>>>>>> discussions and I do not know if MR support based on DHCPv6 will >>>>>>>>> continue >>>>>>>>> to be supported or not, and if they have considered the >>>>>>>>> alternative >>>>>>>>> options for supporting the same. I think we can certainly ask that >>>>>>>>> question, but I also wonder if the coloring is specific to the PDU >>>>>>>>> session, or if its broadly applicable for all UE address/prefix >>>>>>>>> assignments. >>>>>>>>> >>>>>>>>> >>>>>>>>> Sri >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 22/03/2018 à 18:49, Liaison Statement Management Tool a écrit >>>>>>>>>> : >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> SA2 would like to point out that among the four mechanisms for >>>>>>>>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>>>>>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, >>>>>>>>>>> and >>>>>>>>>>> in particular the Router Advertisement message, seem to be >>>>>>>>>>> applicable >>>>>>>>>>> in the 5G System architecture in the specific context of >>>>>>>>>>> Multi-homed >>>>>>>>>>> IPv6 PDU Sessions. >>>>>>>>>> Please tell SA2 that current 4G cellular networks are specified >>>>>>>>>> to, >>>>>>>>>> and >>>>>>>>>> do use to some extent, DHCPv6 Prefix Delegation to assign a >>>>>>>>>> prefix >>>>>>>>>> to >>>>>>>>>> an >>>>>>>>>> end node like an IoT Router. >>>>>>>>>> >>>>>>>>>> A /56 prefix delivered to the end node should have the same >>>>>>>>>> capabilities >>>>>>>>>> as an address. We also want that /56 prefix to be more stable, or >>>>>>>>>> less >>>>>>>>>> stable, etc. >>>>>>>>>> >>>>>>>>>> I dont understand why 5G System architecture excludes DHCPv6 from >>>>>>>>>> the >>>>>>>>>> list of applicable address configuration delivery. >>>>>>>>>> >>>>>>>>>> I understand why 5G System architectures prefers ND - it is for >>>>>>>>>> addresses. >>>>>>>>>> >>>>>>>>>> Alex >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> With respect to the following question in the IETF¹s reply LS: >>>>>>>>>>> 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 request 3GPP to clarify if the Ask is >>>>>>>>>>> explicitly >>>>>>>>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> SA2 would like to clarify that the request is explicitly for >>>>>>>>>>> IPv6. >>>>>>>>>>> SA2 >>>>>>>>>>> discussed the example documents that were referenced in your LS >>>>>>>>>>> reply >>>>>>>>>>> and concluded that the following draft seems to be the most >>>>>>>>>>> promising >>>>>>>>>>> candidate for the problem under discussion in this >>>>>>>>>>> correspondence: >>>>>>>>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>>>>>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>>>>>>>> updated >>>>>>>>>>> of the work on the subject of including property meta-data in >>>>>>>>>>> IPv6 >>>>>>>>>>> ND >>>>>>>>>>> address assignment procedures for potential use in the 5G System >>>>>>>>>>> to >>>>>>>>>>> indicate the mobility property of additional IPv6 prefixes >>>>>>>>>>> assigned >>>>>>>>>>> as >>>>>>>>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2 Actions >>>>>>>>>>> To IETF DMM working group: >>>>>>>>>>> ACTION: SA2 would like to kindly ask IETF DMM working >>>>>>>>>>> group >>>>>>>>>>> to >>>>>>>>>>> keep SA2 updated of the work on the subject of including >>>>>>>>>>> property >>>>>>>>>>> meta-data in IPv6 ND address assignment procedures for potential >>>>>>>>>>> use >>>>>>>>>>> in >>>>>>>>>>> the 5G System to indicate the mobility property of additional >>>>>>>>>>> IPv6 >>>>>>>>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>>>>>>>> functionality. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3 Dates of next TSG SA WG2 meetings >>>>>>>>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>>>>>>>> TSG SA WG2 Meeting 127-Bis 28 May ­ 1 Jun 2018 Newport Beach, US >>>>>>>>>>> Attachments: >>>>>>>>>>> >>>>>>>>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22- >>>>>>>>>>> 3g >>>>>>>>>>> pp >>>>>>>>>>> -t >>>>>>>>>>> sg >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of- >>>>>>>>>>> th >>>>>>>>>>> e- >>>>>>>>>>> ad >>>>>>>>>>> di >>>>>>>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From nobody Mon May 7 07:59:40 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1BA126C89 for ; Mon, 7 May 2018 07:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2hPJeJfsxjW for ; Mon, 7 May 2018 07:59:37 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F03126C26 for ; Mon, 7 May 2018 07:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1578; q=dns/txt; s=iport; t=1525705177; x=1526914777; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cSlazeFxwM7pS7GfoAYpxapUzd3Xjj7SrqOtWltC480=; b=ZX4gE2TrYqLBebp2eQUchXtHViel6l9nJ2qqi83GhZclPIuxYp5j0PNw Y5JvhWwBjQSFfVqYCbK0wq0zMnjmtK7E4sBx2BNg9gUhD4aX/Kg+hv4Tu q8Qq4s0p/1Q07HmygAV5zZpUCcOtC4YnNqs7MktGqFcWzsMZ1fHNqeuGd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQByafBa/5xdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNEgVsoCotnjHOBeYEPhn2MKYF4C4RsAoJPITQYAQIBAQE?= =?us-ascii?q?BAQECbCiFKQEEAXkFCwIBCDsLIRElAgQOBYUJAw0Iqi6HBg2BK4I4iCWBVD+?= =?us-ascii?q?EGoJPgiSFVAKMSYs1LAgCi06CfYxiig+GFgIREwGBJAEcOIFScBWCfoJIjgZ?= =?us-ascii?q?vjmSBGAEB?= X-IronPort-AV: E=Sophos;i="5.49,374,1520899200"; d="scan'208";a="110199548" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2018 14:59:33 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w47ExXQX026028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 May 2018 14:59:33 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 7 May 2018 09:59:32 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Mon, 7 May 2018 09:59:32 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandre Petrescu CC: "dmm@ietf.org" Thread-Topic: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" Thread-Index: AQHT5hQBLD307ytqakC96Q5YWf+i0w== Date: Mon, 7 May 2018 14:59:32 +0000 Message-ID: References: <152174099578.4308.15311731028981741165.idtracker@ietfa.amsl.com> <2b717987-1806-d84b-2525-a41f5bfd97f5@gmail.com> <6396178d-d6d7-81ad-dc71-de5a82c7eaa2@gmail.com> In-Reply-To: <6396178d-d6d7-81ad-dc71-de5a82c7eaa2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.58] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 14:59:39 -0000 > Why operators have no scaling issue allocating a stable IPv4 address to UE but have such an issue when allocating a stable IPv6 prefix to UE? Sure. IPv4 or IPv6, its fundamentally the same issue. May be they will support it in future, or they don=B9t want to extend the same for IPv6. Thi= s is for operators to comment and not for me. I cannot speculate the reasons behind their choices, but I do not see some conspiracy theory behind not extending it to IPv6. Its just flexibility of anchoring nodes on any gateways, IMO. Or, may there are much important reasons than this one that I do not understand. Sri On 5/7/18, 12:25 AM, "Alexandre Petrescu" wrote: > > >Le 04/05/2018 =E0 01:43, Sri Gundavelli (sgundave) a =E9crit : >>>> Well, one can have one own's HA (not cellular network's) to manage the >>>> static prefix allocated to the UE, and the cellular network to assign >>>>a >>>> variable prefix in RA. >>=20 >>=20 >> Sure, but now the discussion is no longer about the IPv6 prefix >>allocation >> for the LTE access. You can do this today if you have a MIPv6 client >> stack, and its already supported over IKEv2/IPsec. > >Sure. > >Why operators have no scaling issue allocating a stable IPv4 address to >UE but have such an issue when allocating a stable IPv6 prefix to UE? > >Why operators live ok with gateway/subscriber stickiness for IPv4 (and >thus allocate a stable IPv4 address to UE) but not for IPv6 (dont >allocate a stable IPv6 to UE)? > >Alex > >>=20 >>=20 >> Sri From nobody Wed May 9 02:06:23 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43788126CD6 for ; Wed, 9 May 2018 02:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I320FnoSSvnT for ; Wed, 9 May 2018 02:06:19 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id D50511241F3 for ; Wed, 9 May 2018 02:06:18 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w49968Y3027882; Wed, 9 May 2018 18:06:08 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 43309EA7A31; Wed, 9 May 2018 18:06:08 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 373C0EA7A03; Wed, 9 May 2018 18:06:08 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.28]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 2F7E04009B4; Wed, 9 May 2018 18:06:08 +0900 (JST) References: From: Shunsuke Homma Message-ID: <390fd5b9-295a-f57f-ac30-f4754872afad@lab.ntt.co.jp> Date: Wed, 9 May 2018 18:05:41 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" , maxpassion@gmail.com X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 09:06:21 -0000 Hi Sri, Dapeng, Can I request a slot for the following draft? Topic Name: Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture Presenter Name: Shunsuke Homma Time: 20-30 mins I-D: draft-homma-dmm-5gs-id-loc-coexistence Best regards Shunsuke On 2018/05/04 6:32, Sri Gundavelli (sgundave) wrote: > The DMM working group is planning to meet in IETF 102, week of 16th of > July, 2018 at Montreal. We currently have requested for one meeting, which > is a 2.5 hour slot. > > We realize in IETF101 we had many items with a fully packaged agenda, and > could not allocate enough time for any of the topics. For this meeting, we > want to avoid that problem by asking for an additional meeting slot, but > we want to be sure there are enough items for discussion before we lock > the resources. > > So, if you need a presentation slot, please send your request to the > chairs (as a response to this email) with the following information. We > still have time and so its not required that you need a published I-D, but > do let us know in the next few days if you are planning to make a > presentation. > > > --- >> Topic Name: >> Presenter Name: >> Time: >> Draft Reference: (Optional) >> --- > > Regards > Dapeng & Sri >>> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed May 9 05:43:19 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0AB1201F8 for ; Wed, 9 May 2018 05:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiPn56RoaaUq for ; Wed, 9 May 2018 05:43:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E391E124205 for ; Wed, 9 May 2018 05:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1904; q=dns/txt; s=iport; t=1525869796; x=1527079396; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gdjla1QEH0fRdaOHTslFQxFzUK0ZvLhRnJJtTcVq6T0=; b=DuLOP7XIRJcASi/YLpOJxsRxEezJgQQuM05ML/6QyG9EENgEYlyC/4GO tT3+sGr/09RPbiJqdHei9I199+J1KHPbFNnaVoadhZMbtzP8v1mE2GyVX rJIomuYFbt0cHabRntUP6RR/9C+TtmvAMuRcBx7UwTW1L5rmbY3KK5kku s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAQAM7PJa/5BdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYXooi3GMcIF5gQ+TKhSBZAsYC4RJAoJnITQYAQIBAQE?= =?us-ascii?q?BAQECbBwMhSgBAQEBAgEBARsdNAsFCwIBCBIGHhAnCxcOAgQOBYMjAoF3CA+?= =?us-ascii?q?qLoM6gR6DaoJDBYglgVQ/gTKCaIFBgVABAYEtARIBH4MwgiQChxUhhF6Eb4c?= =?us-ascii?q?pCAKOTYE1g2CHTpAoAhETAYEkARw4YXFwFTsqAYIYgiyIZIU+bwGObII3AQE?= X-IronPort-AV: E=Sophos;i="5.49,381,1520899200"; d="scan'208";a="174824815" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2018 12:43:16 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w49ChFG5014933 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2018 12:43:15 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 9 May 2018 07:43:15 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Wed, 9 May 2018 07:43:15 -0500 From: "Sri Gundavelli (sgundave)" To: Shunsuke Homma CC: "dmm@ietf.org" , "maxpassion@gmail.com" Thread-Topic: [DMM] IETF102 - Call for agenda items Thread-Index: AQHT53UAdLoR2HaNCUWw+AFQjzzQaaQnV65a Date: Wed, 9 May 2018 12:43:15 +0000 Message-ID: <61EE2DD0-D01F-4AF6-ABA4-2E6B9740206D@cisco.com> References: , <390fd5b9-295a-f57f-ac30-f4754872afad@lab.ntt.co.jp> In-Reply-To: <390fd5b9-295a-f57f-ac30-f4754872afad@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] IETF102 - Call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 12:43:18 -0000 Hi Shunsuke, Sure. Regards Sri > On May 9, 2018, at 2:06 AM, Shunsuke Homma = wrote: >=20 > Hi Sri, Dapeng, >=20 > Can I request a slot for the following draft? >=20 > Topic Name: Co-existence of 3GPP 5GS and Identifier Locator Separation Ar= chitecture > Presenter Name: Shunsuke Homma > Time: 20-30 mins > I-D: draft-homma-dmm-5gs-id-loc-coexistence >=20 > Best regards >=20 > Shunsuke >=20 >> On 2018/05/04 6:32, Sri Gundavelli (sgundave) wrote: >> The DMM working group is planning to meet in IETF 102, week of 16th of >> July, 2018 at Montreal. We currently have requested for one meeting, whi= ch >> is a 2.5 hour slot. >> We realize in IETF101 we had many items with a fully packaged agenda, an= d >> could not allocate enough time for any of the topics. For this meeting, = we >> want to avoid that problem by asking for an additional meeting slot, but >> we want to be sure there are enough items for discussion before we lock >> the resources. >> So, if you need a presentation slot, please send your request to the >> chairs (as a response to this email) with the following information. We >> still have time and so its not required that you need a published I-D, b= ut >> do let us know in the next few days if you are planning to make a >> presentation. >> --- >>> Topic Name: >>> Presenter Name: >>> Time: >>> Draft Reference: (Optional) >>> --- >> Regards >> Dapeng & Sri >>>>=20 >>>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 > --=20 > ---------------------------------- > Shunsuke Homma > > TEL: +81 422 59 3486 > FAX: +81 422 60 7460 >=20 > NTT Network Service Systems Labs. > Musashino city, Tokyo, Japan > ---------------------------------- >=20 From nobody Fri May 11 08:47:23 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9BE127876 for ; Fri, 11 May 2018 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC_eetq9GNq7 for ; Fri, 11 May 2018 08:47:19 -0700 (PDT) Received: from mailer2.neclab.eu (mailer2.neclab.eu [195.37.70.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23880126CBF for ; Fri, 11 May 2018 08:47:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer2.neclab.eu (Postfix) with ESMTP id 5ADE4F20B9; Fri, 11 May 2018 17:47:17 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (neclab.eu) Received: from mailer2.neclab.eu ([127.0.0.1]) by localhost (atlas-b.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCO9QBrBIEQj; Fri, 11 May 2018 17:47:17 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer2.neclab.eu (Postfix) with ESMTPS id 26032F20B2; Fri, 11 May 2018 17:47:11 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.108]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0319.002; Fri, 11 May 2018 17:47:10 +0200 From: Marco Liebsch To: Arashmid Akhavain , Sri Gundavelli , "dmm@ietf.org" Thread-Topic: draft-gundavelli-dmm-mfa Thread-Index: AdPjJkKqeU0dQ2OyRTS8AFGEhuZHtgGEvFwQ Date: Fri, 11 May 2018 15:47:10 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DE03A96EE@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.170] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26DE03A96EEDAPHNISofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] draft-gundavelli-dmm-mfa X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 15:47:23 -0000 --_000_69756203DDDDE64E987BC4F70B71A26DE03A96EEDAPHNISofficehd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Arashmid, please find my take inline [ml]. From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Arashmid Akhavain Sent: Donnerstag, 3. Mai 2018 23:38 To: Sri Gundavelli; dmm@ietf.org Subject: [DMM] draft-gundavelli-dmm-mfa Hi Sri, Please find below some questions and comments. Best regards, Arashmid 1- This technique certainly eliminates the need for fixed anchor points fro= m the data plane point of view. However, it is not clear what happens to other functions provided by the ex= isting 3GPP fixed anchor points. It should be possible to program the nodes for these additional functions a= s well. I think a list of existing functions or those required by 5G in 3GP= P would be a good starting point for the discussion. [ml] Good point, if we think about the MN's AG is a traditional data plane = anchor with some extensions that enable it to be changed per the operation described in this draft, all functions may move to the edge where the AG is= deployed. That may work for metering, paging initiation and QoS in case downstream labels are required for compatibility with the RAN. But = then there is no QoS enforcement in a large part of the network in between the CN and the MN's AG. Hence, the approach would benefit from enforcement = of downlink QoS rules on the CN's anchor /CNA. What do you think? 2- Performance is another issue. How fast can we detect and then program MF= A nodes? This is the issue that applies to all different approaches. I thin= k performance merits a section in the draft. [ml] The draft depicts a reactive approach, which should work and in the wo= rst case it suffers from some packets' re-ordering after enforcing the optimized route. Pro-active extensions should be possible and improve t= hat situation. 3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document we= ll. Appendix? [ml] Are you asking for details about other data plane protocols that are c= urrently being discussed in the IETF? Since the MFA controller enforces pol= icies in the network edges (MN and CN side), these policies can result also in IL= A or LISP mappings per an ingress node operation for the packets, no? The c= urrent draft states at the beginning that it's not dependent on a particular data = plane but it focuses on SRv6 so far. Which of the alternative data plane protocols you think should be covered in the appendix? 4- Page 5, end of MFA-MNA paragraph: " Typically, the MFA-MNA function will be collocated with the UPF in the 3G= PP 5G system architecture." Couldn't it be collocated with the gNB as well? Or did you purposely took g= NB out to avoid touching the N3 interface? [ml] The draft is supposed to be independent of a particular access network= . Move the MNA closer to the access network and you may run your last mile protocol on a 1meter patch cable to the NB. = That's loose coupling and keeps the interface between control plane and the MNA decoupled from the interface between NB and contr= ol plane. Of course you may collocate and run the MNA tightly coupled with any access-specific node and even merg= e the interfaces to the control plane. 5- When correspondent nodes are mobile themselves. e..g. UE-UE communicatio= n, isn't the MFA-CNA is just another MFA-MNA? Some clarification in the dra= ft might come handy. [ml] Sure. To differentiate between policy enforcement points on the data p= lane which are associated with the MN or the CN we chose these abbreviations. They may be of the same type of node. 6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-= CNA in the figure. [ml] Thanks for spotting this, we'll correct in the update. 7- How does paging work? Not sure about this one, but is it possible for a = UE to go to be idle (a new inactive state has also been added in the spec) = in one gNB and wake in another that connects to a different first hop route= r? [ml] adopting the IETF DMM terminology of past work ;-), the dormant monito= ring agent could be in the anchor or current MN-AG and detect packets that are addressed to a MN in dormant mode. Different options exist here. Also, = in case of a reactive mode per this version of the draft, the MN's dormant state may be known only to the MFA NC, which initiates paging = instead of updating the CN's AG and the MN's current AG (which is not known as the MN is in dormant mode..). Multiple good or worse approache= s are possible and this initial draft does not focus on them yet as we want to sketch the key principles first and solicit feedback. 8- Page 19 after step 10: It might be useful to talk about how and when MFA= -CN removes the rule for H1::/64 from AG-2. I guess it is something along w= hat described in 4.3. [ml] Definitely, more details need to be covered. Also here, multiple optio= ns are possible, either remove them after the data session terminated, or k= eep them until the MN enters dormant mode. 9- Page 20, section 4.3, step 1: Might be useful to indicate how the syste= m would know when a flow is inactive and hence the rules associated with it= are no longer need. [ml] Yes, I agree. Another question is whether data flow termination should= serve as only indication to remove these states. In the view of reducing c= ontrol plane load, other events should be considered to remove states. Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26DE03A96EEDAPHNISofficehd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Aras= hmid,

please find my take inline [ml].

&n= bsp;

&n= bsp;

dmm [= mailto:dmm-bounces@ietf.org] On Behalf Of Arashmid Akhavain
Sent: Donnerstag, 3. Mai 2018 23:38
To: Sri Gundavelli; dmm@ietf.org
Subject: [DMM] draft-gundavelli-dmm-mfa

 

Hi Sri,

Please find below some question= s and comments.

 

Best regards,=

Arashmid

 

1- This technique certainly eli= minates the need for fixed anchor points from the data plane point of view.=

However, it is not clear what h= appens to other functions provided by the existing 3GPP fixed anchor points= .

It should be possible to progra= m the nodes for these additional functions as well. I think a list of exist= ing functions or those required by 5G in 3GPP would be a good starting poin= t for the discussion.

&n= bsp;

[ml] Go= od point, if we think about the MN’s AG is a traditional data plane a= nchor with some extensions that enable it to be changed per the operation described in this draft, all functions may move to the edge where the AG is= deployed. That may work for metering, paging initiation and QoS
in case downstream labels are required for compatibility with the RAN. But = then there is no QoS enforcement in a large part of the network in between<= br> the CN and the MN’s AG. Hence, the approach would benefit from enforc= ement of downlink QoS rules on the CN’s anchor /CNA. What do you thin= k?

 

2- Performance is another issue= . How fast can we detect and then program MFA nodes? This is the issue that= applies to all different approaches. I think performance merits a section = in the draft.

&n= bsp;

[ml] Th= e draft depicts a reactive approach, which should work and in the worst cas= e it suffers from some packets’ re-ordering after enforcing
the optimized route. Pro-active extensions should be possible and improve t= hat situation.

&n= bsp;

3- An example with SRv6 and/or = SRv6 with ID-LOC might serve the document well. Appendix?=

&n= bsp;

[ml] Ar= e you asking for details about other data plane protocols that are currentl= y being discussed in the IETF? Since the MFA controller enforces policies in the network edges (MN and CN side), these policies can result also in IL= A or LISP mappings per an ingress node operation for the packets, no? The c= urrent
draft states at the beginning that it’s not dependent on a particular= data plane but it focuses on SRv6 so far. Which of the alternative data
plane protocols you think should be covered in the appendix?

&n= bsp;

4- Page 5, end of MFA-MNA parag= raph:

" Typically, the MFA-MNA f= unction will be collocated with the UPF in the 3GPP 5G system architecture.= "

Couldn't it be collocated with = the gNB as well? Or did you purposely took gNB out to avoid touching the N3= interface?

&n= bsp;

[ml] Th= e draft is supposed to be independent of a particular access network. Move = the MNA closer to the access network
and you may run your last mile protocol on a 1meter patch cable to the NB. = That’s loose coupling and keeps the interface between
control plane and the MNA decoupled from the interface between NB and contr= ol plane. Of course you may collocate
and run the MNA tightly coupled with any access-specific node and even merg= e the interfaces to the control plane.

&n= bsp;

5- When correspondent nodes are= mobile themselves. e..g. UE-UE communication, isn't the MFA-CNA is just an= other MFA-MNA? Some clarification in the draft might come handy.=

&n= bsp;

[ml] Su= re. To differentiate between policy enforcement points on the data plane wh= ich are associated with the MN or the CN we
chose these abbreviations. They may be of the same type of node.=

&n= bsp;

6- Page 14, figure 5: Need to c= hange MFA-NMA= =E0MFA-MNA, and MFA-CAN=E0 MFA-CNA in the figure.

&n= bsp;

[ml] Th= anks for spotting this, we’ll correct in the update.

&n= bsp;

7- How does paging work? Not su= re about this one, but is it possible for a UE to go to be idle (a new inac= tive state has also been added in the spec) in one gNB and wake in another = that connects to a different first hop router?

&n= bsp;

[ml] ad= opting the IETF DMM terminology of past work ;-), the dormant monitoring ag= ent could be in the anchor or current MN-AG and detect packets that
are addressed to a MN in dormant mode. Different options exist here. Also, = in case of a reactive mode per this version of the draft, the
MN’s dormant state may be known only to the MFA NC, which initiates p= aging instead of updating the CN’s AG and the MN’s current AG (= which is
not known as the MN is in dormant mode..). Multiple good or worse approache= s are possible and this initial draft does not focus on them yet as we
want to sketch the key principles first and solicit feedback.

&n= bsp;

8- Page 19 after step 10: It mi= ght be useful to talk about how and when MFA-CN removes the rule for H1::/6= 4 from AG-2. I guess it is something along what described in 4.3.

&n= bsp;

[ml] De= finitely, more details need to be covered. Also here, multiple options are = possible, either remove them after the data session terminated, or keep the= m until the
MN enters dormant mode.

&n= bsp;

9-  Page 20, section 4.3, = step 1: Might be useful to indicate how the system would know when a flow i= s inactive and hence the rules associated with it are no longer need.<= /o:p>

&n= bsp;

[ml] Ye= s, I agree. Another question is whether data flow termination should serve = as only indication to remove these states. In the view of reducing control<= br> plane load, other events should be considered to remove states.<= /span>

&n= bsp;

Best re= gards,

marco

&n= bsp;

&n= bsp;

--_000_69756203DDDDE64E987BC4F70B71A26DE03A96EEDAPHNISofficehd_-- From nobody Tue May 15 00:20:28 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964DE12D778; Tue, 15 May 2018 00:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKcVknDzrGzS; Tue, 15 May 2018 00:20:19 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id D5904127023; Tue, 15 May 2018 00:20:18 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w4F7KGuJ001521; Tue, 15 May 2018 16:20:16 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 0A071EA8093; Tue, 15 May 2018 16:20:16 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id F2CC3EA7EE1; Tue, 15 May 2018 16:20:15 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.28]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id DE6D74005EF; Tue, 15 May 2018 16:20:15 +0900 (JST) References: <152636802001.3766.7474220122681922811.idtracker@ietfa.amsl.com> From: Shunsuke Homma X-Forwarded-Message-Id: <152636802001.3766.7474220122681922811.idtracker@ietfa.amsl.com> Message-ID: <379a638d-3ff2-3991-ab4e-a846be9820f1@lab.ntt.co.jp> Date: Tue, 15 May 2018 16:19:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152636802001.3766.7474220122681922811.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: dmm@ietf.org, 5gangip@ietf.org, ila@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-homma-dmm-5gs-id-loc-coexistence-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 07:20:21 -0000 Hi, We've updated the draft which describes an approach for introducing ID-LOC architecture into 5GS with low-impact. https://www.ietf.org/internet-drafts/draft-homma-dmm-5gs-id-loc-coexistence-01.txt Your feedback would be highly appreciated. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-homma-dmm-5gs-id-loc-coexistence-01.txt Date: Tue, 15 May 2018 00:07:00 -0700 From: internet-drafts@ietf.org To: Kenta Kawakami , Arashmid Akhavain , Shunsuke Homma A new version of I-D, draft-homma-dmm-5gs-id-loc-coexistence-01.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-homma-dmm-5gs-id-loc-coexistence Revision: 01 Title: Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture Document date: 2018-05-15 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-homma-dmm-5gs-id-loc-coexistence-01.txt Status: https://datatracker.ietf.org/doc/draft-homma-dmm-5gs-id-loc-coexistence/ Htmlized: https://tools.ietf.org/html/draft-homma-dmm-5gs-id-loc-coexistence-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-homma-dmm-5gs-id-loc-coexistence Diff: https://www.ietf.org/rfcdiff?url2=draft-homma-dmm-5gs-id-loc-coexistence-01 Abstract: This document describes an approach to introduce Identifier Locator Separation architecture into 3GPP 5GS with low-impact on its specification, and shows the features and considerations of this approach. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue May 15 13:02:08 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1EE127342; Tue, 15 May 2018 13:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152641452209.3704.9900637587233740841@ietfa.amsl.com> Date: Tue, 15 May 2018 13:02:02 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-deployment-models-04.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 20:02:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : DMM Deployment Models and Architectural Considerations Authors : Sri Gundavelli Seil Jeon Filename : draft-ietf-dmm-deployment-models-04.txt Pages : 15 Date : 2018-05-15 Abstract: This document identifies the deployment models for Distributed Mobility Management architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-deployment-models/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-deployment-models-04 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-deployment-models-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-deployment-models-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 15 13:11:03 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D48012E873 for ; Tue, 15 May 2018 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOwdjA4t5lgU for ; Tue, 15 May 2018 13:10:58 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C67312D956 for ; Tue, 15 May 2018 13:10:58 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f8-v6so3410124wmc.4 for ; Tue, 15 May 2018 13:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=NTZrUufNm4JzJd9L/bTj3NE3AzXimQjWcch10z2+eLU=; b=BkiLDL5aRXQlZw6XJHkSTRGiVbhEOHaKPin//ooWBEyZyMiw1JSnV9Z6BW6YIoADIy r3TeJM+fCYgU4zdIBJsDZf3sbDC7DIg2vTeeDwiSftlg6vx2fXbd1+k5+oeH7UQBjm6q YU8zS1YjpPC4CR76opQPYLhoTVBMlbt8fae5cRveQ/1k4qAMT4e+knNsfMZVqqbRy5++ kNhqQgM+/Jd+KGCYigY0AwImkV8zsy+Wx3hMC8je/Od6MFcbSWWTfI4Q2pS//WvLcf/X z8zVA35MzNGvqrBTbPxI4ZvsU3KVlGQvR8K3qt9ejg06H1QFO3IIHsHssdt4/DNIe0VT +ZKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=NTZrUufNm4JzJd9L/bTj3NE3AzXimQjWcch10z2+eLU=; b=IFl6pmcFHzujT536tk9BYAWt3/o0o74qbhQ4Y7RlmWKn43VIBMerQKqWcI4OsW2ORI YYO85iM7+nOsUC0ixHSsfa7FhOtOT9EXFPeVEx/Y5y5RL6/+CuJcdswJ/oIy8odWU4E9 lDQlR/wPfR5+umODuTjMGK3vqz5d476Ol+b9UQekY+q59r8SI6OxQxysRD1vlFPb2RLF Yf+wY3DMhE9tX9U+7NUNPhkk22DjCftIQbZgvVhbAVP0IeYQ1k77KiWuVcgyElLbYR1j vJsg4f/Qek4cdkoz/KdjbusQaj5DvqGLTxcr19QwM7tKylE9nR40UnaXBiRPdcFAMRBw 1k4A== X-Gm-Message-State: ALKqPwfuChb7m9jB7KA2DPMTGhwjayPfdVGhUNJee9e4cFdJQQrw+qXy LPhAiGk3BjcZYWUETnFMiyI= X-Google-Smtp-Source: AB8JxZriufAIc26a3WTUrl3JtuB75dey7sU7/Jy7+uSADL2z7esihO8Vd3ZNThPGDq2IZCn2wDfKPA== X-Received: by 2002:a50:b62c:: with SMTP id b41-v6mr19735708ede.255.1526415056694; Tue, 15 May 2018 13:10:56 -0700 (PDT) Received: from LAPTOPFOEU10F0 (46-253-189-191.dynamic.monzoon.net. [46.253.189.191]) by smtp.gmail.com with ESMTPSA id e24-v6sm481714edc.80.2018.05.15.13.10.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 13:10:55 -0700 (PDT) From: "Seil Jeon" To: Cc: "'Charlie Perkins'" References: <152641452209.3704.9900637587233740841@ietfa.amsl.com> In-Reply-To: <152641452209.3704.9900637587233740841@ietfa.amsl.com> Date: Tue, 15 May 2018 22:10:54 +0200 Message-ID: <004901d3ec88$d4979e50$7dc6daf0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJRTOwfhmEj1O6ZXX2q422MCPb/4KM2dfPA Content-Language: en-us Archived-At: Subject: Re: [DMM] I-D Action: draft-ietf-dmm-deployment-models-04.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 20:11:02 -0000 Hi All, We've just uploaded 04 version for dmm deployment models and architectural considerations. Following the update plan presented in 101th meeting at London, https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-dmm-deploy ment-models-and-architectural-considerations-01, we've revised it. Also, thanks to Charlie's comment in the list, we added the mapping of 3GPP 5G network functions to the DMM functions, dealing what network functions are mapped to the DMM functions with description. Also, abbreviations and nits are checked. Your continuous interest and feedback will be welcome! Regards, Seil Jeon -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, May 15, 2018 10:02 PM To: i-d-announce@ietf.org Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-deployment-models-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : DMM Deployment Models and Architectural Considerations Authors : Sri Gundavelli Seil Jeon Filename : draft-ietf-dmm-deployment-models-04.txt Pages : 15 Date : 2018-05-15 Abstract: This document identifies the deployment models for Distributed Mobility Management architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-deployment-models/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-deployment-models-04 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-deployment-models-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-deployment-models-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Mon May 21 07:24:48 2018 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6013127137; Mon, 21 May 2018 07:24:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Haberman To: Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152691268188.22908.6810216714051964245@ietfa.amsl.com> Date: Mon, 21 May 2018 07:24:41 -0700 Archived-At: Subject: [DMM] Intdir early review of draft-ietf-dmm-ondemand-mobility-14 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 14:24:42 -0000 Reviewer: Brian Haberman Review result: Not Ready This is an early review request for draft-ietf-dmm-ondemand-mobility. I am having a hard time with the thrust of this document. The following issues really need to be addressed in some form... 1. Where is the concept of an IP session defined? Given that IP is connectionless, this term is really about IP address stability and its lifetime. A new term could/should be coined to reflect what is really needed. 2. The needs described in this document have a mix of the ID/Location split issues raised in a variety of other specifications. It would be good to clarify what is different here. 3. The draft only references host-based Mobile IP specifications. What are the implications when other solutions (e.g., PMIP) are employed? 4. It is problematic that this document explicitly rules out of scope any discussion of how this API interacts with address assignment methods (e.g., DHCP). Clearly, there will need to be a way for this API to influence each of the address assignment methods available. Some of the classes of IP addresses described in this document require certain lifetime guarantees from the address assignment method. That needs to addressed since it will require changes to every assignment method. 5. The IETF has a very checkered history of success in getting APIs standardized within the appropriate group (POSIX/Austin/Open). Has this proposed API been discussed within that community? From nobody Wed May 23 10:08:04 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAA412E8D7 for ; Wed, 23 May 2018 10:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sURM7Cvlbehj for ; Wed, 23 May 2018 10:07:55 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008F912E873 for ; Wed, 23 May 2018 10:07:55 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B6FDC7380BB2 for ; Wed, 23 May 2018 18:07:50 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 23 May 2018 18:07:52 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.90]) by SJCEML703-CHM.china.huawei.com ([169.254.5.97]) with mapi id 14.03.0382.000; Wed, 23 May 2018 10:07:47 -0700 From: Uma Chunduri To: Dino Farinacci , Satoru Matsushima CC: dmm Thread-Topic: [DMM] User Plane Protocol Study in 3GPP Thread-Index: AQHTwGu3KCzqWEVQj0G5thzVkVMN9aPZ1QwAgAAO9QCAAARLAIAAW8YAgGOo8/A= Date: Wed, 23 May 2018 17:07:46 +0000 Message-ID: <25B4902B1192E84696414485F57268541358FB5C@sjceml521-mbs.china.huawei.com> References: <10C371AF-8B94-4FDD-B26B-A915CC49CAB5@gmail.com> <736997CE-F6D6-4716-99BB-8D41199A8997@gmail.com> In-Reply-To: <736997CE-F6D6-4716-99BB-8D41199A8997@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] User Plane Protocol Study in 3GPP X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 17:08:02 -0000 RGVhciBBbGwsDQoNCkZvciB0aGUgRGlubydzIHF1ZXN0aW9uIC0NCg0KPiBEbyB5b3UgdGhpbmsg Y2FycmllcnMgd2lsbCBidWlsZCBhbiBJUHY2LW9ubHkgTkdDIGF0IHRoaXMgcG9pbnQgaW4gdGlt ZT8NCg0KSSBkb24ndCB0aGluayBzbyAoZnJvbSB0aGUgZXhpc3RpbmcgZGVwbG95bWVudHMgcGVy c3BlY3RpdmUsIGluY2x1ZGluZyBlYXJseSA1RyB0cmFuc2l0aW9ucykuIA0KDQpTbywgSU1PIC0g YW55IG1vYmlsaXR5IHNvbHV0aW9uIG91Z2h0IHRvIGJlIHVuZGVybGF5IGluZGVwZW5kZW50IC0g dG8gYWxsb3cgZmxleGliaWxpdHkgZm9yIHRoZSBvcGVyYXRvcnMuIEkgc2VlIHRoaXMgZGlzY3Vz c2lvbiBpcyBpbmRlcGVuZGVudCBvZiBhZGRyZXNzIHNwYWNlIGV4aGF1c3Rpb24gb3IgSVB2NiBh ZGRyZXNzIHRvIFVFLi4NCg0KLS0NClVtYSBDLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERpbm8gRmFyaW5hY2NpDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyMCwgMjAxOCA1OjAyIFBNDQpU bzogU2F0b3J1IE1hdHN1c2hpbWEgPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4NCkNjOiBk bW0gPGRtbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRE1NXSBVc2VyIFBsYW5lIFByb3RvY29s IFN0dWR5IGluIDNHUFANCg0KVGhhdCBzb3VuZHMgbGlrZSB5b3Ugd2FudCB0byBkbyBJUHY0IG92 ZXIgSVB2Ni4gRG8geW91IHRoaW5rIGNhcnJpZXJzIHdpbGwgYnVpbGQgYW4gSVB2Ni1vbmx5IE5H QyBhdCB0aGlzIHBvaW50IGluIHRpbWU/DQoNCkRpbm8NCg0KPiBPbiBNYXIgMjAsIDIwMTgsIGF0 IDY6MzMgUE0sIFNhdG9ydSBNYXRzdXNoaW1hIDxzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20+ IHdyb3RlOg0KPiANCj4gTmV4dCBoZWFkZXIgdHlwZSBtYXliZT8NCj4gSW50ZXJlc3RpbmdseSBH VFAtVSBkb2VzbuKAmXQgaGF2ZSBpdC4NCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gDQo+ IDIwMTgvMDMvMjAgMTg6MTfjgIFEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT7j ga7jg6Hjg7zjg6s6DQo+IA0KPj4gSG93PyBQbGVhc2Ugc3VtbWFyaXplIGluIG9uZSBzZW50ZW5j ZSBhbmQgZG9u4oCZdCBtZSB0byBhIGRyYWZ0Lg0KPj4gDQo+PiBEaW5vDQo+PiANCj4+PiBPbiBN YXIgMjAsIDIwMTgsIGF0IDEwOjI0IEFNLCBTYXRvcnUgTWF0c3VzaGltYSA8c2F0b3J1Lm1hdHN1 c2hpbWFAZ21haWwuY29tPiB3cm90ZToNCj4+PiANCj4+PiBZZXMgLCBzdXBwb3J0cyBJUHY0IFBE VSB3aXRoIG1pbmltdW0gZWZmb3J0Lg0KPj4+IA0KPj4+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4+ PiANCj4+PiAyMDE4LzAzLzIwIDE2OjQ344CBTHlsZSBCZXJ0eiA8bHlsZWI1NTExNDRAZ21haWwu Y29tPuOBruODoeODvOODqzoNCj4+PiANCj4+Pj4gSSBkaWQgbm90IGdldCB0byBhc2sgYnV0IEkg a25vdyB5b3VyIHByZXNlbnRhdGlvbiB0YWxrcyBhYm91dCBJUHY2IGJ1dCBpcyB0aGVyZSBhIHJl cXVpcmVtZW50IHRvIHN1cHBvcnQgSVB2NCBtb2JpbGUgb3IgZHVhbCBzdGFjaz8NCj4+Pj4gDQo+ Pj4+IEx5bGUNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IGRtbSBtYWlsaW5nIGxpc3QNCj4+PiBkbW1AaWV0Zi5vcmcNCj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPj4gDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0 DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1t DQo= From nobody Tue May 29 18:22:54 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051E612EB29 for ; Tue, 29 May 2018 18:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a9pEIKEwtxb for ; Tue, 29 May 2018 18:22:45 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38F612FAF4 for ; Tue, 29 May 2018 18:22:41 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id f1-v6so9564982plt.6 for ; Tue, 29 May 2018 18:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tmvqA2+H0s8kcDCF/qMTBbqI7FJIrIda8D+HZ8gMLRI=; b=EsOWrgz2RZUYWbakQIQQXQqbhI6XZQDzSzvwHRtJpYmIuRWBobqeoHDlmVUYEAaxbz rVsBZoIjmsDhMnmbdkjD0cbUGFGaZCGZsBPNJO7maScq92lUjkGJste4Oy6OQJaVdVDb 2edugYdphpHlyJQG3LwkvUhEku/h90S3liQgqmLTiciXihl2kQIp7WTx7xU6e8vi2TBu 7GqaMo977/nVP1Wt07kaQkZ/VD3DXtdN4+FLJ6w9yO8HeFAcDUtOCXESlvX+8VlyQQW9 3lwp8UJKxOjcYN0YNhP43bLAHR/+GakNhQXOrHwe2/b68JA2Nl4CXax7MCeCgRKtJKAv AfSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tmvqA2+H0s8kcDCF/qMTBbqI7FJIrIda8D+HZ8gMLRI=; b=Hp1pTKwKi3UL1rdvQhOijPXp+nWJm+C1W+d9IZhuGzpyGMIchwohKsui3DenPBm2zN YpFuDg5By/rzKWnMVtnZrifC424qV5Vw5ijtpRs2cnUj2iOaD2txCmeq3Ddqnim1tk33 5aD4d7x9SA3BTxwe/f9RUUOYbGJpjmXqp1ps57vIQnb/uPLuvNk5rzvgHpKyKODdOMSw 0LywHqNPHBNQN46Syjq/RiNlsf9apjmRcfkRTiRhAQeTm2peNiCv2nyyKnZEw59faiXw 1OmmbPFQPJ6G4XNz1pmOA4M2RI/feri8rYkzhls9qLkS6HN8XXVP+TDqiBIt9/O0VW63 NTUA== X-Gm-Message-State: ALKqPwfek14JfQp9VygxpLrJBZH2tRoMTDaGw2ROJcsQS7fcUGfrJoHC cucAy8OdXDjaG4makjM2AEM57bht X-Google-Smtp-Source: ADUXVKLUjPU5mcDLuWXb6y14OCeBXSVTOfQzHo6sMScTJQbyOld0YZYSZsC3GJ9BhevweEm8GFH3ew== X-Received: by 2002:a17:902:c81:: with SMTP id 1-v6mr744035plt.126.1527643361059; Tue, 29 May 2018 18:22:41 -0700 (PDT) Received: from [10.207.113.243] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id l71-v6sm24401150pge.8.2018.05.29.18.22.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 18:22:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Satoru Matsushima In-Reply-To: <25B4902B1192E84696414485F57268541358FB5C@sjceml521-mbs.china.huawei.com> Date: Wed, 30 May 2018 10:22:37 +0900 Cc: Dino Farinacci , dmm Content-Transfer-Encoding: quoted-printable Message-Id: References: <10C371AF-8B94-4FDD-B26B-A915CC49CAB5@gmail.com> <736997CE-F6D6-4716-99BB-8D41199A8997@gmail.com> <25B4902B1192E84696414485F57268541358FB5C@sjceml521-mbs.china.huawei.com> To: Uma Chunduri X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [DMM] User Plane Protocol Study in 3GPP X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:22:52 -0000 Hello Uma, let me clarify something.=20 Are you proposing that we need to work on mobile user plane protocol = with IPv4 NAPT? Or, does your employer plan to develop NAPT traversal cellular = equipments and application gateway for the user plane protocol? It seems reinvent of PPTP. Cheers, -satoru > 2018/05/24 2:07=E3=80=81Uma Chunduri = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > Dear All, >=20 > For the Dino's question - >=20 >> Do you think carriers will build an IPv6-only NGC at this point in = time? >=20 > I don't think so (from the existing deployments perspective, including = early 5G transitions).=20 >=20 > So, IMO - any mobility solution ought to be underlay independent - to = allow flexibility for the operators. I see this discussion is = independent of address space exhaustion or IPv6 address to UE.. >=20 > -- > Uma C. >=20 >=20 > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dino Farinacci > Sent: Tuesday, March 20, 2018 5:02 PM > To: Satoru Matsushima > Cc: dmm > Subject: Re: [DMM] User Plane Protocol Study in 3GPP >=20 > That sounds like you want to do IPv4 over IPv6. Do you think carriers = will build an IPv6-only NGC at this point in time? >=20 > Dino >=20 >> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima = wrote: >>=20 >> Next header type maybe? >> Interestingly GTP-U doesn=E2=80=99t have it. >>=20 >> Sent from my iPhone >>=20 >> 2018/03/20 18:17=E3=80=81Dino Farinacci = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >>> How? Please summarize in one sentence and don=E2=80=99t me to a = draft. >>>=20 >>> Dino >>>=20 >>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima = wrote: >>>>=20 >>>> Yes , supports IPv4 PDU with minimum effort. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> 2018/03/20 16:47=E3=80=81Lyle Bertz = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>=20 >>>>> I did not get to ask but I know your presentation talks about IPv6 = but is there a requirement to support IPv4 mobile or dual stack? >>>>>=20 >>>>> Lyle >>>>=20 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue May 29 18:36:16 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5645812EC30 for ; Tue, 29 May 2018 18:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUH6D3NOVl7M for ; Tue, 29 May 2018 18:36:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9DA12EC29 for ; Tue, 29 May 2018 18:36:13 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 47DFBC8F72C2E for ; Wed, 30 May 2018 02:36:10 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 02:36:10 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.90]) by SJCEML702-CHM.china.huawei.com ([169.254.4.203]) with mapi id 14.03.0382.000; Tue, 29 May 2018 18:36:05 -0700 From: Uma Chunduri To: Satoru Matsushima CC: Dino Farinacci , dmm Thread-Topic: [DMM] User Plane Protocol Study in 3GPP Thread-Index: AQHTwGu3KCzqWEVQj0G5thzVkVMN9aPZ1QwAgAAO9QCAAARLAIAAW8YAgGOo8/CACnDfgP//jEAg Date: Wed, 30 May 2018 01:36:04 +0000 Message-ID: <25B4902B1192E84696414485F572685413593A73@sjceml521-mbs.china.huawei.com> References: <10C371AF-8B94-4FDD-B26B-A915CC49CAB5@gmail.com> <736997CE-F6D6-4716-99BB-8D41199A8997@gmail.com> <25B4902B1192E84696414485F57268541358FB5C@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] User Plane Protocol Study in 3GPP X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:36:15 -0000 SGkgU2F0b3J1LA0KDQpJbi1saW5lIFtVbWFdOg0KDQpDaGVlcnMhDQotLQ0KVW1hIEMuDQoocmVz cG9uZGluZyBhcyBhbiBpbmRpdmlkdWFsKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogU2F0b3J1IE1hdHN1c2hpbWEgW21haWx0bzpzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5j b21dIA0KU2VudDogVHVlc2RheSwgTWF5IDI5LCAyMDE4IDY6MjMgUE0NClRvOiBVbWEgQ2h1bmR1 cmkgPHVtYS5jaHVuZHVyaUBodWF3ZWkuY29tPg0KQ2M6IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFj Y2lAZ21haWwuY29tPjsgZG1tIDxkbW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RNTV0gVXNl ciBQbGFuZSBQcm90b2NvbCBTdHVkeSBpbiAzR1BQDQoNCkhlbGxvIFVtYSwgbGV0IG1lIGNsYXJp Znkgc29tZXRoaW5nLiANCg0KQXJlIHlvdSBwcm9wb3NpbmcgdGhhdCB3ZSBuZWVkIHRvIHdvcmsg b24gbW9iaWxlIHVzZXIgcGxhbmUgcHJvdG9jb2wgd2l0aCBJUHY0IE5BUFQ/DQpbVW1hXTogTm9w ZSwgSSBkaWQgbm90IHNheSB0aGF0Lg0KT3IsIGRvZXMgeW91ciBlbXBsb3llciBwbGFuIHRvIGRl dmVsb3AgTkFQVCB0cmF2ZXJzYWwgY2VsbHVsYXIgZXF1aXBtZW50cyBhbmQgYXBwbGljYXRpb24g Z2F0ZXdheSBmb3IgdGhlIHVzZXIgcGxhbmUgcHJvdG9jb2w/DQpbVW1hXTogIFlvdSBhcmUgYXNz dW1pbmcgb24gc29tZXRoaW5nIHdoaWNoIEkgZGlkbid0IHNheSBhbnl0aGluZyBhYm91dC4gIEkg d2FzIGp1c3QgcmVzcG9uZGluZyB0byBEaW5vJ3MgcXVlc3Rpb24gb24gIklQdjYgb25seSBOR0Mi IC4uDQogICAgICAgICAgICAgICAgIA0KDQpJdCBzZWVtcyByZWludmVudCBvZiBQUFRQLg0KDQpD aGVlcnMsDQotc2F0b3J1DQoNCj4gMjAxOC8wNS8yNCAyOjA344CBVW1hIENodW5kdXJpIDx1bWEu Y2h1bmR1cmlAaHVhd2VpLmNvbT7jga7jg6Hjg7zjg6s6DQo+IA0KPiBEZWFyIEFsbCwNCj4gDQo+ IEZvciB0aGUgRGlubydzIHF1ZXN0aW9uIC0NCj4gDQo+PiBEbyB5b3UgdGhpbmsgY2FycmllcnMg d2lsbCBidWlsZCBhbiBJUHY2LW9ubHkgTkdDIGF0IHRoaXMgcG9pbnQgaW4gdGltZT8NCj4gDQo+ IEkgZG9uJ3QgdGhpbmsgc28gKGZyb20gdGhlIGV4aXN0aW5nIGRlcGxveW1lbnRzIHBlcnNwZWN0 aXZlLCBpbmNsdWRpbmcgZWFybHkgNUcgdHJhbnNpdGlvbnMpLiANCj4gDQo+IFNvLCBJTU8gLSBh bnkgbW9iaWxpdHkgc29sdXRpb24gb3VnaHQgdG8gYmUgdW5kZXJsYXkgaW5kZXBlbmRlbnQgLSB0 byBhbGxvdyBmbGV4aWJpbGl0eSBmb3IgdGhlIG9wZXJhdG9ycy4gSSBzZWUgdGhpcyBkaXNjdXNz aW9uIGlzIGluZGVwZW5kZW50IG9mIGFkZHJlc3Mgc3BhY2UgZXhoYXVzdGlvbiBvciBJUHY2IGFk ZHJlc3MgdG8gVUUuLg0KPiANCj4gLS0NCj4gVW1hIEMuDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBEaW5vIEZhcmluYWNjaQ0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAyMCwg MjAxOCA1OjAyIFBNDQo+IFRvOiBTYXRvcnUgTWF0c3VzaGltYSA8c2F0b3J1Lm1hdHN1c2hpbWFA Z21haWwuY29tPg0KPiBDYzogZG1tIDxkbW1AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbRE1N XSBVc2VyIFBsYW5lIFByb3RvY29sIFN0dWR5IGluIDNHUFANCj4gDQo+IFRoYXQgc291bmRzIGxp a2UgeW91IHdhbnQgdG8gZG8gSVB2NCBvdmVyIElQdjYuIERvIHlvdSB0aGluayBjYXJyaWVycyB3 aWxsIGJ1aWxkIGFuIElQdjYtb25seSBOR0MgYXQgdGhpcyBwb2ludCBpbiB0aW1lPw0KPiANCj4g RGlubw0KPiANCj4+IE9uIE1hciAyMCwgMjAxOCwgYXQgNjozMyBQTSwgU2F0b3J1IE1hdHN1c2hp bWEgPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+IE5leHQgaGVh ZGVyIHR5cGUgbWF5YmU/DQo+PiBJbnRlcmVzdGluZ2x5IEdUUC1VIGRvZXNu4oCZdCBoYXZlIGl0 Lg0KPj4gDQo+PiBTZW50IGZyb20gbXkgaVBob25lDQo+PiANCj4+IDIwMTgvMDMvMjAgMTg6MTfj gIFEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT7jga7jg6Hjg7zjg6s6DQo+PiAN Cj4+PiBIb3c/IFBsZWFzZSBzdW1tYXJpemUgaW4gb25lIHNlbnRlbmNlIGFuZCBkb27igJl0IG1l IHRvIGEgZHJhZnQuDQo+Pj4gDQo+Pj4gRGlubw0KPj4+IA0KPj4+PiBPbiBNYXIgMjAsIDIwMTgs IGF0IDEwOjI0IEFNLCBTYXRvcnUgTWF0c3VzaGltYSA8c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwu Y29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IFllcyAsIHN1cHBvcnRzIElQdjQgUERVIHdpdGggbWlu aW11bSBlZmZvcnQuDQo+Pj4+IA0KPj4+PiBTZW50IGZyb20gbXkgaVBob25lDQo+Pj4+IA0KPj4+ PiAyMDE4LzAzLzIwIDE2OjQ344CBTHlsZSBCZXJ0eiA8bHlsZWI1NTExNDRAZ21haWwuY29tPuOB ruODoeODvOODqzoNCj4+Pj4gDQo+Pj4+PiBJIGRpZCBub3QgZ2V0IHRvIGFzayBidXQgSSBrbm93 IHlvdXIgcHJlc2VudGF0aW9uIHRhbGtzIGFib3V0IElQdjYgYnV0IGlzIHRoZXJlIGEgcmVxdWly ZW1lbnQgdG8gc3VwcG9ydCBJUHY0IG1vYmlsZSBvciBkdWFsIHN0YWNrPw0KPj4+Pj4gDQo+Pj4+ PiBMeWxlDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiBkbW0gbWFpbGluZyBsaXN0DQo+Pj4+IGRtbUBpZXRmLm9yZw0KPj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPj4+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZG1tIG1h aWxpbmcgbGlzdA0KPiBkbW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbW0NCg0K From nobody Tue May 29 18:55:06 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E550012E86E for ; Tue, 29 May 2018 18:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3O93UPxLlnu for ; Tue, 29 May 2018 18:55:02 -0700 (PDT) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B265E12EB35 for ; Tue, 29 May 2018 18:55:02 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id bi12-v6so10048613plb.12 for ; Tue, 29 May 2018 18:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r+Wkxi4XdkGa00fKAUkhZLQPRVlgeTbQHOFTN/g+FUQ=; b=GYHPBkqcYDiJkgyUWy2JLjmo9kY8+Z4Y2G9tVUT6bTEdFNudMfHUUwP6oqZFbWP2qk sHjG5J1qvD8IvODOnJAe/QvMWFQTI7jMnN1jpNSCCjbSzb1WilWnWzTGmG+uiOesYJHa 73fz4API+CyCi9UudfyZZwrET1/AOpvPY4vtDvaYxnK9EsECGTpzab7zaWor+rla0Zrl qMZRTlrq6Y+iJuCsM0L3Jww12oeHeNbJWROQGVVQ12zU+GWkSv1mxGlWPbEUbQFTSrLp 6D2J2+MKP9E28ry1mi3f4xAa76Y2bbKZVjJ4QtT6nLr5QzkfPxvzyrWT86K+LqaFPYsv qWqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r+Wkxi4XdkGa00fKAUkhZLQPRVlgeTbQHOFTN/g+FUQ=; b=Ae5GHkK1uI1n47ZdUNIathVm7A99Wk51t02EGZS/Ep+eDl70b7fczCjV5vZiuwx6tn 3YlITDmUr4fthw0dVsFHoua0VJf+qr2lwGw+nk+njUf6vraOgKI1fB/MZ72ZNutSEu5x 95rqYor7z+cNXMZ2aXdfhC6W0H9/Wow+B3JzCU2di9FB4EYELZtOFgR7ivMiaGl7E1AG 7UY1lQrmoxznC8LPkhEbbB5qjkFTrKcOSB8OUHYqMPz5NNrQdJVnz9NcmSWiAx6PA0Ae 2Ag2Aav+7hdH85oAh+sVmbAyYSy/zNoJecYTPLwbw68+8BopqJhGCZQtoH5YrewKVpGx d6/g== X-Gm-Message-State: ALKqPwcsv2C+Woff4F7EhoAHtyn6hrujlx7Yl4ikCM3+REOWt/RooGr4 o2928QudYnnli7kCdjhTLFY= X-Google-Smtp-Source: ADUXVKLo1iT1TBkjinS7w6u1LfWZzmn6w1MC1c2BoVBxdGdBh5Cp54BRqLYcZz19YxbKyVQzHI1QQw== X-Received: by 2002:a17:902:a5c7:: with SMTP id t7-v6mr849916plq.360.1527645302069; Tue, 29 May 2018 18:55:02 -0700 (PDT) Received: from [10.207.113.243] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id j1-v6sm55448256pfh.95.2018.05.29.18.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 18:55:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Satoru Matsushima In-Reply-To: <25B4902B1192E84696414485F572685413593A73@sjceml521-mbs.china.huawei.com> Date: Wed, 30 May 2018 10:54:34 +0900 Cc: Dino Farinacci , dmm Content-Transfer-Encoding: quoted-printable Message-Id: References: <10C371AF-8B94-4FDD-B26B-A915CC49CAB5@gmail.com> <736997CE-F6D6-4716-99BB-8D41199A8997@gmail.com> <25B4902B1192E84696414485F57268541358FB5C@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413593A73@sjceml521-mbs.china.huawei.com> To: Uma Chunduri X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [DMM] User Plane Protocol Study in 3GPP X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:55:05 -0000 Uma, I=E2=80=99m happy to hear that from you.=20 I was just afraid that some vendors are trying to sell NAPT traversal = cellular boxes with additional license fee.=20 As you all know, 5G radio requires us to deploy APs much dense that we = expect several or many IPv4 10/8 and even 100.64/10 should be required = to cover the footprint of operators. What I imagined was if a business person in a vendor finds that hidden = bottleneck, I expected that the guy proposes NAPT traversal products to = his company and easily convinced to get the go sign. I have to admit that he/she must be a smart business person. If a = operator who fully depends on IPv4 as backhaul/core transport, I expect = that the operator couldn't resist to that attractive proposal.=20 I hope you don=E2=80=99t do that even after you know my imagination. Cheers, --satoru > 2018/05/30 10:36=E3=80=81Uma Chunduri = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > Hi Satoru, >=20 > In-line [Uma]: >=20 > Cheers! > -- > Uma C. > (responding as an individual) >=20 > -----Original Message----- > From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com]=20 > Sent: Tuesday, May 29, 2018 6:23 PM > To: Uma Chunduri > Cc: Dino Farinacci ; dmm > Subject: Re: [DMM] User Plane Protocol Study in 3GPP >=20 > Hello Uma, let me clarify something.=20 >=20 > Are you proposing that we need to work on mobile user plane protocol = with IPv4 NAPT? > [Uma]: Nope, I did not say that. > Or, does your employer plan to develop NAPT traversal cellular = equipments and application gateway for the user plane protocol? > [Uma]: You are assuming on something which I didn't say anything = about. I was just responding to Dino's question on "IPv6 only NGC" .. >=20 >=20 > It seems reinvent of PPTP. >=20 > Cheers, > -satoru >=20 >> 2018/05/24 2:07=E3=80=81Uma Chunduri = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >> Dear All, >>=20 >> For the Dino's question - >>=20 >>> Do you think carriers will build an IPv6-only NGC at this point in = time? >>=20 >> I don't think so (from the existing deployments perspective, = including early 5G transitions).=20 >>=20 >> So, IMO - any mobility solution ought to be underlay independent - to = allow flexibility for the operators. I see this discussion is = independent of address space exhaustion or IPv6 address to UE.. >>=20 >> -- >> Uma C. >>=20 >>=20 >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dino Farinacci >> Sent: Tuesday, March 20, 2018 5:02 PM >> To: Satoru Matsushima >> Cc: dmm >> Subject: Re: [DMM] User Plane Protocol Study in 3GPP >>=20 >> That sounds like you want to do IPv4 over IPv6. Do you think carriers = will build an IPv6-only NGC at this point in time? >>=20 >> Dino >>=20 >>> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima = wrote: >>>=20 >>> Next header type maybe? >>> Interestingly GTP-U doesn=E2=80=99t have it. >>>=20 >>> Sent from my iPhone >>>=20 >>> 2018/03/20 18:17=E3=80=81Dino Farinacci = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>=20 >>>> How? Please summarize in one sentence and don=E2=80=99t me to a = draft. >>>>=20 >>>> Dino >>>>=20 >>>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima = wrote: >>>>>=20 >>>>> Yes , supports IPv4 PDU with minimum effort. >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> 2018/03/20 16:47=E3=80=81Lyle Bertz = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>=20 >>>>>> I did not get to ask but I know your presentation talks about = IPv6 but is there a requirement to support IPv4 mobile or dual stack? >>>>>>=20 >>>>>> Lyle >>>>>=20 >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Wed May 30 11:57:27 2018 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5F1120724 for ; Wed, 30 May 2018 11:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iatWPPBrF7dU for ; Wed, 30 May 2018 11:57:23 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BB21270AE for ; Wed, 30 May 2018 11:57:23 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 895E9366ED1E0 for ; Wed, 30 May 2018 19:57:19 +0100 (IST) Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 30 May 2018 19:57:21 +0100 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.97]) by YYZEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0382.000; Wed, 30 May 2018 14:57:14 -0400 From: Arashmid Akhavain To: Uma Chunduri , Dino Farinacci , Satoru Matsushima CC: dmm Thread-Topic: [DMM] User Plane Protocol Study in 3GPP Thread-Index: AQHTwGu3KCzqWEVQj0G5thzVkVMN9aPZ1QwAgAAO9QCAAARLAIAAW8YAgGOo8/CACx7kYA== Date: Wed, 30 May 2018 18:57:13 +0000 Message-ID: References: <10C371AF-8B94-4FDD-B26B-A915CC49CAB5@gmail.com> <736997CE-F6D6-4716-99BB-8D41199A8997@gmail.com> <25B4902B1192E84696414485F57268541358FB5C@sjceml521-mbs.china.huawei.com> In-Reply-To: <25B4902B1192E84696414485F57268541358FB5C@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] User Plane Protocol Study in 3GPP X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 18:57:26 -0000 WW91IGFyZSByaWdodCBVbWEsDQoNCkFueSBkZXBsb3ltZW50IHNjZW5hcmlvIChhc2lkZSBmcm9t IGdyZWVuLWZpZWxkKSB3aWxsIGludm9sdmUgYSBjb21iaW5hdGlvbiBvZiBib3RoIGFkZHJlc3Mg dHlwZXMuDQpJUHY0IHdpbGwgYmUgdGhlIGRvbWluYW50IHR5cGUgYXQgZmlyc3Qgd2hpbGUgSVB2 NiBnZXRzIGludHJvZHVjZWQgZ3JhZHVhbGx5Lg0KQW55IG1vYmlsaXR5IHNvbHV0aW9uIG11c3Qg YWRkcmVzcyBtaWdyYXRpb24uIEJsYW5rIGNhbnZhcyBpcyBhIG5vbnN0YXJ0ZXIgZm9yIG9wZXJh dG9ycy4NCg0KQXJhc2htaWQNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFVt YSBDaHVuZHVyaQ0KPiBTZW50OiAyMyBNYXkgMjAxOCAxMzowOA0KPiBUbzogRGlubyBGYXJpbmFj Y2kgPGZhcmluYWNjaUBnbWFpbC5jb20+OyBTYXRvcnUgTWF0c3VzaGltYQ0KPiA8c2F0b3J1Lm1h dHN1c2hpbWFAZ21haWwuY29tPg0KPiBDYzogZG1tIDxkbW1AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6 IFJlOiBbRE1NXSBVc2VyIFBsYW5lIFByb3RvY29sIFN0dWR5IGluIDNHUFANCj4gDQo+IERlYXIg QWxsLA0KPiANCj4gRm9yIHRoZSBEaW5vJ3MgcXVlc3Rpb24gLQ0KPiANCj4gPiBEbyB5b3UgdGhp bmsgY2FycmllcnMgd2lsbCBidWlsZCBhbiBJUHY2LW9ubHkgTkdDIGF0IHRoaXMgcG9pbnQgaW4g dGltZT8NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgc28gKGZyb20gdGhlIGV4aXN0aW5nIGRlcGxveW1l bnRzIHBlcnNwZWN0aXZlLCBpbmNsdWRpbmcgZWFybHkNCj4gNUcgdHJhbnNpdGlvbnMpLg0KPiAN Cj4gU28sIElNTyAtIGFueSBtb2JpbGl0eSBzb2x1dGlvbiBvdWdodCB0byBiZSB1bmRlcmxheSBp bmRlcGVuZGVudCAtIHRvIGFsbG93DQo+IGZsZXhpYmlsaXR5IGZvciB0aGUgb3BlcmF0b3JzLiBJ IHNlZSB0aGlzIGRpc2N1c3Npb24gaXMgaW5kZXBlbmRlbnQgb2YgYWRkcmVzcw0KPiBzcGFjZSBl eGhhdXN0aW9uIG9yIElQdjYgYWRkcmVzcyB0byBVRS4uDQo+IA0KPiAtLQ0KPiBVbWEgQy4NCj4g DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbW0gW21haWx0bzpk bW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERpbm8gRmFyaW5hY2NpDQo+IFNlbnQ6 IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDE4IDU6MDIgUE0NCj4gVG86IFNhdG9ydSBNYXRzdXNoaW1h IDxzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20+DQo+IENjOiBkbW0gPGRtbUBpZXRmLm9yZz4N Cj4gU3ViamVjdDogUmU6IFtETU1dIFVzZXIgUGxhbmUgUHJvdG9jb2wgU3R1ZHkgaW4gM0dQUA0K PiANCj4gVGhhdCBzb3VuZHMgbGlrZSB5b3Ugd2FudCB0byBkbyBJUHY0IG92ZXIgSVB2Ni4gRG8g eW91IHRoaW5rIGNhcnJpZXJzIHdpbGwNCj4gYnVpbGQgYW4gSVB2Ni1vbmx5IE5HQyBhdCB0aGlz IHBvaW50IGluIHRpbWU/DQo+IA0KPiBEaW5vDQo+IA0KPiA+IE9uIE1hciAyMCwgMjAxOCwgYXQg NjozMyBQTSwgU2F0b3J1IE1hdHN1c2hpbWENCj4gPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNv bT4gd3JvdGU6DQo+ID4NCj4gPiBOZXh0IGhlYWRlciB0eXBlIG1heWJlPw0KPiA+IEludGVyZXN0 aW5nbHkgR1RQLVUgZG9lc27igJl0IGhhdmUgaXQuDQo+ID4NCj4gPiBTZW50IGZyb20gbXkgaVBo b25lDQo+ID4NCj4gPiAyMDE4LzAzLzIwIDE4OjE344CBRGlubyBGYXJpbmFjY2kgPGZhcmluYWNj aUBnbWFpbC5jb20+44Gu44Oh44O844OrOg0KPiA+DQo+ID4+IEhvdz8gUGxlYXNlIHN1bW1hcml6 ZSBpbiBvbmUgc2VudGVuY2UgYW5kIGRvbuKAmXQgbWUgdG8gYSBkcmFmdC4NCj4gPj4NCj4gPj4g RGlubw0KPiA+Pg0KPiA+Pj4gT24gTWFyIDIwLCAyMDE4LCBhdCAxMDoyNCBBTSwgU2F0b3J1IE1h dHN1c2hpbWENCj4gPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+Pg0K PiA+Pj4gWWVzICwgc3VwcG9ydHMgSVB2NCBQRFUgd2l0aCBtaW5pbXVtIGVmZm9ydC4NCj4gPj4+ DQo+ID4+PiBTZW50IGZyb20gbXkgaVBob25lDQo+ID4+Pg0KPiA+Pj4gMjAxOC8wMy8yMCAxNjo0 N+OAgUx5bGUgQmVydHogPGx5bGViNTUxMTQ0QGdtYWlsLmNvbT7jga7jg6Hjg7zjg6s6DQo+ID4+ Pg0KPiA+Pj4+IEkgZGlkIG5vdCBnZXQgdG8gYXNrIGJ1dCBJIGtub3cgeW91ciBwcmVzZW50YXRp b24gdGFsa3MgYWJvdXQgSVB2NiBidXQgaXMNCj4gdGhlcmUgYSByZXF1aXJlbWVudCB0byBzdXBw b3J0IElQdjQgbW9iaWxlIG9yIGR1YWwgc3RhY2s/DQo+ID4+Pj4NCj4gPj4+PiBMeWxlDQo+ID4+ Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+IGRtbSBtYWlsaW5nIGxpc3QNCj4gPj4+IGRtbUBpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gPj4NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRtbSBtYWlsaW5nIGxp c3QNCj4gZG1tQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZG1tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IGRtbSBtYWlsaW5nIGxpc3QNCj4gZG1tQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo=