From nobody Tue Apr 1 20:08:19 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667D51A00BD for ; Tue, 1 Apr 2014 20:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JZy0_GBvJIIR for ; Tue, 1 Apr 2014 20:07:41 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECBE1A00DA for ; Tue, 1 Apr 2014 20:07:30 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 10so8349676ykt.18 for ; Tue, 01 Apr 2014 20:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lV/0+V0EtoW+Y5xr1E1s539J7H5pIbxIzog7XOdY6K8=; b=evqQYAFGxu1nNMMx1qFbAGwRj1R2u3va620NUv17Rz9yXJK1mXgCTsaVvbYW53wX+5 cZmChc0hFuWvAV81+0AZd1MF9pGhyDKUHtpVn06mSWMWEQ5aJgPUkpyquYkwRRLbQn6q W32uSU+SImiQaZBkoBT3KjQFrQxvBNBUm617xE0akxT3tG6Gu7ekfUfnrrYrYQB+gzeW 5hX/VxcFGOyuaqq08K86bnk/GGPKyrueV7tDvDsHuqiT2D9+d29K/QKwjThWOmAbNH9M gFM9TbkCpQGX2qpbGftcn89KRnqmT+4n5yTEg8Yx3hZLHAe4KY7baamG/N/Qbc7JMswa 1IYA== MIME-Version: 1.0 X-Received: by 10.236.77.165 with SMTP id d25mr14242yhe.119.1396408046490; Tue, 01 Apr 2014 20:07:26 -0700 (PDT) Received: by 10.170.161.194 with HTTP; Tue, 1 Apr 2014 20:07:26 -0700 (PDT) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FE19@szxeml522-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FBA1@szxeml522-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE753D9FE19@szxeml522-mbx.china.huawei.com> Date: Wed, 2 Apr 2014 12:07:26 +0900 Message-ID: From: Satoru Matsushima To: Peter McCann Content-Type: multipart/alternative; boundary=20cf30050d7e92998004f60695f1 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/FTu0uvtXsM2N00I_g_NyTnO77Ew Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 03:08:03 -0000 --20cf30050d7e92998004f60695f1 Content-Type: text/plain; charset=ISO-8859-1 Peter, On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann wrote: --snip-- > > No, it isn't meant that specific routes to indicate each UEs prefix > > are advertised into the core. > > I'll try to improve that text in next revision of the draft. > > Yes please clarify because the current text seems to say that UE prefixes > are advertised into the core. > > Yes, thanks. > > I agree with you if a EPC-E has whole UE specific routes that exceed > > its capacity, it doesn't scale, yes. In the recent presentation > > through the webex, Ryuji were trying to explain that it's not intended > to do. > > Routes contained in EPC-E will be limited/partitioned by operators > > policy, such as region, service, population scale, etc., > > I was a bit confused by the suggestion to partition by region, because > there would be no mobility across regions if you partitioned in this way. > That's because different regions would use different PDN prefixes. But, > I suppose it would be ok to do this if you didn't need to support UE > mobility across regions (or if you used OTT mobility such as client MIP > for those cases). > > Partitioned by region sounds like that each regional network is isolated so that they has no connectivity between them. But it is not what I meant. Although a PDN prefix would be partitioned by region, the networks doesn't really need to be isolated. For example, when all EPC-E routers have connectivity to reach all RAN nodes, it makes easy to provide mobility across regions. Do you think that describing in the draft this kind of networking concept would be helpful to make things clear? > >> You seem to attempt to address this issue in Section 4.1 when you > talk > >> about multiple "sets" of EPC-E devices, each one dedicated to a > given > >> geographic region. > > > > > > Ah, no. Sec 4.1 is intended to explain just scalability issue, and how > > to deal that issues with routing techniques in operation. > > Ok, I guess in the most common case you would have several "slices" of > EPC-E, each set serving a different PDN prefix and a different set of UEs. > There would be one EPC-E from each slice, each representing a partition of > the PDN prefixes, at each EPC-E deployment site between eNBs and core. > A given UE's current location would need to be BGP UPDATEd to each of the > EPC-E in the slice that covered that UE's PDN prefix. > In my mind, that sounds like when an operator assign a prefix to a PDN, the operator can divide the prefix into several longer prefixes. Each divided prefix, let's say "sub-PDN prefix", may be allocated to a region, or any other operator's partition policy. It doesn't need to be assign a whole PDN prefix to a partition, or "slice" you said. > > >> It seems to me that each "set" of EPC-E could cover no more than > the > >> scope covered by a single SGW today, because they each have the same > >> amount of state as an SGW. Essentially you have described how to > build > >> a replicated SGW with failover to different nodes based on the > >> re-convergence of BGP after a failure (presumably you could get the > >> core network to react to the closure of a BGP TCP session). So I > think > >> this addresses the problem of fault-tolerance that has been > identified > >> with the tunnel-based solutions, but not really the scalability > >> bottleneck problem. > > > > The nature of BGP makes easy to do that. I think Sec 3.4 would be > > right place to explain that. But I couldn't see that flavor of text in > > sec 4.1. Would you point which text in Sec 4.1 makes you confuse? > > It was the text in the penultimate paragraph that talked about partitioning > by region. If you do that, there is no mobility across regions, right? > As I mentioned before, mobility across regions is available. > But if you partition by PDN prefix (sets of UEs) then you can have a whole > stack of EPC-E at each deployment site, covering the entire population of > UEs. > > >> In fact, if you consider mobility from one "set" to another, if you > >> want to keep the > >> UE's IP address, you would need to broadcast the same set of PDN > >> prefixes from all > >> sets of EPC-E. In fact this would mean that all EPC-E throughout > the > >> network, even > >> if they are in different "sets", need to be prepared to handle > >> packets for any UE > >> and so they ALL would need the eNB F-TEIDs for ALL UEs. Please > tell > >> me where I have > >> made a mistake. > > > > > > > > No, an EPC-E just only receives packets from v6 core network toward > > UEs that routes installed into EPC-E. Because of that an EPC-E should > > advertise aggregated routes only for that includes its downstream UEs. > > When the EPC-E advertises whole routes to the core as you explained, > > yes I agree with you that won't be scalable. But it would depend on > > EPC-E capacity and size of UE population in the network. > > Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE > population, right? There is no need to put all UEs on all EPC-Es. > Right. cheers, --satoru --20cf30050d7e92998004f60695f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Peter,


On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann <Peter.= McCann@huawei.com> wrote:
--snip--
= =A0
> No, it isn'= ;t meant that specific routes to indicate each UEs prefix
> are advertised into the core.
> I'll try to improve that text in next revision of the draft.

Yes please clarify because the current text seems to say that UE pref= ixes
are advertised into the core.


Yes, thanks.

=A0
> I agree = with you if a EPC-E has whole UE specific routes that exceed
> its capacity, it doesn't scale, yes. In the recent presentation > through the webex, Ryuji were trying to explain that it's not inte= nded to do.
> Routes contained in EPC-E will be limited/partitioned by operators
> policy, such as region, service, population scale, etc.,

I was a bit confused by the suggestion to partition by region, becaus= e
there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. =A0B= ut,
I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP
for those cases).


Partitioned by r= egion sounds like that each regional network is isolated so that they has n= o connectivity between them.
But it is not what I meant. Although= a PDN prefix would be partitioned by region, the networks doesn't real= ly need to be isolated.
For example, when all EPC-E routers have connectivity to reach all RAN= nodes, it makes easy to provide mobility across regions.
Do you = think that describing in the draft this kind of networking concept would be= helpful to make things clear?=A0

=A0
>> =A0 =A0 =A0You seem to attempt to address this issue in Section 4.= 1 when you talk
>> about multiple =A0 =A0 =A0 "sets" of EPC-E devices, each= one dedicated to a given
>> geographic region.
>
>
> Ah, no. Sec 4.1 is intended to explain just scalability issue, and how=
> to deal that issues with routing techniques in operation.

Ok, I guess in the most common case you would have several "slic= es" of
EPC-E, each set serving a different PDN prefix and a different set of UEs.<= br> There would be one EPC-E from each slice, each representing a partition of<= br> the PDN prefixes, at each EPC-E deployment site between eNBs and core.
A given UE's current location would need to be BGP UPDATEd to each of t= he
EPC-E in the slice that covered that UE's PDN prefix.
<= div>
In my mind, that sounds like when an operator assign a p= refix to a PDN, the operator can divide the prefix into several longer pref= ixes. Each divided prefix, let's say "sub-PDN prefix", may be= allocated to a region, or any other operator's partition policy. It do= esn't need to be assign a whole PDN prefix to a partition, or "sli= ce" you said.

=A0

>> =A0 =A0 =A0 It seems to me that each "set" of EPC-E coul= d cover no more than the
>> scope covered by a single =A0 =A0SGW today, because they each have= the same
>> amount of state as an SGW. Essentially =A0 =A0 =A0 you have descri= bed how to build
>> a replicated SGW with failover to different nodes =A0 =A0based on = the
>> re-convergence of BGP after a failure (presumably you could get th= e
>> =A0 =A0 =A0core network to react to the closure of a BGP TCP sessi= on). =A0So I think
>> this addresses =A0 =A0 =A0 the problem of fault-tolerance that has= been identified
>> with the tunnel-based solutions, =A0 =A0 but not really the scalab= ility
>> bottleneck problem.
>
> The nature of BGP makes easy to do that. I think Sec 3.4 would be
> right place to explain that. But I couldn't see that flavor of tex= t in
> sec 4.1. Would you point which text in Sec 4.1 makes you confuse?

It was the text in the penultimate paragraph that talked about partit= ioning
by region. =A0If you do that, there is no mobility across regions, right?

As I mentioned before, mobility across r= egions is available.

=A0
But if you partition by PDN prefix (sets of UEs) then you can have a whole<= br> stack of EPC-E at each deployment site, covering the entire population of UEs.

>> =A0 =A0 =A0In fact, if you consider mobility from one "set&qu= ot; to another, if you
>> want to keep the
>> =A0 =A0 =A0UE's IP address, you would need to broadcast the sa= me set of PDN
>> prefixes from all
>> =A0 =A0 =A0sets of EPC-E. =A0In fact this would mean that all EPC-= E throughout the
>> network, even
>> =A0 =A0 =A0if they are in different "sets", need to be p= repared to handle
>> packets for any UE
>> =A0 =A0 =A0and so they ALL would need the eNB F-TEIDs for ALL UEs.= =A0Please tell
>> me where I have
>> =A0 =A0 =A0made a mistake.
>
>
>
> No, an EPC-E just only receives packets from v6 core network toward > UEs that routes installed into EPC-E. Because of that an EPC-E should<= br> > advertise aggregated routes only for that includes its downstream UEs.=
> When the EPC-E advertises whole routes to the core as you explained, > yes I agree with you that won't be scalable. But it would depend o= n
> EPC-E capacity and size of UE population in the network.

Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE=
population, right? =A0There is no need to put all UEs on all EPC-Es.

Right.

cheers,
=
--satoru
--20cf30050d7e92998004f60695f1-- From nobody Wed Apr 2 02:22:46 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0539A1A018F for ; Wed, 2 Apr 2014 02:22:43 -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, SPF_PASS=-0.001] autolearn=ham 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 skhwOJK9kVcs for ; Wed, 2 Apr 2014 02:22:38 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7631A0132 for ; Wed, 2 Apr 2014 02:22:35 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so8053191lbd.1 for ; Wed, 02 Apr 2014 02:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4OakaZqFvKtX2fg4jxUDuDFCSL97wv9MiJN+PD14m9c=; b=MX897yOE+6P8fbpRx/cJRhKFHdyHXO6lrPu2PaXub7qO1LCa1QHgY/AcmSXu2bpm+n Gpnax48TwJ7gcjlUbxfxBGixUUODShpzrd/d6BolgHhdi83TZ7uPr42OeGc27kST+Qo5 lm5hQHpf5//do+R7krYJi8H/dA0x24RyoAGKuslht5WZtbqOo2EubJe99zEomdU8QhiQ nVyF5sVQC0sNSCcXxzQEfyxKY52TBKv5fkR9GxTkduhaGnUyHj/yMX3WQru9WOKVChqP KSktO4R7dg28mnxG/h2I9u52r4fh+dPQQM2UpiqFBjJGZrv/CUUQqpttCjOq/LT1Jpqp 2GEw== X-Received: by 10.152.3.72 with SMTP id a8mr1072602laa.33.1396430551752; Wed, 02 Apr 2014 02:22:31 -0700 (PDT) Received: from [192.168.250.201] ([194.100.71.98]) by mx.google.com with ESMTPSA id u4sm1397925laj.2.2014.04.02.02.22.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 02:22:30 -0700 (PDT) Message-ID: <533BD6D3.7040205@gmail.com> Date: Wed, 02 Apr 2014 12:22:27 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" References: <20140402091655.30419.98687.idtracker@ietfa.amsl.com> In-Reply-To: <20140402091655.30419.98687.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/hYwfZZ-spDlXQKn2pWnzFARDMyw Subject: [DMM] WGLC #1 has ended for draft-ietf-dmm-best-practices-gap-analysis X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 09:22:45 -0000 Folks, The WGLC #1 has ended. Thanks to Charlie for an extensive review. The sooner these nits gets addressed the sooner we can ship the document. - Jouni 4/2/2014 12:16 PM, IETF Secretariat kirjoitti: > > The tags on draft-ietf-dmm-best-practices-gap-analysis have been changed > by Jouni Korhonen: > http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/ > > Tag "Revised I-D Needed - Issue raised by WG" added. > Tag "Other - see Comment Log" cleared. > > > Comment: > Charlie's comments > http://www.ietf.org/mail-archive/web/dmm/current/msg01098.html > http://www.ietf.org/mail-archive/web/dmm/current/msg01091.html > From nobody Thu Apr 3 04:46:15 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1671A01DB for ; Thu, 3 Apr 2014 04:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 FJbaqgylic_j for ; Thu, 3 Apr 2014 04:46:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E91481A019A for ; Thu, 3 Apr 2014 04:46:07 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LfCrI-1Wpekq36Nc-00pBWj; Thu, 03 Apr 2014 07:46:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Alper Yegin In-Reply-To: Date: Thu, 3 Apr 2014 14:45:59 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:4YfYIA5A1u/AHNLCm91OkbmnVWGynYaujYxgUeyN4Qz KWf8rl8G6vgLALOSwBmK87DxKDpy2NZGYqlY5Y8Hm/CX32heOM w7ma1IqGNM7R9TIVn0zJYCrpDV8PdmrKa1fkKoi/7YV2XuEYTR mVRazkILm5Ff7WvGOQLwI9+2DSUTdfDa9Ix24AwsWq9Es5ukHI P2YAIkS2hozgw6yKxRrylehNol/i5lHmVd/6IM6CDciZA/3mPP sMFxEdysDSCElIhruWRpIsh2ud2DMgJUCCTYDSlZgQo+2N0FWK M4CyZ2BQVwvBuF9Po98M7BLOzHyQG+TlbOyhjzjDnC135MlhF3 vbSm4JTuyi3F3wYUeL5VBLb8pXaaEC5W9ViUO8Q7/t4B17U5Bu h0/eazameS7Cg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Mi03Q3m0OOGREl2gbnwSUXU9aCQ Subject: [DMM] Next-Gen Mobility Protocols and Architectures Webex call #3 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 11:46:12 -0000 Folks, Call#3 is for Fred to present "Tranmission of IPv6 Packets over AERO Links" http://www.ietf.org/id/draft-templin-aerolink-13.txt Please mark your availability here: http://doodle.com/cdqufqrtvwci37ip Doodle deadline is next Monday. Cheers, Alper From nobody Fri Apr 4 05:47:55 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492921A015F for ; Fri, 4 Apr 2014 05:47:53 -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_HELO_PASS=-0.001] autolearn=ham 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 hoBbQyEZaG7L for ; Fri, 4 Apr 2014 05:47:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0951A0141 for ; Fri, 4 Apr 2014 05:47:49 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LevHL-1WoJyn2579-00q8OJ; Fri, 04 Apr 2014 08:47:42 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_105D8F66-E50C-453C-8DA5-C436BCD5211C" From: Alper Yegin In-Reply-To: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> Date: Fri, 4 Apr 2014 15:47:36 +0300 Message-Id: References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:SRpmrBtDnYQWDns05BlbCs4/F3Q3SaIcVDnuRdKBd3M UgmrSabPyMv7E/i+HHtdnb0GTRlU3ZaHusZywS7tEz7osEyyr3 vbtTVESzFmOd581KhzmkppoPIcTAzRd7DJLrADhwNvejgPq7sr 2ypHgmd9djY/yYzXpb6S61i64EuUl04sBr5depbrXVfsDWBu1K p10x8OLDYtM3cnVgmSlIPxPtYJzFw+Was6Dnem6v66rmDnhlqW la6q9kV8AyC9Bg9hNvmjyH0P4UTG7WYXTH3hKi5fqWxhiRT4Zc R1N9OG8w7/4jQrUBQmbc+80hMAKNcC3Xq4gHdbWnYxH/+4cb9r Iv2hnPVVnT6prPcz7KAEucNpT4oxYGK16h7xklvXikvUYNqsyt HMdBZwL6gatsQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/fSnNjbQopi7Q5v6Ld1A5v7FcxK4 Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 12:47:53 -0000 --Apple-Mail=_105D8F66-E50C-453C-8DA5-C436BCD5211C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jouni, One more thing: The DMM working group will also work on maintenance-oriented and incremental extensions to the Proxy Mobile IPv6 protocol, = specified in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily addresses any protocol gaps required to support existing = deployments and other standards development organizations using the Proxy = Mobile IPv6 protocol in their system architectures. We shall not shut the door on the client-based mobility. Hence, I propose the following revision: The DMM working group will also work on maintenance-oriented and incremental extensions to the Mobile IPv6 protocol, specified in RFC 5213, RFC 5844, and RFC 3775.=20 I removed the last sentence because I wasn't sure if it really added any = value. Alper On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: > Folks, >=20 > Take a look at the latest revision. I have added the initial stab > for the milestones. Comments and flames are welcome. If you want > something to be changed, just propose text & diff. You might also > want to say why the change is needed. >=20 > = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >=20 > - Jouni >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_105D8F66-E50C-453C-8DA5-C436BCD5211C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
 The DMM working group will also work on = maintenance-oriented and
      incremental extensions to the = Proxy Mobile IPv6 protocol, specified
      in RFC 5213 and RFC 5844. The = Proxy Mobile IPv6 work primarily
      addresses any protocol gaps = required to support existing deployments
      and other standards = development organizations using the Proxy Mobile
      IPv6 protocol in their system = architectures.

We shall not shut = the door on the client-based mobility.
Hence, I propose the = following revision:


      The DMM working group =
will also work on maintenance-oriented and
      incremental extensions to =
the Mobile IPv6 protocol, specified


I removed the last sentence because I wasn't sure if it really =
added any value.

Folks,

Take a look at the latest revision. I =
have added the initial stab
for the milestones. Comments and flames =
are welcome. If you want
something to be changed, just propose text =
& diff. You might also
want to say why the change is =
needed.

https://github.com/jounikor/dmm-re-charter/blob/master/recharter=
_draft.txt

- =
Jouni

_______________________________________________
dmm =
mailing =
list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

= --Apple-Mail=_105D8F66-E50C-453C-8DA5-C436BCD5211C-- From nobody Fri Apr 4 13:07:14 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F38A1A0424 for ; Fri, 4 Apr 2014 13:07:11 -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, SPF_PASS=-0.001] autolearn=ham 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 W6RA4ppHEj4a for ; Fri, 4 Apr 2014 13:07:05 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0762E1A0305 for ; Fri, 4 Apr 2014 13:06:54 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ec20so2792446lab.25 for ; Fri, 04 Apr 2014 13:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2frDtLXioLlY6ugB+Iv52eq+7eqITmulVajzX/zFojI=; b=uuX6+XFUF0MUgs2Z1g8xnCCUisuoFowYnlzH4O+lByE9YBv48CrMebSq3TKDRDFznW BXJ2NHmRfmT9IFplKutGlYX2P1C6dj4dKyXND9t4hH7kcovE8LR0IvG7HSlDaGZrvNxV 4mROk/XyzT1aVUkeJDyXhfaI3OeUvlHVYrAmnzKL7ergQCRBGKzQiLF2R78NKs+hH6WB gQn/kYb6/afxgJ3ANRZ2vIzhpef7wkc+FZ3tWE3syHUu9xuGLFe9TPkhwYQLk825Nt3B nXvhWXVczBLnMkJN1iR1qLpHs1KkVToDgG9CZ/YzdD7REjxNBcaVvBLbnyt57kzWRKjD 330A== X-Received: by 10.152.170.137 with SMTP id am9mr10059398lac.15.1396642009032; Fri, 04 Apr 2014 13:06:49 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:2492:6f45:f4db:947b? ([2001:1bc8:101:f101:2492:6f45:f4db:947b]) by mx.google.com with ESMTPSA id zf7sm8746280lab.7.2014.04.04.13.06.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 13:06:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Fri, 4 Apr 2014 23:06:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2919D60D-F96C-4596-8D89-2FA1248AB7E1@gmail.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> To: Alper Yegin X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/xehWXGSe9fnrFuQ5tMv332ibgP0 Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 20:07:11 -0000 Alper, Thanks for the proposed text. I am not entirely sure about the addition of the client mobility. It was not discussed during the meeting when we were advised to add the maintenance part. What do the others think? - Jouni On Apr 4, 2014, at 3:47 PM, Alper Yegin wrote: > Jouni, >=20 > One more thing: >=20 > The DMM working group will also work on maintenance-oriented and > incremental extensions to the Proxy Mobile IPv6 protocol, = specified > in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily > addresses any protocol gaps required to support existing = deployments > and other standards development organizations using the Proxy = Mobile > IPv6 protocol in their system architectures. >=20 > We shall not shut the door on the client-based mobility. > Hence, I propose the following revision: >=20 >=20 > The DMM working group will also work on maintenance-oriented and > incremental extensions to the Mobile IPv6 protocol, specified > in RFC 5213, RFC 5844, and RFC 3775.=20 >=20 >=20 > I removed the last sentence because I wasn't sure if it really added = any value. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 > On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >=20 >> Folks, >>=20 >> Take a look at the latest revision. I have added the initial stab >> for the milestones. Comments and flames are welcome. If you want >> something to be changed, just propose text & diff. You might also >> want to say why the change is needed. >>=20 >> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>=20 >> - Jouni >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Fri Apr 4 13:21:50 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA791A05C3 for ; Fri, 4 Apr 2014 13:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wpbUMHtSR75B for ; Fri, 4 Apr 2014 13:21:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF01A0502 for ; Fri, 4 Apr 2014 13:21:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG93516; Fri, 04 Apr 2014 20:21:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 21:20:32 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 21:21:32 +0100 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.182]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Sat, 5 Apr 2014 04:21:21 +0800 From: Peter McCann To: Jouni , Alper Yegin Thread-Topic: [DMM] rechartering draft text updated Thread-Index: AQHPUEF5E5y7TR31c0GJHwKz8IPljpsB5C5A Date: Fri, 4 Apr 2014 20:21:20 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE753DA0ED3@szxeml522-mbx.china.huawei.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <2919D60D-F96C-4596-8D89-2FA1248AB7E1@gmail.com> In-Reply-To: <2919D60D-F96C-4596-8D89-2FA1248AB7E1@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/TmNBRyMbsBz67YzbeFLwzZWk5zQ Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 20:21:47 -0000 I think there may need to be some work on dynamic HA assignment and security association configuration for client MIP. This is because DMM assumes that the MN will prefer the use of a locally assigned, more topologically correct address, which means it will need to set up dynamic relationships with HAs. Ideally, the MN would be able to use its network access credentials to set up the SA with the HA. Even if that HA is not used for the localized mobility (i.e., we have netdmm or something) the HA would come in handy when the MN has moved beyond the scope of the netdmm solution. It could fall back to client MIP in that case. The netdmm solution could then be used in place of gratuitous ND/ARP to get the packets to the HA before they are tunneled to the MN on another network. This would widen the reach of the HA beyond a single link, and allow placement of the HA near the boundary of the netdmm region instead of on the link where the assigned address would fall topologically. The HA would then become completely analogous to a base station/ access router, in that you use your network access credentials to authenticate yourself to it, and where the remote tunnel connection=20 is used instead of a wireless link. -Pete Jouni wrote: >=20 > Alper, >=20 > Thanks for the proposed text. I am not entirely sure about the > addition of the client mobility. It was not discussed during the > meeting when we were advised to add the maintenance part. >=20 > What do the others think? >=20 > - Jouni >=20 > On Apr 4, 2014, at 3:47 PM, Alper Yegin wrote: >=20 >> Jouni, >>=20 >> One more thing: >>=20 >> The DMM working group will also work on maintenance-oriented and >> incremental extensions to the Proxy Mobile IPv6 protocol, >> specified in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work >> primarily addresses any protocol gaps required to support >> existing deployments and other standards development >> organizations using the Proxy Mobile IPv6 protocol in their >> system architectures. >> We shall not shut the door on the client-based mobility. >> Hence, I propose the following revision: >>=20 >>=20 >> The DMM working group will also work on maintenance-oriented and >> incremental extensions to the Mobile IPv6 protocol, specified in >> RFC 5213, RFC 5844, and RFC 3775. >>=20 >> I removed the last sentence because I wasn't sure if it really added >> any value. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>=20 >>> Folks, >>>=20 >>> Take a look at the latest revision. I have added the initial stab for >>> the milestones. Comments and flames are welcome. If you want something >>> to be changed, just propose text & diff. You might also want to say >>> why the change is needed. >>>=20 >>> https://github.com/jounikor/dmm-re- charter/blob/master/recharter_draf >>> t.txt >>>=20 >>> - Jouni >>>=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 Sat Apr 5 04:25:02 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7646E1A042D for ; Sat, 5 Apr 2014 04:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 jzXZUiEAfyam for ; Sat, 5 Apr 2014 04:24:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 727DB1A0417 for ; Sat, 5 Apr 2014 04:24:35 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MVNsE-1WWrah35Z8-00Yf2l; Sat, 05 Apr 2014 07:24:28 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <2919D60D-F96C-4596-8D89-2FA1248AB7E1@gmail.com> Date: Sat, 5 Apr 2014 14:24:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <69BFE919-116C-4D86-B987-1EEDC4FE92A4@yegin.org> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <2919D60D-F96C-4596-8D89-2FA1248AB7E1@gmail.com> To: Jouni X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:aG9vu7pUhiL7ggxrpQK2C2dM/+MTIa6GY44HfidMpu+ hFEFWsQ+iC+lZaGRSxugAlyNPFC/vTJjBFzujK5aKUl9fGIi3+ sWtF93wuA0FEjgqQ+/kxfiVDYCY8FMsMYztZu+4W+mbVxKcPMi D49B02YTTI+Q3seJwsokuEldqsDmNl8NrIA3Jjyepwa6ECU1R1 3XW3Qrez9BfaFtZWOLp2/KTOeANV/rO2aMBIszdgOd9HF06H89 ioFB55iZekJ72KGCervhYBCQ4tJv9/kph6Iqek+D14pzzh2s2F wB2o+g3HR2hQ765NLbIjk2WCs+tD5gkeynuqTfr7P9D4NDPPpi NGZKo8rhT9WEn74GWdxAdaejx/WdNFIEq9/1O0ai3kAJ7DG0PS 2cOAF/8dLKvyQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2m6YcKMfeLEk-sC4tyJ3SWBsKvI Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 11:24:40 -0000 Hi Jouni, For the DMM solution, if we need extensions on the PMIPv6 or MIPv6, we'd = do that -- naturally. I think this goes w/o saying. It's just part of = the solution. And I now think the charter text does not aim that aspect.=20 I guess that PMIPv6 text is about maintenance of PMIPv6 outside the = scope of DMM "problem space". If PMIPv6 needs some extension that is not related to DMM, the place to = do that in IETF would be the DMM WG. If so, OK, that's an extra, which I have no objection. I do not know specifically what we'd need to do on PMIPv6, or CMIPv6 = (outside the scope of DMM space). But I cannot imagine why we'd let PMIPv6 go in but exclude MIPv6. Alper On Apr 4, 2014, at 11:06 PM, Jouni wrote: >=20 > Alper, >=20 > Thanks for the proposed text. I am not entirely sure about the = addition > of the client mobility. It was not discussed during the meeting when = we > were advised to add the maintenance part. >=20 > What do the others think? >=20 > - Jouni >=20 > On Apr 4, 2014, at 3:47 PM, Alper Yegin wrote: >=20 >> Jouni, >>=20 >> One more thing: >>=20 >> The DMM working group will also work on maintenance-oriented and >> incremental extensions to the Proxy Mobile IPv6 protocol, = specified >> in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily >> addresses any protocol gaps required to support existing = deployments >> and other standards development organizations using the Proxy = Mobile >> IPv6 protocol in their system architectures. >>=20 >> We shall not shut the door on the client-based mobility. >> Hence, I propose the following revision: >>=20 >>=20 >> The DMM working group will also work on maintenance-oriented and >> incremental extensions to the Mobile IPv6 protocol, specified >> in RFC 5213, RFC 5844, and RFC 3775.=20 >>=20 >>=20 >> I removed the last sentence because I wasn't sure if it really added = any value. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>=20 >>> Folks, >>>=20 >>> Take a look at the latest revision. I have added the initial stab >>> for the milestones. Comments and flames are welcome. If you want >>> something to be changed, just propose text & diff. You might also >>> want to say why the change is needed. >>>=20 >>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>=20 >>> - Jouni >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 From nobody Sun Apr 6 01:45:27 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42581A0364 for ; Sun, 6 Apr 2014 01:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 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, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham 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 yrY8PEpk0J_a for ; Sun, 6 Apr 2014 01:45:17 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 54DE71A035E for ; Sun, 6 Apr 2014 01:45:17 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so3736767lbi.36 for ; Sun, 06 Apr 2014 01:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jXIHG7wffo3YFxxkIYaEfM+t+gt0t32DuIRE34+eWi4=; b=Pegz1l1uaOrL2ssAD6GrYvlNhkkkUlqx6BWA2qc91z4FEum5Vp2SfLSm9OZN3dlSws njZSsX9uNOPJAgD5LtcTkQbfaMaTNEh6e4Z/ck4NV7XsRnVeY1LczJ6+pASvj/+eksZL vcaEJGTdh0Y00Hj5a/u18P/4cYgfXdps04/s3OE9ipCAorRJS2TFyQPdK1nooutuF/Fl TSaZrllpF63Nsr4hI1vmI+zinn64TJH9bFONz6tJIZKZ3B1sqLDkdEFOoq0IkV5z1zwf MPTN/URb3Ms5SeXdXhmElAIdB5nS6wRphZDirwDa9IEhCJUVW8DFagQLk3cvTBCxn2da jtgA== X-Received: by 10.112.135.198 with SMTP id pu6mr43836lbb.58.1396773911550; Sun, 06 Apr 2014 01:45:11 -0700 (PDT) Received: from [10.222.29.208] ([82.203.205.227]) by mx.google.com with ESMTPSA id qf1sm9343497lbc.8.2014.04.06.01.45.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Apr 2014 01:45:10 -0700 (PDT) Message-ID: <53411416.3080309@gmail.com> Date: Sun, 06 Apr 2014 11:45:10 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alper Yegin References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <2919D60D-F96C-4596-8D89-2FA1248AB7E1@gmail.com> <69BFE919-116C-4D86-B987-1EEDC4FE92A4@yegin.org> In-Reply-To: <69BFE919-116C-4D86-B987-1EEDC4FE92A4@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/pyZiDMo_IRlhbS4KGSmFCz5w-BU Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 08:45:24 -0000 Alper, 4/5/2014 2:24 PM, Alper Yegin kirjoitti: > Hi Jouni, > > For the DMM solution, if we need extensions on the PMIPv6 or MIPv6, we'd do that -- naturally. I think this goes w/o saying. It's just part of the solution. > And I now think the charter text does not aim that aspect. Right. Could be sloppy wording but if the DMM solution needs (P)MIPv6 enhancements, those are in scope. They both have always been. > I guess that PMIPv6 text is about maintenance of PMIPv6 outside the scope of DMM "problem space". > If PMIPv6 needs some extension that is not related to DMM, the place to do that in IETF would be the DMM WG. > If so, OK, that's an extra, which I have no objection. This is correct, regarding the latest addition of maintenance text. > I do not know specifically what we'd need to do on PMIPv6, or CMIPv6 (outside the scope of DMM space). > But I cannot imagine why we'd let PMIPv6 go in but exclude MIPv6. Ok. If you see it beneficial to add MIPv6 also into the maintenance part, then fine. Honestly, even if that gets mentioned there it is not to be considered and open invitation to work on client MIPv6 specific "outside DMM scope" topics just because it is in charter. - Jouni > > Alper > > > > > On Apr 4, 2014, at 11:06 PM, Jouni wrote: > >> >> Alper, >> >> Thanks for the proposed text. I am not entirely sure about the addition >> of the client mobility. It was not discussed during the meeting when we >> were advised to add the maintenance part. >> >> What do the others think? >> >> - Jouni >> >> On Apr 4, 2014, at 3:47 PM, Alper Yegin wrote: >> >>> Jouni, >>> >>> One more thing: >>> >>> The DMM working group will also work on maintenance-oriented and >>> incremental extensions to the Proxy Mobile IPv6 protocol, specified >>> in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily >>> addresses any protocol gaps required to support existing deployments >>> and other standards development organizations using the Proxy Mobile >>> IPv6 protocol in their system architectures. >>> >>> We shall not shut the door on the client-based mobility. >>> Hence, I propose the following revision: >>> >>> >>> The DMM working group will also work on maintenance-oriented and >>> incremental extensions to the Mobile IPv6 protocol, specified >>> in RFC 5213, RFC 5844, and RFC 3775. >>> >>> >>> I removed the last sentence because I wasn't sure if it really added any value. >>> >>> Alper >>> >>> >>> >>> >>> >>> >>> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>> >>>> Folks, >>>> >>>> Take a look at the latest revision. I have added the initial stab >>>> for the milestones. Comments and flames are welcome. If you want >>>> something to be changed, just propose text & diff. You might also >>>> want to say why the change is needed. >>>> >>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt >>>> >>>> - Jouni >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >> > From nobody Mon Apr 7 12:13:33 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEECB1A07F2 for ; Mon, 7 Apr 2014 12:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JC4K-RwTpIoO for ; Mon, 7 Apr 2014 12:13:27 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF971A03EA for ; Mon, 7 Apr 2014 12:13:26 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so5161017lbv.38 for ; Mon, 07 Apr 2014 12:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A+KGX/OBX+a56cDdcSXKf4w49NLuxfPjP+tckoQN67Q=; b=AdOxTaS/NllQ1fSFl18cfzK+C7uvu7H5VMufntO0Gzg9SXX1EWkxooeeuLvxZ8oP0Z 3cU2vqDrPupDL/CHE1sKwuacb4rWGSvwcw839o7xQH0ofSpalmodASU6lW/KGoT2wVPZ LPsxAAYOHXRR0WfFwIp19HbdCCSTUsmMT8OYYNJtLTp27K2BcYndFL+OlFycxGOTAly9 zKWZQMDg9NGpbpFIjNyOZ5k1mRXK6be58+6OlVnMMaicl2w67kbEc9CCapUl72XuEJAn Og2H5LqU7rU29UStwhzk7IA3cLC4LEjOtT9TJZGTxyAMyCIlclkHSDWaX4wGWsYY3Avr NF4Q== MIME-Version: 1.0 X-Received: by 10.153.7.69 with SMTP id da5mr2826068lad.38.1396898000180; Mon, 07 Apr 2014 12:13:20 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 7 Apr 2014 12:13:20 -0700 (PDT) In-Reply-To: <53411416.3080309@gmail.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <2919D60D-F96C-4596-8D89-2FA1248AB7E1@gmail.com> <69BFE919-116C-4D86-B987-1EEDC4FE92A4@yegin.org> <53411416.3080309@gmail.com> Date: Mon, 7 Apr 2014 14:13:20 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=001a1134563016995704f678a9f0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/fn5hHVLFZTAFi89uxAbhN4HQAEg Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:13:32 -0000 --001a1134563016995704f678a9f0 Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, On Sun, Apr 6, 2014 at 3:45 AM, Jouni Korhonen wrote: > Alper, > > 4/5/2014 2:24 PM, Alper Yegin kirjoitti: > > Hi Jouni, >> >> For the DMM solution, if we need extensions on the PMIPv6 or MIPv6, we'd >> do that -- naturally. I think this goes w/o saying. It's just part of the >> solution. >> And I now think the charter text does not aim that aspect. >> > > Right. Could be sloppy wording but if the DMM solution needs (P)MIPv6 > enhancements, those are in scope. They both have always been. > > > I guess that PMIPv6 text is about maintenance of PMIPv6 outside the scope >> of DMM "problem space". >> If PMIPv6 needs some extension that is not related to DMM, the place to >> do that in IETF would be the DMM WG. >> If so, OK, that's an extra, which I have no objection. >> > > This is correct, regarding the latest addition of maintenance text. > > > I do not know specifically what we'd need to do on PMIPv6, or CMIPv6 >> (outside the scope of DMM space). >> But I cannot imagine why we'd let PMIPv6 go in but exclude MIPv6. >> > > Ok. If you see it beneficial to add MIPv6 also into the maintenance part, > then fine. Honestly, even if that gets mentioned there it is not to be > considered and open invitation to work on client MIPv6 specific "outside > DMM scope" topics just because it is in charter. > > The issue here is in a routing based approach such as vEPC or the flat architecture MIP6 extension may come into picture, as Pete explained. So it is not MIP6 extensions that MIP6 based DMM protocol needs which is in charter's scope already. I hope this clarifies. Regards, Behcet > - Jouni > > > >> Alper >> >> >> >> >> On Apr 4, 2014, at 11:06 PM, Jouni wrote: >> >> >>> Alper, >>> >>> Thanks for the proposed text. I am not entirely sure about the addition >>> of the client mobility. It was not discussed during the meeting when we >>> were advised to add the maintenance part. >>> >>> What do the others think? >>> >>> - Jouni >>> >>> On Apr 4, 2014, at 3:47 PM, Alper Yegin wrote: >>> >>> Jouni, >>>> >>>> One more thing: >>>> >>>> The DMM working group will also work on maintenance-oriented and >>>> incremental extensions to the Proxy Mobile IPv6 protocol, >>>> specified >>>> in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily >>>> addresses any protocol gaps required to support existing >>>> deployments >>>> and other standards development organizations using the Proxy >>>> Mobile >>>> IPv6 protocol in their system architectures. >>>> >>>> We shall not shut the door on the client-based mobility. >>>> Hence, I propose the following revision: >>>> >>>> >>>> The DMM working group will also work on maintenance-oriented and >>>> incremental extensions to the Mobile IPv6 protocol, specified >>>> in RFC 5213, RFC 5844, and RFC 3775. >>>> >>>> >>>> I removed the last sentence because I wasn't sure if it really added >>>> any value. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>>> >>>> Folks, >>>>> >>>>> Take a look at the latest revision. I have added the initial stab >>>>> for the milestones. Comments and flames are welcome. If you want >>>>> something to be changed, just propose text & diff. You might also >>>>> want to say why the change is needed. >>>>> >>>>> https://github.com/jounikor/dmm-re-charter/blob/master/ >>>>> recharter_draft.txt >>>>> >>>>> - Jouni >>>>> >>>>> _______________________________________________ >>>>> 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 > --001a1134563016995704f678a9f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jouni,


On Sun, Apr 6, 2014 at 3:45 AM, Jouni Korhonen <jo= uni.nospam@gmail.com> wrote:
Alper,

4/5/2014 2:24 PM, Alper Yegin kirjoitti:

Hi Jouni,

For the DMM solution, if we need extensions on the PMIPv6 or MIPv6, we'= d do that -- naturally. I think this goes w/o saying. It's just part of= the solution.
And I now think the charter text does not aim that aspect.

Right. Could be sloppy wording but if the DMM solution needs (P)MIPv6 enhan= cements, those are in scope. They both have always been.

I guess that PMIPv6 text is about maintenance of PMIPv6 outside the scope o= f DMM "problem space".
If PMIPv6 needs some extension that is not related to DMM, the place to do = that in IETF would be the DMM WG.
If so, OK, that's an extra, which I have no objection.

This is correct, regarding the latest addition of maintenance text.


I do not know specifically what we'd need to do on PMIPv6, or CMIPv6 (o= utside the scope of DMM space).
But I cannot imagine why we'd let PMIPv6 go in but exclude MIPv6.

Ok. If you see it beneficial to add MIPv6 also into the maintenance part, t= hen fine. Honestly, even if that gets mentioned there it is not to be consi= dered and open invitation to work on client MIPv6 specific "outside DM= M scope" topics just because it is in charter.<= font color=3D"#888888">


The issue here is in a r= outing based approach such as vEPC or the flat architecture MIP6 extension= =A0 may come into picture, as Pete explained.
So it is not MI= P6 extensions that MIP6 based DMM protocol needs which is in charter's = scope already.

I hope this clarifies.

Regards,

Behcet
- Jouni



Alper




On Apr 4, 2014, at 11:06 PM, Jouni wrote:


Alper,

Thanks for the proposed text. I am not entirely sure about the addition
of the client mobility. It was not discussed during the meeting when we
were advised to add the maintenance part.

What do the others think?

- Jouni

On Apr 4, 2014, at 3:47 PM, Alper Yegin wrote:

Jouni,

One more thing:

=A0 =A0 =A0 The DMM working group will also work on maintenance-oriented an= d
=A0 =A0 =A0 incremental extensions to the Proxy Mobile IPv6 protocol, speci= fied
=A0 =A0 =A0 in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily<= br> =A0 =A0 =A0 addresses any protocol gaps required to support existing deploy= ments
=A0 =A0 =A0 and other standards development organizations using the Proxy M= obile
=A0 =A0 =A0 IPv6 protocol in their system architectures.

We shall not shut the door on the client-based mobility.
Hence, I propose the following revision:


=A0 =A0 =A0 The DMM working group will also work on maintenance-oriented an= d
=A0 =A0 =A0 incremental extensions to the Mobile IPv6 protocol, specified =A0 =A0 =A0 in RFC 5213, RFC 5844, and RFC 3775.


I removed the last sentence because I wasn't sure if it really added an= y value.

Alper






On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote:

Folks,

Take a look at the latest revision. I have added the initial stab
for the milestones. Comments and flames are welcome. If you want
something to be changed, just propose text & diff. You might also
want to say why the change is needed.

https://github.com/jounikor/dmm-re-cha= rter/blob/master/recharter_draft.txt

- Jouni

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm




_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

--001a1134563016995704f678a9f0-- From nobody Tue Apr 8 05:06:17 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD51A0379 for ; Tue, 8 Apr 2014 05:06:15 -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=[GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 Lp7zAtbNzcKL for ; Tue, 8 Apr 2014 05:06:13 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25A1A0380 for ; Tue, 8 Apr 2014 05:06:11 -0700 (PDT) Received: from aca807e5.ipt.aol.com (212.156.127.134.static.turktelekom.com.tr [212.156.127.134]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MPlHO-1WbMP41uoU-004S6D; Tue, 08 Apr 2014 08:06:10 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8025865A-F77E-49AB-AF64-31F176967968" From: Alper Yegin X-Priority: 3 X-Mail-Calendar-Part: Yes Date: Tue, 8 Apr 2014 15:06:10 +0300 Message-Id: <9197F963-9A7B-426E-B831-A9BDFBD122B5@yegin.org> References: <1336987016.3856891396958635834.JavaMail.nobody@rln9rmd101.webex.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:X4EYPKK4w+RafVZdKm1/+9Ceb451nyq/F4tf4qZTvZC 4JxNYHEz23CWUZFvq3TtnQYrkD/709AGXXAEu6x8XJDPK0HoWx /z3TWXreo2tbu+KMatmBsQWKUi4tfI8lbhfLyPe01uVrTOIgND lPvenEIGzmtGREnxIlbSFe27AJSqaj6Fk/AzGgfJ79EqQozjJl KE0YxUaEY43PpjiWvLWHa40RubmwcB8Vrw4f7Ym5tNiwi0wkG8 uvVq0R91+moSNznvssT6qG/aZpwwI/cEcoTjsJqj4qN/BbVDHC g+74883tFYg/T9vwlLdLyFAMGhGmQsZRb1lJPrlcbCN6p8/wcy 8pk4t9vRW6atvI3BpfONvTx8f1KEc2f4IVUfbnvm2jLfewTPaR 91gHS8CD1R4Gg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_ME6Jsu4XYJrgb-J6_Xvy88ONJo Subject: [DMM] Fwd: Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures, Call #3 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 12:06:16 -0000 --Apple-Mail=_8025865A-F77E-49AB-AF64-31F176967968 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Folks, See below for the details of the next call. Cheers, Alper =09 Begin forwarded message: >=20 >=20 > Hi, > =09 > =20 > Alper Yegin is inviting you to this WebEx meeting: > =09 > Next-Gen Mobility Protocols and Architectures, Call #3=20 > Wed, Apr 16, 5:00 pm | 1 hr 30 min > Istanbul (Eastern Europe Summer Time, GMT+03:00) > Host: Alper Yegin > =09 > Join > =09 > =20 > Add the attached iCalendar (.ics) file to your calendar. > =09 > Agenda >=20 > Fred presenting Transmission of IPv6 Packets over AERO Links. >=20 > http://www.ietf.org/id/draft-templin-aerolink-13.txt > =09 > Access Information >=20 > Where: WebEx Online > Meeting number: 237 737 343 > Password: This meeting does not require a password. > =09 > Audio Connection >=20 > +44-203-478-5289 UK Domestic Toll > Access code: 237 737 343 > Can't access your meeting? Get help. > Delivering the power of collaboration > Cisco WebEx Team >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. By joining this meeting, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation. >=20 > =A92013 Cisco and/or its affiliates. All rights reserved. > MT-A-001 >=20 --Apple-Mail=_8025865A-F77E-49AB-AF64-31F176967968 Content-Type: multipart/mixed; boundary="Apple-Mail=_8A4A66C9-9DB2-416B-86F0-CD3D7A4308CB" --Apple-Mail=_8A4A66C9-9DB2-416B-86F0-CD3D7A4308CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 =

Begin forwarded message:


= 3D"Cisco
=
=
Hi,
3D""
 
Alper Yegin is inviting you to this WebEx meeting:
3D""   
Next-Gen Mobility Protocols and Architectures, Call = #3
Wed, Apr 16, 5:00 pm | 1 hr 30 = min
Host: = Alper Yegin
  
3D""
 
3D""  

Agenda

= Fred presenting Transmission of IPv6 Packets = ;over AERO Links.

http://www.i= etf.org/id/draft-templin-aerolink-13.txt
3D""  

Access Information

Where:  WebEx Online
Meeting = number:  237 737 343
Password:  This meeting does not require a = password.
3D""  

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 237 737 343

Can't access your = meeting? Get = help.
= = = = = = = = =
=
= Delivering the power of collaboration
= Cisco WebEx Team =
=
= =
3D"Footer"
=20
IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation.
=20

=A92013 Cisco = and/or its affiliates. All rights reserved.
MT-A-001
= 3D"Cisco"
= --Apple-Mail=_8A4A66C9-9DB2-416B-86F0-CD3D7A4308CB Content-Disposition: attachment; filename="Next-Gen Mobility Protocols and Architectures, Call _3.ics" Content-Type: text/calendar; name="Next-Gen Mobility Protocols and Architectures, Call _3.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2012.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0A=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Europe=0ABEGIN:STANDARD=0ADTSTART:20001029T040000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10;BYHOUR=3D4=0A= TZOFFSETFROM:+0300=0ATZOFFSETTO:+0200=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20000326T030000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3;BYHOUR=3D3=0A= TZOFFSETFROM:+0200=0ATZOFFSETTO:+0300=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0A=0ABEGIN:VEVENT=0ACLASS:PUBLIC=0A= UID:M1TWTLL72TSSDY9796SQG392DB-1KJ9=0ADTSTAMP:20140408T120355Z=0A= SUMMARY:Next-Gen=20Mobility=20Protocols=20and=20Architectures,=20Call=20= #3=0ALOCATION:WebEx=20Online=0APRIORITY:5=0ASEQUENCE:1039473436=0A= TRANSP:OPAQUE=0A=0AORGANIZER;CN=3D"Alper=20Yegin=20via=20Cisco=20= WebEx":MAILTO:alper_yegin@hotmail.com=0A= ATTENDEE;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:MAILTO= :alper.yegin@yegin.org=0A=0ADTSTART;TZID=3D"Eastern=20= Europe":20140416T170000=0ADTEND;TZID=3D"Eastern=20= Europe":20140416T183000=0A=0ADESCRIPTION:Hi,\n\nAlper=20Yegin=20is=20= inviting=20you=20to=20this=20WebEx=20meeting:\n\nNext-Gen=20Mobility=20= Protocols=20and=20Architectures,=20Call=20#3\nWed,=20Apr=2016,=205:00=20= pm=20|=201=20hr=2030=20min\nIstanbul=20(Eastern=20Europe=20Summer=20= Time,=20GMT+03:00)\nHost:=20Alper=20Yegin\n\nWhen=20it's=20time,=20join=20= the=20meeting=20from=20= here:\nhttps://meetings.webex.com/collabs/meetings/join?uuid=3DM1TWTLL72TS= SDY9796SQG392DB-1KJ9\n\nAgenda\nFred=20presenting=20Transmission=20of=20= IPv6=20Packets=20over=20AERO=20= Links.\n\nhttp://www.ietf.org/id/draft-templin-aerolink-13.txt\n\nAccess=20= Information\nWhere:=20WebEx=20Online\nMeeting=20number:=20237=20737=20= 343\nMeeting=20password:=20This=20meeting=20does=20not=20require=20a=20= password.\n\nAudio=20Connection\n+44-203-478-5289=20UK=20Domestic=20= Toll\nAccess=20code:=20237=20737=20343\n\n\n\n\n\nCan't=20access=20your=20= meeting?=20Get=20= help:\nhttps://meetings.webex.com/collabs/#/support\n\n\nDelivering=20= the=20power=20of=20collaboration\nCisco=20WebEx=20= Team\n\n-----------------------------------------------------------\n\nIMP= ORTANT=20NOTICE:=20This=20WebEx=20service=20includes=20a=20feature=20= that=20allows=20audio=20and=20any=20documents=20and=20other=20materials=20= exchanged=20or=20viewed=20during=20the=20meeting=20to=20be=20recorded.=20= By=20joining=20this=20meeting,=20you=20automatically=20consent=20to=20= such=20recordings.=20If=20you=20do=20not=20consent=20to=20the=20= recording,=20discuss=20your=20concerns=20with=20the=20meeting=20host=20= prior=20to=20the=20start=20of=20the=20recording=20or=20do=20not=20join=20= the=20meeting.=20Please=20note=20that=20any=20such=20recordings=20may=20= be=20subject=20to=20discovery=20in=20the=20event=20of=20= litigation.\n\n=C2=A92013=20Cisco=20and/or=20its=20affiliates.=20All=20= rights=20reserved.\n\nMT-A-001\n=0A=0ABEGIN:VALARM=0AACTION:DISPLAY=0A= DESCRIPTION:REMINDER=0ATRIGGER:-PT900S=0AEND:VALARM=0A=0AEND:VEVENT=0A=0A= END:VCALENDAR=0A= --Apple-Mail=_8A4A66C9-9DB2-416B-86F0-CD3D7A4308CB Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_8A4A66C9-9DB2-416B-86F0-CD3D7A4308CB-- --Apple-Mail=_8025865A-F77E-49AB-AF64-31F176967968-- From nobody Thu Apr 17 14:57:14 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F531A0045 for ; Thu, 17 Apr 2014 14:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 TgrL6uXg6O-P for ; Thu, 17 Apr 2014 14:57:08 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 618611A01F0 for ; Thu, 17 Apr 2014 14:57:08 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so998605wgg.9 for ; Thu, 17 Apr 2014 14:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+KqMG46Noch6YrffthztYkPrDBguAfdaA+XMOfn8CaE=; b=s82QXwgPZ5Qh9P4Tu7xkiN9yRDNKvSUi4b9hForRKgYNsrIox87FKr5l+kRyOi62I3 hI+UBrxa60AZQGjPoDoLvIL7BL/ANF2guWdrIsZkOO8yNfjxDJvNRcBhw/yKxvxG40iz 2vYOdilpCb3+fzlo6jRalDNwKqGmaid48zarPpIDLiWgSP1az4siBMe1xnkTnTdtALmY t/gGqq+yc7MxzuD06YkXnq3e2F6cJqTOtx2S8BL31tfdNcDHCRZQlakd7shvEFewJ8FJ NSuToMgZKdiTIdoxHUJHd73qnkOFhKF+iCtX+oiHQVEnh06QaRjIzlBfpEZXSLjQYc/y w07g== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr13829966wic.5.1397771824109; Thu, 17 Apr 2014 14:57:04 -0700 (PDT) Received: by 10.227.231.197 with HTTP; Thu, 17 Apr 2014 14:57:04 -0700 (PDT) In-Reply-To: References: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FBA1@szxeml522-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE753D9FE19@szxeml522-mbx.china.huawei.com> Date: Thu, 17 Apr 2014 16:57:04 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: multipart/alternative; boundary=001a11c26ab40d9f4704f7441d51 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/GdE_cxaCg0WDHM_Jqq-pPD6Dafc Cc: Peter McCann , "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:57:12 -0000 --001a11c26ab40d9f4704f7441d51 Content-Type: text/plain; charset=UTF-8 Hi Satoru, I have a question about vEPC. As the UE moves around its default router changes. Which node is the default router? EPC-E? Regards, Behcet On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Peter, > > > On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann wrote: > --snip-- > > >> > No, it isn't meant that specific routes to indicate each UEs prefix >> > are advertised into the core. >> > I'll try to improve that text in next revision of the draft. >> >> Yes please clarify because the current text seems to say that UE prefixes >> are advertised into the core. >> >> > Yes, thanks. > > > >> > I agree with you if a EPC-E has whole UE specific routes that exceed >> > its capacity, it doesn't scale, yes. In the recent presentation >> > through the webex, Ryuji were trying to explain that it's not intended >> to do. >> > Routes contained in EPC-E will be limited/partitioned by operators >> > policy, such as region, service, population scale, etc., >> >> I was a bit confused by the suggestion to partition by region, because >> there would be no mobility across regions if you partitioned in this way. >> That's because different regions would use different PDN prefixes. But, >> I suppose it would be ok to do this if you didn't need to support UE >> mobility across regions (or if you used OTT mobility such as client MIP >> for those cases). >> >> > Partitioned by region sounds like that each regional network is isolated > so that they has no connectivity between them. > But it is not what I meant. Although a PDN prefix would be partitioned by > region, the networks doesn't really need to be isolated. > For example, when all EPC-E routers have connectivity to reach all RAN > nodes, it makes easy to provide mobility across regions. > Do you think that describing in the draft this kind of networking concept > would be helpful to make things clear? > > > >> >> You seem to attempt to address this issue in Section 4.1 when you >> talk >> >> about multiple "sets" of EPC-E devices, each one dedicated to a >> given >> >> geographic region. >> > >> > >> > Ah, no. Sec 4.1 is intended to explain just scalability issue, and how >> > to deal that issues with routing techniques in operation. >> >> Ok, I guess in the most common case you would have several "slices" of >> EPC-E, each set serving a different PDN prefix and a different set of UEs. >> There would be one EPC-E from each slice, each representing a partition of >> the PDN prefixes, at each EPC-E deployment site between eNBs and core. >> A given UE's current location would need to be BGP UPDATEd to each of the >> EPC-E in the slice that covered that UE's PDN prefix. >> > > In my mind, that sounds like when an operator assign a prefix to a PDN, > the operator can divide the prefix into several longer prefixes. Each > divided prefix, let's say "sub-PDN prefix", may be allocated to a region, > or any other operator's partition policy. It doesn't need to be assign a > whole PDN prefix to a partition, or "slice" you said. > > > >> >> >> It seems to me that each "set" of EPC-E could cover no more than >> the >> >> scope covered by a single SGW today, because they each have the same >> >> amount of state as an SGW. Essentially you have described how to >> build >> >> a replicated SGW with failover to different nodes based on the >> >> re-convergence of BGP after a failure (presumably you could get the >> >> core network to react to the closure of a BGP TCP session). So I >> think >> >> this addresses the problem of fault-tolerance that has been >> identified >> >> with the tunnel-based solutions, but not really the scalability >> >> bottleneck problem. >> > >> > The nature of BGP makes easy to do that. I think Sec 3.4 would be >> > right place to explain that. But I couldn't see that flavor of text in >> > sec 4.1. Would you point which text in Sec 4.1 makes you confuse? >> >> It was the text in the penultimate paragraph that talked about >> partitioning >> by region. If you do that, there is no mobility across regions, right? >> > > As I mentioned before, mobility across regions is available. > > > >> But if you partition by PDN prefix (sets of UEs) then you can have a whole >> stack of EPC-E at each deployment site, covering the entire population of >> UEs. >> >> >> In fact, if you consider mobility from one "set" to another, if >> you >> >> want to keep the >> >> UE's IP address, you would need to broadcast the same set of PDN >> >> prefixes from all >> >> sets of EPC-E. In fact this would mean that all EPC-E throughout >> the >> >> network, even >> >> if they are in different "sets", need to be prepared to handle >> >> packets for any UE >> >> and so they ALL would need the eNB F-TEIDs for ALL UEs. Please >> tell >> >> me where I have >> >> made a mistake. >> > >> > >> > >> > No, an EPC-E just only receives packets from v6 core network toward >> > UEs that routes installed into EPC-E. Because of that an EPC-E should >> > advertise aggregated routes only for that includes its downstream UEs. >> > When the EPC-E advertises whole routes to the core as you explained, >> > yes I agree with you that won't be scalable. But it would depend on >> > EPC-E capacity and size of UE population in the network. >> >> Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE >> population, right? There is no need to put all UEs on all EPC-Es. >> > > Right. > > cheers, > --satoru > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > --001a11c26ab40d9f4704f7441d51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Satoru,

I have a question a= bout vEPC.

As the UE moves around its default router changes. = Which node is the default router? EPC-E?

Regards,

Behce= t


On Tue, = Apr 1, 2014 at 10:07 PM, Satoru Matsushima <satoru.matsushima@gm= ail.com> wrote:
Peter,


On Mon, Mar 31, 2014 at 10:18 = PM, Peter McCann <Peter.McCann@huawei.com> wrote:
--snip--
=C2=A0
> No, it i= sn't meant that specific routes to indicate each UEs prefix
> are advertised into the core.
> I'll try to improve that text in next revision of the draft.

Yes please clarify because the current text seems to say that UE pref= ixes
are advertised into the core.


Yes, thanks.

=C2=A0
> I agree with you if a EPC-E has whole UE specific routes that exceed<= br>
> its capacity, it doesn't scale, yes. In the recent presentation > through the webex, Ryuji were trying to explain that it's not inte= nded to do.
> Routes contained in EPC-E will be limited/partitioned by operators
> policy, such as region, service, population scale, etc.,

I was a bit confused by the suggestion to partition by region, becaus= e
there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. =C2= =A0But,
I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP
for those cases).


Partitioned by region= sounds like that each regional network is isolated so that they has no con= nectivity between them.
But it is not what I meant. Although a PD= N prefix would be partitioned by region, the networks doesn't really ne= ed to be isolated.
For example, when all EPC-E routers have connectivity to reach all RAN= nodes, it makes easy to provide mobility across regions.
Do you = think that describing in the draft this kind of networking concept would be= helpful to make things clear?=C2=A0

=C2=A0
>> =C2=A0 =C2=A0 =C2=A0You seem to attempt to address this issue in S= ection 4.1 when you talk
>> about multiple =C2=A0 =C2=A0 =C2=A0 "sets" of EPC-E devi= ces, each one dedicated to a given
>> geographic region.
>
>
> Ah, no. Sec 4.1 is intended to explain just scalability issue, and how=
> to deal that issues with routing techniques in operation.

Ok, I guess in the most common case you would have several "slic= es" of
EPC-E, each set serving a different PDN prefix and a different set of UEs.<= br> There would be one EPC-E from each slice, each representing a partition of<= br> the PDN prefixes, at each EPC-E deployment site between eNBs and core.
A given UE's current location would need to be BGP UPDATEd to each of t= he
EPC-E in the slice that covered that UE's PDN prefix.
<= div>
In my mind, that sounds like when an operator assi= gn a prefix to a PDN, the operator can divide the prefix into several longe= r prefixes. Each divided prefix, let's say "sub-PDN prefix", = may be allocated to a region, or any other operator's partition policy.= It doesn't need to be assign a whole PDN prefix to a partition, or &qu= ot;slice" you said.

=C2=A0

>> =C2=A0 =C2=A0 =C2=A0 It seems to me that each "set" of E= PC-E could cover no more than the
>> scope covered by a single =C2=A0 =C2=A0SGW today, because they eac= h have the same
>> amount of state as an SGW. Essentially =C2=A0 =C2=A0 =C2=A0 you ha= ve described how to build
>> a replicated SGW with failover to different nodes =C2=A0 =C2=A0bas= ed on the
>> re-convergence of BGP after a failure (presumably you could get th= e
>> =C2=A0 =C2=A0 =C2=A0core network to react to the closure of a BGP = TCP session). =C2=A0So I think
>> this addresses =C2=A0 =C2=A0 =C2=A0 the problem of fault-tolerance= that has been identified
>> with the tunnel-based solutions, =C2=A0 =C2=A0 but not really the = scalability
>> bottleneck problem.
>
> The nature of BGP makes easy to do that. I think Sec 3.4 would be
> right place to explain that. But I couldn't see that flavor of tex= t in
> sec 4.1. Would you point which text in Sec 4.1 makes you confuse?

It was the text in the penultimate paragraph that talked about partit= ioning
by region. =C2=A0If you do that, there is no mobility across regions, right= ?

As I mentioned before, mobility= across regions is available.

=C2= =A0
But if you partition by PDN prefix (sets of UEs) then you can have a whole<= br> stack of EPC-E at each deployment site, covering the entire population of UEs.

>> =C2=A0 =C2=A0 =C2=A0In fact, if you consider mobility from one &qu= ot;set" to another, if you
>> want to keep the
>> =C2=A0 =C2=A0 =C2=A0UE's IP address, you would need to broadca= st the same set of PDN
>> prefixes from all
>> =C2=A0 =C2=A0 =C2=A0sets of EPC-E. =C2=A0In fact this would mean t= hat all EPC-E throughout the
>> network, even
>> =C2=A0 =C2=A0 =C2=A0if they are in different "sets", nee= d to be prepared to handle
>> packets for any UE
>> =C2=A0 =C2=A0 =C2=A0and so they ALL would need the eNB F-TEIDs for= ALL UEs. =C2=A0Please tell
>> me where I have
>> =C2=A0 =C2=A0 =C2=A0made a mistake.
>
>
>
> No, an EPC-E just only receives packets from v6 core network toward > UEs that routes installed into EPC-E. Because of that an EPC-E should<= br> > advertise aggregated routes only for that includes its downstream UEs.=
> When the EPC-E advertises whole routes to the core as you explained, > yes I agree with you that won't be scalable. But it would depend o= n
> EPC-E capacity and size of UE population in the network.

Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE=
population, right? =C2=A0There is no need to put all UEs on all EPC-Es.
=

Right.

chee= rs,
--satoru

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm


--001a11c26ab40d9f4704f7441d51-- From nobody Fri Apr 18 09:06:53 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E991A0455; Fri, 18 Apr 2014 09:06:50 -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] autolearn=ham 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 mvrZ9Qc7eNTJ; Fri, 18 Apr 2014 09:06:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AB51A042C; Fri, 18 Apr 2014 09:06:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418160648.25760.67609.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 09:06:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/dSo0QdOw4tpFdZTe3OoDnM1vRJs Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-16.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:06:50 -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 Working Group of the IETF. Title : Requirements for Distributed Mobility Management Authors : H Anthony Chan Dapeng Liu Pierrick Seite Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-dmm-requirements-16.txt Pages : 21 Date : 2014-04-18 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-requirements-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-requirements-16 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 Fri Apr 18 20:58:53 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B91A01E0 for ; Fri, 18 Apr 2014 20:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Q0m4tZ8Eh8GK for ; Fri, 18 Apr 2014 20:58:47 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F232A1A00C2 for ; Fri, 18 Apr 2014 20:58:46 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 20so1926429yks.33 for ; Fri, 18 Apr 2014 20:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kuAk7M1o+Z005PBMn6PLMYhTmn0uomc2NRHnbHhX2hI=; b=oyCgAK+O7Eyd4aCHTyEumVKBbtlSqOA3aoCzVq6+Jq+cJjeNCYQNFpuzA5ruTeDyHQ Srm7CD4SW71lfN5FNXZvrMwc8Z6/vBzjKyOUB5pHKwIQTeqNHklGwJWL+keIocRh3arr QC5qnuEy35bD4Dfbkzd9Bhj3//UmobNGT8t704A2ihdkYIICGul4i/zxQPTDCiJtMCeG GIbfynBN08xiIfKucm+ktyN5C+0p/qE3gdBQn9Tk5V6Fciy62BppN3gSWDt8opt3dkoC Hpx5OXsd/QRxI2y7nn6aYCmgMJCFyWyXIJRRO0v1c36H0NnyxiHEHAG7M5UwAw+I4LhK Gqdg== MIME-Version: 1.0 X-Received: by 10.236.125.12 with SMTP id y12mr34834336yhh.42.1397879922718; Fri, 18 Apr 2014 20:58:42 -0700 (PDT) Received: by 10.170.161.194 with HTTP; Fri, 18 Apr 2014 20:58:42 -0700 (PDT) In-Reply-To: References: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FBA1@szxeml522-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE753D9FE19@szxeml522-mbx.china.huawei.com> Date: Sat, 19 Apr 2014 12:58:42 +0900 Message-ID: From: Satoru Matsushima To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf303a36a13b7d8104f75d4807 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/in1lemMB993dpH_Ra63icJhh9gE Cc: Peter McCann , "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 03:58:51 -0000 --20cf303a36a13b7d8104f75d4807 Content-Type: text/plain; charset=UTF-8 Hi Behcet, Yes, EPC-E routers should be default router for UEs. If I understand the background of your question correctly, you think an UE session is moved from an EPC-E router from another while moving around. It should be true because the UE sending packets are routed most closest node of the anycast tunnel. The assumption here is the c-plane will guide the UE session to connect an appropriate EPC-E routers set which preserve the UE route and shares the anycast address. That sounds like UEs are always in the area where it wouldn't require eNB to changing remote end-point of the tunnel. cheers, --satoru On Fri, Apr 18, 2014 at 6:57 AM, Behcet Sarikaya wrote: > Hi Satoru, > > I have a question about vEPC. > > As the UE moves around its default router changes. Which node is the > default router? EPC-E? > > Regards, > > Behcet > > > On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima < > satoru.matsushima@gmail.com> wrote: > >> Peter, >> >> >> On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann wrote: >> --snip-- >> >> >>> > No, it isn't meant that specific routes to indicate each UEs prefix >>> > are advertised into the core. >>> > I'll try to improve that text in next revision of the draft. >>> >>> Yes please clarify because the current text seems to say that UE prefixes >>> are advertised into the core. >>> >>> >> Yes, thanks. >> >> >> >>> > I agree with you if a EPC-E has whole UE specific routes that exceed >>> > its capacity, it doesn't scale, yes. In the recent presentation >>> > through the webex, Ryuji were trying to explain that it's not intended >>> to do. >>> > Routes contained in EPC-E will be limited/partitioned by operators >>> > policy, such as region, service, population scale, etc., >>> >>> I was a bit confused by the suggestion to partition by region, because >>> there would be no mobility across regions if you partitioned in this way. >>> That's because different regions would use different PDN prefixes. But, >>> I suppose it would be ok to do this if you didn't need to support UE >>> mobility across regions (or if you used OTT mobility such as client MIP >>> for those cases). >>> >>> >> Partitioned by region sounds like that each regional network is isolated >> so that they has no connectivity between them. >> But it is not what I meant. Although a PDN prefix would be partitioned by >> region, the networks doesn't really need to be isolated. >> For example, when all EPC-E routers have connectivity to reach all RAN >> nodes, it makes easy to provide mobility across regions. >> Do you think that describing in the draft this kind of networking concept >> would be helpful to make things clear? >> >> >> >>> >> You seem to attempt to address this issue in Section 4.1 when >>> you talk >>> >> about multiple "sets" of EPC-E devices, each one dedicated to a >>> given >>> >> geographic region. >>> > >>> > >>> > Ah, no. Sec 4.1 is intended to explain just scalability issue, and how >>> > to deal that issues with routing techniques in operation. >>> >>> Ok, I guess in the most common case you would have several "slices" of >>> EPC-E, each set serving a different PDN prefix and a different set of >>> UEs. >>> There would be one EPC-E from each slice, each representing a partition >>> of >>> the PDN prefixes, at each EPC-E deployment site between eNBs and core. >>> A given UE's current location would need to be BGP UPDATEd to each of the >>> EPC-E in the slice that covered that UE's PDN prefix. >>> >> >> In my mind, that sounds like when an operator assign a prefix to a PDN, >> the operator can divide the prefix into several longer prefixes. Each >> divided prefix, let's say "sub-PDN prefix", may be allocated to a region, >> or any other operator's partition policy. It doesn't need to be assign a >> whole PDN prefix to a partition, or "slice" you said. >> >> >> >>> >>> >> It seems to me that each "set" of EPC-E could cover no more >>> than the >>> >> scope covered by a single SGW today, because they each have the >>> same >>> >> amount of state as an SGW. Essentially you have described how >>> to build >>> >> a replicated SGW with failover to different nodes based on the >>> >> re-convergence of BGP after a failure (presumably you could get the >>> >> core network to react to the closure of a BGP TCP session). So >>> I think >>> >> this addresses the problem of fault-tolerance that has been >>> identified >>> >> with the tunnel-based solutions, but not really the scalability >>> >> bottleneck problem. >>> > >>> > The nature of BGP makes easy to do that. I think Sec 3.4 would be >>> > right place to explain that. But I couldn't see that flavor of text in >>> > sec 4.1. Would you point which text in Sec 4.1 makes you confuse? >>> >>> It was the text in the penultimate paragraph that talked about >>> partitioning >>> by region. If you do that, there is no mobility across regions, right? >>> >> >> As I mentioned before, mobility across regions is available. >> >> >> >>> But if you partition by PDN prefix (sets of UEs) then you can have a >>> whole >>> stack of EPC-E at each deployment site, covering the entire population of >>> UEs. >>> >>> >> In fact, if you consider mobility from one "set" to another, if >>> you >>> >> want to keep the >>> >> UE's IP address, you would need to broadcast the same set of PDN >>> >> prefixes from all >>> >> sets of EPC-E. In fact this would mean that all EPC-E >>> throughout the >>> >> network, even >>> >> if they are in different "sets", need to be prepared to handle >>> >> packets for any UE >>> >> and so they ALL would need the eNB F-TEIDs for ALL UEs. Please >>> tell >>> >> me where I have >>> >> made a mistake. >>> > >>> > >>> > >>> > No, an EPC-E just only receives packets from v6 core network toward >>> > UEs that routes installed into EPC-E. Because of that an EPC-E should >>> > advertise aggregated routes only for that includes its downstream UEs. >>> > When the EPC-E advertises whole routes to the core as you explained, >>> > yes I agree with you that won't be scalable. But it would depend on >>> > EPC-E capacity and size of UE population in the network. >>> >>> Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE >>> population, right? There is no need to put all UEs on all EPC-Es. >>> >> >> Right. >> >> cheers, >> --satoru >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> > --20cf303a36a13b7d8104f75d4807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Behcet,

Yes, EPC-E routers should be= default router for UEs. If I understand the background of your question co= rrectly, you think an UE session is moved from an EPC-E router from another= while moving around. It should be true because the UE sending packets are = routed most closest node of the anycast tunnel.=C2=A0

The assumption here is the c-plane will guide the UE se= ssion to connect an appropriate EPC-E routers set which preserve the UE rou= te and shares the anycast address. That sounds like UEs are always in the a= rea where it wouldn't require eNB to changing remote end-point of the t= unnel.

cheers,
--satoru



= On Fri, Apr 18, 2014 at 6:57 AM, Behcet Sarikaya <sarikaya2012@gmail.= com> wrote:
Hi Satoru,
I have a question about vEPC.

As the UE moves arou= nd its default router changes. Which node is the default router? EPC-E?

Regards,

Behcet


On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:
Peter,


On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann <= Peter.McCann@h= uawei.com> wrote:
--snip--
=C2=A0
> No, it isn't me= ant that specific routes to indicate each UEs prefix
> are advertised into the core.
> I'll try to improve that text in next revision of the draft.

Yes please clarify because the current text seems to say that UE pref= ixes
are advertised into the core.


Yes, thanks.

=C2=A0
> I agr= ee with you if a EPC-E has whole UE specific routes that exceed
> its capacity, it doesn't scale, yes. In the recent presentation > through the webex, Ryuji were trying to explain that it's not inte= nded to do.
> Routes contained in EPC-E will be limited/partitioned by operators
> policy, such as region, service, population scale, etc.,

I was a bit confused by the suggestion to partition by region, becaus= e
there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. =C2= =A0But,
I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP
for those cases).


Partitioned by region= sounds like that each regional network is isolated so that they has no con= nectivity between them.
But it is not what I meant. Although a PD= N prefix would be partitioned by region, the networks doesn't really ne= ed to be isolated.
For example, when all EPC-E routers have connectivity to reach all RAN= nodes, it makes easy to provide mobility across regions.
Do you = think that describing in the draft this kind of networking concept would be= helpful to make things clear?=C2=A0

=C2=A0
>> =C2=A0 =C2=A0 =C2=A0You seem to attempt to address this issue in S= ection 4.1 when you talk
>> about multiple =C2=A0 =C2=A0 =C2=A0 "sets" of EPC-E devi= ces, each one dedicated to a given
>> geographic region.
>
>
> Ah, no. Sec 4.1 is intended to explain just scalability issue, and how=
> to deal that issues with routing techniques in operation.

Ok, I guess in the most common case you would have several "slic= es" of
EPC-E, each set serving a different PDN prefix and a different set of UEs.<= br> There would be one EPC-E from each slice, each representing a partition of<= br> the PDN prefixes, at each EPC-E deployment site between eNBs and core.
A given UE's current location would need to be BGP UPDATEd to each of t= he
EPC-E in the slice that covered that UE's PDN prefix.
<= div>
In my mind, that sounds like when an operator assi= gn a prefix to a PDN, the operator can divide the prefix into several longe= r prefixes. Each divided prefix, let's say "sub-PDN prefix", = may be allocated to a region, or any other operator's partition policy.= It doesn't need to be assign a whole PDN prefix to a partition, or &qu= ot;slice" you said.

=C2=A0

>> =C2=A0 =C2=A0 =C2=A0 It seems to me that each "set" of E= PC-E could cover no more than the
>> scope covered by a single =C2=A0 =C2=A0SGW today, because they eac= h have the same
>> amount of state as an SGW. Essentially =C2=A0 =C2=A0 =C2=A0 you ha= ve described how to build
>> a replicated SGW with failover to different nodes =C2=A0 =C2=A0bas= ed on the
>> re-convergence of BGP after a failure (presumably you could get th= e
>> =C2=A0 =C2=A0 =C2=A0core network to react to the closure of a BGP = TCP session). =C2=A0So I think
>> this addresses =C2=A0 =C2=A0 =C2=A0 the problem of fault-tolerance= that has been identified
>> with the tunnel-based solutions, =C2=A0 =C2=A0 but not really the = scalability
>> bottleneck problem.
>
> The nature of BGP makes easy to do that. I think Sec 3.4 would be
> right place to explain that. But I couldn't see that flavor of tex= t in
> sec 4.1. Would you point which text in Sec 4.1 makes you confuse?

It was the text in the penultimate paragraph that talked about partit= ioning
by region. =C2=A0If you do that, there is no mobility across regions, right= ?

As I mentioned before, mobility= across regions is available.

=C2=A0
But if you partition by PDN prefix (sets of UEs) then you can have a whole<= br> stack of EPC-E at each deployment site, covering the entire population of UEs.

>> =C2=A0 =C2=A0 =C2=A0In fact, if you consider mobility from one &qu= ot;set" to another, if you
>> want to keep the
>> =C2=A0 =C2=A0 =C2=A0UE's IP address, you would need to broadca= st the same set of PDN
>> prefixes from all
>> =C2=A0 =C2=A0 =C2=A0sets of EPC-E. =C2=A0In fact this would mean t= hat all EPC-E throughout the
>> network, even
>> =C2=A0 =C2=A0 =C2=A0if they are in different "sets", nee= d to be prepared to handle
>> packets for any UE
>> =C2=A0 =C2=A0 =C2=A0and so they ALL would need the eNB F-TEIDs for= ALL UEs. =C2=A0Please tell
>> me where I have
>> =C2=A0 =C2=A0 =C2=A0made a mistake.
>
>
>
> No, an EPC-E just only receives packets from v6 core network toward > UEs that routes installed into EPC-E. Because of that an EPC-E should<= br> > advertise aggregated routes only for that includes its downstream UEs.=
> When the EPC-E advertises whole routes to the core as you explained, > yes I agree with you that won't be scalable. But it would depend o= n
> EPC-E capacity and size of UE population in the network.

Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE=
population, right? =C2=A0There is no need to put all UEs on all EPC-Es.
=

Right.

chee= rs,
--satoru

___________________________________________= ____
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--20cf303a36a13b7d8104f75d4807-- From nobody Tue Apr 22 05:55:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1BC1A0410 for ; Tue, 22 Apr 2014 05:55:54 -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, SPF_PASS=-0.001] autolearn=ham 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 HBUKLZ4mP4C0 for ; Tue, 22 Apr 2014 05:55:53 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D19381A041F for ; Tue, 22 Apr 2014 05:55:49 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pn19so4221377lab.6 for ; Tue, 22 Apr 2014 05:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=KKH5YzDTtmnTVormsC+IxG9IJYFc5dvLnhO3aynuyBE=; b=xPFn79Q4YzHvb9h4HBJvx0aY8rnW7SnzBRlDsZAb7j2J9vWS/zqvbDf7Nj7AYICdwn g2BkkO1+cV2kXpP85+4xxpGsCDpXr5zlCH6d9OHdAvi59nJCK8Jj134972cWm/N6qxzq ZbfpprQeNCFuusqeYlQ0whMwo+zPiq7OjXbxht+83ioDkfJFNzHZTdEiaYEAYncXbDem MK4OQ0dlhCk/SscRHIMMA35fTNnYBQGv9f6mrjHvpDvE4FkPBkTjADtOEMR3qDaE0ZER bz3lR/HDong7mhYt6WLHWMfJ57h8R2MVMkgMiAmj+1mzrxp9IpvQgwaKTta6iQ4RrLBX C2ew== X-Received: by 10.152.116.99 with SMTP id jv3mr31180350lab.19.1398171343950; Tue, 22 Apr 2014 05:55:43 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id z10sm40772148lbu.1.2014.04.22.05.55.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 05:55:43 -0700 (PDT) Message-ID: <535666B3.9060301@gmail.com> Date: Tue, 22 Apr 2014 15:55:15 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Opp36Kz8wsPGj2IRGhHnxPNHXV8 Subject: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:55:54 -0000 Folks, Sorry for letting this topic to rot in a dark for the couple of last weeks. I'll crank out a revision shortly.. - Jouni & Dapeng From nobody Fri Apr 25 09:43:59 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B3F1A0584 for ; Fri, 25 Apr 2014 09:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 w806kDgSFsS0 for ; Fri, 25 Apr 2014 09:43:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A3B161A0268 for ; Fri, 25 Apr 2014 09:43:54 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LnxgW-1X6CIF446q-00gMfj; Fri, 25 Apr 2014 11:35:34 -0400 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_BEFFD648-025C-4D20-A560-7C3198036AA2" Date: Fri, 25 Apr 2014 18:35:30 +0300 Message-Id: To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:E2zHRPiLODkEu6IsjcJe3mg+5G9HBuYYgj3pAD8CUop y/2p0J37VcOOQovdiXx8GRXRSygmCAsynSf0eYTvnD5qHAs7BT 3KKabXtkVgDw9RL/niNdnyaaLstmp1LNmE8h+UNMDBu4n+23D+ A38Rg8p6LAONXVLRlxANWnN2eCGjan6vzAzlmKtP3zD3tu92Aj UI76NRwInWYgdA5lOpIpFM4pfJGh0kIFJnw6R9feKgWU83wkiE YGbC48HPnzfnSkdUaYEs/N5jdyfn23/k1OdiFVzHpQsJFfqjhd SQhtrT0ackPPIjPDLjqEDZ/P28AmktdLu2WGMqEGzpg2QFRQgD TIk3TR4ubbyTSMxHjHSRHOz9z9kJWoFAGx9ATl8auWoT/BuMRI +g3r9NQ/xox7g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/t4wgBep9XV6erb9PwkE7-Q7MQjg Subject: [DMM] Next-Generation Mobility Protocols and Architectures, Call #4 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:43:57 -0000 --Apple-Mail=_BEFFD648-025C-4D20-A560-7C3198036AA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, Charlie will be giving a talk: "Wireless handovers: relative importance = of various technologies" There are two candidate dates. Please register your availability on the = following doodle, before the end of next Monday (April 28). http://doodle.com/atpvfek9b2zf5b82 =20 Cheers, Alper --Apple-Mail=_BEFFD648-025C-4D20-A560-7C3198036AA2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Folks,

Charlie will be giving a talk: "Wireless handovers: relative importance of various technologies"

There are two candidate dates. Please register your availability on the following doodle, before the end of next Monday (April 28).

 

Cheers,

Alper




--Apple-Mail=_BEFFD648-025C-4D20-A560-7C3198036AA2-- From nobody Tue Apr 29 04:47:03 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C731A0850 for ; Tue, 29 Apr 2014 04:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 M-smmFBPaB3T for ; Tue, 29 Apr 2014 04:46:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB3A1A0840 for ; Tue, 29 Apr 2014 04:46:58 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MGj4T-1WjFE71hpp-00ED0B; Tue, 29 Apr 2014 07:46:56 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_47AA6767-E818-49F4-9231-FEA5B91E16E0" From: Alper Yegin X-Priority: 3 X-Mail-Calendar-Part: Yes Date: Tue, 29 Apr 2014 14:46:53 +0300 Message-Id: References: <416053726.1069491398771869203.JavaMail.nobody@rln9rmd101.webex.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:W3jFbeR4EBAA7H3Fkr0Ny5hea0VtQ9rcrx7alfb2mB9 62q43buOD2zRD223ZU/joNabqNrK0Dq2gfy6mC/LCHxiYeb4y2 aUN2wT0UxOw//fpFq6gxRIr2QLRILOofYUBUYJfg3fhQXkUzvX 3bZHsdm5rY1grG0qLq44KIRu74dRt7B8fcjRxtZHv2MzaEsvwM MHMi1+IXf6UrHQlZUjehY8RQZAoX2iovtMrtC3jFGMreDx7F5S Dpv/jnsB+jNuFOTa7+AF9nB1Emx2MfUyywElJPnW+oP3Bv/WzB aM9JC46u8mzel/NHNU3W8jBdjXGf+7cGsWQAt5YlIR8ZpHtQI2 NcESkTMruIkgNVj5y+rjGBTIwotbdP2G4d+KrQSjl2HQLIEwub QztVsGiQgEXzQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/mSyr9usPVBOQHAeVHkByck9sNok Subject: [DMM] Fwd: Invitation to WebEx meeting: Next-Generation Mobility Protocols and Architectures, Call #4 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 11:47:01 -0000 --Apple-Mail=_47AA6767-E818-49F4-9231-FEA5B91E16E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Folks, Please see below for the details of the upcoming Next-Generation = Mobility Protocols and Architectures call. Cheers, Alper Begin forwarded message: >=20 >=20 >=20 > Hi, > =09 > =20 > Alper Yegin is inviting you to this WebEx meeting: > =09 > Next-Generation Mobility Protocols and Architectures, Call #4=20 > Mon, May 5, 5:00 pm | 1 hr 30 min > Istanbul (Eastern Europe Summer Time, GMT+03:00) > Host: Alper Yegin > =09 > Join > =09 > =20 > Add the attached iCalendar (.ics) file to your calendar. > =09 > Agenda >=20 > Charlie Perkins presenting "Wireless handovers: relative importance of = various technologies" > =09 > Access Information >=20 > Where: WebEx Online > Meeting number: 236 359 345 > Password: This meeting does not require a password. > =09 > Audio Connection >=20 > +44-203-478-5289 UK Domestic Toll > Access code: 236 359 345 > Can't access your meeting? Get help. > Delivering the power of collaboration > Cisco WebEx Team >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. By joining this meeting, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation. >=20 > =A92013 Cisco and/or its affiliates. All rights reserved. > MT-A-001 >=20 --Apple-Mail=_47AA6767-E818-49F4-9231-FEA5B91E16E0 Content-Type: multipart/mixed; boundary="Apple-Mail=_5AFDACB8-2355-4D2A-B2C4-15E9185E6E71" --Apple-Mail=_5AFDACB8-2355-4D2A-B2C4-15E9185E6E71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


= 3D"Cisco
=
=
Hi,
3D""
 
Alper Yegin is inviting you to this WebEx meeting:
3D""   
Next-Generation Mobility Protocols and Architectures, = Call #4
Mon, May 5, 5:00 pm | 1 hr 30 = min
Host: = Alper Yegin
  
3D""
 
3D""  

Agenda

= Charlie Perkins presenting "Wireless handovers: r= elative importance of various technologies"
3D""  

Access Information

Where:  WebEx Online
Meeting = number:  236 359 345
Password:  This meeting does not require a = password.
3D""  

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 236 359 345

Can't access your = meeting? Get = help.
= = = = = = = = =
=
= Delivering the power of collaboration
= Cisco WebEx Team =
=
= =
3D"Footer"
=20
IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation.
=20

=A92013 Cisco = and/or its affiliates. All rights reserved.
MT-A-001
= 3D"Cisco"
= --Apple-Mail=_5AFDACB8-2355-4D2A-B2C4-15E9185E6E71 Content-Disposition: attachment; filename*0="Next-Generation Mobility Protocols and Architectures, Call _4.ic"; filename*1=s Content-Type: text/calendar; name="Next-Generation Mobility Protocols and Architectures, Call _4.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2012.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0A=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Europe=0ABEGIN:STANDARD=0ADTSTART:20001029T040000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10;BYHOUR=3D4=0A= TZOFFSETFROM:+0300=0ATZOFFSETTO:+0200=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20000326T030000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3;BYHOUR=3D3=0A= TZOFFSETFROM:+0200=0ATZOFFSETTO:+0300=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0A=0ABEGIN:VEVENT=0ACLASS:PUBLIC=0A= UID:M3BYQGE1FSOI2GB5LUVCRWJ5QQ-1KJ9=0ADTSTAMP:20140429T114429Z=0A= SUMMARY:Next-Generation=20Mobility=20Protocols=20and=20Architectures,=20= Call=20#4=0ALOCATION:WebEx=20Online=0APRIORITY:5=0ASEQUENCE:1057605770=0A= TRANSP:OPAQUE=0A=0AORGANIZER;CN=3D"Alper=20Yegin=20via=20Cisco=20= WebEx":MAILTO:alper_yegin@hotmail.com=0A= ATTENDEE;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:MAILTO= :alper.yegin@yegin.org=0A=0ADTSTART;TZID=3D"Eastern=20= Europe":20140505T170000=0ADTEND;TZID=3D"Eastern=20= Europe":20140505T183000=0A=0ADESCRIPTION:Hi,\n\nAlper=20Yegin=20is=20= inviting=20you=20to=20this=20WebEx=20meeting:\n\nNext-Generation=20= Mobility=20Protocols=20and=20Architectures,=20Call=20#4\nMon,=20May=205,=20= 5:00=20pm=20|=201=20hr=2030=20min\nIstanbul=20(Eastern=20Europe=20Summer=20= Time,=20GMT+03:00)\nHost:=20Alper=20Yegin\n\nWhen=20it's=20time,=20join=20= the=20meeting=20from=20= here:\nhttps://meetings.webex.com/collabs/meetings/join?uuid=3DM3BYQGE1FSO= I2GB5LUVCRWJ5QQ-1KJ9\n\nAgenda\nCharlie=20Perkins=20presenting=20= "Wireless=20handovers:=20relative=20importance=20of=20various=20= technologies"\n\nAccess=20Information\nWhere:=20WebEx=20Online\nMeeting=20= number:=20236=20359=20345\nMeeting=20password:=20This=20meeting=20does=20= not=20require=20a=20password.\n\nAudio=20Connection\n+44-203-478-5289=20= UK=20Domestic=20Toll\nAccess=20code:=20236=20359=20345\n\n\n\n\n\nCan't=20= access=20your=20meeting?=20Get=20= help:\nhttps://meetings.webex.com/collabs/#/support\n\n\nDelivering=20= the=20power=20of=20collaboration\nCisco=20WebEx=20= Team\n\n-----------------------------------------------------------\n\nIMP= ORTANT=20NOTICE:=20This=20WebEx=20service=20includes=20a=20feature=20= that=20allows=20audio=20and=20any=20documents=20and=20other=20materials=20= exchanged=20or=20viewed=20during=20the=20meeting=20to=20be=20recorded.=20= By=20joining=20this=20meeting,=20you=20automatically=20consent=20to=20= such=20recordings.=20If=20you=20do=20not=20consent=20to=20the=20= recording,=20discuss=20your=20concerns=20with=20the=20meeting=20host=20= prior=20to=20the=20start=20of=20the=20recording=20or=20do=20not=20join=20= the=20meeting.=20Please=20note=20that=20any=20such=20recordings=20may=20= be=20subject=20to=20discovery=20in=20the=20event=20of=20= litigation.\n\n=C2=A92013=20Cisco=20and/or=20its=20affiliates.=20All=20= rights=20reserved.\n\nMT-A-001\n=0A=0ABEGIN:VALARM=0AACTION:DISPLAY=0A= DESCRIPTION:REMINDER=0ATRIGGER:-PT900S=0AEND:VALARM=0A=0AEND:VEVENT=0A=0A= END:VCALENDAR=0A= --Apple-Mail=_5AFDACB8-2355-4D2A-B2C4-15E9185E6E71 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_5AFDACB8-2355-4D2A-B2C4-15E9185E6E71-- --Apple-Mail=_47AA6767-E818-49F4-9231-FEA5B91E16E0--